Стажёрскую программу в Southbridge мы запустили три с половиной месяца назад, чтобы найти новых коллег и поделиться знаниями и опытом с теми, кому интересно развиваться в DevOps-направлении. За это время на стажировку было принято 54 начинающих инженера, большая часть из них ещё проходит программу. Первый поток завершен, в этом посте делимся итогами и историей Михаила Снеткова, который теперь работает в одной из команд Southbridge.

В первом потоке стажёрской программы участвовало девять специалистов. До конца дошло шесть. Михаил Снетков получил оффер в Southbridge, Александр Зольников — в Слёрм, еще три инженера получили офферы в другие компании во время стажировки.

Про программу стажировки и скиллы

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

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

Какие знания можно получить и проверить во время стажировки:

архитектура Linux и администрирование Linux-серверов;
стек веб-технологий: Nginx, PHP-FPM/Apache, MySQL, Memcached;
технологии контейнеризации;
принципы методологии DevOps;
Git: возможность работать с локальными и удалёнными репозиториями;
администрирование реляционной базы данных MySQL;
работа с Docker;
работа с Kubernetes: настройка и обслуживание отказоустойчивого кластера, работа с сетевой безопасностью;
мониторинг и логирование в Kubernetes: работа с EFK, Prometheus, Loki, Grafana;
построение пайплайнов с Gitlab CI/CD, интеграция с Kubernetes, проверка качества кода;
софт-скиллы: работа в команде, самостоятельное обучение, тайм-менеджмент.

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

— Программированием и администрированием я занимаюсь, можно сказать, всю сознательную жизнь. Несколько лет совмещал учёбу и работу в Сибирском федеральном университете в Красноярске. На должности программиста повидал очень много разных интересных задач: от настройки сетевого принтера в кабинете до сложного кейса обслуживания и доработки системы вещания IPTV на 140 плазменных панелях университетского кампуса. Занимался разработкой и поддержкой сайтов, настройкой и обслуживанием серверов.

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

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

В 2020 году во время локдауна узнал про вечернюю школу Слёрма по Kubernetes. Давно хотел попробовать k8s, поэтому для меня было очень актуально. По вечерам смотрел онлайн-лекции, не пропустил ни одной. Тогда я и обратил внимание на компанию Southbridge, в которой появились курсы Слёрма. После видел открытую вакансию DevOps-инженера в Southbridge, но было страшно, я не решился откликнуться. Весной 2021 прочитал анонс стажировки в Telegram-канале вечерней школы. Я подумал: опытные наставники, большая учебная база, реальные задания — то, что доктор прописал. Ни секунды не сомневался в своём решении подать заявку на стажировку.

Над резюме пришлось покорпеть

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

Сначала изучил лучшие практики и типовые примеры резюме, потом сверстал шаблон с помощью Tailwind CSS, наполнил его, создал приватный репозиторий и настроил CI/CD для сборки готовых PDF из исходников. Получил в ответ на резюме тестовые вопросы, через пару недель после тестирования пришло приглашение встретиться в Zoom. С одной стороны был очень рад, с другой — сильно нервничал и переживал, потому что не верил во всё происходящее. Ещё через полторы недели меня пригласили на стажировку.

Только 10% всей работы видно конечному пользователю, 90% процентов спрятано внутри

Стажировка началась с организационной встречи в Zoom. Нам всё рассказали, разделили на команды по 3-4 человека. Потом было две недели на первое задание. Задание интересное, максимально близкое к жизни и похожее на айсберг: только 10% всей работы видно конечному пользователю и 90% процентов спрятано внутри. ТЗ с одной стороны позволяло делать, «как
считаешь правильным», а с другой — не давало расслабиться. Постоянно хотелось что-нибудь перепроверить, подстраховаться, сделать лучше.

После первого задания было последовательное изучение курсов Слёрма и сертификации по ним. Отдельно хочу рассказать про практикум по Kubernetes. Для меня это был совершенно новый этап, потому что до этого я никогда не работал в команде, обычно решал все задачи в одиночку.

