Action Items Tracking

«Action items с прошлого постмортема? Половина закрыта, половина забыта». Я регулярно вижу команды, у которых сам разбор работает как надо: режим blameless соблюдён, причины разобраны, задачи сформулированы. А через полгода возвращается тот же инцидент, потому что до задач руки так и не дошли. Action Items Tracking — это дисциплина выполнения. Без неё постмортем превращается в ритуал самообмана: «мы извлекли уроки» при том, что не изменилось ничего. Главная практика внутри L1 Problem Management, замыкающая цикл с Blameless Postmortem.

Граница простая: blameless postmortem — процесс, который задачи порождает; action items tracking — процесс, который их выполняет и проверяет. Теряются задачи ровно на стыке, и, по моим наблюдениям, теряется скорее половина, чем единицы.

Что должен уметь

Главный навык на уровне L4 — считать долю закрытых задач и читать её как метрику качества всего разбора. По моим наблюдениям, там, где эту долю не считают, поток задач нездоров всегда: без метрики поломку процесса нечем увидеть, пока не вернётся тот же инцидент. Живая команда меряет долю раз в квартал, и падение ниже 70% разбирает как отдельную проблему процесса, а не как повод «лучше стараться».

У каждой задачи есть владелец (конкретный человек, не команда), срок и критерий «что значит — сделано». Без всех трёх это не задача, а пожелание.
Задачи живут в трекере рядом с обычной работой (Jira, Linear, GitHub Issues), а не внутри документа постмортема. Документ — статичный снимок, задачи — живые тикеты.

Проставляет приоритет явно: P0 — «чтобы это не повторилось», P3 — «хорошо бы когда-нибудь». Без приоритета все задачи размываются в одну кучу.
Ведёт регулярный смотр задач (раз в месяц или после каждого крупного инцидента): что закрыто, что просрочено, что пора эскалировать, пересобрать или снять.

Следит за долей закрытых задач как за опережающим сигналом о качестве разборов; на нисходящем тренде разбирает процесс, а не давит на исполнителей.
Держит политику эскалации: что происходит, когда задача просрочена на один цикл, на два, на три. Без явной эскалации просроченное копится тихим долгом.

L6+

Смотрит тренды по инцидентам: какие задачи повторяются от разбора к разбору (системный дефект), какие снимаются раз за разом (хронически недооценены), какие закрываются сознательно как «риск принят».
Связывает эту работу со стратегией инцидентов в организации: время на надёжность, включая выполнение задач из разборов, зарезервировано явно, иначе они всегда проигрывают продуктовым.

Материалы

Книги

Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 15 «Postmortem Culture». Часть про задачи неглубокая, но фиксирует канон: задача без владельца, срока и критерия — не задача.
Betsy Beyer et al. (eds) — The Site Reliability Workbook (O’Reilly, 2018), глава 10 «Postmortem Culture: Learning from Failure». Расширяет первую: метрики по задачам, отслеживание закрытия, антипаттерны.
John Allspaw, Morgan Evans, Daniel Schauenberg — Etsy Debriefing Facilitation Guide (Etsy, 2016). Не про отслеживание напрямую, но описывает ту самую исходную культуру разборов, где доведение задач до конца было частью «учиться на инцидентах».

Статьи и доклады

Lorin Hochstein — Why I don’t like discussing action items during incident reviews (Surfing Complexity, 2024). Позиция ровно против того, что описано в этом листе: Хохштейн считает, что обновление картины мира у участников даёт больше, чем список задач. Я с ним не согласен в части «вместо», но согласен в части «список задач не заменяет понимание» — читать как контраргумент к собственной практике.
John Allspaw — Blameless PostMortems and a Just Culture (Etsy Code as Craft, 2012). Первоисточник словаря; важен здесь тем, что связывает готовность людей честно рассказывать о своих действиях с тем, какие задачи в итоге формулируются.

Инструменты

Jira / Linear / GitHub Issues / Notion — основное место для задач, в одном списке с остальной работой. По моим наблюдениям, чаще выигрывает вариант «задачи там же, где обычная работа»: отдельный трекер под постмортемы через полгода застывает.
incident.io / FireHydrant / Rootly — платформы для инцидентов со встроенным учётом задач; выигрыш в том, что задача заводится прямо из хронологии инцидента и связывается с ним сама. По моим наблюдениям, такие платформы чаще берут команды с высоким потоком инцидентов. Команде, у которой один-два инцидента в месяц, отдельная платформа не годится: заводить её дороже, чем вести те же задачи в общем трекере.
Jeli — разбор через нарратив: задачи учитываются, но главное здесь — восстановить историю инцидента подробнее, чем это делает список задач. Самостоятельного продукта больше нет: PagerDuty купила Jeli в 2023 и встроила в свою платформу; методичка Howie, которую Jeli выпускала отдельно, разошлась по копиям в сообществе.
Dashboards (Grafana / Datadog / custom) — доля закрытых задач, число просроченных, распределение времени до закрытия. Самая полезная витрина, которую регулярно забывают собрать.

Best practices

