Инженерная практика
Собираем вместе: постройте петлю доставки команды
Знать петлю — не то же самое, что её гонять. Поднимите всю петлю доставки для небольшой команды на реальном (или реалистичном) сервисе — CI-гейт, trunk-based development плюс флаги, нормы ревью, on-call и цикл постмортем-к-фиксу — затем докажите, что она работает, прогнав через неё инцидент и увидев, как DORA двигается в правильную сторону.
Превратить ментальную модель трека в работающую систему: быстрый CI-гейт, делающий частый мерж безопасным, флаги, отвязывающие деплой от релиза, лёгкие нормы ревью, путь on-call с kill-switch и цикл постмортема, чьи action items возвращаются вверх по течению — всё измеряемое четырьмя метриками DORA вместе.
Для небольшого сервиса (2-3 компонента, ваш или стартовый) поднимите полную петлю доставки и систему практик вокруг неё — CI-гейт, trunk-based + флаги, нормы ревью, on-call, постмортем-к-фиксу — затем докажите целостность петли, прогнав реалистичный инцидент от начала до конца и показав, что DORA двигается верно.
- Ревьюер может смержить маленький PR только когда CI-гейт зелёный; принудительный красный на любом блокирующем шаге наглядно блокирует мерж.
- Рискованное изменение деплоится в прод dark и восстанавливается выключением флага — без сборки отката — а время восстановления записано как MTTR.
- Снимок DORA до/после при одинаковой нагрузке: lead time, deployment frequency, change-fail rate и MTTR — измеренные с дашборда/логов, а не оценённые.
- Инвентарь флагов показывает, что у каждого флага есть владелец, тикет на удаление и срок; демо-флаг закрыт (completed → archived, ветка удалена) после учения.
- Постмортем содержит хотя бы один owned, датированный, отслеживаемый action item, выкатывающий конкретное изменение вверх по течению (тест / контракт / дефолт флага), и вы можете указать на это изменение, смерженное через гейт.
- Добавьте в CI страж flag-debt: роняйте сборку (или открывайте тикет) для любого флага с истёкшим сроком или без владельца, чтобы flag debt не мог тихо копиться.
- Добавьте регулятор change-fail rate: автоматическую проверку, блокирующую дальнейший рост deployment frequency, если CFR или MTTR деградируют сверх порога — кодируя 'оптимизируй петлю, а не одну метрику'.
- Прогоните property-based или контрактный тест, ловящий класс регрессий, который пропустил бы единичный пример-тест, и покажите, как он роняет гейт на намеренно плохом изменении.
- Проведите второе учение, где фикс — контрактное утверждение на границе сервисов, и покажите, что тот же дефект больше не может доехать до trunk — доказав, что петля замкнулась.
Это петля, которую вы будете гонять в каждой реальной команде: быстрый надёжный CI-гейт делает частый мерж безопасным, trunk-based плюс флаги отвязывают деплой от релиза, нормы ревью держат батчи маленькими, а латентность низкой, on-call с kill-switch держит радиус поражения любого прорыва крошечным, а blameless-постмортем с owned action items возвращает фикс вверх по течению — всё под управлением четырёх метрик DORA вместе. Построить это однажды на небольшом сервисе и прогнать через него один инцидент от начала до конца — вот что превращает ментальную модель в то, как ваша команда реально поставляет.