Инцидентный трамвай в карандашных набросках: как провести одну «бумажную карту» через все стадии аварии

Когда в продакшене что‑то ломается, первым в деградированный режим уходит ваш мозг.

Вы жонглируете алертами, логами, тредами в Slack, вопросами руководителей про ETA, обрывками воспоминаний о runbook’ах и, возможно, встревоженным клиентом. В таком стрессе у мозга ещё нет материала для чёткого рассуждения. Он пытается построить ментальную карту происходящего, пока вы уже ведёте трамвай.

Этот текст — о том, как строить эту карту осознанно — с помощью «инцидентного трамвая в карандашных набросках»: простой, общей, постоянно дорабатываемой схемы, которая проходит через все стадии аварии. Представьте один лист бумаги (или доску, или цифровой аналог), на который могут смотреть все, чтобы понять:

• Что мы знаем
• Что мы пробуем
• Кто за что отвечает
• Где место для ИИ (и где его точно быть не должно)

А позже эта же карта поможет восстановить ход инцидента и написать ясный, полезный постмортем.

Начинайте с мозга читателя, а не с часов

Большинство разборов инцидентов пишут так: «В 09:13 сработал алерт. В 09:16…»

Хронология легко логируется, но её тяжело читать. Когда я пытаюсь понять аварию — по дашборду, runbook’у или постмортему — мне нужна карта до таймлайна.

Пересоберите историю вокруг когнитивной нагрузки

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

1. Карта верхнего уровня (общая картина)

   • Что сломалось (симптом)?
   • Что пострадало (пользователи, системы)?
   • Какого типа был сбой (производительность, порча данных, недоступность и т.п.)?
   • Что его починило (на высоком уровне)?

2. Обзор системы (как всё связано)

   • Простая схема основных задействованных компонентов
   • Стрелки, показывающие поток данных/трафика

3. Ключевые точки принятия решений

   • Что мы считали правдой в тот момент
   • Что решили сделать
   • Что в итоге узнали

4. Подробная временная шкала

   • События, логи, метрики, изменения, выдержки из чатов

Люди читают сверху вниз, а не слева направо по времени. Используйте это: стройте документы по инциденту так, чтобы они соответствовали тому, как мозг наводит порядок в хаосе.

«Одна бумажная карта» для инцидента

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

На этом листе вы рисуете «greenhouse tram» — схему потока: по коробке на каждый ключевой компонент и линии трафика между ними. По мере развития инцидента вы добавляете:

• Красные крестики на компоненты, которые подозреваются или подтверждённо сломались
• Стикеры или выноски с гипотезами и тестами («Если сделаем X, ожидаем увидеть Y»)
• Имена или роли рядом с каждой активной задачей («Откат API — владелец On‑call A»)

Эта карта становится вашим визуальным нервным центром инцидента.

Что попадает на карту?

Минимальный набор:

• Точка входа пользователя: где начинается трафик (браузер, мобильное приложение, внешний потребитель API)
• Критический путь: балансировщики нагрузки → API‑шлюзы → сервисы → базы данных → очереди и т.д.
• Текущий симптом: где мы видим проблему (например, «Latency checkout > 5s», «Ошибка 500 на /login»)
• Последняя известная здоровая точка: где путь ещё был в норме
• Известные изменения: деплой, конфиг‑изменения, обновления инфраструктуры, затрагивающие этот путь

Вы обновляете карту в реальном времени, когда:

• Собираете данные (метрики, логи, трейсы)
• Меняете гипотезы («Может, дело в базе… нет, всё‑таки в кэширующем слое»)
• Выполняете действия (фейловер, откат, переключение feature flag’ов)

Эта единая карта — тот самый трамвайный маршрут, по которому вся команда едет через аварию.

Проектируйте процесс под мозг в стрессе

Во время инцидента ни у кого нет полной картины. Люди:

• Частично информированы
• На адреналине
• Постоянно выдёргиваются из контекста

Это не баг вашей команды, так устроены люди.

Поэтому проектируйте процесс инцидентов и документацию под низкую когнитивную нагрузку:

1. Делайте runbook’и визуальными и просматриваемыми взглядом

• Начинайте каждый runbook с:
  • «Вы здесь, если…» (симптомы)
  • Простой схемы задействованных систем
  • 3–5 шагов верхнего уровня до любых детализированных подпунктов
• Используйте списки и явные проверки:
  • «Убедитесь, что метрика X выше Y в течение Z минут. Если нет — остановитесь и переоцените ситуацию»

2. Сделайте роли кристально понятными

На бумажной карте всегда отображайте:

• Incident Commander (IC) — ведущий по инциденту
• Comms lead — ответственный за коммуникации
• Основных респондентов по каждому подсистеме

Когда зоны ответственности явно обозначены, люди не тратят ресурсы на мысли «Кто этим занимается?» или «Это вообще моя задача?».

3. Ограничивайте число активных веток расследования

Поощряйте респондентов:

• Откладывать некритичные идеи в видимую секцию «потом» на карте
• Фокусироваться на одной гипотезе за раз
• Явно закрывать гипотезы («Исключено: сетевой путь A»)

