DevOps (от development — разработка и operations — эксплуатация) — это подход к созданию и сопровождению программ, при котором разработка и эксплуатация работают как одна команда с общей целью: часто, небольшими порциями и предсказуемо выпускать изменения и быстро восстанавливать сервис, если что-то сломалось. DevOps держится на трех опорах, которые важно не смешивать: культура (общая ответственность за продукт в проде), практики (непрерывная интеграция и поставка, инфраструктура как код, мониторинг) и инструменты (Git, Docker, Kubernetes, Terraform, Prometheus и другие).
Содержание
Инструменты без культуры DevOps не делают. Ниже — откуда взялся подход, модель CALMS, цикл DevOps, ключевые практики, как измерить результат (с примером на Python) и коротко о том, кто такой DevOps-инженер.
Мини-словарь: что путают с DevOps
- DevOps — подход и культура организации работы. Это не должность, не отдел и не программа.
- DevOps-инженер — роль в команде, которая строит и поддерживает «конвейер» выпуска: сборку, тесты, выкладку, инфраструктуру, мониторинг.
- SRE (Site Reliability Engineering) — инженерная дисциплина надежности, которую сформулировали в Google: цели по доступности (SLO), бюджет ошибок, автоматизация рутины. Часто описывается как одна из конкретных реализаций идей DevOps.
- Платформенная инженерия (platform engineering) — команда строит внутреннюю платформу «самообслуживания», чтобы продуктовые команды выкладывали код сами, не разбираясь в каждом инструменте.
Границы между этими ролями в компаниях размыты, названия вакансий не всегда совпадают с содержанием работы.
Откуда появился DevOps
До DevOps типичная схема выглядела так: разработчики пишут код и «передают через стену» администраторам, те выкладывают его в прод и отвечают за стабильность. Цели противоречили друг другу (быстрее выпускать новое против «ничего не трогать»), релизы шли редко и крупными пачками.
Термин DevOps закрепился в 2009 году: бельгийский инженер Патрик Дебуа провел в Генте первую конференцию DevOpsDays. В том же году на конференции Velocity инженеры Flickr рассказали, как делают больше десяти выкладок в день за счет сотрудничества разработки и эксплуатации. Идеи опирались на Agile и бережливое производство (Lean): небольшие партии работы, быстрая обратная связь, устранение потерь.
CALMS: из чего состоит DevOps
Удобная модель для проверки «есть ли у нас DevOps» — CALMS. Сначала ее формулировали как CAMS (культура, автоматизация, измерения, обмен), позже добавили L — Lean.
| Буква | Что значит | Как выглядит на практике | Признак, что не работает |
|---|---|---|---|
| C — Culture | Общая ответственность за продукт в проде | Разработчики участвуют в разборе инцидентов, разбор без поиска виноватых | «Это проблема админов» |
| A — Automation | Автоматизировать повторяющееся | Сборка, тесты, выкладка и создание серверов — скриптами и конфигами | Релиз по инструкции из 40 ручных шагов |
| L — Lean | Малые партии, меньше ожидания | Небольшие изменения, короткие ветки, частые выкладки | Релиз раз в квартал на сотни изменений |
| M — Measurement | Решения по данным | Метрики выкладок, мониторинг, алерты | О падении узнают от пользователей |
| S — Sharing | Обмен знаниями | Общая документация, открытые разборы, общие инструменты | Знания в голове одного человека |
Модель — упрощение: она не дает готового плана внедрения, а помогает увидеть, какой опоры не хватает.
Цикл DevOps
Цикл часто рисуют знаком бесконечности: левая петля — разработка, правая — эксплуатация, и данные из эксплуатации возвращаются в планирование.
- Plan — планирование: задачи, приоритеты, небольшие порции работы.
- Code — код в системе контроля версий (обычно Git), ревью через merge/pull request.
- Build — автоматическая сборка, например в Docker-образ.
- Test — автотесты и проверки безопасности на каждое изменение.
- Release — артефакт готов к выкладке, версия зафиксирована.
- Deploy — выкладка в прод, часто постепенная (canary, blue-green) с возможностью отката.
- Operate — работа сервиса: масштабирование, конфигурация, инциденты.
- Monitor — метрики, логи, алерты; выводы идут обратно в Plan.
Это не жесткая последовательность этапов: в зрелой команде по кругу одновременно идут десятки мелких изменений.
Ключевые практики DevOps
CI/CD. Под этой аббревиатурой скрываются три разные вещи, и их важно различать:
| Практика | Что автоматизировано | Кто решает о выкладке в прод |
|---|---|---|
| Continuous Integration (непрерывная интеграция) | Каждое изменение сливается в общую ветку, собирается и проходит тесты | Не касается выкладки |
| Continuous Delivery (непрерывная поставка) | Любую прошедшую проверки версию можно выложить в прод одной командой | Человек нажимает кнопку |
| Continuous Deployment (непрерывное развертывание) | Прошедшая проверки версия уходит в прод сама | Пайплайн, без ручного шага |
Инфраструктура как код (IaC). Серверы, сети, базы и права описываются текстовыми файлами в Git, а не настраиваются руками в консоли. Изменение инфраструктуры проходит ревью, как код, и его можно воспроизвести на новом окружении. Например, Terraform или OpenTofu создают облачные ресурсы, Ansible настраивает серверы.
Контейнеры и оркестрация. Приложение с зависимостями упаковывается в образ (Docker), оркестратор (Kubernetes) запускает нужное число копий и выкатывает новые версии постепенно.
Наблюдаемость. Метрики, логи и трассировки плюс алерты по понятным порогам. Цель — узнать о проблеме раньше пользователей и быстро найти причину.
DevSecOps. Безопасность встраивается в конвейер, а не проверяется в конце: сканирование зависимостей и образов, проверка конфигов, секреты в хранилище секретов, а не в репозитории и не в переменных, видных всем. Сам пайплайн — тоже цель атаки: у него есть доступ к проду, поэтому права раннеров и токенов ограничивают минимально необходимыми.
Инструменты DevOps по задачам
Конкретный набор зависит от компании и облака; таблица показывает типичные варианты на 2026 год, а не обязательный список.
| Задача | Примеры инструментов |
|---|---|
| Контроль версий и ревью | Git, GitLab, GitHub |
| CI/CD | GitLab CI, GitHub Actions, Jenkins, Argo CD (GitOps для Kubernetes) |
| Контейнеры | Docker, Podman |
| Оркестрация | Kubernetes, управляемые Kubernetes-сервисы облаков |
| Инфраструктура как код | Terraform, OpenTofu, Ansible |
| Мониторинг и логи | Prometheus, Grafana, Loki, OpenTelemetry |
| Секреты | HashiCorp Vault, секрет-хранилища облаков |
Выбирать стоит от задачи: если команда живет в GitLab, логично начать с GitLab CI. Условия лицензий тоже проверяют: в 2023 году Terraform перешел на лицензию BSL, и сообщество выпустило открытый форк OpenTofu.
Как понять, что DevOps работает: метрики DORA
Исследовательская программа DORA (сейчас в составе Google Cloud) предложила метрики, по которым оценивают процесс выпуска. Классических метрик четыре:
- частота выкладок — как часто изменения попадают в прод;
- время до прода (change lead time) — от коммита до работы в проде;
- доля неудачных выкладок (change fail rate) — сколько выкладок потребовали срочного вмешательства: отката, хотфикса;
- время восстановления (failed deployment recovery time) — за сколько сервис возвращают в строй после неудачной выкладки.
В актуальном руководстве DORA (dora.dev) к ним добавлена пятая — доля внеплановых выкладок (deployment rework rate), сделанных из-за инцидента в проде. Метрики там делятся на две группы: пропускная способность (частота, время до прода и время восстановления) и нестабильность (доля неудачных и внеплановых выкладок). В старых отчетах время восстановления относили к стабильности, поэтому в статьях встречаются обе схемы. Смысл DevOps в том, что при хорошей организации скорость и стабильность улучшаются вместе, а не за счет друг друга. Посчитать их можно по журналу выкладок. Минимальный пример на Python (проверен на Python 3.14.7, 24.09.2026):
from datetime import datetime
from statistics import median
# Журнал выкладок за неделю: когда сделан коммит, когда он попал в прод,
# сломал ли выкладку прод и когда сервис восстановили.
DEPLOYS = [
{"commit": "2026-09-14 10:00", "deploy": "2026-09-14 15:00", "failed": False},
{"commit": "2026-09-15 09:30", "deploy": "2026-09-16 11:30", "failed": True,
"restored": "2026-09-16 12:10"},
{"commit": "2026-09-16 14:00", "deploy": "2026-09-16 17:00", "failed": False},
{"commit": "2026-09-17 11:00", "deploy": "2026-09-18 10:00", "failed": False},
{"commit": "2026-09-18 16:00", "deploy": "2026-09-19 09:00", "failed": True,
"restored": "2026-09-19 11:00"},
]
FMT = "%Y-%m-%d %H:%M"
DAYS = 7
def hours(start, end):
delta = datetime.strptime(end, FMT) - datetime.strptime(start, FMT)
return delta.total_seconds() / 3600
def dora(deploys, days):
if not deploys:
return None # нет выкладок - метрики не определены
lead = [hours(d["commit"], d["deploy"]) for d in deploys]
failed = [d for d in deploys if d["failed"]]
# незакрытый инцидент (нет "restored") в медиану восстановления не попадает
restore = [hours(d["deploy"], d["restored"]) for d in failed if "restored" in d]
return {
"выкладок в день": round(len(deploys) / days, 2),
"время до прода, ч (медиана)": median(lead),
"доля неудачных выкладок, %": round(100 * len(failed) / len(deploys)),
"восстановление, ч (медиана)": round(median(restore), 2) if restore else None,
}
for name, value in dora(DEPLOYS, DAYS).items():
print(f"{name}: {value}")
print(dora([], DAYS))Программа печатает:
выкладок в день: 0.71
время до прода, ч (медиана): 17.0
доля неудачных выкладок, %: 40
восстановление, ч (медиана): 1.33
None
Разбор: пять выкладок за 7 дней дают 0,71 в день; время от коммита до прода — 5, 26, 3, 23 и 17 часов, медиана 17; две выкладки из пяти сломали прод — 40%; восстановление заняло 40 минут и 2 часа, медиана 1,33 часа. Медиану берут вместо среднего, чтобы одна затянувшаяся выкладка не искажала картину.
Ошибка, которую легко допустить: убрать проверку if not deploys и вызвать dora([], 7) для недели без выкладок. Результат — падение отчета:
statistics.StatisticsError: no median for empty data
Исправление — то, что уже есть в коде: при пустом журнале вернуть None («метрики не определены»), а не ноль. Ноль часов до прода выглядел бы как идеальный результат, хотя выкладок не было. Второй злой случай — неудачная выкладка, которую еще не восстановили: у записи нет поля restored, и без условия if "restored" in d отчет падал бы с KeyError: 'restored'. Такая выкладка учитывается в доле неудачных, но в медиану восстановления попадет только после закрытия инцидента.
Граница примера: это учебный расчет на 5 записях. В реальной команде данные берут из системы CI/CD и трекера инцидентов, а «неудачную выкладку» заранее определяют договоренностью (откат, хотфикс, инцидент по SLO). Сравнивать команды только по этим числам нельзя: они показывают тренд одной команды во времени, а не ее «качество».
Кто такой DevOps-инженер — кратко
DevOps-инженер строит и поддерживает то, что позволяет команде работать по DevOps: пайплайны CI/CD, инфраструктуру как код, контейнерные платформы, мониторинг и алерты. Он не заменяет ни разработчиков, ни администраторов: цель роли — чтобы разработчики могли сами безопасно выкладывать свой код, а не ждать, пока кто-то сделает это за них.
От системного администратора роль отличает объект работы (конвейер выпуска и платформа для приложений, а не серверы и рабочие места) и способ работы (код и конфиги в Git вместо ручной настройки). Разделение условное: современный администратор тоже пишет скрипты и использует Ansible, а в небольших компаниях обе роли совмещает один человек. Базу для роли обычно составляют Linux, сети, Git, один скриптовый язык (Python или Bash), Docker, основы Kubernetes и облаков.
Выводы
- DevOps — это подход, где разработка и эксплуатация отвечают за продукт вместе; культура, практики и инструменты — три разных уровня, и инструменты без культуры не работают.
- Модель CALMS (культура, автоматизация, Lean, измерения, обмен) помогает найти, какой опоры не хватает команде.
- Ключевые практики — CI, непрерывная поставка или развертывание, инфраструктура как код, контейнеры, наблюдаемость и встроенная безопасность.
- Результат измеряют метриками DORA: частота выкладок и время до прода (скорость), доля неудачных выкладок и время восстановления (стабильность).
- DevOps-инженер — роль, которая строит конвейер выпуска и платформу, а не отдельный «отдел DevOps».
Где применяется / связь с практикой
Освойте тему на практике
DevOps-практики нужны везде, где продукт обновляется часто. Чтобы перейти от понимания модели к работающему конвейеру — собрать пайплайн, описать инфраструктуру кодом, поднять мониторинг и считать метрики выкладок, — нужна практика на реальных проектах. Ее дает курс DevOps практики и инструменты. Попробовать формат и разобрать отдельные инструменты можно на бесплатных открытых уроках.
FAQ
Можно ли внедрить DevOps без Kubernetes и облака?
Да. Kubernetes и облака — удобные инструменты, но основу составляют практики: автотесты на каждое изменение, выкладка скриптом вместо ручных шагов, конфигурация в Git и мониторинг. Их можно применять и на нескольких обычных серверах.
DevOps и Agile — это одно и то же?
Нет. Agile в первую очередь про то, как команда планирует и разрабатывает продукт короткими итерациями. DevOps продолжает эти идеи на выпуск и эксплуатацию: чтобы сделанное за итерацию быстро и надежно попадало к пользователям.
Нужен ли «отдел DevOps»?
Отдельный отдел, через который проходят все выкладки, легко превращается в ту же «стену» между разработкой и эксплуатацией, только с новым названием. Чаще работают платформенная команда, которая дает инструменты самообслуживания, или DevOps-инженеры внутри продуктовых команд.
