Опиши в 3-4 предложениях что происходило и почему. Это информативное представление о факапе с высоты птичьего полета, оно должно быть понятно любому человеку без контекста.
Качественная оценка Какая функциональность не работала, насколько долго, у кого. Была ли потеря или порча данных. Выбери поле справа.
Количественная оценка По метрикам приложения и приложений-клиентов (сколько запросов отпало, насколько выросла latency). По обращениям пользователей (сколько звонков потеряно, размер очереди по проблеме).
Ссылки на снэпшоты графиков из графаны: системные метрики машин, дашборды пострадавших сервисов. Подпиши, куда какая ссылка ведет. Что такое снэпшот и как его сделать почитай в вики).
Как узнали о проблеме. По каким алертам, что написали в саппорт, etc. Выбери поле справа.
Развернуто опиши, что послужило триггером факапа: релиз (какой, когда), повышение нагрузки (от какого сервиса, пользовательского сценария), проблема с железом (где находится, за что отвечает). Выбери поле в описании справа.
Подробно опиши и проанализируй причины произошедшего. Опиши механизм падения. Причинно-следственные связи должны быть понятны человеку без контекста.
Не нужно писать от первого лица, оправдываться или винить своих коллег. Если в причинах фигурирует человеческий фактор, нужно докопаться, какой именно информации не хватило: осведомленности о процессах в команде, о механике работы системы, логике интеграции.
Что сделали непосредственно для решения проблемы и почему. "Откатили релиз", "дважды перезагрузили машины", "сидели и наблюдали, рассосалось само", etc.
Опиши все значимые моменты в происшествии: когда внесли ломающее изменение, когда выстрелили алерты, шаги по тушению пожара, etc. Все метки времени укажи с датой и часовым поясом.
Что пошло как надо Какие механизмы помогли в обнаружении, предотвращении и тушении факапа.
Что пошло не так Какой автоматики не хватило, чтобы факапа не произошло. Можно ли предотвратить подобное в будущем. Что уменьшило бы время реакции, длительность факапа, ущерб.
Где повезло Моменты, которые по случайности предотвратили больший ущерб. Случайно посмотрели на метрики сервиса, заметили подозрительную строчку в логах, раскапывая другую проблему, нужный человек оказался у компьютера в нерабочее время.
Ссылки на задачи в трекере, которые помогут уменьшить ущерб, ускорить реакцию, убрать случайности, избежать подобного факапа в будущем. Не ставь абстрактные или невыполнимые задачи ("писать код лучше", "исправить все баги в коде"). Этот постмортем должен зависеть от задач через отношение depends on.