{
  "index": 254,
  "slug": "editorial-2020-12-mechanism-incident-review",
  "title": "Разбор инцидента: как не перепутать симптом с причиной",
  "excerpt": "После восстановления сервиса обход легко принять за окончательное решение. Разбираем цепочку от наблюдения до проверки и показываем, как сохранить отрицательный результат и превратить вывод в проверяемое действие.",
  "contentHtml": "<p>Синтетический сценарий выглядит знакомо: операция вернула ошибку, после отката проверка снова прошла, и команда записала результат как «исправили». Через месяц похожий симптом появился после другого изменения. Повторный обход сработал на одном входе, но никто не мог показать, какая граница нарушилась и какой сигнал подтвердил решение.</p>\n<p>Проблема здесь не в самом откате. Временное действие становится опасным, когда его принимают за объяснение причины. Оно может скрыть потерю данных, увеличить задержку или перенести отказ на следующую границу. Отчёт тогда сохраняет уверенный пересказ, но не сохраняет факты, ход проверки и то, что осталось неизвестным.</p>\n<p>Разбор полезен, когда разделяет пять состояний: наблюдение, гипотезу, действие, проверку и профилактику. Наблюдение фиксирует факт. Гипотеза объясняет факт и допускает опровержение. Действие меняет одну ограниченную часть системы. Проверка измеряет результат именно этого действия. Профилактика меняет будущий путь и считается выполненной только после отдельной проверки.</p>\n<h2>Сначала фиксируем границу и симптом</h2>\n<p>Разбор начинается с границы, а не со слова «причина». Граница — место, где можно сравнить вход и выход: переход между mapper и адаптером, запись в базу, публикация сообщения или вызов внешнего API. Рядом с ней запишите фактический вход, ожидаемое поведение и наблюдаемый результат.</p>\n<p>В учебном примере объект заказа проходит через <code>order-mapper</code> и попадает в <code>pricing-adapter</code>. Адаптер принимает заказ только с непустым полем <code>currency</code>. После изменения mapper поле исчезает, а операция <code>preview-order</code> получает статус <code>blocked</code>. Это два наблюдения. Они ещё не доказывают, что mapper — единственная причина отказа.</p>\n<p>Сценарий синтетический: он не описывает production-систему, реальный трафик, время восстановления или фактический инцидент. Маленький вход нужен для воспроизводимой проверки формы рассуждения. В рабочем расследовании те же места заполняются данными из запроса, журнала, трассировки и версии контракта.</p>\n<h2>Механизм: пять состояний не смешиваются</h2>\n<table><caption>Что известно на каждом шаге учебной проверки</caption><thead><tr><th scope=\"col\">Состояние</th><th scope=\"col\">Запись</th><th scope=\"col\">Проверка</th><th scope=\"col\">Граница вывода</th></tr></thead><tbody><tr><td>Наблюдение</td><td><code>preview-order</code> вернул <code>blocked</code></td><td>Сохранить вход и ответ операции</td><td>Зафиксирован симптом, но не его причина</td></tr><tr><td>Гипотеза</td><td>После mapper отсутствует <code>currency</code></td><td>Сравнить объект до и после преобразования</td><td>Версия объясняет этот вход, но не все пути заказа</td></tr><tr><td>Действие</td><td>Временно выбрать известный mapper с тем же входом</td><td>Не менять одновременно retry, timeout и кеш</td><td>Решение ограничено выбранной границей</td></tr><tr><td>Проверка</td><td>Старый mapper вернул заказ с <code>currency</code></td><td>Повторить валидацию на том же входе</td><td>Подтверждено действие, а не устранение всех причин</td></tr></tbody></table>\n<p>В первой строке есть только симптом. Во второй появляется проверяемая гипотеза. В третьей действие меняет одну переменную. В четвёртой измеряется ожидаемый сигнал. Если добавить к откату повторные попытки и новый таймаут, улучшение результата уже нельзя будет связать с одной причиной.</p>\n<p>Наблюдение должно пережить неудачную гипотезу. Запись «после преобразования поле отсутствует» останется верной, даже если поле пропало до mapper. Запись «mapper отбросил поле» утверждает больше, чем показывает сигнал. Если эксперимент опровергнет эту версию, меняется гипотеза, а не прошлое наблюдение.</p>\n<h2>Конкретный пример с двумя преобразованиями</h2>\n<p>Код ниже воспроизводит симптом и отдельно проверяет ограниченный обход. В нём нет сети, базы и скрытого состояния, поэтому результат можно получить на любом запуске JavaScript:</p>\n<pre><code>const input = { amount: 1250, currency: 'RUB' };\n\nfunction mapOrderV2(order) {\n  return { amount: order.amount };\n}\n\nfunction mapOrderV1(order) {\n  return { amount: order.amount, currency: order.currency };\n}\n\nfunction validateForPricing(order) {\n  return typeof order.currency === 'string' &amp;&amp; order.currency.length &gt; 0\n    ? 'allowed'\n    : 'blocked';\n}\n\nconst mapped = mapOrderV2(input);\nconst symptom = validateForPricing(mapped);\n\nif (symptom !== 'blocked') throw new Error('expected the exercise symptom');\nif ('currency' in mapped) throw new Error('currency must be absent');\n\nconst restored = mapOrderV1(input);\nconst check = validateForPricing(restored);\n\nif (check !== 'allowed') throw new Error('the bounded check failed');</code></pre>\n<p>Первый вызов подтверждает воспроизводимость симптома: версия <code>V2</code> теряет поле до адаптера. Второй вызов проверяет только действие <code>A1</code> — выбор известного преобразования для того же объекта. Статус <code>allowed</code> не доказывает, что исправлены новая версия, все валюты, пустые значения, другие ветки или рабочая система.</p>\n<p>Важна и отрицательная проверка. Если <code>mapOrderV1</code> тоже вернёт <code>blocked</code>, обход не подтвердился. Нельзя переписать результат как «система всё равно восстановилась»: новый факт сужает поиск. Следующий шаг — сравнить вход до mapper, версию схемы, ветку маршрутизации и контракт адаптера.</p>\n<figure><img src=\"/assets/editorial/2020/incident-decision-record-2020.svg\" alt=\"Схема decision record: наблюдение E2 ведёт к гипотезе H1, ограниченному действию A1 и проверке V1; профилактика P1 имеет собственный критерий\" loading=\"lazy\" /><figcaption>Проверяемая цепочка отделяет временный обход от профилактики и не назначает виноватого.</figcaption></figure>\n<h2>Действие должно иметь trigger и сигнал</h2>\n<p>Во время инцидента решение выбирают быстро, но его границы можно записать сразу. Зафиксируйте trigger, изменение и ожидаемый сигнал. Добавьте условие возврата к диагностике. Тогда результат действия не смешается со случайным совпадением.</p>\n<p>В учебном случае trigger таков: на границе адаптера отсутствует <code>currency</code>. Изменение одно: для этого входа выбрать известный mapper. Ожидаемый сигнал — поле присутствует, а валидатор возвращает <code>allowed</code>. Условие возврата — любой другой ответ, отсутствие поля или расхождение входа; при нём действие считают неподтверждённым.</p>\n<p>Этот порядок не делает retry или timeout вредными сами по себе. Они проверяют другие гипотезы. Повторная попытка уместна при обоснованной временной ошибке и защите от дублей. Таймаут проверяет задержку, а не потерю поля. Каждой мере нужен собственный trigger, ожидаемый сигнал и отрицательный путь.</p>\n<h2>Профилактика меняет будущий путь</h2>\n<p>Фраза «добавить тест» слишком коротка для action item. Назовите контракт, место проверки и ожидаемый отказ. Например: mapper обязан сохранить непустой <code>currency</code>; проверка должна стоять перед вызовом <code>pricing-adapter</code>; минимальный вход без валюты должен приводить к явной ошибке до внешнего вызова.</p>\n<p>Профилактика не завершена в момент, когда её записали в отчёт. Она готова, когда изменение появилось в нужном коде, проверка запускается в этом пути, а отрицательный сценарий действительно обнаруживает нарушение. До этого состояние следует назвать планом. Иначе отчёт приписывает системе защиту, которой в ней ещё нет.</p>\n<p>Для рабочего postmortem полезно сохранить не только действие, но и влияние, исходные данные, contributing causes и follow-up. При этом техническая запись может быть blameless: она называет поле, границу и отсутствующую защиту, но не приписывает человеку намерение, которого нет в evidence.</p>\n<h2>Как проверить причинную связь</h2>\n<p>Сначала сохраните базовый результат. Затем измените только одну переменную и повторите проверку на сопоставимом входе. Сравните объект на границе, ответ валидатора и побочные сигналы. Если результат изменился, это evidence в пользу гипотезы, но не доказательство для всех вариантов.</p>\n<p>Чтобы не расширить вывод случайно, перечислите непроверенные ветки: другая версия схемы, пустая строка, неизвестная валюта, повторная доставка, параллельный маршрут и ошибка внешнего сервиса. Для каждой ветки укажите отдельный тест или наблюдение. Успех одного минимального примера остаётся успехом одного минимального примера.</p>\n<h2>Порядок действий</h2>\n<ol><li>Назовите одну границу и один наблюдаемый симптом. Сохраните вход, ответ, версию и время наблюдения.</li><li>Отделите факт от гипотезы: «поле отсутствует после преобразования» — наблюдение, «mapper его потерял» — версия для проверки.</li><li>Выберите один эксперимент с ограниченным радиусом и запишите trigger, ожидаемый сигнал и условие возврата.</li><li>Проверьте действие на том же входе. Не меняйте одновременно retry, timeout, кеш и формат данных.</li><li>Сохраните отрицательный результат, если сигнал не появился. Он меняет направление поиска, но не исправляет историю.</li><li>Проверьте соседние ветки и версии контракта отдельными входами, не распространяя вывод без evidence.</li><li>Опишите профилактику как изменение контракта, кода, теста или наблюдения и укажите критерий её выполнения.</li></ol>\n<h2>Ограничения модели</h2>\n<p>Разделение состояний не вычисляет корневую причину автоматически и не заменяет мониторинг, резервирование, контроль доступа, откат или техническое расследование. У одного отказа может быть несколько contributing causes: потеря поля, отсутствие проверки и слишком широкий обход. Для каждого условия нужны свои наблюдения.</p>\n<p>Код выше не измеряет доступность, задержку, нагрузку, восстановление или влияние на пользователей. Он не подтверждает, что конкретный mapper вызвал реальный отказ. В рабочей системе проверьте фактический контракт адаптера, версию схемы, трассировку поля, права, данные и внешние зависимости. Если данных нет, вывод ограничивается учебным сценарием.</p>\n<h2>Критерий готовности</h2>\n<p>Разбор готов, когда другой инженер без устного пересказа может назвать симптом и границу, увидеть исходный evidence, повторить ограниченное действие, получить ожидаемый сигнал и найти отрицательный путь. Он также должен видеть, что осталось непроверенным и какая профилактика защищает контракт в будущем.</p>\n<p>Финальная проверка должна отвечать на пять вопросов: что произошло; где это наблюдалось; какая гипотеза проверялась; что именно изменили; какой результат получен. Если на любой вопрос приходится отвечать «так принято» или «сервис восстановился», в записи не хватает evidence.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://sre.google/sre-book/managing-incidents/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Book: Managing Incidents</a> — официальный материал о сохранении живого состояния инцидента, разделении работы и восстановлении сервиса.</li><li><a href=\"https://sre.google/sre-book/postmortem-culture/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Book: Postmortem Culture</a> — официальный материал о фиксации влияния, действий, contributing causes и follow-up, а также о разборе без персонального обвинения.</li><li><a href=\"https://sre.google/sre-book/effective-troubleshooting/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Book: Effective Troubleshooting</a> — официальный материал о наблюдениях, проверяемых гипотезах, controlled change и подтверждающих или опровергающих сигналах.</li></ul>"
}