Главный публичный кейс — GitLab database incident, January 31 2017. Команда опубликовала подробный postmortem — пример blameless write-up. Менее известна его вторая половина: в конце документа перечислены пятнадцать задач, каждая со ссылкой на публичный issue в их инфраструктурном трекере — «Prometheus monitoring for backups», «Automated testing of recovering PostgreSQL database backups», «Assign an owner for data durability» и так далее. Отдельным пунктом заведён meta-issue со сводным статусом всех остальных: то есть команда сразу построила себе единую точку, по которой видно, что закрыто, а что нет. Это образец того, как исполнительская часть постмортема бывает видна снаружи: не только «мы написали постмортем», но «вот тикет, вот смерженный PR, вот изменённый runbook». Сравните с командами, у которых постмортем публикуется, а задачи уходят в закрытый проект: разница в доверии и для клиента, и для самой команды.

Из этого вытекают три правила, на которых всё держится. Первое: задача без владельца, срока и критерия «что значит — сделано» задачей не считается. «Команда подумает над улучшением мониторинга» — это не action item, это пожелание, и через полгода оно выглядит ровно так же, как в день написания. Второе: задачи живут в трекере, а не в документе постмортема. Документ — статичный снимок момента, когда команда разобралась; задачи после него идут в общий backlog и конкурируют там со всем остальным. Дублировать «status: done» в двух местах не надо, эти два места разъедутся.

Третье правило — про метрику. Доля закрытых задач работает как SLI всей программы разборов: дашборд со счётчиками закрытых, просроченных и снятых за квартал показывает состояние процесса раньше, чем это сделает вернувшийся инцидент. Ниже 70% — разбирать сам процесс, а не давить на исполнителей.

Владелец — человек, а не команда. «Бэкенд улучшит мониторинг» — типовой сценарий отказа: команда в графе «владелец» означает, что владельца нет. Подписывается кто-то конкретный, даже если работу потом раскидают на троих. Без имени задача сползает в подзадачу продуктового бэклога и проигрывает любому приоритету оттуда. Я регулярно вижу команды, которые искренне уверены, что «этим владеет команда», — а через полгода задача не сделана, и виноватых нет, потому что виноваты все.

Задачи с приоритетом, а не равнозначные. «По итогам разбора завели двенадцать задач» — плохая новость, если все двенадцать равноценны: двенадцать одинаковых приоритетов означают, что приоритета нет. Рабочая раскладка: две-три P0 («чтобы не повторилось»), три-пять P1 (заметное улучшение), остальное — P2 и P3, которые не стыдно снять. Без этого силы тратятся равномерно, и на выходе P0 не закрыт, а P3 закрыт, потому что был проще.

Сознательно снять задачу — здоровое решение. Выполнять всё подряд не обязательно. Иногда честный ответ звучит как «риск принят, мы этого делать не будем», и он лучше молчаливой просрочки. В рабочем процессе выходов несколько: пересобрать, снять, принять риск. В нездоровом выход один — «выполнить», поэтому всё невыполненное превращается в тихий долг. Раз в квартал просроченное пересматривается с явным решением по каждой задаче: продолжаем, пересобираем или закрываем как принятый риск с обоснованием.

Театр закрытых задач — антипаттерн, который трудно разглядеть. Формально сделано всё: PR смержен, метрика добавлена, runbook обновлён. Фактически инцидент вернётся, потому что закрыли формулировку, а не причину. По моим наблюдениям, единственный способ это поймать — разбирать повторы: тот же инцидент пришёл через полгода, какие задачи по нему заводили, что с ними стало. Если задачи «выполнены», а инцидент вернулся, значит, был театр. Не повод искать виноватых, а сигнал, что задача формулировалась на уровне симптома.

Связанные листья

Blameless Postmortem — постмортем — место, где задачи рождаются; этот лист — где они выполняются. Без одной из половин цикл не замыкается.
Incident Response — инцидент — источник задач; закрытие инцидента включает их постановку с владельцем, сроком и критерием.
Postmortem Culture — сторона культуры: норма в организации, при которой выполнение задач обсуждают на ретро, а не молча снимают.
SLO Engineering — доля закрытых задач — опережающий сигнал по SLO: чем меньше закрывается, тем быстрее копятся системные риски и тем быстрее горит бюджет ошибок.
Toil Tracking — повторяющиеся задачи вида «пока обходим руками» — прямые кандидаты в бэклог toil.
One-on-Ones — просроченную задачу сначала обсуждают с владельцем на 1:1, а не публично через эскалацию. 1:1 — первое место, где её можно расшить.

Открытые вопросы

Порог severity, с которого разбор вообще заводит задачи, я для себя не закрыл: нужны ли action items для P3 и P4 или это уже процесс ради процесса. По моим наблюдениям, ответ сильно зависит от потока инцидентов в команде. Рядом лежит cross-team ownership (TBD) — что делать, когда задача требует изменений в чужой команде; эскалация тут отдельный набор паттернов, и одним абзацем он не закрывается.

Не хватает и политики устаревания. Через какой срок — полгода, год, полтора — просроченная задача закрывается автоматически с явным обоснованием? Канонического правила я не встречал, у каждой команды свой.

Я не уверен и в том, какой порог completion rate правилен как алертный сигнал. 70% — практическая догадка. Если у вас есть данные, расскажите через PR.