Сайт переехал на pragmatic-km-guide.ru. Обновите ссылки!

Задать вопрос Поделиться знаниями Редактировать страницу

Анализ инцидентов (Post Mortem)

Post Mortem (постмортем) — это структурированный процесс и отчет, создаваемый после крупного технического инцидента или сбоя. Его главная цель — детально разобраться в причинах произошедшего, вынести уроки и внедрить изменения, которые предотвратят повторение подобных ситуаций в будущем.

Ключевые принципы эффективного постмортема

  1. Безобвинительная культура (Blameless Culture)
    Самый важный фактор. Если инженеры будут бояться наказания или публичного порицания за ошибки, они начнут скрывать детали сбоев, затягивать реакцию и искажать хронологию. Постмортем строится на убеждении, что люди действовали из лучших побуждений на основе той информации, которая у них была на тот момент. Если произошел сбой — виноват дизайн системы или процесса, а не конкретный исполнитель.

  2. Поиск системных причин вместо поверхностных
    Вместо банального вывода «разработчик совершил опечатку в конфигурационном файле» команда копает глубже: почему система позволила выкатить некорректный файл? Почему не сработало автотестирование или канареечный деплой? Почему мониторинг зафиксировал проблему только через 20 минут?

  3. Фокус на ментальных моделях (Mental Models)
    Разбор должен реконструировать ход мыслей участников во время инцидента. Что они видели на дашбордах? Какие алерты сработали? Какая документация ввела их в заблуждение? Это помогает найти и починить «слепые зоны» в интерфейсах и процессах.

  4. Информационная открытость
    Результаты анализа не должны пылиться в закрытых папках. Ими нужно делиться со всей компанией или инженерной лигой, чтобы другие команды могли перенять опыт и проверить свои сервисы на аналогичные уязвимости.

Процесс проведения Post Mortem

  1. Стабилизация системы: Первоочередная задача — устранить влияние сбоя на пользователей. Анализ начинается только после восстановления работоспособности.

  2. Сбор фактов и составление хронологии: Собирается лог событий: когда появились первые аномалии, когда сработал алерт, какие действия предпринимали инженеры, когда система пришла в норму.

  3. Заполнение черновика отчета: Ответственный (обычно дежурный инженер или владелец пострадавшего сервиса) заполняет шаблон отчета.

  4. Проведение встречи (Postmortem Meeting): Собираются вовлеченные инженеры, представители смежных команд и стейкхолдеры. Происходит конструктивный разбор хронологии и причин.

  5. Формирование Action Items: Создается список конкретных шагов по улучшению системы.

Требования к Action Items (избирательность и качество)

Чтобы постмортем не превратился в формальность, каждый выработанный Action Item должен соответствовать строгим критериям:

  • Конкретный владелец: Задача назначается на одного конкретного человека, а не «на команду разработки».

  • Четкий дедлайн: Указывается точная дата исполнения вместо размытых формулировок вроде «в следующем квартале».

  • Измеримый результат: Критерий готовности должен быть легко проверяем (например: «добавить алерт на превышение лимита соединений БД в Slack», а не «сделать базу данных надежнее»).

  • Обязательное занесение в таск-трекер: Каждое улучшение должно стать тикетом в Jira/Linear/ClickUp. Без тикета задачи не существует.

Продвинутый уровень: Blameless 2.0 и Комитет по надежности

В зрелых IT-организациях (например, как это устроено в Google или крупных ритейлерах вроде Купера) создается специальный формат шеринга опыта — Комитет по надежности (Reliability Committee).

На регулярных встречах комитета публично (внутри компании) разбираются 2-3 самых значимых инцидента за период. Слайды включают: масштаб ущерба для бизнеса, хронологию, корневые причины и принятые решения. Это создает мощный горизонтальный обмен знаниями: инженеры из соседних отделов видят, «где тонко», и проактивно исправляют схожие проблемы у себя до того, как они упадут.

Шаблон Post Mortem документа

  • Заголовок: [Дата] [Имя сервиса] [Краткая суть сбоя]

  • Статус: [В процессе / Завершен]

  • Авторы и участники: [Имена]

  • Бизнес-эффект: [Сколько пользователей затронуто, финансовые потери, репутационный ущерб]

  • Хронология событий: [Время - Событие]

  • Пять «Почему» (5 Whys): [Метод поиска корневой причины]

  • Что сработало хорошо: [Где команда быстро среагировала, какие бэкапы спасли]

  • Где нам не повезло / Что пошло не так: [Слепые зоны, задержки алертов, нерабочие инструкции]

  • Список Action Items: [Таблица: Задача | Владелец | Ссылка на тикет | Срок]

Полезные материалы и ссылки

Лицензия Creative Commons | by Igor Tsupko, Lana Novikova, Rodion Nagornov & community