Что такое DevOps: откуда взялся подход и какие проблемы решает

Lesson from the course “Курс подготовки DevOps-инженеров”

Хронометраж: занятие 60 минут — теория 30 минут, практика 30 минут. Домашняя работа: 1–2 часа.

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

1. Что изучаем

После урока вы сможете:

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

2. Зачем это нужно и где применяется

Это не «вводная про историю, которую можно пролистать». Дальше весь курс — инструменты: Linux, сети, контейнеры, CI/CD, Kubernetes. Инструменты легко выучить и так же легко применить не туда. Неудачные внедрения выглядят одинаково: компания поставила Kubernetes и наняла «DevOps-инженера», а релизы как выходили раз в месяц по ночам, так и выходят — просто теперь ночью падает ещё и кластер.

Понимание, зачем всё это, нужно вам в трёх ситуациях:

На собеседовании. Вопрос «что такое DevOps» задают почти всегда. Ответ «это Docker, Jenkins и Kubernetes» отсеивает кандидата на месте: он показывает, что человек видел инструменты, но не видел задачу.
При выборе решения. Когда вы решаете, нужен ли здесь Kubernetes или хватит трёх серверов с systemd, критерий — не мода, а то, сокращает ли это путь изменения до продакшена и сколько стоит эксплуатация.
Когда вас просят «внедрить DevOps». Это просьба поменять процесс, а не поставить программу. Если не разобраться, что именно болит, вы автоматизируете существующий беспорядок и сделаете его быстрее.

3. Теория (30 минут)

3.1. Конфликт, из которого всё выросло

Возьмём типичную компанию середины 2000-х. Есть отдел разработки и отдел эксплуатации, у каждого свои цели.

Разработку оценивают по выпущенной функциональности: сколько задач сделано, успели ли к сроку. Чем больше изменений уехало в продакшен, тем лучше выполнена работа.

Эксплуатацию оценивают по стабильности: сколько было простоев, как быстро чинили. А главный источник аварий — изменения. Система, в которую ничего не выкатывают, не падает.

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

Как это выглядит на практике:

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

Обратите внимание: в этом списке нет ни одной проблемы, которая решается покупкой инструмента. Все они про то, как устроен поток изменений.

3.2. Откуда взялось название

Два события 2009 года.

В июне 2009 на конференции O'Reilly Velocity Джон Оллспоу и Пол Хэммонд из Flickr сделали доклад «10+ Deploys per Day: Dev and Ops Cooperation at Flickr». Их тезис по тем временам звучал вызывающе: выкатывать десять раз в день безопаснее, чем раз в квартал. Не потому, что они смелее, а потому что маленькое изменение проще проверить, проще понять и проще откатить. И для этого разработка и эксплуатация должны работать как одна система, а не через заявки.

В октябре 2009 бельгийский инженер Патрик Дебуа, который не смог попасть на Velocity и смотрел доклад в записи, провёл в Генте свою конференцию — DevOpsDays. Название он получил, сократив «agile system administration» до того, что помещается в хештег: #DevOps. Так термин и закрепился — фактически из-за ограничения длины сообщения в Twitter, а не из-за продуманной методологии.

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

3.3. Почему это стало возможно именно тогда

Разумный вопрос: проблема существовала и в 1999 году, почему подход появился только в конце 2000-х? Потому что к этому моменту сложились технические предпосылки. Раньше многие практики были физически неосуществимы.

Серверы перестали быть штучным товаром. Пока сервер — это железная коробка, которую закупают три месяца, никакая «одинаковая тестовая среда» невозможна: тестовый стенд собирают из того, что осталось. Виртуализация, а затем публичные облака это изменили: Amazon EC2 открылся в ограниченной публичной бете 25 августа 2006 года. Машина стала одноразовым ресурсом, который можно создать под задачу и удалить после.

Конфигурацию научились описывать кодом. Puppet появился в 2005 году, Chef — в 2009-м. До них настройки сервера жили в голове администратора и в файле с инструкцией, которая устаревала в момент написания. С этого момента настройку можно положить в репозиторий, отревьюить и применить повторно.

Распределённые системы контроля версий стали массовыми. Первый коммит в Git сделан 7 апреля 2005 года, версия 1.0 вышла 21 декабря 2005-го. Дешёвое ветвление и слияние сделали реалистичной работу небольшими изменениями с частой интеграцией — до этого ветка была дорогой операцией, и её старались не заводить.

Появились доступные серверы сборки. Hudson (из которого в 2011 году форкнулся Jenkins) впервые вышел в феврале 2005 года. Автоматический прогон тестов на каждое изменение перестал быть привилегией крупных компаний с собственной инфраструктурой.

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

