Что вы делаете, чтобы тот же тип incident не случился во второй раз?

Question

Accepted Answer

Проводите **blameless postmortem**, который находит системную причину, затем превращаете её в **конкретные, закреплённые за ответственными и отслеживаемые** action items — и проверяете, что они действительно реализованы. Цель не в том, чтобы найти, кого винить; она в том, чтобы изменить систему так, чтобы тот же класс сбоя стал невозможным или самообнаруживаемым.

## Основной цикл

1. **Blameless postmortem.** Постройте честный таймлайн: что произошло, когда мы обнаружили, как отреагировали, каково было влияние. Обвинение убивает правду, которая вам нужна.
2. **Докопаться до системной причины**, а не до триггера. «Инженер запушил плохой config» — это триггер; «не было валидации или поэтапного rollout для config'ов» — это причина. Используйте **Пять почему**, но останавливайтесь на системе, никогда на человеке.
3. **Сгенерировать слои предотвращения**, а не единственный фикс:
   - **Предотвратить** — сделать сбой невозможным (валидация, типы, защитные ограждения).
   - **Обнаружить** — поймать раньше (alerts, SLO, синтетические проверки).
   - **Смягчить** — ограничить радиус поражения (rollback, флаги, circuit breakers).
4. **Назначить ответственных и сроки.** Action item без ответственного — это пожелание. Отслеживайте их как реальную работу в бэклоге.
5. **Проверить и замкнуть цикл.** Реализован ли фикс? Поймал бы он исходный сбой? Реально ли улучшились MTTR и обнаружение?

## Компромиссы и подводные камни

- **Postmortems, которые производят документы, а не изменения** — самый частый провал. Нет доведения до конца — встретите тот же incident снова.
- **Чрезмерное исправление конкретного симптома**, пока класс бага остаётся открытым. Чините категорию, а не только этот экземпляр.
- **Усталость от alerts** от наваливания обнаружения без настройки; шумные alerts игнорируются, и следующий incident проскальзывает.
- **Культура обвинения** загоняет отчётность в подполье; вы теряете near-misses, которые есть ваши самые дешёвые уроки.
- Относитесь к **повторяющимся incidents как к сигналу провала процесса**, а не невезения — отслеживайте повторяемость как метрику.

## Почему это важно

Incidents — это плата за обучение, которую вы уже внесли; единственная растрата — не извлечь из них урок. Команда, которая систематически предотвращает повторение, становится надёжнее каждый квартал, тогда как команда, которая лишь тушит пожары, заново переживает те же outages вечно. Построить этот цикл обучения — и безопасность быть в нём честным — одна из самых долговечных вещей, которые Tech Lead может оставить после себя.