Поздравляем, вы DevOps-инженер. Как найти себя в необъятном мире ИТ

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

Как всё начиналось

У меня есть техническое образование, но после учебы я стал работать не по специальности. Через несколько лет работы «то тут, то там» решил, что все-таки нужно попробовать свои силы в ИТ. Чтобы набраться опыта, я сначала устроился на техническое направление, но не в ИТ-компанию. Это был университет, где я занял позицию младшего инженера, другими словами — эникейщика. Можно сказать, что у меня был классический старт с самых основ. Там я поработал 6 лет и дошел до позиции младшего сисадмина, после чего понял, что пора искать место в ИТ-компании. Хоть это был и полезный опыт, но мне хотелось развиваться дальше как ИТ-специалисту. А здесь уже требовалось понимание коммерческой специфики ИТ, что бюджетная организация из сферы гуманитарного образования дать не могла.

Я составил план по дальнейшему профессиональному развитию. К выбору новой работы подошел тщательно: мне было важно найти стабильную ИТ-компанию с большим количеством направлений, нормальными отзывами от сотрудников и соискателей. Ну и такие нюансы, как, например, удобное расположение, тоже были важны. В итоге со мной связались HR-менеджеры СИГМЫ и предложили должность в техподдержке пользователей. Это была более низкая позиция, чем на предыдущем месте, но я согласился, так как для меня было важно понять всю специфику работы ИТ-компании.

Так я начал свой путь в СИГМЕ. Работая в техподдержке, я общался с сотрудниками самых разных подразделений: это были департаменты заказной разработки, биллинговых решений, системной интеграции, поддержки бизнес-приложений. Постепенно стал лучше понимать, как работает коммерческая ИТ-компания, какие в ней есть команды и направления. Я стремился максимально качественно выполнять свои обязанности и запомниться коллегам, заявки которых выполнял. В силу характера не мог отказать в помощи, всегда был на виду. Параллельно я изучал разные ИТ-направления, чтобы определиться, в каком мне хотелось бы развиваться.

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

Погружение в DevOps

После года работы в техподдержке пользователей я понял, что хочу развиваться в направлении DevOps. В нашем департаменте разработки бизнес-приложений была возможность пойти на позицию младшего DevOps-инженера с полным обучением. Чтобы попасть на это место, я сделал тестовое задание. В этом департаменте разрабатываются приложения, которые позволяют клиентам энергосбытовых компаний оплачивать счета за электроэнергию и другие услуги. И в рамках тестового мне нужно было изучить правила, нюансы, всю техническую составляющую непрерывной компиляция кода в мобильных приложениях вместе с их отправкой в Google store и App store. Я собирал эту информацию и в итоге предоставил её как тестовое задание. В целом получилось неплохо, не идеально, конечно, но мое тестовое приняли и пригласили в департамент уже заниматься этими задачами на практике. Можно сказать, что это не классический DevOps- инженер, а Mobile DevOps — что-то более верхнеуровневое. То есть я работаю именно с мобильными приложениями.

Сложно ли мне было поначалу? ОЧЕНЬ СЛОЖНО. Для меня всё было новое, и объем информации, которую требовалось изучить, был огромен. Первое время мне хотелось уйти, и не просто с этой должности, а из ИТ вообще. Ну там пойти жить в лес, дрова рубить или коров пасти, но иметь дело с чем-то максимально отдаленным от ИТ.

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

Благодаря ментору из моей команды я изучал продукт, CI/CD, Docker, Jenkins, YAML и Postgresql. От разработчиков узнал всё про архитектуру приложения, с которым мы вели работу. Аналитики поделились информацией о user flow и о том, как работать с джирой и конфой. Тестировщики подсказывали, как выявить вафку у сервиса по логам. Девопс, занятый на нашем проекте, помог мне в изучении GitOps-инструментов (ArgoCD, OKD).

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

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

Чем я занимаюсь

Основной моей задачей является автоматизация сборки кода в проекте гита и непрерывная доставка его во внутреннее тестирование сторов. После моего прихода на проект мы вместе с мобильными разработчиками реализовали обновленную версию CI/CD. В ней при пуше в релизную ветку автоматически создавались теги, которые в свою очередь являются именем билда. Также мы автоматизировали нумерацию билдов с учетом имеющихся и правил публикации. Для этого используем ci_pipeline_id=build_number — такой подход оказался удобен тестировщикам и релиз- менеджеру. Ранее для релиз-кандидатов это делалось руками.

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

Одна из моих последних крупных задач по мобильным приложениям — рефакторинг CI и внедрение SSDLC. У нас есть основная ветка кода, которая всегда готова к выкатыванию на прод, есть релизные (текущая разработка), будущие, старые, и все они по каким-то причинам были разные. С помощью гибких правил, глобальных переменных и скриптов условий нам удалось создать единый CI под все ветки. Плюс, мы добавили обновления по информационной безопасности — когда мы с мастер-ветки хотим задеплоить приложение на платформу, оно обязательно должно пройти все итерации сканирования на уязвимости (DAST, скан кодовой базы). Это была большая работа на несколько месяцев. Лучший показатель результата по этой задаче — сразу после сдачи доработки я ушел на три недели в отпуск, и за время моего отсутствия ничего не поломалось 🙂

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

Планы на будущее

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

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

Советы для начинающих айтишников

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

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

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

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

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