Инженерная практика
Собираем вместе: тест с множественным выбором
Суть Синтез всего трека engineering-practice в формате выбора — как CI, trunk-based, флаги, ревью, on-call и постмортемы образуют одну петлю, где каждое звено включает следующее.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, пронизывающих весь трек. Каждый — это решение о порядке или зависимости, которое реально принимает тимлид: не определение для пересказа, а вопрос о том, какое звено петли доставки несущее и что ломается, когда его вынимают.
Цель
Убедиться, что вы можете связать TDD, контрактное тестирование, код-ревью, trunk-based development, feature flags, on-call и постмортемы в одну петлю обратной связи — и предсказать отказ на стыке, когда практику внедряют без её зависимости.
Викторина
Completed
Руководство в понедельник насаждает ежедневные деплои в trunk. У команды 25-минутный, флакающий набор тестов и нет feature flags. Каков предсказуемый исход и какой зависимости не хватало?
Heads-up Trunk-based development держит конфликты маленькими только потому, что интеграция частая И каждый мерж гейтится надёжной сборкой. Медленный флакающий набор — не гейт, так что частота просто умножает сломанные интеграции.
Heads-up Качество CI — предусловие для trunk-based development. Стратегия ветвления напрямую зависит от того, чтобы сигнал был достаточно быстрым и надёжным, чтобы гейтить каждый мерж.
Heads-up Change-fail rate падает от маленьких батчей плюс надёжного гейта. Без гейта отказы продолжают просачиваться в trunk, как бы часто вы ни деплоили.
Викторина
Completed
Команда гордо деплоит 40 раз в день, но change-fail rate — 28%, а MTTR ползёт вверх. Что в терминах DORA они сделали не так?
Heads-up Скорость и стабильность не противоречат друг другу в данных; элитные команды имеют обе. Замедление лечит симптом, а не отсутствующие зависимости (CI, флаги, быстрое восстановление), которые делают частоту безопасной.
Heads-up Deployment frequency — валидная метрика DORA. Ошибка в том, что её отчитывают в одиночку, без change-fail rate или MTTR, которые её регулируют.
Heads-up Частота без метрики стабильности деградирует систему; это ровно тот отказ, который сбалансированный набор DORA призван выявить.
Викторина
Completed
В сервисе 340 feature flags, ни один не удалён за год. Изменение конфига переключает забытый 'release toggle' на пике трафика и кладёт checkout. Какого звена петли на самом деле не хватало?
Heads-up Флаги — это то, что позволяет отвязать деплой от релиза и мгновенно убить плохой код (урок Knight Capital). Дефект — отсутствие TTL/очистки, а не существование флагов.
Heads-up On-call ловит инцидент после взрыва; он не может предотвратить устаревший toggle, который надо было удалить много месяцев назад. Профилактика живёт в жизненном цикле флагов — это owned action item постмортема.
Heads-up Blameless-анализ ищет contributing factors, а не один root cause. Глубокий фактор — flag debt: release toggle, к которому относятся как к постоянному, без шага удаления.
Викторина
Completed
On-call инженер за четыре минуты сводит сбой checkout к одному PR и восстанавливается, выключив флаг — без сборки отката. Какие две вышестоящие практики сделали это быстрое восстановление возможным?
Heads-up Большие редкие релизы делают радиус поражения большим, а бисекцию медленной — противоположность тому, что обеспечило восстановление за четыре минуты. Рычагом были маленькие батчи плюс kill-switch.
Heads-up MTTR здесь задан размером батча и kill-switch'ем флага, а не сырой вычислительной мощностью или штатом. Тот же инцидент на гигантском релизе всё равно сводился бы часами.
Heads-up Больше QA на входе удлиняет lead time и ничего не даёт скорости восстановления, когда изменение уже живое. Быстрое восстановление идёт от маленьких батчей и возможности выключить флаг.
Викторина
Completed
Один и тот же сбой повторяется три квартала подряд, каждый раз со свежим документом-постмортемом на вики. Какой единственный стык петли сломан?
Heads-up Вина заставляет людей прятать инциденты, и вы теряете обучение. Повторение идёт от того, что action items никогда не выкатываются, а не от недостатка вины.
Heads-up Количество документов — не проблема, их отсутствие доведения до конца — да. Один постмортем с owned, выкаченным action item лучше трёх, по которым никто не действует.
Heads-up Длина ротации не определяет, выкатится ли фикс. Сломанное звено — отсутствие отслеживаемых action items, которые возвращаются в тесты, контракты и дефолты флагов.
Викторина
Completed
Организация из 20 сервисов гоняет полный end-to-end интеграционный набор на каждый мерж; он медленный и флакающий, поэтому инженеры заглушают падения и баги доезжают до прода. Какой сеньорный фикс сохраняет петлю доставки целой?
Heads-up Перенос e2e на ночь полностью убирает гейт с мержа; сломанная работа весь день садится в trunk, и вы узнаёте об этом наутро. Петле нужен быстрый сигнал на мерж, который дают контракты.
Heads-up Ретраи флакающих e2e прячут реальные падения за зелёным и приучают команду игнорировать гейт — ровно то заглушение, что пропустило баги. Фикс — более быстрый детерминированный сигнал, а не больше ретраев.
Heads-up Флаги отвязывают деплой от релиза; они не валидируют корректность. Вывод непроверенного кода за флаги просто прячет баги и растит flag debt. Контракты валидируют ту границу, которую мок в unit-тесте подделывает.
Итог
Сквозная линия всего трека — одна замкнутая петля с несущим порядком: тесты и контрактные проверки делают CI надёжным гейтом; этот гейт делает trunk-based мерж безопасным; trunk-based плюс feature flags отвязывают деплой от релиза; маленькие частые деплои держат радиус поражения любого прорыва крошечным, где его ловит on-call; а blameless-постмортем с owned action items превращает инцидент в новые тесты, контракты и дефолты флагов — замыкая петлю. Вынь звено — и нижестоящая практика инвертируется. И всем этим управляешь через четыре метрики DORA вместе, никогда — одной церемонией изолированно.