DevOps — это не отдельная роль, а скорее философия или набор практик, принятых внутри компании/команды. Его цель — улучшить коммуникацию и объединить разработку и эксплуатацию общей целью, повысить прозрачность и скорость доставки ценности до клиента.

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

За свой опыт я успел побывать, наверное, во всех вариантах «DevOps»: и как отдельный инженер, жёстко привязанный к команде разработки, и как инженер,
который оказывает «сервисную» услугу всем командам разработки, и как часть продуктовой команды. Всё это время я стремился размыть границы существующих ролей, проводил внутреннее обучение, консультировал лично. И у меня сформировалось
некоторое видение ситуации, которым я хотел бы поделиться.

Как это устроено сейчас

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

DevOps как вещь в себе

Это структура, к которой применимо описание «сисадмины на стероидах». Отдельная организационная единица, в которой находятся инженеры и решают, по большей части, только свои задачи. Для разработки такая структура остаётся «чёрным ящиком», который иногда «выплёвывает» во внешний мир какой-нибудь GitLab pipeline или Helm chart. Да, конечно, к ним можно обратиться за помощью или настройкой чего-либо, но это всё равно не разрушает стену между development и operations. Внутри же этого чёрного ящика можно услышать следующие настроения:

• «Опять этой разработке что-то надо».

• «А давайте отполируем вот это решение, хоть оно и не несёт business value».

• «Давайте переизобретём свой костыль!» (чистейший NIH-синдром).

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

DevOps «привязанный» к команде

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

Здесь DevOps-инженер — это некий Данко или Прометей, который принёс «свет» из своего хаба и теперь пытается вывести команду из тьмы, решая все проблемы, связанные с инфраструктурой, CI/CD, деплоями, мониторингом и т. д.
На бумаге это вполне жизнеспособная схема, но всё ломается о реальность. В реальности всё не так радужно. Сценарий часто развивается следующим образом:
Команда разработки определяет DevOps-инженера как «человека, который чинит пайплайны».
И всё — любые, даже совсем незначительные, проблемы делегируются DevOps-специалисту.
К этому добавляется то, что стандарты и практики, которые «спускаются» из хаба, могут замедлить разработку или вообще противоречить продуктовым целям команды.

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

Что такое "DevOps по учебнику"

Понятно, что никаких "учебников" на самом деле нет.
Есть набор выступлений, научных работ, и книг тех, кто стоял у истоков. Такие книги как:

• "Project Phoenix"

• "Accelerate"

• "SRE Book"

Говорят, что DevOps это не человек, а набор практик и культура.
DevOps — это не роль, а уровень инженерной зрелости команды. В которой преобладают:

• Автоматизация

• Общее владение продуктом. Без разделения ответственности.

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

Почему "DevOps по учебнику" круто?

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

• Скорость. Не нужно ждать DevOps-инженера, если сломался пайплайн или когда нужно выкатить новый сервис или фичу на прод

• Улучшение коммуникации. Все инженеры говорят на одном языке. В следствие чего любые вопросы решаются быстрее.

• DevOps-инженер вовлечен в разработку. Оказывает на неё влияние и заинтересован в достижении продуктовых целей.

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

Какие могут быть сложности в реальности?

• В больших командах нужны стандарты и единообразность. Здесь, стоит рассмотреть такую вещь как "Платформенная инженерия". Об этом я расскажу в другой раз.

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

• Люди хотят делить ответственность.

Как к этому можно прийти

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

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

Используйте кодерские инструменты

Ansible, Terraform, Helm, yaml для CI - это все инструменты, которые мы называем общим словом Infrastructure as Code.
То есть они должны помочь нам привнести практики разработки программного обеспечения внутрь эксплуатации.
И это хорошие и проверенные в продакшене инструменты, однако они далеки от языков общего назначения, к которым привыкла разработка.
Такие вещи как циклы, условия, модульность, наследование или композиция в этих инструментах, выглядят странно с точки зрения разработчика.

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

Для многих общепринятных IaC-инструментов можно найти более "программистский" аналог.
Например:

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

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

