Хочется один раз подробно изложить это всё, чтобы при очередном “DevOps это не человек” просто кидать уже ссылку.

Контекст

В начале времен были отдельные команды разработчиков и отдельные команды сисадминов.

Разработчики пилили сервис, как-то его поставляли для развертывания на серверах.

А сисадмины как-то следили за работой серверов и собирали развалившиеся RAID-массивы.

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

Бизнесу, к слову, глубоко наплевать, что и почему там упало. Главное и единственное для бизнеса - это не нарушать cash flow!

Не забывайте об этом, особенно, если вы инженер.

А если вы попробуете не просто не нарушать cash flow, а начать извлекать дополнительную прибыль, то вы и вовсе восхитительны 💰

Методология

В какой-то момент умные парни придумали DevOps-методологию.

Это набор тезисов, утверждающих заинтересованность абстрактного сотрудника в успехе бизнеса.

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

Да и, не только инженер. У менеджеров и прочих аналитиков должна быть ровно та же приверженность.

Короче, DevOps - это про преследование бизнес-целей в технически сложной среде.

Ну, и немного, чтобы Development и Operations отделы не разругались.

Такие Разные Вакансии

Итак, DevOps - это набор рекомендаций для инженера, который заинтересован соблюдать интересы бизнеса.

Это, в идеале, бодрый парень, хорошо понимающий, на чем компания зарабатывает и как это не сломать.

Понятно, что на рынке таких инженеров очень ценят.

Однако, если вы откроете типичные предложения для DevOps-инженера, то создаётся впечатление, что это какой-то сугубо технический человек-оркестр:

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

Вообще говоря, это выглядит как “мастер по ремонту - квартиры, частные дома, канализация, трактор, часы, ноутбуки, ветеринария”.

То есть - абсолютная ахинея, всё навалено в одну кучу.

Почему так получается и что с этим делать?

История про пиццерию

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

Скажем, у нас есть компания, делающая доставку пиццы по району. У неё есть сайт и мобильное приложение.

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

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

Компания выкладывает вакансию DevOps-инженера.

Его находят, проходит год, всё работает довольно надежно.

Но тут на райное появляется ещё одна пиццерия! Она выкатывает новые фишечки, и первая вынуждена с ней конкурировать.

Теперь первая пиццерия готова не упарываться в надежность, а искать баланс между скоростью поставки фич и доступностью системы.

Для этого нужен инженер, который наладит CI/CD процесс, ускорит поставку, распараллелит тяжелые тесты.

Компания выкладывает вакансию DevOps-инженера.

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

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

Хочется это всё как-то оптимизировать и автоматизировать. Хочется внедрить внутренние системы, описать процессы и в целом победить бюрократию.

Собирается совет и решается внедрить условный KeyCloak и написать чат-ботов.

Окей, компания выкладывает вакансию DevOps-инженера.

Потом будут и другие вакансии DevOps-инженера: в команду безопасности, в ML, в команду мобильной разработки.

Список можно продолжать. И это реальные примеры.

И что, всё это - DevOps-инженеры? Ну, да.

Разные роли под одной лычкой

Вспомним, что DevOps - это методология.

И вакансия DevOps-инженера это частный случай применения этой методологии (или просто неграмотного употребления термина) в конкретно взятой компании.

Поэтому, если я прохожу собеседование на позицию “DevOps”, то всегда стараюсь на собеседовании понять, какие именно ожидания от этой роли у нанимающей стороны.

  • Какой у вас продукт/сервис?
  • Чем занимается команда?
  • Я буду в этой команде или сбоку?
  • Кто будет мой руководитель?
  • Какие задачи хотим закрыть за испытательный срок?

Всегда проверяйте, что роль соответствует вашему внутреннему балансу новаторство-стабильность, это важно для вашего благополучия 👨‍⚕️

Чаще всего пожелания матчатся в одну из трёх групп, рассмотрим их далее.

DevOps-инженер про бизнес

Это специалист в продуктовой команде, от которого ждут удовлетворения потребностей бизнеса.

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

Тут важно про скорость-фичи-бизнес. А надежность просто купим у коллег или провайдера.

Это тот чувак, который накидал за полчаса lambda-функцию, которая стала что-то рассылать клиентам в тот же вечер 🚀

Бизнесу хорошо, бизнес вырвал пальму первенства у конкурента.

DevOps-инженер про надежность

DevOps-методологии подразумевают обеспечение надежности.

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

Такому специалисту важно про надежность-доступность-мониторинг-алертинг.

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

Бизнесу хорошо, бизнес пережил “черную пятницу” и наплыв трафика.

Нормальные пацаны называют такие роли SRE.

DevOps-инженер про сервис

DevOps-методологии подразумевают всякие внутренние сервисы (self service).

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

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

Это тот чувак, который пилит UI над LDAP, какой-нибудь внутрикорпоративный API или k8s-контроллер, реализующий внутренние договоренности 🧰

Бизнесу хорошо, бизнес экономит человеко-часы и справляется с масштабированием.

Нормальные пацаны называют такие вакансии “Platform-инженер”. Про это явление надо бы написать отдельно.

Прочие AnyOps-инженеры

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

Всегда важно понимать границы своей ответственности, чтобы поставлять качественные решения и не чувствовать себя человеком-отделом 🧑‍🔧

Ну и славно.

Подытожим

  • DevOps - это методология

  • Не вполне правильно писать “DevOps-инженер”, это дань HR-реалиям

  • Один и тот же “DevOps-инженер” в вакансии, может раскрываться в совсем разные роли