Бумажный самописец инцидентов: низкотехнологичная «чёрная коробка» для вашего следующего сбоя в проде

Когда прод «горит», никто не кричит: «Срочно откройте новую страницу в Confluence».

Обычно всё выглядит иначе: люди врываются на звонок, дэшборды вспыхивают графиками, чат прокручивается с бешеной скоростью, кто‑то шарит экран, десяток разрозненных заметок раскидывается по блокнотам, терминалам и наполовину созданным тикетам. Потом от вас ждут постмортем, и вы понимаете, что собираете картину происшествия по смутным воспоминаниям и обрывочным логам.

Именно в этот момент особенно полезен бумажный самописец.

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

Что такое бумажный самописец?

Бумажный самописец — это просто стандартизованный, распечатанный шаблон, который заполняет руководитель инцидента (или назначенный человек) во время аварии или серьёзного сбоя. По сути это ручная «чёрная коробка» для вашей продакшен‑среды.

Как и бортовой самописец в самолёте, он фокусируется на (a) входах, (b) выходах и (c) контексте, а не обязательно на внутренних механизмах в реальном времени:

• Входы — что мы делали: запущенные команды, изменения конфигурации, переключённые feature flags, запуски деплоев, откаты.
• Выходы — что мы наблюдали: метрики, изменения алёртов, аномалии в логах, влияние на пользователей, уровни ошибок, скриншоты.
• Контекст — что мы решили и почему: предположения, гипотезы, эскалации, кто подключился/ушёл, внешние факторы.

Его нужно заполнять во время инцидента, а не пытаться восстановить детали потом, когда память уже потихоньку стирает хронологию.

Ключевая идея: не доверяйте памяти — доверяйте бумаге.

Зачем низкие технологии, когда у нас столько инструментов?

Легко подумать: «У нас уже есть логи, трейсинг, дэшборды и incident‑канал. Зачем ещё бумага?» Причин несколько:

1. Во время инцидента инструменты распыляют информацию.

   • Алёрты — в одной системе, логи — в другой, история деплоев — в третьей, чат — в четвёртой.
   • Пока всё происходит, у никого нет полной картины в одном месте.

2. Люди принимают решения, которые нигде не логируются.

   • «Мы решили пока не делать rollback, потому что…»
   • «Мы временно отключили это правило как эксперимент.»
   • «Мы посчитали базу здоровой, исходя из X.» Эти моменты критичны для понимания, почему всё пошло так, а не иначе, но их почти никогда нет в телеметрии.

3. Стресс резко ухудшает качество памяти.

   • Время «плывёт».
   • Люди путают, кто что делал и в какой последовательности.
   • Важные детали («на 10:14 был короткий всплеск») исчезают.

4. Бумага надёжна и не создаёт трения.

   • Она не падает, не истекает по таймауту и не требует авторизации.
   • Любой может взять лист, начать писать, передать другому.
   • Лист лежит на столе или висит на стене и служит общей точкой опоры.

Бумажный самописец — намеренно скучная технология. Его ценность — в дисциплине и структуре, которые он привносит в фиксацию событий.

Что фиксировать: превращаем хаос в понятный рассказ

Цель не в том, чтобы написать роман, а в том, чтобы получить чёткую хронологическую историю инцидента. Хороший шаблон бумажного самописца подталкивает записывать:

1. Базовые метаданные инцидента

• Название / ID инцидента
• Дата и время начала (первый алёрт / первый репорт от пользователя)
• Кто первым заметил проблему
• Incident commander или основной ответственный

Кажется банальностью — пока вы не попробуете потом разобраться, к какому из трёх похожих сбоев относился тот самый тред в Slack.

2. Таймлайн и действия

Просто устроенная таблица отлично работает:

Не нужны полные детали («точная команда kubectl…»), — достаточно информации, чтобы восстановить, что и в какой последовательности происходило.

3. Снимки состояния системы

В ключевые моменты зафиксируйте, как выглядела система:

• Уровни ошибок
• Загрузка CPU / память
• Размеры очередей
• Показатели здоровья базы данных
• Состояние внешних зависимостей (платёжные провайдеры, DNS и т.п.)

Думайте об этом как о показаниях «приборной панели» в важные моменты: до изменения, после изменения, при появлении нового симптома и т.д.

4. Решения и гипотезы

Здесь самописец становится по‑настоящему ценным. Для каждого значимого решения фиксируйте:

• Что мы считали происходящим?
• Что решили сделать? (или не делать)
• Почему так решили? (предпосылки, ограничения, компромиссы)

Пример записи:

10:15 – Гипотеза: всплеск задержки вызван недавним деплоем payment-service. Решение: сначала откатиться на предыдущую версию, а уже потом масштабировать инфраструктуру — откат быстрый и малорисковый.

Такие заметки позже объяснят не только что случилось, но и почему это тогда казалось разумным.

5. Разрешение инцидента и восстановление

В финале зафиксируйте:

• Время, когда сервис восстановился / рост влияния на пользователей остановился
• Какое изменение или событие совпало по времени со стабилизацией
• Какие временные меры и обходные решения всё ещё включены

Это помогает ответить на вопрос: что на самом деле всё починило? (что в горячке часто совсем не очевидно).

От бумаги к постмортему: как улучшить разбор корневых причин

После инцидента этот лист превращается в качественный вход для постмортема и root cause analysis (RCA).

