Скрытая цена красного CI/CD: влияние на DORA метрики и Time to Market
Lead Time for Changes часто тормозит не на коде, а на красных пайплайнах. Как контекст-свитчинг бьёт по DORA, почему ручной триаж логов — это риск для TTM и зачем автоматизировать первый шаг разбора.
Time to Market и DORA metrics обычно обсуждают на уровне процессов: trunk-based development, feature flags, наблюдаемость в проде. Мало кто добавляет в слайд отдельной строкой «стоимость красного CI» — хотя именно она съедает календарные дни у команд, которые уже «сделали всё правильно» в теории.
Где застревает Lead Time for Changes
Lead Time for Changes — время от коммита до продакшена для типичного изменения. Внутри него есть этап, который редко рисуют на value stream map: «пайплайн упал → кто-то разобрал лог → починил / перезапустил / откатил».
Пока CI красный, изменение формально «в работе», но ценности пользователю не добавляется. Вы платите зарплатой инженерного времени и упущенной выгодой релиза — двойной счёт.
Цена контекст-свитчинга
Разработчик в середине задачи получает пинг: «упал пайплайн на твоей ветке» или «сломали main». Он сворачивает ментальную модель текущей фичи, грузит в голову другой стек (Docker, тесты, раннеры, секреты), и через сорок минут возвращается к исходной задаче — уже с ощущением усталости.
Это не «мелочь». Такой переключатель умножается на размер команды и становится главным источником ощущения «мы постоянно тушим пожары».
Связка с DORA
Четыре ключевые DORA metrics — deployment frequency, lead time for changes, change failure rate, time to restore service. Красный CI бьёт по ним неизящно, но предсказуемо:
- Change Failure Rate растёт, если «починка» превращается в повторные коммиты вслепую: люди торопятся вернуть зелёный статус.
- Time to Restore Service для пайплайна (восстановить зелёный trunk / разблокировать релиз) тянется, пока RCA не ясен — команда гадает, а не чинит.
- Deployment frequency падает не потому, что «релизить нельзя», а потому что очередь на доверие к CI исчерпана: все боятся очередного красного.
Почему автоматизация триажа — логичный следующий шаг
Первый этап после падения job'а почти всегда одинаковый: прочитать лог и классифицировать сбой. Это рутина, хорошо поддающаяся автоматизации — при условии, что вы не сохраняете чувствительные данные и честно показываете уверенность разбора.
Exlogare как раз про этот первый шаг: подключение к GitLab, реакция на failed pipeline, короткий RCA в MR, issue или мессенджер. Цель — сократить MTTR именно этапа «понять, что случилось», чтобы инженеры возвращались к изменению системы, а не к чтению простыни лога.
Резюме для руководителя инженерии
Если вы измеряете только «сколько фич в спринте», вы недооцениваете налог на инфраструктурный шум. Добавьте в разговор про DevOps метрики и оптимизацию CI/CD хотя бы один практический эксперимент: автоматический разбор первых N падений и сравнение времени до первого осмысленного действия.
Начать можно без риска для бюджета: первые 20 анализов бесплатно. Если нужен разговор про Enterprise и политики данных — контакты.