Вы можете провести лучший дебрифинг в своей жизни. Честная таймлинов, blameless-тон, реальные выводы. Люди уходят из комнаты, кивая.
И потом ничего не происходит.
Это проблема последней мили пост-мортемов — и в неё легко попасть. Action items — это разрыв между «мы поняли инцидент» и «мы что-то с ним сделали». Если они умирают, весь процесс становится театром.
Почему так происходит
1. Owner — это не человек, это namespace
Типичная запись: «Owner: @platform-team». Через месяц на ревью никто не понимает, кто конкретно должен был это сделать. Команда — не owner. Owner — это конкретный человек, который может сказать «я заблочен» или «я закончил».
Если action item требует работы нескольких команд, разбейте его на несколько с поименным owner-ом каждый. «Координацию» как action item оставьте кому-то одному.
2. Acceptance criteria — это «как мы поймём, что задача закрыта»
Две формулировки одного и того же:
-
Плохо: «Улучшить мониторинг сервиса X.»
-
Хорошо: «Добавить алерт на P99 latency > 500ms для X, проверить срабатывание на staging, подключить к on-call rotation.»
Первая никогда не закроется, потому что улучшить — бесконечный процесс. Вторая закроется или явно провалится.
3. Action items живут не там, где живёт работа
Если пост-мортем-документ в Notion, а команда работает в Jira/Linear/GitHub Issues, items в документе мертворождены. Их никто не видит на standup. Они не попадают в спринт.
Правило: action item должен быть конвертирован в тикет в трекере команды-owner до конца пост-мортем-встречи. С линком обратно на пост-мортем.
4. Нет owner-а для всей очереди
Кто следит, что action items закрываются? Чаще всего — никто. SRE-команда написала, продуктовая команда сделала, и никто не возвращается с проверкой. Назначьте follow-up owner (часто это SRE-лид или incident-commander), который раз в две недели проходит по открытым items и эскалирует залежавшиеся.
5. «Обсудили — значит решили»
Культурная ловушка. На пост-мортеме все согласились, что нужно сделать X. Это создаёт ощущение, что что-то уже произошло. На уровне знаний — да. На уровне системы — нет. Без trackable-тикета и нагрузки в спринте, action item остаётся только в коллективной памяти, которая стирается за две недели.
Что работает на практике
-
Action item template: owner (FIO), acceptance criteria, deadline, ссылка на тикет.
-
Тикет создаётся на встрече. Не «потом». Сразу. Pair-mode pinger: один человек ведёт пост-мортем, другой создаёт тикеты.
-
Двухнедельный stand-up по follow-ups: 15 минут, проходим по всем открытым action items за последние 3 месяца. Закрыты / в работе / устарели.
-
Связь с roadmap: если action item требует месяца работы, он должен пройти приоритезацию вместе с фичами. «Скрытая инженерная работа» здесь не пройдёт.
-
Метрика follow-up rate: процент action items, закрытых в обещанный срок. Если ниже 60% — у вас процесс, а не инцидент-менеджмент.
Когда action item — это не action item
Иногда из инцидента следует, что система должна работать иначе на архитектурном уровне. Это не action item — это design proposal. Action item — это «изменить config файл», «добавить алерт», «написать runbook». Если задача — «переделать партиционирование БД», она должна выйти из пост-мортема как inception document для отдельного проекта, со своим планированием.
Смешивание этих двух уровней — частая причина смерти action items: лёгкие быстро уходят в фоновую очередь, тяжёлые висят месяцами и тянут вниз метрику.
Главное
Цель пост-мортема — не документ. Цель — изменение в системе. Документ это побочный артефакт. Если у вас красивые пост-мортемы и не уменьшающаяся частота инцидентов одного типа — это знак, что action items дохнут где-то на последней миле.