Многие команды сталкивались с ситуацией: вы собираетесь на постмортем и проводите половину времени, споря о таймлайне. С бумажным самописцем у вас уже есть:

• Хронологический рассказ о ключевых действиях
• Снимки состояния системы в важные моменты
• След решений — что люди думали и почему так действовали

Это идеальная основа для структурированных методик RCA, например 5 Whys («5 почему»).

Пример: поддержка метода «5 почему»

Представим аварию, когда checkout 30 минут возвращал ошибки. С записанным таймлайном сессия по «5 почему» может выглядеть так:

1. Почему checkout не работал?
   Потому что payment-service начал возвращать 500‑е ошибки.

2. Почему payment-service начал возвращать 500‑е?
   Потому что он исчерпал подключения к базе на фоне всплеска нагрузки.

3. Почему исчерпал подключения?
   Потому что новая версия, задеплоенная в 10:02, увеличила использование БД на один запрос.

4. Почему эта версия увеличила нагрузку на БД?
   Потому что новая фича добавила несколько лишних запросов на каждую транзакцию.

5. Почему это изменение дошло до продакшена незамеченным?
   Потому что у нас нет перфоманс‑регрессионных тестов и реалистического нагрузочного тестирования в CI.

Бумажная запись помогает верифицировать каждый шаг:

• В 10:02 вы зафиксировали деплой.
• В 10:04 — насыщение подключений к базе.
• В 10:07 — откат и его эффект.

Теперь вы можете различать ближайшие причины (деплой увеличил нагрузку на БД) и системные причины (нет защит от таких изменений), а именно за этим и делается RCA.

Выявление слабостей дизайна, которых не видно в логах

Логи и метрики отлично рассказывают, что делала система. Но гораздо хуже объясняют, что система позволяла делать и что поощряла или терпела организация.

Типичные паттерны, которые вскрывает бумажный самописец:

• Отсутствующие защитные механизмы
  «Мы вручную поменяли эту настройку во время инцидента и поняли, что только она мешает потерять данные. Почему нет автоматического guardrail’а?»

• Тихо рухнувшие предположения дизайна
  «Мы думали, что сервис выдержит 2× трафика, а записи показывают, что он посыпался уже при 1,2×. Значит, наша модель емкости неверна.»

• Организационные пробелы
  «Мы потеряли 10 минут, потому что никто не понимал, кто может одобрить rollback для этой системы.»

• Неясная зона ответственности
  «В 10:10 стало ясно, что никто на созвоне не понимает компонент X. Почему для него нет выделенного on‑call?»

Это как раз те инсайты, которые действительно двигают надёжность вперёд, но их почти никогда не видно в логах.

Как спроектировать свой бумажный самописец

Вам не нужно идеальное решение. Нужен маленький и стандартный инструмент, которым люди реально будут пользоваться. Обычный лист формата A4/Letter прекрасно подходит.

Рекомендуемые секции:

1. Шапка

   • ID / название инцидента
   • Дата
   • Время начала
   • Incident commander

2. Краткий обзор влияния (первоначальный)

   • Затронутые системы
   • Видимые пользователю симптомы
   • Оценка серьёзности (например, SEV‑1/2/3)

3. Таблица таймлайна
   Колонки: время, участник, действие/наблюдение, заметки.

4. Ключевые решения и гипотезы
   Короткие пункты:

   • Время
   • Решение
   • Обоснование

5. Снимки состояния системы
   Несколько строк, чтобы набросать ключевые метрики в важные моменты.

6. Итоговое резюме по разрешению инцидента

   • Время стабилизации
   • Вероятное исправление / изменение
   • Оставшиеся риски или временные меры

Распечатайте пачку листов, держите рядом с теми, кто управляет инцидентами, и по желанию сделайте цифровую версию с теми же полями для распределённых команд.

Как сделать его частью практики надёжности

Бумажный самописец — не серебряная пуля. Это небольшая практика, которая при регулярном использовании открывает дорогу к более серьёзным улучшениям.

Чтобы встроить её эффективно:

• Назначайте ответственного за записи в каждом инциденте (часто это incident commander или выделенный «писарь»).
• Кратко обучите людей, как им пользоваться — 5–10 минут в онбординге on‑call’а обычно достаточно.
• Опирайтесь на бумагу осознанно во время постмортемов, используя её как основной источник таймлайна.
• Итерируйте шаблон после нескольких инцидентов: убирайте поля, которые никто не заполняет, добавляйте подсказки там, где постоянно не хватает данных.
• Используйте его как дополнение к инструментам, а не замену: он не вместо дэшбордов и чатов, а чтобы связать их в целостную картину.

Со временем вы, скорее всего, заметите, что инциденты ощущаются меньше как хаос и больше как структурированные расследования.

Вывод: записывайте, пока ещё свежо в памяти

Инциденты в продакшене — стрессовые, беспорядочные и очень быстрые. Детали, которые больше всего важны для обучения — что люди думали, решали и наблюдали, — как раз и теряются в первую очередь.

Бумажный самописец даёт простой, устойчивый, низкотехнологичный способ фиксировать эту историю в реальном времени. Он превращает размытое воспоминание об аварии в пригодный для работы рассказ, который подпитывает более качественные постмортемы, глубокий разбор корневых причин и конкретные улучшения систем и процессов.

У вас уже есть «чёрная коробка» для машин в виде логов и метрик. Дайте такую же людям — с помощью всего лишь листа бумаги и ручки.