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

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

Сначала ТЗ — потом Kubernetes

Меня зовут Антон Быстров, я ведущий DevOps-инженер Cloud.ru. Когда меня спрашивают, чем занимается DevOps-инженер, часто ждут перечисления технологий: Kubernetes, Terraform, CI/CD. Но в работе инструмент — не отправная точка, а ответ на задачу. Сначала нужно понять, что мы строим, как должна работать система и какие ограничения придется учитывать.

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

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

Возьмем пример из жизни — маркетологи запланировали рекламную кампанию. Но как выдержать рост и не добавить много нулей в счета за ресурсы?

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

В таких задачах недостаточно знать, как развернуть кластер. Нужно собрать требования бизнеса, разработки, эксплуатации и не забыть про надежность. Далее — сравнить риски и расходы, а затем объяснить компромисс людям с разными интересами. 

«Тут работы минут на двадцать»

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

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

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

Такой режим подходит тем, кому интересно проверять гипотезы, искать связи между компонентами и переключаться, когда меняется ситуация. Но важно не путать интерес к расследованию с нормой перерабатывать: история до 21:30 показывает, как легко увлечься задачей, а не задает стандарт рабочего дня.

У кода долгий путь до релиза

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

На схеме все выглядит просто: DevOps-инженер настраивает путь кода от компьютера разработчика до продакшена. Его задача — сделать этот путь таким, чтобы он соответствовал методологии «12 факторов». Но это уже тема для отдельной статьи. Хотя, если коротко, важно вот что:

• код одинаково разворачивается в нужных окружениях;

• проверки запускаются автоматически;

• результат не зависит от человека, который помнит правильную последовательность команд.

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

Поэтому фраза «DevOps ускоряет доставку фичей» описывает цель практики, но не должностную инструкцию конкретного инженера.

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

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

Здесь хорошо виден предмет профессии: DevOps-инженер строит не один сервер, а повторяемый и безопасный процесс доставки изменений. Удачное решение ускоряет несколько команд сразу. 

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

Одна должность — разные задачи

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

А где-то DevOps-инженер может входить в одну продуктовую команду и сопровождать весь путь до прода. Если компания небольшая, то специалист вдобавок занимается эксплуатацией, доступами, дежурствами и инцидентами.

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

Так что зоны ответственности пересекаются: при сбое к расследованию подключаются DevOps-инженеры, разработчики, DBA, эксплуатация или SRE — в зависимости от причины и распределения ролей.

Поэтому перед откликом на вакансию стоит выяснить не только стек, но и специфику работы в конкретной компании:

• за какой результат отвечает DevOps-команда;

• какие окружения и этапы доставки находятся в ее зоне;

• как разделены задачи между DevOps-инженерами, разработчиками, SRE, эксплуатацией и безопасностью;

• сколько в работе проектирования и автоматизации, а сколько поддержки, доступов и другой рутины;

• есть ли дежурства и какую роль DevOps играет при инцидентах.

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

Как начать карьеру в DevOps

Поделюсь своим опытом. Я работаю в ИТ с 2008 года. Начинал как сисадмин, затем думал «уйти из айти», пока все, наоборот, хотели войти. В DevOps пришел постепенно — стал глубже заниматься автоматизацией и доставкой изменений. 

Но вот мой совет: ждать, пока вы узнаете обо всей инфраструктуре все, не нужно.

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

• разверните приложение в тестовом окружении;

• настройте автоматическую сборку, тесты и проверки;

• опишите инфраструктуру как код;

• продумайте откат, падение компонентов и восстановление системы;

• запишите принятые решения и ограничения в документации.

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

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

Но важнее проверить не готовность бесконечно собирать сертификаты, а интерес к самому процессу. Нравится ли вам видеть систему целиком, распутывать неизвестное и договариваться с людьми, которые хотят от нее разного? Если да, DevOps стоит попробовать. 

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

А какой вы представляли свою профессию до начала работы и что оказалось совсем не так? Или вы только хотите к нам в клуб и пока что только строите представление о специальности? Расскажите в комментариях.