В комментариях к последнему посту про SLA (https://set.ki/post/jEukYPt) я увидел тенденцию: все слышали про постмортем, но всем интересно - а что это такое и как это на практике?

1. Давайте для начала на пальцах. Есть такая штука как инцидент: у вас в продукте что-то упало. Далее эта проблема решается по шагам (примерно так, у вас могут быть вариации): 1.0 Вы узнаёте об инциденте (в идеале сами, иногда - от клиентов); 1.1 Поднимается протокол инцидента, делается чат с дежурными, которые должны его отрулить; 1.2 Вы ищете проблему; 1.3 Вы думаете, что нашли проблему, и устраняете её; 1.4 Если проблема не устранена - см. шаг 2, если устранена - идёте дальше; 1.5 Вы выкатываете хотфикс - какое-то временное решение, которое убережёт от воспроизведения проблемы в кратчайшем будущем; 1.6 Вы планируете и делаете полноценное решение, чтобы обезопасить себя и клиента;

2. И где же здесь случается постмортем? Речь идёт о саммари, которое надо дать вашим клиентам/партнёрам, которых задел инцидент. Почему без этого вам будет плохо, и вы встанете на штрафы - я рассказывал в том самом посте про SLA, так что тут это пропустим. Чтобы правильно написать постмортем - нужна правильная комм 2.1 Коммуникация начинается с уведомления клиентов/партнёров. На втором шаге жизненного цикла инцидента вам надо определить, задевает ли проблема ваших пользователей и видят ли они её. Возможно, вы и так знаете ответ уже на шаге 1, если клиент зашёл и сказал "всё сломалось". Что здесь важно: ЕСЛИ проблема задевает клиентов (видна), ТО неважно, сказал ли про неё хоть один клиент - вам всё равно важно сообщить им напрямую "видим, есть такая проблема". З - забота, не стоит уповать на то, что проблему не увидят. 2.2 Далее в ходе всего инцидента нужна рука на пульсе. Поместите клиента на свою сторону - он заинтересован проверять фиксы вместе с вами, чтобы всё скорее заработало. Сообщайте о любых подвижках и не стесняйтесь транслировать статус работ по запросу. Только без лишней конкретики - вам стрессово, клиенту стрессово, но наружу - никаких данных о сути проблемы, об этом поговорим позже.

3. И вот, проблема решена, пора писать постмортем. Что содержит хорошее описание проблемы? 3.1 Описание старта проблемы: В ХХ:YY заметили [симптомы проблемы] 3.2 Описание завершения проблемы: В ZZ:AA проблема полностью устранена 3.3 Описание причины проблемы: Случилось A в зоне B, которое повлекло за собой [симптомы проблемы] 3.4 Какая-то гарантия того, что проблема не повторится*: Мы уже сделали B, в течение недели добавим C + мониторинг, который подтвердит отсутствие таких проблем, а если что-то подобное случится - мы уведомим вас первыми и решим за 5 минут.

• • Надо писать только про итог. Если в процессе что-то делали - тестировали - оно не срабатывало, то постмортем не должен этого содержать. Такая информация в результатах проблемы - мусорная, она провоцирует отторжение. ** - Информация в 3.3 и 3.4 крайне чувствительна. Не выносите весь сор из избы, но не держите клиентов за дураков. Например, если у вас сгорела стойка в датацентре, и из-за этого сломался логин в приложении, то причиной проблемы для клиента может быть: "Обнаружили инфраструктурный недостаток, который мог влиять на недоступность логина". Гарантия безопасности - "Обновили инфраструктуру и увеличили отказоустойчивость приложения".

🧠 Ну и порция здравого смысла напоследок: по инцидентам, которые не задели ваших клиентов, внешние постмортемы не нужны. Это не значит, что эти инциденты требуют меньшего внимания, но оно должно быть направлено внутрь, нежели наружу.

📝 Пишите в комментариях, какие ещё принципы вы используете в написании постмортемов

📣 Делитесь этим постом, чтобы мы узнали и собрали как можно больше полезных практик под этой записью

Автор (пишет про проекты и продукты): https://t.me/shteinausmoskau