Во время крупного матча техническая проблема быстро превращается в проблему координации. Playbook нужен не для описания каждой возможной аварии, а для заранее принятых решений: кто командует, когда включается safe-mode, какие компоненты можно отключить и как проверяется восстановление.

Incident commander отделяет решение от диагностики

Владельцы feed, pricing, client и коммуникаций продолжают разбирать свои контуры, но один человек управляет приоритетами и фиксирует решение. Это снижает риск, что несколько команд одновременно меняют систему в противоположных направлениях.

Guardrails задаются до начала события

Пороги для suspend, fallback и безопасной деградации должны иметь владельца и понятную причину. Числовые значения зависят от реальной платформы и не должны выдумываться в редакционном материале; важен сам принцип предварительно согласованного триггера.

Хронология решений живёт отдельно от чата

Технический чат быстро становится шумным. Короткий журнал времени, симптома, решения и ответственного помогает восстановить причинность и позже провести postmortem без реконструкции по сотням сообщений.

Учебный сценарий. Перед ключевым событием растёт задержка feed. Команда сравнивает её с заранее определённым guardrail, включает согласованный safe-mode и фиксирует момент переключения. Это не описание реального инцидента.

Восстановление заканчивается reconciliation

После возврата сервисов нужно проверить backlog, согласованность market state и клиентских проекций. Система может «подняться» технически, но продолжать отдавать устаревший кэш. Только после reconciliation инцидент можно закрывать.

Postmortem должен менять систему

Итогом становятся не общие выводы, а конкретные защитные меры, владельцы и критерии проверки. Отдельно полезно записывать, какие guardrails сработали — это сохраняет рабочие решения, а не только список ошибок.

Практический контекст

Что должно быть решено до большого матча

Incident playbook полезен только тогда, когда роли и пороги определены заранее. Во время нагрузки нет времени обсуждать, кто может остановить публикацию рынка, какой feed считать резервным и когда переключение безопаснее ожидания. Решения стоит привязать к наблюдаемым сигналам и конкретным действиям.

Контрольные вопросы

  • назначить владельца инцидента и отдельного координатора коммуникаций
  • описать условия suspend, fallback и полного отключения функции
  • вести журнал решений с временем и причиной
  • после восстановления выполнить reconciliation и проверить пропущенные события

После инцидента важен не поиск виноватого, а восстановление цепочки причин: какой сигнал появился первым, какой механизм сработал и что видел пользователь. Такой postmortem делает следующий playbook точнее.

Decision log сохраняет не только команды, но и основания

Во время инцидента через час легко забыть, почему provider не переключили сразу или зачем временно отключили часть publish path. Короткая запись «решение → наблюдаемый сигнал → ожидаемый риск» помогает следующей смене продолжить работу без повторного обсуждения. В неё не нужно копировать весь чат. Достаточно timestamp, owner, выбранного действия и ссылки на метрику/trace/audit event. После инцидента этот же журнал становится основой честного timeline и показывает, какие guardrails были известны заранее, а какие пришлось изобретать на ходу.

Playbook нужен до матча, а не в момент первого критичного алерта

Во время крупного события самая дорогая часть инцидента — не всегда техническая неисправность. Команда теряет время на выяснение ролей, безопасных режимов деградации и того, кто имеет право менять trading/config state. Поэтому playbook должен заранее фиксировать несколько практических вещей: кто ведёт incident channel, кто принимает решение о деградации, какие изменения запрещены без второго подтверждения и по каким признакам начинается recovery. Это снижает количество параллельных «быстрых исправлений», которые потом мешают понять исходную причину.

Решения лучше привязывать к сигналам, описанным в observability live-платформы. Например, рост server CPU сам по себе ещё не объясняет пользовательский impact, а увеличение возраста опубликованного state уже показывает конкретную потерю свежести. Если playbook опирается на продуктовые SLI, дежурная смена быстрее отличает локальный шум от проблемы, требующей suspend или ограничения функциональности.

Recovery завершается не тогда, когда график снова зелёный. Нужны проверка backlog, reconciliation спорных версий и подтверждение, что защитный режим отключён осознанно. Только после этого инцидент можно переводить в review и собирать timeline без догадок.

Хороший playbook также ограничивает коммуникационный шум. Один канал используется для решений и timeline, отдельные рабочие треды — для гипотез, а ключевые изменения фиксируются с временем и владельцем. Это не бюрократия: во время восстановления нескольких компонентов легко забыть, кто включил fallback и почему. После инцидента такой журнал позволяет восстановить причинную последовательность без чтения сотен несвязанных сообщений и заметно улучшает качество postmortem.