На полевой ретроспективе проблема обычно возникает раньше, чем открывают документ. Один участник говорит «надо было сразу откатывать», другой вспоминает иной сигнал, третий объясняет мотивацию коллеги. У команды появляется версия истории, но не способ её проверить. Цена — следующая дежурная смена повторяет выбор без понимания условий и ограничений конкретного момента.
Не нужно выигрывать спор о версии событий. Нужен маршрут, который уменьшает область утверждений. Ведущий возвращает разговор к наблюдаемому: что зафиксировано, откуда запись, в каком порядке она стала известна. Затем он отделяет решение при этом наборе данных от гипотезы о профилактике. Такой порядок не отменяет ответственность за follow-up: у action item остаются владелец роли, проверка и точка возврата.
Первые пятнадцать минут: восстановить границу знания
Начните с одной цели разбора: не «узнать, кто допустил ошибку», а «понять, какие факты были доступны перед решением и какой риск проверить следующим». Заведите три колонки. В facts попадают timestamped statements с source reference. В decisions — действия и набор facts на тот момент. В experiments — будущие проверки с остановкой. Unknown не маскируйте: строка «источник не найден» полезнее пересказа.
| Шаг | Вопрос к группе | Артефакт на выходе | Стоп-сигнал |
|---|---|---|---|
| 1. Факты | что именно зафиксировано? | fact card с временем и source reference | в строке появилась причина или имя человека |
| 2. Решение | что было известно до действия? | decision card + ordered fact IDs | добавлен факт, появившийся позже |
| 3. Unknown | какой пробел мешает выводу? | вопрос, owner role, способ проверки | пробел заполняют догадкой |
| 4. Experiment | что проверим до следующего change? | гипотеза, criterion, rollback | задача обещает устранить все повторения |
Остановите фразу, которая звучит как причина
Фразы «это из-за релиза», «дежурный не заметил», «runbook подвёл» могут быть хорошими вопросами, но плохими facts. Ведущий не обязан спорить с ними. Достаточно попросить разделить фразу: какое событие зафиксировано, какой источник это подтверждает, какая часть остаётся hypothesis. Если источника нет, запишите `unknown` и назначьте безопасную проверку. Это снимает давление с человека в комнате и одновременно повышает требовательность к документу.
Особенно осторожно с chat-историей. Сообщение в канале помогает восстановить порядок, но само по себе не подтверждает технический механизм. У него есть автор, время и контекст, но нет статуса root cause. Для таких материалов отдельно определяют доступ, redaction, retention и круг читателей. В статье нет настоящих сообщений, логов или пользователей; речь только о форме вопроса до публикации выводов.
Проверьте решение по доступным фактам
Когда facts упорядочены, возьмите одно решение. Спросите: какой сигнал был доступен, какое действие выбрали, какие альтернативы были реально обратимы, что стало известно позже. Не спрашивайте «почему человек сделал это», пока не назвали границу его информации и управления. Решение может оказаться плохим даже при хороших намерениях, но это проверяется через условия: отсутствующий dashboard, неоднозначный runbook, слишком долгий deploy, права доступа, неясный owner, неверный stop criterion.
В fixed synthetic fixture решение `pause-synthetic-change-review` ссылается на три fact IDs. Оно не имеет `actor`, не получает оценку «правильно» или «ошибка» и не знает причин настоящего события. Такая искусственная строгость помогает провести live review: если участники добавляют к карточке человека как объяснение, нужно спросить, какое системное условие мы пытаемся изменить. Если ответа нет, это ещё не preventive action, а наблюдение о процессе, которому требуется отдельный evidence.
Сделайте один experiment меньше, чем хочется
После восстановления timeline у команды часто десяток идей: новый мониторинг, больше тестов, запреты в CI, переписывание сервиса. Не принимайте их единым списком. Выберите один управляемый риск и сформулируйте experiment. Внутри него должны быть гипотеза, минимальный scope, criterion, владелец роли, дата review и rollback. Если criterion звучит как «ничего больше не сломается», задачу надо сузить: он не показывает, когда проверка завершена и что делать при отрицательном результате.
Хороший первый experiment может быть документальным и всё равно техническим. Например: для одного опасного действия в runbook добавить explicit stop criterion и rollback reference, затем провести review с человеком, который не участвовал в исходном сценарии. Успех — он может назвать границу остановки по документу; неуспех — поля неполны. Это не измерение reliability и не доказательство предотвращения outage. Зато оно даёт короткий feedback loop, который можно повторить до изменения production конфигурации.
Используйте fixture как чек-лист против самообмана
Fixture держит пять fixed synthetic incident records в памяти. Он не читает файл, environment, clock, CI, сеть, incident storage, logs, traces, alerts или users. `runPostmortemFixture()` проверяет девятнадцать условий: полноту facts, порядок, связь decision с facts, явную границу actor, experiment с rollback и отрицательные ветки для culprit, root cause и real effect. Он не автоматизирует встречу, не делает расследование и не знает, что произошло в настоящем контуре.
import {
assembleSyntheticPostmortem,
runPostmortemFixture,
syntheticIncidentRecords,
} from './upgrade-2023-11.mjs';
const card = assembleSyntheticPostmortem(syntheticIncidentRecords);
if (!card.accepted) throw new Error(card.reason);
const report = runPostmortemFixture();
if (!Object.values(report.assertions).every(Boolean)) throw new Error('fixture failed');
console.log(card.evidence.permittedConclusion);
// record-boundaries-present-in-fixed-synthetic-model
// Только fixed synthetic records в памяти. Нет I/O, сети, CI,
// logs, traces, alerts, users или production runtime.
node web/scripts/upgrade-2023-11.mjs --verify-fixture
# PASS означает только согласованность fixed synthetic records in memory.
# Он не назначает виновника и не подтверждает фактическую причину, impact или production effect.После прогона не переносите `PASS` в заголовок postmortem. Корректнее написать: «черновик выдержал проверку формы; источники и выводы требуют отдельного review». Если fixture отклонил `rootCause`, это не значит, что причин не существует. Значит, причина не должна появиться в наборе, который обязан описывать только fact, decision и experiment. Причинная гипотеза может жить отдельно, с уровнем уверенности, evidence и способом опровержения.
Маршрут: симптом → причина → проверка → действие
- Симптом. Встреча застряла на воспоминаниях, оценках людей и споре о том, что было очевидно.
- Причина. У документа нет границы между source-backed fact, решением в моменте и future experiment; позднее знание смешалось с исходным контекстом.
- Проверка. По очереди маркируйте записи. Для fact потребуйте timestamp и evidence reference; для decision — только предшествующие facts; для experiment — criterion и rollback.
- Действие. Остановите персональную оценку, заведите unknown как отдельную задачу и выберите один обратимый experiment вместо списка обещаний.
- Проверка вывода. Попросите независимого читателя назвать из карточки, что известно, что было решено и что ещё только проверят. Если ответ смешан, переразметьте текст.
- Следующий шаг. На следующем review посмотрите только на артефакт experiment: сделан ли критерий, не изменился ли scope, сохранён ли rollback и какой evidence допустим.
Что делать при споре и при необходимости rollback
Если спор продолжается, не голосуйте за самую убедительную версию. Зафиксируйте competing hypotheses отдельно от facts и спросите, какое evidence могло бы различить их. Бывает, что такого evidence уже нет. Тогда честный результат — «не установлено», а следующий шаг — изменить instrument или retention для будущего случая. Это защита от решения, которое строится на уверенности без наблюдения.
Rollback реального change не выводится из одной ретроспективы. Он требует scope, доступа, операционного владельца, безопасного действия и наблюдаемой проверки. В fixture rollback возвращает лишь frozen synthetic snapshot и сообщает `effect=no-system-change`. Не используйте этот код как operational procedure. Его роль — напомнить: действие нельзя считать обратимым, пока не названы точка возврата и способ увидеть, что обратная операция закончилась.
Ограничения и следующий шаг
Здесь нет реального incident data, logs, traces, alerts, users, CI, network access или production runtime. Timeline и experiment — fixed synthetic records. Статья не делает вывода о людях, причинах, security impact, доступности, финансовом ущербе, пользователях или эффекте настоящего изменения. Она также не заменяет incident command, HR-процесс, legal review, privacy policy и требования к disclosure. Эти границы необходимо определить для своего окружения отдельно.
Следующий шаг — провести короткий rehearsal на synthetic карточке: ведущий, независимый читатель и reviewer action item. Цель — проверить язык документа: видны ли facts, граница решения, unknown, criterion и rollback. Затем адаптируйте template под допустимые источники и роли команды. Если адаптация требует выдуманных цифр или «идеального» героя, вернитесь к меньшему эксперименту и наблюдаемому артефакту.
Историческая граница ноября 2023
До конца ноября 2023 официально были опубликованы Google SRE Book 2017, включая главу о blameless postmortem и example с timeline, а также NIST SP 800-61 Rev. 2 (2012) и CISA federal playbooks (2021) для cybersecurity incident response. Они поддерживают идею documented follow-up и lessons learned в своих областях. Автор не приписывает им универсальную организационную модель, не заявляет, что этот маршрут проверен на конкретной команде, и не переносит поздние инструменты или требования в 2023 год.
Проверяемые источники
- Google SRE Book: Postmortem Culture: Learning from Failure, 2017 — официальная публикация Google, доступная до ноября 2023. Она описывает опыт и практику Google: документирование инцидента, разбор contributing causes, review и action items. Это не универсальное доказательство эффекта для другой команды.
- Google SRE Book: Example Postmortem, 2017 — официальный учебный пример с timeline, impact, action items и lessons learned. Он показывает форму артефакта, но не является данными этого fixture или причиной какого-либо чужого сбоя.
- NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide, август 2012 — официальное руководство по обработке компьютерных security-инцидентов, включая phase post-incident lessons learned. Его область — incident response в security, а не готовый шаблон для любого продуктового или эксплуатационного разбора.
- CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks, ноябрь 2021 — официальный федеральный playbook США, опубликованный до ноября 2023. Он относится к FCEB cybersecurity response; статья не переносит его обязательства, сроки или полномочия в иной контур.