Postmortem stale odds: как разбирать инцидент без выдуманного кейса

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

Impact: описать пользовательское состояние

Начинать лучше не с «service X degraded», а с того, что произошло на границе продукта. Какие рынки/события были затронуты? Как определялось stale state? Как долго мог существовать разрыв? Были ли действия заблокированы через suspend или клиент продолжал показывать старую версию? Если точного числа пользователей нет, это фиксируется как неизвестное, а не заменяется оценкой «около 15%» без источника.

Detection: кто заметил проблему первым

Записать конкретный сигнал: freshness SLI, provider gap, synthetic check, anomaly в suspend rate или пользовательское обращение. Если инцидент первым заметил пользователь, это не стыдная деталь, а указание на пробел в наблюдаемости. Corrective action потом должен закрывать именно этот пробел.

Timeline: только события с доказуемым временем

В timeline удобно разделять system event и human decision. «12:04 — processing lag превысил рабочую границу» и «12:07 — on-call отключил publish path» — события разного типа. Для каждого времени желательно иметь источник: metric, deployment event, incident log, audit trail.

Не стоит задним числом приписывать системе знания команды. Если в 12:10 причина ещё была неизвестна, timeline должен это отражать.

Mitigation: почему выбран именно этот безопасный режим

Описание mitigation отвечает не только на вопрос «что сделали», но и «какой риск этим сняли». Suspend, переключение provider, возврат на snapshot, ограничение обновлений или rollback имеют разные последствия. Если решение временно ухудшило доступность ради предотвращения stale publication, это важно зафиксировать явно.

Reconciliation: как доказали восстановление

Нулевой lag или зелёный dashboard не всегда достаточны. Нужно проверить authoritative и published versions, отсутствие пропущенных corrections, состояние downstream caches и то, что клиент после reconnect получает свежий snapshot. Именно reconciliation отличает «похоже, прошло» от завершённого восстановления.

Root cause и contributing factors не смешивать

Одна непосредственная причина редко объясняет масштаб инцидента. Например, gap у provider может быть trigger, а отсутствие sequence validation — contributing factor, который позволил stale state пройти дальше. Отдельно полезно записывать, почему существующие guardrails не остановили проблему раньше.

Corrective actions должны иметь проверяемый результат

Формулировка «улучшить мониторинг» не имеет критерия готовности. Лучше: добавить SLI возраста опубликованной версии, связать алерт с provider/competition и проверить synthetic reconnect на controlled gap. Каждое действие должно иметь владельца и способ проверки, но конкретные сроки определяет команда с учётом риска, критичности и порядка выпуска изменений.

Хороший postmortem остаётся полезным после того, как участники забыли детали. Читатель должен понять, какое состояние было неверным, почему защита не сработала, как команда доказала восстановление и что изменилось в системе после разбора.

Unknowns стоит сохранять до конца разбора

По мере расследования возникает соблазн переписать раннюю неопределённость в уверенную историю. Лучше оставить отдельный список неизвестного и отмечать, когда каждый вопрос получил доказанный ответ. Это помогает увидеть, какие данные в системе отсутствовали принципиально: например, нельзя определить client-visible version или неизвестно время конкретного correction. Такие пробелы часто важнее непосредственного root cause, потому что именно они замедляют следующий incident response.

Отдельно стоит зафиксировать, какие данные могли повлиять на решения команды, но не были доступны в момент инцидента. Это помогает не оценивать дежурных по информации, появившейся позже, и делает corrective actions направленными на систему, а не на ретроспективную «идеальность» человеческих действий.

Если corrective action невозможно связать с конкретным failure mode, его стоит переформулировать. «Добавить ещё один dashboard» слабее, чем «измерять возраст published version и алертить до пользовательского stale-state».

Так postmortem остаётся инженерным документом, а не литературной реконструкцией.

Хороший postmortem отделяет impact от предполагаемой причины

Сначала фиксируется наблюдаемый результат: какие рынки или пользователи видели устаревшее состояние, как долго и по каким версиям это подтверждается. Только затем строится причинная цепочка. Это защищает отчёт от ранней гипотезы, которая позже меняется. Для числовой части полезно использовать те же определения, что в SLO freshness и error budget; иначе incident report и reliability dashboard могут описывать один и тот же период разными правилами.

Corrective action в postmortem должна иметь проверяемый конец. Формулировка «улучшить мониторинг» почти ничего не значит; лучше указать, какой signal появится, какой failure mode он ловит и как команда проверит его на тестовом сценарии. То же относится к архитектурным изменениям: если обещан gap detection, нужен воспроизводимый тест разрыва. Так postmortem перестаёт быть описанием прошлого и становится инструментом снижения вероятности повторения.