В 14 лет тратил ночи на сборку Linux: как я выбрал вместо вуза работу в IT и почему не жалею об этом

Платону 22 года, он работает с клиентскими проектами в команде инженеров Southbridge с октября 2020. Мы побеседовали с ним, и он рассказал, как пришел в администрирование, почему решил не учиться в вузе и зачем начинающим DevOps-инженерам уметь собирать Gentoo Linux. Возможно, его опыт будет интересен начинающим инженерам эксплуатации и DevOps-инженерам. Передаем слово Платону.

Почему я начал работать в 18

Я начал увлекаться IT уже в 5-м классе. Ходил в местный IT-кружок, где учился программированию и базовым вещам администрирования Windows/Linux.

С 14 лет в этом же кружке преподавал на курсах компьютерной грамотности для пожилых людей.

В 15 лет я официально устроился на подработку в IT-отдел компании, где работает мой отец. Получал белую зарплату — $65, с отпусками и больничными. Там я занимался всеми вопросами, связанными с Linux — от парсинга логов прокси, чтобы выяснить, на какие сайты пользователи ходят больше всего, до настройки Moodle и BigBlueButton, потому что штатные администраторы умели настраивать только Windows, а Linux до этого видели только на картинках.

Там же я написал на С# простую программу для автоматизированного опроса характеристик железа компьютеров, которую разливал пользователям через сервер антивируса, но довести ее до продакшена так и не успел. 

В свободное от учебы и работы время, в том числе по ночам и прогуливая уроки, устанавливал разные дистрибутивы Linux и пытался приспособить их для игр и повседневного использования.

Часами зависал в Google в попытках решить очередную проблему с каким-нибудь компонентом ОС, пробовал разные языки программирования, пытался писать текстовые игры просто ради удовольствия.

Gentoo Linux

После окончания 11 классов школы у меня было три варианта: пойти в вуз, устроиться на работу или служить в армии. В армию я не попадал по здоровью, поэтому решил сразу после школы поискать работу. Если бы я не смог быстро найти подходящую, задумался бы о поступлении, баллов по экзаменам мне хватало.

Примерно через неделю после последнего государственного экзамена меня взяли в отдел технической поддержки компании, разрабатывающей ПО под Linux.

После двухнедельного обучения мне выделили наставника, я получил доступы и приступил к работе.

Поначалу я показывал своему ментору все, что писал клиентам, а он комментировал. Постепенно моя внутренняя нейронная сеть обучилась, я переписывался с клиентами и решал вопросы с коллегами уже без подсказок. 

В мои обязанности входило решение возникающих у клиентов проблем с нашим ПО, поверхностная настройка их серверов, консультирование, создание баг-репортов для отдела разработки. Но при каких-то более глубоких проблемах с самим сервером, где требовалось длительное разбирательство (например, если требовалась тонкая настройка сети, или если из-за ручных правок клиента что-то не работало), мы советовали клиенту обратиться к системным администраторам, так как мы фокусировались именно на поддержке разрабатываемого компанией ПО.

В компании я проработал три года, было интересно, со временем перешел на более сложный продукт, брал задачи на тестирование нового функционала у отдела разработки, сам был наставником во время онбординга двух новых сотрудников. В итоге стало понятно, что в этой компании я уперся в потолок, надо двигаться дальше.

Нужно было выбрать, чем заниматься: продолжать развиваться в администрировании или уйти в сторону программирования (процесс разработки ПО изнутри я уже видел).

Выбор пал на администрирование.

Бывшая коллега скинула в один из «админских» чатов нашего города вакансию Southbridge, и я откликнулся.

Проекты в Southbridge

В Southbridge мы занимаемся поддержкой инфраструктуры для клиентских проектов, работаем в командах. Как правило, в команде три инженера, и среди них необязательно кто-то должен быть «главным». Обычно администраторы внутри команды просто распределяют между собой проекты, в которые они будут углубляться больше, чем коллеги, а какие-то организационные вопросы решаются совместным обсуждением.

Командам дается полная свобода на своих проектах при условии, что клиент доволен, и все сделано по внутренним стандартам, чтобы с проектом в случае чего смог справиться дежурный администратор.

Процесс онбординга был еще более плавным, чем в предыдущей компании: мне заранее выдали доступы, чтобы я на выходных поковырялся в системе и почитал базу знаний, а в первый рабочий день сразу приступил к решению простых задач, которые мне выдавал наставник.

Постепенно сложность задач росла, а через несколько недель я и вовсе начал ощущать себя полноценным членом команды, мог уже сам брать задачи и решать их практически самостоятельно.

Мы используем  DevOps-подход и инструменты, внутри компании разрабатываются курсы, которые бесплатны для сотрудников. Адаптироваться к новым методологиям поначалу было сложно, но после нескольких курсов и интенсивов я стал гораздо лучше понимать, что тут вообще происходит, и полностью включился в работу.

У каждого клиента своя архитектура, механизмы работы, разные инструменты использованы. Иногда кажется, что все очень сложно, а когда разберешься, понимаешь, что получил новый опыт. В предыдущей компании я смотрел на ситуацию с точки зрения работы продукта, его внутреннего устройства, разработки, сейчас — с точки зрения инфраструктуры. 