3.4. Что именно предлагается менять

Если убрать маркетинг, останется пять вещей.

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

Маленькие частые изменения вместо больших редких. Это контринтуитивно: кажется, что чем реже трогаем продакшен, тем безопаснее. На деле наоборот. Изменение на десять строк проверяется за минуты, а если сломалось — понятно, что откатывать. Квартальный релиз на сто задач нельзя ни проверить целиком, ни откатить частично. Риск не исчезает от редких релизов, он накапливается.

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

Обратная связь из продакшена. Нельзя управлять тем, чего не видишь. Метрики, логи, трассировки и алерты нужны для того, чтобы о проблеме узнавали не от пользователя в поддержке. Отдельный признак зрелости — знать не только «упало или нет», но и «стало ли хуже после вчерашнего релиза».

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

Эти пункты иногда сворачивают в аббревиатуру CALMS: Culture, Automation, Lean, Measurement, Sharing. История у неё такая же неформальная, как у самого термина: Дэймон Эдвардс и Джон Уиллис после DevOpsDays в Маунтин-Вью в 2010 году предложили CAMS, позже Джез Хамбл добавил букву L — Lean. Как чек-лист для самопроверки удобно, как строгую модель воспринимать не стоит.

3.5. Как понять, что подход работает

Ощущения «стало лучше» недостаточно. Исследовательская программа DORA (изначально аббревиатура от DevOps Research and Assessment; с 2025 года название используется само по себе) с 2014 года измеряет процесс доставки количественно. Началось всё с четырёх ключевых показателей:

частота развёртывания — как часто изменения попадают в продакшен;
время от коммита до продакшена (lead time for changes);
доля неудачных изменений — какая часть выкатов приводит к сбою;
время восстановления после сбоя.

Набор с тех лет уточнялся: в 2023 году «время восстановления» переопределили как время восстановления после неудачного развёртывания, а в 2024-м добавили пятый показатель. Актуальный состав и способы считать метрики на своих данных — в уроке 01.04; здесь нужен только вывод.

А вывод такой: скорость и надёжность не противопоставлены. Команды, которые катят часто, обычно восстанавливаются быстрее — потому что научились катить маленькими порциями и откатываться. Это ровно тот тезис, который в 2009 году защищали Оллспоу и Хэммонд.

3.6. Чем DevOps не является

Это не набор инструментов. Можно поставить Kubernetes, Jenkins и Prometheus и остаться с квартальными релизами, которые согласуются в почте. И наоборот: команда с одним сервером, systemd и парой скриптов может катить по десять раз в день безопасно. Инструменты помогают, но менять надо процесс.

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

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

Это не «катить как можно чаще любой ценой». Частота — следствие, а не цель. Если увеличить число выкатов, не построив тесты, мониторинг и откат, вы получите просто больше аварий. Порядок обратный: сначала возможность безопасно выкатывать, потом частота.

3.7. Примеры и варианты реализации

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

Среда	Как решается	Что нужно иметь
Локальный стенд (Docker / VM / kind)	`docker compose build && docker compose up -d`, проверка вручную	Docker и терминал
VPS / bare-metal	Сборка образа в CI, доставка на сервер, перезапуск сервиса, проверка health-эндпоинта	Сервер, доступ по SSH, реестр образов
Yandex Cloud	Пайплайн собирает образ и обновляет managed-сервис или Kubernetes, балансировщик переключает трафик	Аккаунт в облаке, настроенные права, деньги на счету

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

VPS / bare-metal. Появляется всё, что в реальности отнимает время: доступы, фаервол, TLS-сертификаты, логи на диске, который кончился. Каждый шаг делается руками, поэтому именно здесь становится понятно, за что вы платите облаку. Это самый полезный стенд для понимания основ и самый трудоёмкий.

Yandex Cloud. Часть работы берёт на себя провайдер: балансировщик, резервное копирование базы, обновление управляемого кластера. Взамен вы получаете чужие ограничения, чужие сроки обновлений и счёт в конце месяца. Здесь важно уметь считать: managed-сервис обычно дороже в деньгах и дешевле в человеко-часах.

Что выбрать. В курсе мы делаем всё три раза не ради повторения. Локальный стенд — чтобы понять механику без затрат. VPS — чтобы увидеть работу, которую облако скрывает. Облако — чтобы уметь работать так, как работает большинство компаний. На собеседовании ценится способность объяснить разницу, а не знание одной кнопки в одной панели.

4. Практика на занятии (30 минут)

