DevOps это не должность и не набор инструментов, а способ работы, при котором разработка и эксплуатация отвечают за продукт вместе: от коммита до работающего в проде сервиса. Раньше разработчики «перекидывали релиз через стену» админам, и у каждой стороны были свои цели: одни хотят выпускать чаще, другие хотят, чтобы ничего не ломалось. DevOps убирает эту стену.
CALMS: из чего состоит DevOps
- Culture: общая ответственность, без поиска виноватых (blameless).
- Automation: сборка, тесты, деплой, инфраструктура описаны кодом и запускаются машиной.
- Lean: маленькие партии изменений, убираем ожидания и ручные передачи.
- Measurement: решения принимаются по метрикам, а не по ощущениям.
- Sharing: знания, дашборды и постмортемы открыты всем командам.
Если на собесе спросят «что такое DevOps», назовите эти пять пунктов своими словами и приведите пример из опыта: «раньше выкатка была раз в месяц ночью вручную, после автоматизации стала несколько раз в день».
Метрики DORA
Исследование DORA (DevOps Research and Assessment, сейчас часть Google Cloud) много лет показывает, что эффективность доставки описывают четыре метрики:
| Метрика | Что меряет | Элитные команды |
|---|---|---|
| Deployment frequency | как часто выкатываем в прод | по требованию, много раз в день |
| Lead time for changes | от коммита до прода | меньше дня |
| Change failure rate | доля выкаток, которые ломают прод | низкая |
| Time to restore (failed deployment recovery time) | за сколько чиним после неудачной выкатки | меньше часа |
Первые две метрики про скорость, вторые две про стабильность. Главный вывод исследований: скорость и стабильность не конфликтуют. Команды, которые выкатывают часто маленькими порциями, ломают прод реже и чинят быстрее.
Частая ошибка: считать lead time от создания задачи в трекере. В DORA это время от коммита до прода, то есть про пайплайн и ревью, а не про продуктовое планирование.
DevOps и SRE
SRE (Site Reliability Engineering) придумали в Google как конкретную реализацию идей DevOps: «надёжностью занимаются инженеры, которые пишут код». Ключевые идеи SRE:
- надёжность задаётся числом: SLO и бюджет ошибок;
- рутина (toil) ограничивается, обычно ориентир не больше половины времени, остальное автоматизация;
- постмортемы без поиска виноватых.
На собесе DevOps-инженер чаще отвечает за пайплайны, инфраструктуру и платформу, SRE за надёжность сервиса в проде. В РФ эти вакансии часто смешивают, поэтому полезно знать обе стороны.
Ветвление и релизный цикл
- Git Flow: ветки
develop,release/*,hotfix/*. Подходит для продуктов с редкими версионированными релизами (коробка, мобильные приложения). - GitHub Flow: короткая ветка от
main, пул-реквест, мерж, деплой. - Trunk-based development: все вливают в
mainминимум раз в день, незаконченное прячут за feature flags. DORA связывает его с высокими результатами.
Долгоживущие ветки опасны: чем дольше ветка, тем больнее мерж и тем больше изменений приходит в прод одним куском.
Непрерывная интеграция, доставка, развёртывание
- Continuous Integration: каждый коммит собирается и тестируется автоматически, сломанный
mainчинится первым делом. - Continuous Delivery: любой коммит из
mainможно выкатить в прод одной кнопкой, артефакт готов. - Continuous Deployment: кнопки нет, каждый зелёный коммит уходит в прод сам.
Разница между двумя последними: есть ли ручное решение «выкатываем».
Platform engineering
В крупных компаниях появляются платформенные команды: они делают внутреннюю платформу (шаблоны сервисов, пайплайны, кластеры, наблюдаемость), чтобы продуктовые команды получали всё через самообслуживание, а не через тикет админам. Это развитие DevOps, а не его замена.
Частые ошибки
- Назвать DevOps отделом, которому «кидают задачи на деплой».
- Путать Continuous Delivery и Continuous Deployment.
- Считать, что частые релизы обязательно ухудшают стабильность.
- Мерить успех числом закрытых тикетов вместо метрик доставки.
Что спросят на собесе
- Что такое DevOps своими словами и чем он отличается от «админа с Jenkins».
- Четыре метрики DORA и как их посчитать у себя.
- Чем отличаются Continuous Delivery и Continuous Deployment.
- Trunk-based против Git Flow: что выберете и почему.
- Чем SRE отличается от DevOps-инженера.