Цель — сделать состояние расследования видимым, чтобы мозг не держал всё это в оперативной памяти.

Роль ИИ: ассистент, а не авторитет

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

Относитесь к ним как к ассистентам, а не авторитетам.

Известные слабые места ИИ в инцидентах

• Логическое рассуждение: ИИ часто выдаёт правдоподобные, но неверные цепочки причин и следствий.
• Галлюцинации: он может выдумывать API, флаги или конфиги, которых не существует.
• Недостаток контекста: он не видит всего, что видите вы — особенно сигналы живой системы — если вы специально не скормите ему этот контекст.

Безопасные способы использовать ИИ во время аварии

На бумажной карте вы можете прямо помечать идеи или код с пометкой «AI‑assisted».

ИИ особенно полезен, когда его применяют для:

• Суммаризации логов или ошибок, которые вы ему вставляете
• Подсказок поисковых запросов для логов или метрик
• Генерации шаблонных диагностических скриптов (например, скрипт, который регулярно бьёт health‑endpoint)
• Черновиков обновлений runbook’ов или резюме инцидента постфактум

Во всех этих случаях требуется человеческая валидация.

Опасные способы использования ИИ (без ограничений)

• Спросить: «Из‑за чего эта авария?» — и сразу действовать по ответу
• Давать ИИ менять прод‑конфиги или infra‑код без ревью
• Принимать от ИИ запросы или миграции, затрагивающие реальные пользовательские данные, без тестов

Любое предложение ИИ, которое меняет код / конфиги / данные, следует рассматривать как:

• Код от неизвестного джуниора,
• Который может оказаться очень умным,
• Но которого вы должны жёстко ревьюить и тестировать.

Это тоже можно отражать на карте: «Гипотеза от ИИ: X. Ревью человеком: Y. Статус: принято/отклонено». Так люди остаются хозяевами рассуждений.

Изменения с помощью ИИ: каждый раз ревью и тесты

Во время кризиса возникает сильное искушение: «ИИ говорит, что этот запрос всё починит, давайте просто его запустим».

Сдержитесь. Введите явные правила:

1. Все изменения, сгенерированные ИИ, проходят ревью

   • Названный человек просматривает diff, скрипт или команду.
   • Ревьюер фиксируется на карте инцидента.

2. Изменения тестируются сначала в максимально безопасной среде

   • Staging, shadow‑трафик или ограниченный blast radius (например, один shard или tenant).

3. Шаги отката прописываются до выполнения

   • «Если что‑то пойдёт не так, мы откатимся так: X, Y, Z».

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

Проводите постмортем в течение 48 часов

Инцидент не заканчивается в момент, когда графики снова зелёные.

Чем дольше вы тянете с постмортемом, тем сильнее распадается общая карта. Люди забывают:

• Что они на самом деле думали в тот момент
• Какие пути исследовали и бросили
• Насколько они были в стрессе или замешательстве

Чтобы восстановленная карта была точной, введите простое правило:

Проводить постмортем в течение 48 часов после разрешения инцидента.

Запланируйте встречу, пока вы ещё в инцидентном канале.

Этот короткий срок даёт:

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

Соберите полную картину с помощью качественных данных

Метрики и логи показывают, что произошло. Они редко показывают, как это ощущалось и почему люди приняли те или иные решения.

Хороший постмортем рассматривает инцидент как событие «люди + системы». Чтобы зафиксировать человеческую сторону, собирайте качественные данные:

1. Короткие анкеты

После разрешения инцидента отправьте короткую форму всем участникам:

• Что было самым непонятным?
• В какой момент вы чувствовали себя наиболее «застрявшими»?
• Какие инструменты/документы помогали, а какие мешали?
• Чего вам не хватало на экране?

2. Краткие интервью

Для ключевых участников (IC, основные респонденты, on‑call разработчики):

• 10–15‑минутные разговоры
• Фокус на точках выбора: «В 10:27 почему вы выбрали путь A, а не B?»

3. Заметки от первого лица

Поощряйте респондентов вести заметки с таймстампами во время инцидента (даже в виде грубых пунктов). Они помогают восстановить:

• Реальные гипотезы vs. вычищенную задним числом версию
• Эмоциональное состояние («Здесь я был совсем не уверен»)

В письменный постмортем вплетайте эти перспективы вместе с данными. Так вы получите настоящую карту инцидента, а не только отлакированную техническую версию.

Собираем всё вместе

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

Резюмируя:

• Структурируйте документы под когнитивную нагрузку: сначала карта верхнего уровня, потом таймлайн.
• Используйте одну визуальную карту, чтобы отслеживать системы, гипотезы, ответственность и действия.
• Проектируйте под мозг в стрессе: чёткие роли, визуальные runbook’и, минимум параллельных веток расследования.
• Относитесь к ИИ как к ассистенту: полезен, быстрый, иногда неправ — никогда не источник истины.
• Ревьюйте и тестируйте все изменения от ИИ как недоверенный код.
• Проводите постмортем в течение 48 часов, пока память свежа.
• Собирайте качественные данные, чтобы понять не только, что сломалось, но и как люди проходили через хаос.

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