Курс проходят самостоятельно, поэтому шаги ниже — пошаговая инструкция: что сделать, зачем, что должно получиться и что делать, если вышло не так. Разбираем путь изменения в чужом публичном проекте с настроенным CI; для примера берём prometheus/prometheus, но подойдёт любой на ваш выбор.

Шаг 1 (5 минут). Найти, чем проверяются изменения.

Что сделать: открыть репозиторий на GitHub → вкладка Actions (либо посмотреть файлы в каталоге .github/workflows/).
Зачем: это и есть «непрерывная интеграция» в действии — набор проверок, которые запускаются на каждое предложенное изменение до того, как оно попадёт в основную ветку.
Ожидаемый результат: список workflow; на pull request запускаются проверки (сборка, тесты, линтеры); у одной-двух видно время прогона в минутах; среди прошлых прогонов попадаются красные.
Если не так: нет вкладки Actions — это не значит, что CI нет. Проект может использовать GitLab CI, Jenkins или внешний сервис; поищите в корне репозитория .gitlab-ci.yml, Jenkinsfile, .circleci/. «Нет Actions» и «нет CI» — разные вещи.

Шаг 2 (5 минут). Найти, что считается артефактом.

Что сделать: открыть вкладку Releases (и, если есть, Packages).
Зачем: артефакт — это то, что реально уезжает пользователям; важно отличать релиз (выпуск версии) от деплоя (выкат на продакшен).
Ожидаемый результат: видно, что выпускает проект — архивы с бинарниками, образы контейнеров или пакеты; у релизов есть версии по правилам semver и описание изменений.
Если не так: вкладка Releases пустая — проект может выпускать только git-теги без оформленных релизов; тогда скрипт из шага 3 честно скажет, что релизов не нашёл (см. ниже).

Шаг 3 (10 минут). Посчитать частоту выпуска.

Что ввести: (из корня репозитория курса)

cd blocks/01-intro/examples/01.01-what-is-devops
python3 deploy_frequency.py prometheus/prometheus

Зачем: перевести ощущение «часто/редко» в число. Это грубый прокси метрики «частота развёртывания»: у чужого проекта не видно выкатов на продакшен, но видно выпуски релизов.
Ожидаемый результат: (числа со временем меняются, важен формат)

Загружаю список релизов prometheus/prometheus…
Репозиторий:            prometheus/prometheus
Всего релизов получено: 100 (максимум 100 за запрос)
Первый в выборке:       2024-01-15
Последний в выборке:    2026-09-25

За последние 90 дней: 11 релизов
Это примерно 0.9 релиза в неделю
Медианный интервал между релизами: 7 дн.
Максимальный интервал:             20 дн.
С последнего релиза прошло: 3 дн.

Если не так: GitHub вернул 403 — исчерпан лимит анонимных запросов (60 в час с адреса); подождите час или задайте токен через export GITHUB_TOKEN=…. Репозиторий не найден — проверьте формат аргумента: владелец/репозиторий. Сообщение «релизов не найдено» — нормально: проект выпускает только теги.
Повторите на втором проекте для сравнения: python3 deploy_frequency.py grafana/grafana --days 180.

Шаг 4 (10 минут). Ответить письменно на три вопроса.

Что сделать: записать в конспект короткие ответы (по 1–2 предложения).
Зачем: цифра без интерпретации бесполезна и опасна — по ней легко сделать неверный вывод.
Вопросы: (а) релиз и деплой — одно и то же, и что из них мы на самом деле посчитали? (б) о чём говорит медианный интервал в 0 дней (несколько релизов за один день)? (в) проект с 0,9 релиза в неделю работает хуже, чем проект с 1,9, — и достаточно ли этих данных, чтобы так сказать?
Ожидаемый результат: у вас записаны три ответа, и главный вывод сформулирован явно — по одной цифре частоты о качестве процесса судить нельзя.
Если не так: если ответы на (а)–(в) получились одинаковыми для любого проекта — вы описываете инструмент (GitHub, релизы), а не процесс; вернитесь к цифрам из шага 3 и привяжите каждый ответ к ним. Если по (в) хочется сказать «да, хуже» — это и есть ошибка, которую ловит вопрос: данных о том, что реально доходит до пользователя, у вас нет.

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

5. Домашняя работа (1–2 часа)

Задание. Составьте карту доставки для двух публичных проектов и сравните их.

