DEV Community: Anton Streltsov

DevOps как по учебнику. Возможно ли? [RU]

Anton Streltsov — Mon, 23 Jun 2025 20:39:51 +0000

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

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

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

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

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

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

«Опять этой разработке что-то надо».
«А давайте отполируем вот это решение, хоть оно и не несёт business value».
«Давайте переизобретём свой костыль!» (чистейший NIH-синдром — Not Invented Here).

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

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

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

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

В реальности всё не так радужно.
Сценарий часто развивается следующим образом:

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

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

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

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

"Project Phoenix"
"Accelerate"
"SRE Book"

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

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

Почему это круто?

Прозрачность. Инженеры с обоих сторон понимают систему целиком, понимают, что нужно сделать, чтобы провести деплой и какими механизмами он осуществляется
Скорость. Не нужно ждать DevOps-инженера, если сломался пайплайн или когда нужно выкатить новый сервис или фичу на прод
Улучшение коммуникации. Все инженеры говорят на одном языке. В следствие чего любые вопросы решаются быстрее.
DevOps-инженер вовлечен в разработку. Оказывает на неё влияние и заинтересован в достижении продуктовых целей.
DevOps-инженер получает те самые "интересные" задачи. Вместо того, чтобы в сотый раз чинить упавший пайплайн, можно сосредоточиться на настоящей автоматизации и оптимизации процессов

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

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

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

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

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

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

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

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

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

| Цель                                 | Iac-инструмент          | Аналог                                      |
|--------------------------------------+-------------------------+---------------------------------------------|
| Управление облачной и/или bare-metal | Terraform               | Pulumi/SDK облачного провайдера             |
| инфраструктурой.                     |                         |                                             |
|                                      |                         |                                             |
|--------------------------------------+-------------------------+---------------------------------------------|
| Менеджмент Ресурсов k8s              | Helm                    | k8sdk                                       |
|                                      |                         |                                             |
|--------------------------------------+-------------------------+---------------------------------------------|
| Описание CI/CD пайплайнов            | GitlabCI/GitHub Actions | DaggerCI. TeamCity(Kotlin). Jenkins(Groovy) |
|                                      |                         |                                             |
|--------------------------------------+-------------------------+---------------------------------------------|

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

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

Гайды "for Developers"

Организуйте процесс ввода любого разработчика в те технологии, которые вы используете.
С этим могут помочь внутренние гайды.
Но не нужно строить гайды на теории. Видео, которые объясняют: "Что такое 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 это один из способов к этой цели прийти.

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

Дополнение:
В процессе подготовки статьи, мне захотелось поделиться теми ресурсами, которые продвигают DevOps как культуру.

Книги:

Project Phoenix
SRE Book (Site Reliability Engineering. How Google runs production systems)
Operations Anti-Patterns, DevOps Solutions
The DevOps Handbook
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
DevOps Adoption Strategies: Principles, Processes, Tools, and Trends: Embracing DevOps through effective culture, people, and processes

Все книги, кроме последних двух переведены на русский.

Статьи:

Подписывайтесь: https://t.me/itdeploysometimes

Организация IaC: Модули. [RU]

Anton Streltsov — Mon, 23 Jun 2025 20:25:04 +0000

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

Модуль — это проект который описывает конфигурацию каких-либо инфраструктурных компонентов и их связи между собой. Деплоится как единое целое.

В данном посте, я намеренно даю такое общее описание модуля, чтобы его можно было рассматривать в отрыве от реализации (Terraform, Pulumi, Cloud SDK).

Monolith Module

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

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

infra/
├── database.yaml
├── main.yaml
└── vpc.yaml

Application Group Module

Application Group Module — Способ организации кода, когда инфра для всех сервисов команды помещается в один общий модуль.
Если ваше приложение состоит из нескольких микросервисов, и вы управляете их инфраструктурой с помощью одного модуля — у вас Application Group Module.
Если ваша команда разрабатывает несколько приложений, и вы управляете ими как одним целым — у вас Application Group Module.

Иметь Application Group Module привлекательно, потому что позволяет думать, обо всем приложении как о чем-то цельном, плюс, хорошо работает, если вся инфраструктура для приложения находиться в управлении одной команды.
Также, может быть хорошим промежуточным состоянием при "распиле" Монолитных Модулей.

Пример "Application Group Module"

infra/
├── team-a
│   ├── service-1
│   │   ├── db.yaml
│   │   └── main.yaml
│   ├── service-2
│   │   ├── db.yaml
│   │   └── main.yaml
│   └── service-3
│       ├── db.yaml
│       └── main.yaml
└── team-b
    ├── service-1
    │   ├── db.yaml
    │   └── main.yaml
    ├── service-2
    │   ├── db.yaml
    │   └── main.yaml
    └── service-3
        ├── db.yaml
        └── main.yaml

Application Module

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

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

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

Пример "Application Module"

infra/
├── microservice-1
│   ├── db.yaml
│   └── main.yaml
├── microservice-2
│   ├── db.yaml
│   └── main.yaml
├── microservice-3
│   ├── db.yaml
│   └── main.yaml
├── microservice-4
│   ├── db.yaml
│   └── main.yaml
└── microservice-5
    ├── db.yaml
    └── main.yaml

Service Module

Service Module — Способ организации кода, когда каждую сервисную часть для нашего приложения мы оборачиваем в отдельным модуль.
Например:

Отдельный модуль для Базы данных
Отдельный модуль для Application Server
Отдельный модуль для сети
Отдельный модуль для кеша и т.д.

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

Пример "Service Module"

infra/
├── db
│   └── main.yaml
├── ecs
│   └── main.yaml
├── iam
│   └── main.yaml
├── kubernetes
│   └── main.yaml
├── s3
│   └── main.yaml
└── vpc
    └── main.yaml

А как инфраструктурный код устроен у вас?