Собираем вместе: тест с множественным выбором
Синтез всего трека engineering-practice в формате выбора — как CI, trunk-based, флаги, ревью, on-call и постмортемы образуют одну петлю, где каждое звено включает следующее.
Шесть вопросов, пронизывающих весь трек. Каждый — это решение о порядке или зависимости, которое реально принимает тимлид: не определение для пересказа, а вопрос о том, какое звено петли доставки несущее и что ломается, когда его вынимают.
Убедиться, что вы можете связать TDD, контрактное тестирование, код-ревью, trunk-based development, feature flags, on-call и постмортемы в одну петлю обратной связи — и предсказать отказ на стыке, когда практику внедряют без её зависимости.
Руководство в понедельник насаждает ежедневные деплои в trunk. У команды 25-минутный, флакающий набор тестов и нет feature flags. Каков предсказуемый исход и какой зависимости не хватало?
Команда гордо деплоит 40 раз в день, но change-fail rate — 28%, а MTTR ползёт вверх. Что в терминах DORA они сделали не так?
В сервисе 340 feature flags, ни один не удалён за год. Изменение конфига переключает забытый 'release toggle' на пике трафика и кладёт checkout. Какого звена петли на самом деле не хватало?
On-call инженер за четыре минуты сводит сбой checkout к одному PR и восстанавливается, выключив флаг — без сборки отката. Какие две вышестоящие практики сделали это быстрое восстановление возможным?
Один и тот же сбой повторяется три квартала подряд, каждый раз со свежим документом-постмортемом на вики. Какой единственный стык петли сломан?
Организация из 20 сервисов гоняет полный end-to-end интеграционный набор на каждый мерж; он медленный и флакающий, поэтому инженеры заглушают падения и баги доезжают до прода. Какой сеньорный фикс сохраняет петлю доставки целой?
Сквозная линия всего трека — одна замкнутая петля с несущим порядком: тесты и контрактные проверки делают CI надёжным гейтом; этот гейт делает trunk-based мерж безопасным; trunk-based плюс feature flags отвязывают деплой от релиза; маленькие частые деплои держат радиус поражения любого прорыва крошечным, где его ловит on-call; а blameless-постмортем с owned action items превращает инцидент в новые тесты, контракты и дефолты флагов — замыкая петлю. Вынь звено — и нижестоящая практика инвертируется. И всем этим управляешь через четыре метрики DORA вместе, никогда — одной церемонией изолированно. Теперь, когда встретишь разбор инцидента без owned action items или CI-шаг с пометкой «разрешено падать», — ты знаешь, как назвать звено и какой разговор начать.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.