Выберите два проекта на GitHub: один крупный и известный, второй — небольшой, но с настроенным CI.
Для каждого заполните шаблон examples/01.01-what-is-devops/delivery-map-template.md: путь изменения, ручные операции, частота выпуска (данные скрипта), узкие места.
Напишите сравнение по шаблону examples/01.01-what-is-devops/comparison-template.md: чей путь от коммита до релиза короче и предсказуемее, за счёт чего и что вы бы поменяли в более слабом первым делом. Текст сравнения — 5–10 предложений.
Сохраните обе карты и сравнение в репозиторий с конспектами (создадим его в уроке 01.05; пока можно держать локально).

Критерии приёмки.

Обе карты заполнены целиком; там, где этапа нет, стоит «нет», а не пустая ячейка.
В каждой карте указана минимум одна ручная операция либо явно обосновано, что снаружи их не видно.
Вывод скрипта deploy_frequency.py вставлен в каждую карту.
Названо минимум два узких места на проект, у каждого написано, чем оно грозит.
В сравнении есть хотя бы одно утверждение о том, чего по публичным данным узнать нельзя.

Файлы для работы: blocks/01-intro/examples/01.01-what-is-devops/ — скрипт deploy_frequency.py, шаблоны delivery-map-template.md и comparison-template.md.

6. Частые ошибки и подводные камни

Считать релизы деплоями. У публичного проекта не видно выкатов на продакшен, поэтому мы смотрим на релизы. Это прокси, а не метрика. Для своего сервиса частоту развёртывания считают по фактическим выкатам.

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

Путать «нет CI» и «CI не на GitHub». Отсутствие вкладки Actions не значит, что проверок нет: проект может использовать GitLab CI, Jenkins или внешний сервис. Прежде чем делать вывод, поищите конфигурационные файлы в корне репозитория.

Ждать, что DevOps «внедрят» за спринт. Меняются процесс и распределение ответственности, а это идёт месяцами. Первым делом обычно чинят не инструменты, а видимость: пока никто не знает, сколько времени изменение идёт до продакшена, спорить об улучшениях бессмысленно.

Читать «10+ deploys per day» как призыв катить чаще всем. Flickr пришёл к этому, построив тесты, мониторинг и возможность быстрого отката. Частота была следствием. Скопировать следствие, не построив причину, — значит получить те же десять выкатов и в десять раз больше инцидентов.

7. Проверка усвоения

Почему конфликт между разработкой и эксплуатацией не решается тем, что обе команды «договорятся»?
Почему маленькие частые изменения считаются менее рискованными, чем редкие большие? Приведите два довода.
Компания поставила Kubernetes и наняла DevOps-инженера, но релизы по-прежнему раз в месяц по ночам. Что именно осталось не сделано?
Чем «DevOps-отдел» противоречит исходной идее подхода — и почему при этом должность «DevOps-инженер» существует на рынке?
Назовите четыре ключевых показателя, с которых начиналась DORA. Какие из них про скорость, а какие — про надёжность?
Вы посчитали, что проект выпускает 0,6 релиза в неделю. Какие выводы из этой цифры делать нельзя?
Что означает медианный интервал между релизами, равный нулю дней?
Почему разбор аварии без поиска виноватых — это вопрос качества данных, а не вежливости?

8. Материалы

Первоисточники:

Velocity 09: John Allspaw, Paul Hammond — «10+ Deploys per Day: Dev and Ops Cooperation at Flickr» — тот самый доклад 2009 года, около часа. Стоит посмотреть, чтобы увидеть, как идею аргументировали до того, как она стала общим местом.
devopsdays.org — сайт конференции, с которой пошло название. Полезен как напоминание, что это сообщество, а не стандарт.

Про метрики и исследования:

dora.dev — материалы исследовательской программы DORA, ежегодные отчёты State of DevOps.
Метрики DORA — актуальное описание того, что и как измеряют. Пригодится к уроку 01.04.

Книги (достаточно одной на выбор, читаются параллельно с курсом):

Джин Ким, Кевин Бер, Джордж Спаффорд. «Проект Феникс» — производственный роман про завод и ИТ-отдел. Читается за пару вечеров, хорошо объясняет, почему проблема организационная, а не техническая.
Николь Форсгрен, Джез Хамбл, Джин Ким. «Accelerate» — исследовательская сторона вопроса: откуда взялись метрики DORA и что именно измеряли.
Google SRE Books — доступны онлайн бесплатно. Соседний взгляд на ту же задачу со стороны инженерии надёжности; вернёмся к ним в блоке 17.

Для контекста:

DevOps Culture (Part 1), IT Revolution — разбор культурной части подхода и модели CALMS.

Блок 01 · Следующий: 01.02. Роли на рынке: DevOps, SRE, платформенный инженер, системный администратор →

Practice materials

Scripts, cheat sheets and starter files for the lesson tasks. The lesson text is on this page.