Карта DevOps-практик: от проблемы к решению

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

Эта глава — карта курса. Термины здесь нужны как ориентиры; устройство каждой практики разберём дальше.

История изменений и одинаковый запуск

Если команда не может определить, что запущено на сервере, начните с Git, версий и учёта сборок. Git хранит историю файлов, а версия связывает изменение с выпущенным приложением. Сам по себе репозиторий не расскажет о ручной правке на сервере: её тоже нужно зафиксировать.

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

Infrastructure as Code, или IaC, позволяет описывать инфраструктуру в файлах: какие нужны серверы, сети и настройки. Такое изменение можно обсудить до применения и сопоставить с фактическим состоянием.

Проверки и доставка

CI/CD помогает регулярно объединять изменения, проверять их и доставлять в окружения. Pipeline — последовательность автоматизированных заданий: например, проверить код, собрать приложение и выложить готовую сборку.

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

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

Работающий сервис и улучшение процесса

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

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

Эти понятия не взаимозаменяемы. Быстрый выпуск новой версии не доказывает, что пользователи могут успешно оформить заказ.

Люди, договорённости и инструменты

Модель CALMS помогает не сводить DevOps к автоматизации:

Область	Практический вопрос
Culture — культура	Можно ли сообщить о проблеме и попросить помощь без страха?
Automation — автоматизация	Какие повторяемые действия можно выполнять надёжнее?
Lean — сокращение потерь	Где задача ждёт или возвращается на переделку?
Measurement — измерение	По каким данным узнаем, стало ли лучше?
Sharing — обмен знаниями	Сможет ли коллега выполнить работу без её единственного автора?

Это не список обязательных продуктов. Можно использовать знакомые инструменты и улучшать взаимодействие; можно установить много новых систем и оставить прежние очереди.

Как выбрать первое улучшение

Допустим, создание тестового окружения занимает десять минут работы, но заявка ждёт исполнителя два дня. Команда сначала выясняет, какие проверки и согласования действительно нужны. Затем может предложить готовый способ создавать типовое окружение самостоятельно.

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

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

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