Дмитрий Харламов начинал свою карьеру в DevOps с работы инфраструктурным администратором, а сейчас он релиз-инженер. Дмитрий рассказывает, как устроен CI/CD-пайплайн, можно ли убедить разработчиков в надежности своего решения и как стажировки помогают новичкам устроиться на работу.
Кто такой DevOps-инженер?
Методология DevOps очень объемная, поэтому сотрудники компаний чаще всего специализируются на определенной нише. Я релиз-инженер. Этот специалист следит за правильным размещением и развертыванием кода. Существуют еще платформенные инженеры, которые поднимают кластеры (серверы, объединенные в группу) и разворачивают инфраструктуру, DevSecOps-инженеры, которые следят за безопасностью, и другие.
DevOps-инженер отвечает за использование одноименной методологии в компании. Он разбирается в программировании и инфраструктуре и объединяет эти знания для оптимальной работы бизнеса.
Мы писали, чем занимается DevOps-инженер в этом разборе.
Символ бесконечности — это последовательность этапов, благодаря которой код с компьютера разработчика попадает в продакшн. Для этого специалист должен предусмотреть этапы согласования, проверок, сценарии откатов, простоя и обновлений.
Необходимость в DevOps возникает, когда в компании взаимодействует много команд. Сейчас очень популярны микросервисы, и за каждый из них отвечают разные команды, которые находятся в информационном вакууме. Им нужно релизить свой сервис, но они не всегда успевают узнавать, что изменилось у соседей.
Читайте также: «Я был сисадмином, а стал DevOps-инженером в международной компании»
Проблемы могут возникнуть на этапе интеграционного тестирования, когда нужно проверить, что все сервисы слаженно взаимодействуют друг с другом. Здесь начинается: кто-то говорит, что все работает; кто-то внезапно выясняет новые детали, которые нужно переделать. Когда поджимают сроки, разработчики ищут компромиссы, про которые потом забывают — сервис же работает. Из-за этого появляются костыли, доработки и технический долг. Задача тестировщиков и DevOps-инженеров — отслеживать все эти нюансы и не пропускать в продакшн то, что не доделано.
Чем я занимаюсь
Я настраиваю CI/CD-пайплайны. CI/CD (continuous integration, continuous delivery) — это два основных направления из восьмерки DevOps. С их помощью можно без остановки собирать код и доставлять его до различных стейджей или сред. В CI/CD-пайплайне для непрерывной интеграции кода обычно используют Jenkins (сервер для сборки, тестирования и развертывания ПО) и Git либо GitLab (система управления с Git-репозиториями и сборкой кода).
Continuous Integration
Когда разработчик начинает писать модуль, он забирает из Git-репозитория код или часть кода. В соответствии с задачами он его дописывает, проверяет у себя на компьютере, компилируется ли код, проходит ли локальный набор тестов, и отправляет наработки обратно в репозиторий.
После этого CI-система подхватывает изменения, пытается собрать код с помощью компиляторов (компилятор преобразует код, в программу, состоящую из команд для процессора), создает артефакты. Чтобы его запустить, поднимается база данных, на которую настраивается сервис. Базовый функционал проверяется с помощью unit-тестов (проверка каждой функции по отдельности) — с их помощью мы убеждаемся, что код работает и выполняет свои задачи.
Потом код сливается в тестовую, релизную или мастер-ветку. С помощью всё той же CI-системы запускается интеграционное тестирование: из разных репозиториев поднимаются разные части кода и пытаются друг с другом работать. Так мы проверяем бизнес-логику, что на выходе получается нужный результат. На этом этапе проверяется также безопасность, проходит нагрузочное тестирование. Только после этого создаются финальные артефакты, которые отправятся на продакшн.
Читайте также: «Я был хирургом, потом работал на стройке, а в итоге стал DevOps-инженером»
Continuous Delivery
На этом этапе у нас уже есть готовый, проверенный, работающий набор артефактов, которые нужно доставить до серверов. Если в компании сложная система кластеров, то артефакты нужно разложить по полочкам на нужные серверы, правильно настроить маршрутизацию сети. Для доставки кода также используют Jenkins или GitLab. Для работы с Windows есть и дополнительные сервисы, например Octopus Deploy.
Как устроена работа DevOps-инженера?
Мы работаем по SCRUM — это цикл работы команды. Во время двухнедельного спринта (фиксированное время) между разработчиками распределяются задачи, они оценивают время на их выполнение, а через две недели все подводят итоги, собирают релиз из выполненных задач. После начинается ретроспектива: насколько точно мы попали в поставленные сроки, как хорошо справились, где возникли проблемы.
По SCRUM часто работают стартапы, потому что им необходимо выдавать результат как можно чаще. В таких проектах DevOps-инженер один, потому что ресурсов на большую команду зачастую не хватает. Вначале он создает инфраструктуру, настраивает первоначальный Git-репозиторий и CI-систему для сборки кода. Он прорабатывает, как изменения разработчика будут доходить до первоначальных тестирований на серверах. Иногда DevOps-инженера привлекают к решению споров и проработке архитектуры, но это зависит от авторитета специалиста внутри команды.
Перед DevOps-инженером также стоят задачи по мониторингу и поддержке сервисов, чтобы они работали и не ломались. Для этого надо обновлять серверы, следить за их безопасностью, предоставлять инструменты для команды. Разработчикам необходима централизованная система логирования приложения, чтобы они не тратили время на ручную сборку логов или метрик для отслеживания растущей нагрузки или проверки узких мест.
Так как у всех в команде разный уровень знаний, DevOps помогает стандартизировать все подходы. Кто-то из разработчиков умеет писать Docker-файлы (документ с образами, на основе которых создаются контейнеры), кто-то — нет. Кто-то пишет их специфически — значит, его надо поправить, предупредить, что необходим определенный формат логов и нельзя открывать порты, потому что это небезопасно.
Сейчас редко встречаются операционные команды — за поддержку отвечают администраторы облачных провайдеров. Например, при работе с Amazon, если происходит проблема с платформой, мы создаем задачу, и администраторы Amazon решают ее у себя.
Как исследования помогают справиться с рутиной?
DevOps-инженер всегда изучает новые инструменты, которые появляются на рынке. Мы обязательно запускаем пилотные проекты, чтобы понять, как инструмент поведет себя в нашей инфраструктуре. Если он не просто популярный, но еще и полезный и у него нормальная поддержка, тогда мы переходим на него.
Бывало, приходилось откатываться даже с классными инструментами. Например, он может быть несовместим с последующими решениями и в процессе эксплуатации все портит: приходится делать двойную конвертацию данных, потому что у нас другой формат или нам дорого.
Совет: Если что-то может пойти не так — оно обязательно пойдет. Поэтому лучше всегда иметь план Б и проверять все заранее, симулировать на соседнем стенде, а не на продакшене. Это убережет от репутационных потерь и лишних стрессов.
Использование новых инструментов или новых подходов — всегда самая увлекательная часть работы. Рутина никому не интересна, а ежедневные задачи — один из самых быстрых способов выгорания. Даже когда я был лидом, у нас было негласное правило: раз в квартал давать человеку исследовать новую технологию и проверять концепции, это очень мотивирует.
Компании тоже должны поощрять специалистов развиваться. В одно время появился Kubernetes, который позиционировался как решение всех проблем. Это инструмент для оркестрации Docker-контейнеров, который позволяет автоматизировать большую часть их жизненного цикла. С ним можно не переживать, что серверы закончатся, нужно докупать железо и ждать, пока его установят. Если усиливается нагрузка, то автоматически закупаются облачные серверы. Как только нагрузка падает, серверы уходят. Компания платит по факту за использование ресурсов.
В тот период мне как раз хотелось развития, и я загорелся идеей Kubernetes. Я предложил съездить на интенсив по нему, а компания меня в этом поддержала. После этого я попробовал развернуть ПО на работе: проверил концепцию, кластеры Kubernetes, завел туда часть наших сервисов. Всем понравилось решение, и мы взяли вектор на миграцию.
Совет: Не стоит скептически относиться к предложениям. Невозможно знать всё, а у коллеги может быть положительный опыт в сфере, которым он хочет поделиться. Нужно понять его доводы, боли, конструктивно выстроить диалог и через призму его опыта разобрать проблему. Тогда проще найти консенсус.
Сами по себе инструменты тоже необходимо обновлять, так как у них есть жизненный цикл. Постоянно появляются новые фичи, старые удаляются, обновляются безопасность, удобство. Например, если долго не обновлять базу данных, в какой-то момент ее больше нельзя будет обновить, если пропустить одну-две версии поэтапного обновления.
Зачем нужен DevOps-инженер?
Идеальный вариант — когда в команде нет DevOps-инженера. Он стремится к автоматизации всех процессов, хотя на самом деле это недостижимо. Поэтому DevOps-инженер делает так, чтобы продукт обновлялся и продолжал жить долгое время без какого-либо вмешательства, даже если специалист уйдет из компании.
Тимлидом в этой сфере быть сложнее. Это наполовину менеджерская позиция: надо следить за KPI, эффективностью, доступностью сред разработки, надежностью продакшен-сред. Сейчас у меня нет менеджерских обязанностей, но коммуникация — это 50 процентов работы DevOps-инженера. Нужно искать подходы, компромиссы, мотивировать и уговаривать людей. Иногда нужно бороться с явным саботажем, потому что люди не любят меняться, их нужно убедить принять твои решения, которые пойдут на пользу бизнесу.
В начале карьеры это особенно тяжело, потому что тебе не хватает экспертизы или житейского опыта. Приходится воевать с молодыми амбициозными ребятами, спорить, лавировать между командами. Мне доводилось устраивать соревнования: использовать статический анализатор кода, чтобы следить за количеством багов у разных команд. Для этого нужно тонко чувствовать настроения и уметь этично выстроить коммуникацию, чтобы никого не обидеть и не перегнуть палку, возможно, где-то даже перевести соревнование в шутку.
Как стать DevOps-инженером?
В DevOps сложно зайти с нуля, несмотря на то что сейчас порог вхождения намного ниже. Есть два пути вхождения: из разработчиков и системных администраторов. Я начал карьеру DevOps-инженера после восьми лет работы инфраструктурным администратором.
Однако сейчас существует много стажировок, например в Яндексе или VK. Однажды я был ментором на стажировке у троих студентов и даже сисадмина из Новой Зеландии. Новички жадно впитывают информацию и уже через полгода готовы подхватить ежедневную рутину, чтобы разгрузить мидлов и синьоров. Если компания готова выращивать начинающих, то она может взять даже неопытных джуниоров. Именно так мы и поступили: трое ребят остались в компании на позиции DevOps-инженера.
Про то, как начинающим DevOps-инженерам попасть на стажировку, мы писали в этой статье.
Что нужно знать?
От начинающего специалиста обычно требуется настраивать автоматическую сборку и сохранение артефактов.
- Ядро инструментов для этих задач — это CI/CD-системы, мониторинговые программы, которые позволяют собирать логи или метрики.
- Базы данных: SQL, NoSQL (MongoDB, Redis, PostgreSQL).
- Инструменты оркестрации (Ansible, Terraform, Kubernetes, Docker).
- Знать архитектуру Windows, Linux. Если в компании работают с мобильными приложениями, то еще и устройство Android и iOS.
- Разбираться в видах тестирования.
- В идеале DevOps-инженер умеет читать языки, на которых работают в компании. Он разбирается, как работать с выводом логов, или умеет подключать библиотеку в язык.
Чтобы стать мидлом, нужно работать в сфере около двух лет, а синьором — 3–5 лет. Для этого нужно не только выполнять поручения, но и уметь самостоятельно предлагать решения. Синьор понимает, куда развивается компания, ищет задачи и знает, какие из них приоритетнее.
Важно учиться делегировать, для меня это был один из самых сложных скиллов. Иногда кажется, что самому быстрее сделать, чем объяснять, а потом еще и контролировать выполнение. Но когда задачи накапливаются, сложно со всем справиться. Сначала ты жертвуешь личным временем, а потом выгораешь.
DevOps — очень энергозатратное направление. Важно сохранять баланс между рациональным использованием ресурсов и своего времени. Не забывать про рутинные задачи, даже если хочется заниматься только исследованиями. От рутины всегда спасает отдых: важно брать отпуск, выходные, ходить в спортзал и выключать телефон на время.