Практикум по Kubernetes — это групповое задание, сначала на учебном стенде из 5 машин нужно развернуть кластер с помощью Kubespray, а потом настроить CI/CD приложения из репозитория на GitLab в этот кластер. Во время практикума мы очень сплотились с ребятами из команды. До этого этапа мы много общались в чате, а на практикуме общались онлайн, решали задачи вместе в Zoom. Четыре дня сидели вечерами часа по три, наверно.

Для нас очень важно было выполнить задания практикума именно командой, чтобы все поняли, что делалось на каждом этапе. Старались уделить внимание обсуждению, разбору решений, искали компромиссы. Даже голосовали за то, как правильнее сделать, если возникали споры. Ближе к концу этапа с практикумом мы уже стали искать компромисс между «сделать очень хорошо и подробно разобрать» и «сделать быстро», потому что всё-таки нам надо было сдать работу вовремя. Такое командное взаимодействие помогло мне прокачать навыки общения, я стал лучше понимать других людей.

Полтора часа отвечал на технические вопросы

Примерно через полтора месяца после начала стажировки меня пригласили на интервью с тремя лидерами команд эксплуатации Southbridge и CTO. Полтора часа отвечал на технические вопросы, потом мы попрощались. Вечером я лег спать, а ночью проснулся и решил проверить чаты (я живу в Красноярске, часовой пояс МСК +4). И тут я увидел сообщение о том, что меня приглашают на работу в команду. И как после такого уснуть!

Через две недели я закончил все свои дела на прошлой работе и начал работать в Southbridge.

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

В первый день была интересная задача. На одном из клиентских сайтов раз в сутки, вечером, веб-сервер Apache 2 прекращал обрабатывать запросы, потому что одномоментно становилось очень много долгих запросов, которые забирали все ресурсы. Такая ситуация длилась полторы минуты, и потом как ни в чём не бывало все возвращалось к норме.

Я стал разбираться, и оказалось, что дело в плагине для сжатия картинок. У сайта 70 региональных поддоменов, запрос несуществующей картинки у плагина порождал 70 запросов к плагинам других поддоменов. И так по кругу полторы минуты, пока Apache 2 не перезапускался. Мы сообщили разработчикам, приложили метрики, логи, воспроизведение проблемы. Они потом исправили ошибку в коде, а я закрыл тикет в нашей системе.

Зачем DevOps-инженеру классическое администрирование

В первое время в команде я выполняю классические задачи администрирования. Постепенно задачи, которую доверяют мне, усложняются. Не за горами переход к DevOps-проектам.

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

Допустим, ты администратор облачных сервисов и считаешь себя DevOps-инженером, при этом не знаешь элементарные вещи. Все будет хорошо до поры до времени. Когда ты столкнешься с какими-то большими проблемами, ты не сможешь решить их, не зная причинно-следственных связей, не понимая, почему так произошло. Можно, конечно, везде мышкой покликать — вдруг заработает. Но это не выход. Ты должен сесть, подумать, разобрать, какие-то факты свести вместе. Такой маленький детектив. Без основ никак.

Или, например, если в облаке используешь какой-то балансировщик, тот же Nginx, он не сильно от классического администрирования отличается. То есть ты так же пишешь для Nginx конфиги, так же его настраиваешь, какие-то параметры подбираешь. Просто теперь это делается не в файле конфигурации, это делается через метки, аннотации в манифестах и так далее. По сути в DevOps-проектах всё те же старые вещи, просто сверху есть какие-то абстракции, которые помогают разделить управление между компонентами.

В будущем я хочу развиваться в сторону облачной инфраструктуры. Если обратиться к концепции про питомцев и стада («Pets vs Cattle»), то питомцы у меня уже есть, хочу «управлять стадами».

Сейчас мы принимаем заявки на новый поток стажёрской программы. Отправить резюме можно на почту job@southbridge.ru.

«Сайт падал на полторы минуты в сутки, но мы уже решили эту проблему». Итоги стажировки и онбординга нового инженера