{
  "index": 150,
  "slug": "editorial-2023-11-practice-postmortem",
  "title": "Postmortem, который помогает исправить систему",
  "excerpt": "Как отделить наблюдаемые факты от поздних объяснений, связать решение с доступной информацией и превратить профилактику в проверяемое действие.",
  "contentHtml": "<p>После сбоя команда обычно помнит две вещи: какой сигнал сработал и кто последним менял систему. На встрече эти детали быстро превращаются в объяснение: «ошибка произошла из-за этого изменения». Такой вывод может быть неверным. Он смешивает факт, решение и гипотезу о причине.</p>\n<p>Цена ошибки высока. Команда тратит время на защиту вокруг случайного признака, а настоящий механизм остаётся без проверки. Следующий дежурный получает документ с обвинением и общим советом «быть внимательнее». Похожий сбой повторяется, но его уже труднее разобрать: нужные логи истекли, контекст решения забыт, а исправление объявили готовым без измерения.</p>\n<p>Рабочая схема проста: сначала записать симптом и его цену, затем собрать факты с источниками, отдельно описать решение в моменте и только после этого сформулировать небольшую профилактическую проверку. Postmortem не должен угадывать причину по одной строке лога. Он должен показывать, что известно, чего не известно и какое действие уменьшит неопределённость.</p>\n<h2>Три разных типа записи</h2>\n<p><strong>Факт</strong> отвечает на вопрос «что было зафиксировано и где это видно?». Это узкое утверждение с временем и ссылкой на разрешённый артефакт: лог, trace, метрику, версию конфигурации или запись мониторинга. Фраза «в 10:03 запросы к маршруту получили 502» может быть фактом, если рядом есть запрос к источнику и задано окно времени.</p>\n<p><strong>Решение</strong> отвечает на вопрос «что команда сделала, имея такую информацию?». В него входят время, действие и список фактов, доступных до действия. Поздний trace или результат расследования нельзя добавлять в этот список задним числом. Он помогает понять выбор, но не доказывает, что выбор был правильным или ошибочным.</p>\n<p><strong>Профилактическая проверка</strong> отвечает на вопрос «что мы проверим, чтобы уменьшить риск повторения?». В ней нужны гипотеза, минимальный метод, бинарный критерий и обратимый путь. До прогона это намерение проверить, а не доказательство того, что новый alert, лимит или тест уже защитил пользователей.</p>\n<table><caption>Не смешивайте записи в одной строке</caption><thead><tr><th>Тип</th><th>Вопрос</th><th>Минимальные поля</th><th>Нельзя выводить</th></tr></thead><tbody><tr><td>Факт</td><td>Что зафиксировано?</td><td>время, наблюдение, ссылка на источник</td><td>виновника и root cause</td></tr><tr><td>Решение</td><td>Что выбрали тогда?</td><td>время, действие, доступные fact ID</td><td>оценку задним числом</td></tr><tr><td>Проверка</td><td>Что проверим дальше?</td><td>гипотеза, метод, критерий, rollback</td><td>реальный эффект до измерения</td></tr><tr><td>Действие</td><td>Кто доведёт работу?</td><td>владелец роли, срок, ссылка на проверку</td><td>обещание устранить все риски</td></tr></tbody></table>\n<h2>Механизм на маленьком примере</h2>\n<p>Представим учебный инцидент в HTTP-сервисе. После релиза доля ответов 502 выросла. Дежурный откатил конфигурацию таймаута. Через несколько минут доля ошибок снизилась. Этого недостаточно, чтобы написать «новый таймаут был причиной». За это время могли исчезнуть входной всплеск, зависший upstream или другая ошибка маршрутизации.</p>\n<p>Сначала запишите наблюдения:</p>\n<pre><code>const facts = [\n  { id: 'f-1', at: '10:03', text: 'gateway reported 502 for /checkout', source: 'metric:gateway_5xx' },\n  { id: 'f-2', at: '10:04', text: 'timeout config was version 17', source: 'config:checkout@17' },\n  { id: 'f-3', at: '10:05', text: 'on-call restored version 16', source: 'change:rollback-482' },\n];\n\nconst decision = {\n  at: '10:05',\n  action: 'restore checkout config to version 16',\n  availableFactIds: ['f-1', 'f-2'],\n};\n\nconst check = {\n  hypothesis: 'the timeout change contributes to the 502 path',\n  method: 'replay the same request class with versions 16 and 17',\n  criterion: 'both outcomes and upstream status are captured',\n  rollback: 'keep version 16 and stop the replay if error rate rises',\n};</code></pre>\n<p>Пример учебный. Он не читает настоящие метрики, не запускает rollback и не доказывает связь между таймаутом и 502. Его польза в форме: у решения видны только два доступных факта, а проверка имеет отдельный критерий и остановку. Если команда позже найдёт новый trace, его добавят в факты и пересмотрят гипотезу, но не перепишут историю доступной информации.</p>\n<p>Нужна и отрицательная ветка. Если в карточке факта появилось поле <code>rootCause</code>, система или ревью должны остановить запись. Если решение ссылается на факт, который возник позже, его нельзя считать контекстом решения. Если проверка говорит «сбой больше не повторится», но не называет вход, окно и измерение, это обещание, а не критерий.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<table><caption>Маршрут разбора</caption><thead><tr><th>Симптом</th><th>Вероятная причина смешения</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>В черновике есть имя инженера, но нет источников</td><td>оценка человека заменяет анализ условий</td><td>найти timestamp и evidence для каждой фразы</td><td>убрать имя из объяснения, добавить владельца следующего действия</td></tr><tr><td>«Релиз вызвал ошибку» написано как факт</td><td>гипотеза попала в timeline</td><td>сравнить время релиза, симптома и альтернативные изменения</td><td>пометить связь как непроверенную и сформулировать эксперимент</td></tr><tr><td>Action item звучит как «добавить мониторинг»</td><td>нет сценария и порога срабатывания</td><td>назвать вход, сигнал, окно и ожидаемое значение</td><td>сделать критерий бинарным и указать обратное действие</td></tr><tr><td>После отката написано «проблема решена»</td><td>снижение симптома приняли за доказательство причины</td><td>сопоставить ошибку с upstream, версиями и временем</td><td>описать откат как mitigation, а причину оставить открытой</td></tr><tr><td>Документ нельзя проверить через неделю</td><td>в нём остались воспоминания без артефактов</td><td>проверить каждое утверждение по ссылке и сроку хранения</td><td>сохранить минимальный разрешённый evidence или отметить пробел</td></tr></tbody></table>\n<h2>Иллюстрация временной границы</h2>\n<figure><img src=\"/assets/editorial/2023/postmortem-2023-fact-timeline.svg\" alt=\"Учебная временная шкала: факты предшествуют решению, после решения стоит обратимая проверка\" /><figcaption>Учебная схема: факты стоят до решения, а профилактическая проверка — после него. Она не представляет настоящий инцидент и не показывает production-метрики.</figcaption></figure>\n<p>Временная граница нужна не для бюрократии. Она защищает от hindsight bias: после сбоя команда видит больше, чем видела в момент действия. Поэтому в записи решения храните не весь итоговый материал, а именно набор сведений, который мог повлиять на выбор. Если действие необратимо, отдельно запишите владельца точки возврата и сигнал остановки.</p>\n<h2>Порядок работы</h2>\n<ol><li><strong>Опишите симптом.</strong> Укажите затронутый путь, окно времени, наблюдаемый сигнал и цену ошибки: недоступность операции, потерю данных, ручное восстановление или задержку.</li><li><strong>Зафиксируйте факты.</strong> Для каждой строки назовите источник, время и точную формулировку. Не добавляйте в факт причину, виновника или эффект, которого источник не измеряет.</li><li><strong>Восстановите контекст решения.</strong> Запишите действие, доступные fact ID, обратимость и сигнал, по которому команда решала продолжать или остановиться.</li><li><strong>Разделите mitigation и cause.</strong> Откат, переключение трафика или отключение функции может убрать симптом. Это ещё не доказательство механизма сбоя.</li><li><strong>Сформулируйте одну гипотезу.</strong> Укажите конкретный вход, способ проверки и альтернативу. Не начинайте с общего «повысить надёжность».</li><li><strong>Задайте критерий.</strong> Критерий должен приводить к PASS или FAIL и ссылаться на измеримый артефакт. Добавьте rollback и условие остановки.</li><li><strong>Проверьте документ.</strong> Уберите фразы, которые шире источника. Отдельно перечислите открытые вопросы и назначьте владельца только для следующей проверяемой работы.</li></ol>\n<h2>Ограничения</h2>\n<p>Такая схема не заменяет расследование распределённой системы. Один trace может не показать потерю сообщения. Откат может убрать симптом, но оставить повреждённые данные. Метрика может считать только успешные запросы и скрывать ошибки до входа в сервис. Поэтому границы источников и неполные данные нужно писать прямо.</p>\n<p>Blameless не означает «никто ни за что не отвечает». Документ должен содержать владельца действия, срок и критерий завершения. Он также должен фиксировать небезопасное изменение, нарушенный контроль или отсутствие доступа к сигналу, если это подтверждено. Не следует приписывать человеку мотив или использовать его имя как техническую причину.</p>\n<p>Учебный код выше не подключается к сети, CI, логам, alert-системе или production runtime. Его нельзя выдавать за результат прогона. В реальной системе доступ к incident data, приватность, retention и право публикации требуют отдельной проверки. Если источник недоступен, честная запись — «не проверено», а не правдоподобная реконструкция.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Postmortem готов к разбору, когда другой инженер может пройти его без устного пересказа:</p>\n<ul><li>симптом и цена ошибки привязаны к окну времени;</li><li>каждый факт имеет источник или явно отмечен как непроверенный;</li><li>решение связано только с фактами, доступными до него;</li><li>mitigation не выдан за доказанную причину;</li><li>профилактика содержит гипотезу, метод, PASS/FAIL, rollback и владельца;</li><li>в документе нет необоснованных утверждений о виновнике, root cause или реальном эффекте.</li></ul>\n<p>Проверка готовности не утверждает, что система стала надёжнее. Она утверждает более узкую вещь: документ сохраняет границу знания и задаёт следующий эксперимент, который можно проверить. После прогона обновите запись фактическим результатом, источником и новой оценкой риска.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://sre.google/sre-book/postmortem-culture/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE: Postmortem Culture — Learning from Failure</a> — официальное описание blameless-подхода, документирования инцидента и follow-up действий.</li><li><a href=\"https://sre.google/workbook/postmortem-culture/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Workbook: Postmortem Practices for Incident Management</a> — практические рекомендации по структуре и разбору postmortem.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/61/r3/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-61 Rev. 3</a> — официальный документ по incident response и улучшениям после инцидента; его рекомендации нужно применять с учётом своей среды и типа риска.</li></ul>"
}