Гайды "for Developers"

Организуйте процесс ввода любого разработчика в те технологии, которые вы используете.
С этим могут помочь внутренние гайды.
Но не нужно строить гайды на теории или оставлять умирать в корпоративном Confluence. Видео, которые объясняют: "Что такое Kubernetes", "Что такое Pod", полно, но я все равно встречаю полное непонимание этого инструмента.

На практике я вывел более оптимальную форму того, как выстроить подачу информации, которую для себя назвал "... for Developers".
Вот какими отличительными чертами обладает такой гайд:

• Минимально необходимое количество теории. Навык разработки, как и навык траблшутинга инфраструктуры, это навыки, которые закрепляются через практику. Мы изучаем новую концепцию, а потом долго играемся в стиле "а что если..", пытаясь решить уже ту задачу, которая интересует лично нас. IT-инженеры, именно так привыкли погружаться в новую для них область. Так почему бы не перенести этот подход в изучение DevOps инструментов? Получается простая схема:

  • Объясняем концепцию/абстракцию.

  • Даем кучу прикладных заданий.

  • Больше теории и то как что-то работает "под капотом" оставляем ссылками. Некоторые чисто инфраструктурные вещи, можно на первых порах выкинуть. Например: "Как обновлять сертификаты в кластере Kubernetes" можно оставить за рамками гайда.

• Возможность вопроизвести локально. Буквально с первого занятия разработчик должен иметь возможность, создать небольшую лабораторию на своем ноутбуке.
  Это подстегивает к экспериментам и позволяет "пощупать" технологию в безопасном режиме.
  Озаботьтесь простой возможностью собрать локальное окружение.
  Например: Подготовьте конфиги для kind, напишите интерактивную инструкцию в чем-то типа Jupyter Notebook, напишите скрипт позволит "Сохранить локальное состояние" или "Сбросить все и создать заново"

• Акцент на то, как это принято у вас в компании. Любое объяснение, можно и нужно подкреплять примерами реальных процессов, которые уже выстроены в компании.
  Например: При рассказе о CI/CD пайплайнах показывайте те практики, которые вы сами применяете. Показывайте примеры job из реальных проектов.
  Это плавно знакомит разработчика с тем, с чем он сможет столкнуться на реальной практике уже через некоторое время.
  Плюс, "боевые" примеры имеют реальную ценность для членов команды, а значит лучше запоминаются!

Brown-bags/Q&A сессии

Данный вид активности, делает DevOps открытым для всех желающих.
Здесь подойдет любой контакт с аудиторией, которой было бы интересно глубже погрузиться в DevOps культуру.
Это могут быть как Q&A сессии, на которых вы отвечаете на любые вопросы о процессах, технологиях, и принимаете обратную связь.
Либо же это могут быть различные workshops или brown-bag сессии, где вы в быстром формате для всех желающих показываете реальную практическую работу с вашей инфраструктурой.

Приведу несколько примеров того, что получалось организовать на моей практике:

• Q&A сессии с разработчиками раз в неделю. Разработка могла заранее формировать интересующие их вопросы или задавать вопросы вживую.

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

• DevOps Demo. Короткие презентации того, что изменилось в нашей команде с точки зрения релизного цикла или инфраструктуры. Почему были внедрены те или иные стандарты.

Парное администрирование

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

Если эта практика такая хорошая, то почему бы не внедрить ее и на уровне задач, связанных с инфраструктурой?

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

Заключение

"DevOps по учебнику" — это не идеал. Но это сильное инженерное взросление команды.
Часто, переход к такой культуре означает борьбу с хаосом. Но начинать можно с малого:

• Объяснять.

• Приглашать к участию.

• Делать вещи более простыми и понятными.

Нас всех объединяет одна цель и DevOps это один из способов к этой цели прийти.

В данной статье намеренно не рассмотрено такое явление как "Платформенная инженерия" или "Внутренняя платформа". О культурной стороне которой я бы хотел поговорить в отдельной статье.