Если у клиента, например, код делает слишком много неоптимальных запросов к MySQL, я указываю на проблему и советую, как можно поправить, чтобы все было хорошо и приложение работало быстрее. Это интересно, мне очень нравится улучшать проекты, участвовать в их развитии.

Опыт в  программировании помогает общаться с разработчиками со стороны клиента

Со стороны клиента мы обычно общаемся с разработчиками: здесь мне помогает и опыт программирования — иногда можно быстро понять, какая проблема есть со стороны кода, или предсказать потенциальные узкие места в проекте.

Как сделать, чтобы коллеги не будили ночью

Время реакции на аварию Southbridge не более 15 минут, у нас есть дневные и ночные дежурные. Бывает, что меня будят ночью, если что-то случается на проектах. А бывает, что в свои дежурства звоню ответственным администраторам я. 

Вообще по каждому проекту ведется документация, и если не хочешь, чтобы тебя будили ночью, надо хорошо ее заполнять, описывать возможные проблемы и методы их решения, хотя бы даже временного, чтобы проект дожил до рабочих часов ответственной за него команды.

Случаются, конечно, разные ситуации. В первые месяцы работы  в одном из проектов мне нужно было переключить проект на резервный сервер, чтобы заменить на продакшене сбойный диск.

Мы согласовали переключение и даунтайм с клиентом, на работы я запланировал полчаса-час. Но так быстро не получилось — все легло.

Было довольно страшно, пришлось поднимать всю свою команду и совместно смотреть, в чем может быть дело. Проблемой оказалась внутренняя особенность проекта, при переключении на резервный сервер сменился IP-адрес базы данных, который был прописан в коде в нескольких местах, я долго не мог их найти из-за недостающего опыта. К счастью, этот простой не был критичным, работы проводились ночью, не в прайм-тайм сайта, прод мы подняли, все остались живы.

Когда упал сервер

Успешных кейсов, где обошлось без даунтайма, конечно, больше. Например, недавно я для одного из высоконагруженных проектов, ответственность за который по большей части лежит на мне, переносил сервера продакшена со старой инфраструктуры на новую, настроенную по нашим стандартам. Компания работает с финансами, и работает круглосуточно — если бы серверы упали, это привело бы к большим убыткам. Из-за этого я сильно нервничал, но все прошло по плану.

Про планы на будущее и DevOps

У нас в компании много опытных инженеров в командах поддержки и есть выделенная проектная команда — они могут создать с нуля практически любую инфраструктуру. Их навыки вдохновляют.

Я планирую развиваться как DevOps-инженер, чтобы уметь так же хорошо работать с инфраструктурой, как они — использовать продвинутые технологии на продвинутом уровне, а может, и разрабатывать собственные решения, которые можно было бы применять в компании и вне ее.

Как стать хорошим инженером и при чем тут Linux

Мне кажется, чтобы стать хорошим инженером, в первую очередь важно быть действительно заинтересованным в профессии. Скажем так, на первом месте мотивация, потом идет практика, а потом — способность не бояться сложного и непонятного, стремление в этом разобраться.

Мне было интересно администрирование.

Я мог в 14-15 лет вместо компьютерных игр потратить несколько ночей на сборку Gentoo, это всегда казалось увлекательным.

В 16 я впервые попробовал собрать систему по книге Linux From Scratch, этот опыт также был очень полезным и интересным, подобные вещи, по моему мнению, помогают на более глубоком уровне понять, из чего на самом деле состоит система и как она работает, потому что собирать ее нужно вручную из исходных кодов.

Книга Linux From Scratch

Было увлекательно ковыряться, разбирать какой-нибудь пакет, собирать ebuild для Gentoo, читать исходные коды ядра. Я думаю, что человек не может заниматься администрированием, если не способен собрать какой-нибудь абстрактный, считающийся сложным в освоении, дистрибутив вроде Gentoo. То есть сесть, вчитаться в документацию, поковыряться и в итоге собрать из него систему Production Ready, даже если с ней он до этого не работал.

Та же Gentoo, в отличие от CentOS или Ubuntu, устанавливается вручную, тут не прокатит прокликивание «Далее» до конца, потому что в базовой поставке не то что графического (с мышкой и привычным браузером), даже простого текстового установщика нет, и для сборки тебе нужно четко понимать, что именно ты хочешь от системы — какие ПО и флаги для его компиляции тебе нужны, какие модули можно включить в ядро, а какие лучше выбросить.

О себе скажу, что я люблю и использую в работе Arch Linux.

Я считаю, что именно в процессе такой практики, ковырянии в разных дистрибутивах и исходных кодах, можно глубоко разобраться в Linux, а понимание и опыт в совершенно разных вещах — это очень важно для администрирования настоящих, боевых проектов.

Опыт в программировании тоже с большой вероятностью пригодится DevOps-инженеру, так как зная примерно как разрабатывается ПО, можно примерно прикинуть, что в нем может пойти не так при рабочей нагрузке. 

Я часто разрабатываю небольшие личные пет-проекты, пробуя различные актуальные технологии, и когда я вижу у клиента в списке используемых технологий проекта что-то, что я уже использовал сам, становится значительно проще разобраться.