Метрики и оптимизация CI-CD: DORA, flaky jobs, critical path, стоимость
Зачем это на собесе
Зрелый DevOps измеряет процесс. Спрашивают DORA-метрики и способы ускорения пайплайна.
DORA-метрики
Четыре ключевые метрики эффективности поставки (исследования DORA/Accelerate):
| Метрика | Что измеряет | Elite-уровень |
|---|---|---|
| Deployment Frequency | как часто выкатываем в прод | по запросу, несколько раз в день |
| Lead Time for Changes | время от коммита до прода | менее часа |
| Change Failure Rate | доля релизов, вызвавших сбой/откат | 0–15% |
| Time to Restore (MTTR) | время восстановления после сбоя | менее часа |
| (+) Reliability | выполнение SLO/доступность |
Первые две — скорость, вторые две — стабильность. Лучшие команды высоки по обоим измерениям: скорость и качество не противоречат друг другу.
Как считать:
- Deployment Frequency: число успешных деплоев в прод за период (из GitLab Environments/Deployments API);
- Lead Time: время между первым коммитом (или merge) и деплоем этого коммита;
- Change Failure Rate: деплои с откатом/хотфиксом/инцидентом ÷ все деплои;
- MTTR: от начала инцидента до восстановления (из инцидент-системы).
Инструменты: GitLab DORA/Value Stream Analytics, Grafana + данные CI, Four Keys (Google), Sleuth, LinearB, Datadog. Метрики — для улучшения процесса, а не сравнения людей (закон Гудхарта).
Метрики пайплайна
| Метрика | Цель |
|---|---|
| Длительность пайплайна (p50/p95) | MR-пайплайн ≤ 10 мин |
| Время в очереди (ожидание раннера) | минимальное |
| Success rate / доля красных main | стабильность |
| Flaky rate | < 1–2% |
| MTTR пайплайна (время починки красной сборки) | минуты–часы |
| Стоимость сборки (минуты раннеров) | контроль |
| Cache hit ratio | высокий |
| Частота повторных запусков | индикатор нестабильности |
Как ускорять
Критический путь (critical path) — самая длинная цепочка зависимых заданий; ускорять нужно её, остальное параллельно «бесплатно».
- Измерить: где время (по заданиям, стадиям, очередям); профили пайплайна (GitLab Pipeline Analytics).
- Параллелизм: независимые задания и сервисы;
needs(DAG) вместо ожидания стадий; шардирование тестов (parallel: N). - Кэш: зависимости, слои Docker/BuildKit (внешний кэш в реестре), артефакты сборки; ключи по lock-файлам.
- Запускать только нужное:
rules: changes,nx affected, test impact analysis. - Быстрые проверки — первыми (fail fast): линт → unit → медленные.
- Лёгкие и предустановленные образы раннеров; зеркала пакетов (Nexus), prebuilt builder-образы.
- Мощность раннеров и автоскейлинг; локальные SSD; отдельные пулы под тяжёлые задачи.
- Инкрементальная сборка (Bazel/Gradle build cache,
dotnet buildincremental,turbo). - Отмена устаревших пайплайнов (
interruptible,cancel-in-progress). - Сократить тесты: переписать медленные, мокировать, тестовая пирамида (меньше e2e), параллелизация.
- Не делать лишнего: nightly для тяжёлых проверок, а не на каждый коммит.
Flaky jobs
Нестабильные тесты/задания подрывают доверие.
- обнаружение: история результатов, одинаковый коммит с разным исходом, тесты, падающие с повтором; отчёты flaky-детекторов;
- причины: гонки и асинхронность, зависимость от времени/порядка, общие данные, внешние сервисы, нехватка ресурсов, неполный cleanup;
- меры: изоляция и детерминизм, ожидание условий вместо sleep, моки внешнего мира, фиксированные seed, ретраи только как временная мера с метрикой, карантин с задачей и владельцем, правило «flaky чинится в приоритете».
Стоимость
- учитывать минуты раннеров, хранилище артефактов/кэша, трафик, лицензии;
- оптимизации: кэш, меньше лишних запусков, spot-инстансы для раннеров, TTL артефактов (
expire_in), очистка образов и кэша, правильный размер раннеров, nightly вместо каждого коммита; - отчётность по командам/проектам (FinOps);
- баланс: дешёвый, но медленный пайплайн дороже — из-за времени разработчиков.
Практики улучшения
- владелец пайплайна, дашборд метрик, SLO на CI (например, 95% MR-пайплайнов < 10 мин);
- регулярная ревизия и рефакторинг пайплайнов (шаблоны, компоненты);
- единые шаблоны и стандарты, инструменты локального воспроизведения;
- small batch: маленькие MR — быстрее ревью и меньше рисков;
- trunk-based + feature flags для частых релизов;
- автоматизация отката и проверки после деплоя, блеймлес-постмортемы.
Вопросы с ответами
Назовите четыре метрики DORA.
Частота деплоев, время выполнения изменений (lead time), доля неудачных изменений (change failure rate) и время восстановления (MTTR).
Как ускорить медленный пайплайн?
Измерить критический путь, распараллелить задания и использовать DAG, кэшировать зависимости и слои, запускать только затронутое, выполнять быстрые проверки первыми, оптимизировать раннеры и медленные тесты.
Как бороться с flaky-тестами?
Обнаруживать по статистике, изолировать в карантин с владельцем, устранять причины (время, асинхронность, общие данные, внешние зависимости), а ретраи использовать только как временную меру.