Инженерная практика
Postmortems: написать и отревьюить blameless-ретро
Читать про blameless-postmortem — не то же самое, что написать тот, что переживёт сеньорское ревью. Возьми реальный инцидент (или заданный ниже), напиши полный документ, затем прогони ту же критику, что и staff-инженер, — охотясь на язык вины, схлопнутый root cause и action items, которые никто не сможет зашипить.
Преврати модель юнита в воспроизводимый артефакт и цикл ревью: построй нейтральный таймлайн, квантифицируй impact, выдели два-пять contributing factors вместо одного root cause, напиши владеемые и датированные action items и докажи, что документ меняет будущее, а не просто документирует прошлое.
Напиши полный blameless-postmortem для одного инцидента, затем отревьюй его по чек-листу, ловящему три режима отказа — язык вины, схлопывание к единственному root cause и неотслеживаемые action item, — и переписывай, пока он не пройдёт.
- Чек-лист ревью, применённый к собственному документу, с pass/fail по каждой строке: таймлайн нейтрален и с метками времени; impact квантифицирован; есть 2–5 системных contributing factors и нет единственного человеческого root cause; у каждого action item один владелец, срок и определение «готово»; план follow-through существует.
- Короткая заметка до/после, показывающая хотя бы одно предложение, что ты переписал, чтобы убрать язык вины или сломать рамку единственного root cause, с переписанным вариантом рядом.
- Каждый action item проходит тест на отслеживаемость — посторонний прочёл бы и понял, кто владеет, когда срок и как понять, что сделано, — с нулём items в стиле «быть аккуратнее».
- Абзац-обоснование выбранного severity trigger и почему полное ретро на каждый всплеск размыло бы follow-through на инцидентах, что важны.
- Преврати чек-лист в переиспользуемый шаблон postmortem (timeline / impact / contributing factors / action items / follow-through) и одностраничный гайд ревьюера для ловли трёх режимов отказа.
- Добавь лёгкий трекер action item (таблица или метка issue) и определи отчёт на 30/60/90 дней, что вскрывает просроченные items и считает rate завершённости против цели 85%+.
- Напиши тот же инцидент дважды — раз blameful («человеческая ошибка, добавили чеклист») и раз blameless — и проаннотируй, какую именно информацию разрушает blameful-версия и какой повтор она не предотвращает.
- Проведи 30-минутное учебное ревью своего postmortem с коллегой, используя только вопросы «как»; зафиксируй, какие новые contributing factors всплыли, что твоя сольная писанина упустила.
Это артефакт и цикл ревью, который ты будешь прогонять после каждого реального инцидента: построй нейтральный таймлайн, квантифицируй impact, назови два-пять системных contributing factors вместо одного человеческого root cause, прогони проход «infinite hows», чтобы вскрыть условия, и напиши action items конкретные, владеемые и датированные. Затем отревьюй собственный документ на три режима отказа — язык вины, схлопывание к единственному root cause, неотслеживаемые items — и защити follow-through через severity trigger и трекинг 30/60/90 дней. Сделав это раз намеренно, ты доводишь production-версию, написанную под давлением в 2 ночи, до уровня мышечной памяти.