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

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

Можно её игнорировать и дальше замазывать трещины шпаклёвкой, а можно относиться к каждому простою как к шансу перерисовать чертёж того, как на самом деле работает ваша система (и ваша команда).

Этот пост — про простую, почти старомодную идею: рисуйте свои инциденты.

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

Постмортемы — это изменение культуры, а не галочка в чек‑листе

Когда вы внедряете постмортемы (или пытаетесь починить сломанные), очень легко начать относиться к ним как к очередной технической практике:

• «Добавим шаблон в Confluence»
• «Попросим root cause и action items»
• «Заведём задачи в Jira»

Это не трансформация; это бумажная волокита.

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

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

Это работа с культурой.

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

И вот здесь в игру входят небольшие, аналоговые, визуальные разборы инцидентов.

Перестаньте надеяться, что системы «починят себя сами»

После инцидента часто подкрадывается удобная ложь:

«Мы поправили баг и добавили дашборд, значит, всё в порядке».

Что произошло на самом деле:

• Вы лечили симптомы, а не структуру.
• Вы изменили один путь в коде, а не социотехническую систему.
• Вы понадеялись, что система «научится» после патча.

Системы не учатся от надежд.

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

Без осознанного анализа вы просто перекидываете кубики с чуть другим случайным зерном.

Начните с малого: лёгкий разбор инцидента

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

Цельтесь примерно в такой формат:

• 30–45 минут на каждый подходящий инцидент
• В течение 1–3 рабочих дней после события
• Не более 6–8 человек: участники + один ведущий/фасилитатор
• Результат: одностраничное текстовое резюме и один аналоговый скетч

И всё. Никакой сложной таксономии, шести комитетов и мгновенной автоматизации.

Почему мало и просто?

• Меньше сопротивление. Люди охотнее пробуют формат, который не ощущается как процедура «дознания».
• Больше повторений. Вы можете проводить больше разборов чаще, формируя привычку и нормализуя практику.
• Улучшения заметнее. В небольшом формате легко пробовать и обкатывать правки процесса.

Вы не строите The Final Postmortem Process™. Вы строите первый безопасный, повторяемый шаг.

Используйте инженерный каркас реагирования на инциденты

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

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

1. Объявляем инцидент

   • Понятные уровни серьёзности (SEV‑1, SEV‑2 и т. п.).
   • Один человек — Incident Commander (IC, руководитель инцидента).

2. Стабилизируем систему

   • Сначала — «остановить кровотечение» (откаты, feature flags, failover).
   • Ведём лёгкий журнал событий в реальном времени («в 10:32 откатили X»).

3. Коммуницируем

   • Один единый канал или комната обновлений статуса.
   • Регулярные апдейты (например, каждые 15–30 минут для SEV‑1).

4. Документируем сразу после

   • IC сводит таймлайн по журналу событий.
   • Кратко фиксируем гипотезу о причинах (может оказаться неверной — это нормально).

5. Разбираем

   • Назначаем небольшой разбор с участниками инцидента.
   • Вместе рисуем аналоговый поэтажный план отказа.

Цель — не «идеальный» фреймворк, а понятный, обучаемый паттерн, который держит всех в одном контексте и даёт чистый вход в разборы.

Аналоговый чертёж: рисуем поэтажный план инцидента

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

Бумага — нет.

На разборе отложите дашборды в сторону и возьмите:

• Лист бумаги (или доску)
• Толстый маркер
• Стикеры, если есть

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

Что рисовать

1. Комнаты = крупные компоненты или домены

   • Сервисы, внешние зависимости, базы данных, очереди, точки входа пользователей.
   • Каждой — свой прямоугольник/комната, подписанная простым языком («Checkout API», «Поисковый индекс», «Платёжный провайдер»).

2. Двери и коридоры = взаимодействия

   • Стрелки или проходы, показывающие запросы, события, потоки данных.
   • Обозначьте направление (кто кого вызывает, от кого кто зависит).

3. Люди = акторы и роли

   • Дежурный инженер, SRE, поддержка, пользователи.
   • Где они были в этом «здании», когда всё ломалось? Кто что заметил и когда?

4. Зоны повреждений = точки отказа

   • Где впервые проявился наблюдаемый сбой?
   • Где он реально зародился?
   • Подсветьте области каскадного эффекта.

5. Ограждения безопасности = существующие (или нужные) защиты

   • Circuit breakers, rate limits, fallbacks, плейбуки, ранбуки.
   • Отметьте, что сработало, чего не было, о чём никто не знал.

Как использовать скетч

Пока рисуете, задавайте вопросы:

• Где реальность не совпала с нашим ментальным образом системы?
• Где информация двигалась слишком медленно или не двигалась вообще?
• Что сделало этот инцидент больше, чем он мог бы быть?

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

«Я думал, что веб‑приложение здесь ходит прямо в базу данных».

«Подождите, эта очередь фан‑аутится на три консьюмера?»

Такие неожиданности — золото. Именно в них живёт работа по повышению устойчивости.

Сфотографируйте скетч и приложите к документу разбора. Ему не нужно быть красивым; он должен быть честным.

Делайте разбор без обвинений и с фокусом на устойчивость

Если ваши разборы напоминают трибунал, они быстро умрут.

Проговорите правила явно:

• Никакой вины и стыда. Мы рассматриваем действия как разумные с точки зрения того, что люди знали и в каких были ограничениях.
• Мы ищем вклад системы, а не ошибки людей.
• Мы оптимизируем за обучение, а не наказание.

На практике это значит:

• Запретить «человеческую ошибку» как root cause. Спросить: почему такую ошибку было легко совершить?
• Вместо «Кто накосячил?» спрашивать «Что сделало такой исход вероятным?»
• Фокусироваться на том, как расширить диапазон успешного поведения под нагрузкой, а не на том, чтобы сильнее «закрутить гайки» отдельным людям.

Вопросы, которые помогают строить устойчивость:

• Как мы могли бы обнаружить это раньше?
• Как мы могли бы сузить blast radius (зону поражения)?
• Как сделать так, чтобы следующий похожий инцидент был максимально скучным в обработке?

Результаты могут включать:

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

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

Это и есть изменение культуры.

Итерации и автоматизация по мере взросления культуры

Вам не нужен полностью автоматизированный конвейер постмортемов в первый же день.

Пусть ваша практика развивается вместе с культурой:

1. Фаза 1 — Вручную и аналогово

   • Простой инженерный каркас реагирования.
   • Бумажные или досочные чертежи инцидентов.
   • Короткие письменные резюме.

2. Фаза 2 — Повторяемые паттерны

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

3. Фаза 3 — Точечная автоматизация

   • Инструменты, которые заранее подтягивают таймлайны, логи, метрики.
   • Дашборды, отражающие уроки из прошлых инцидентов.
   • Ранбуки, привязанные к алертам.

4. Фаза 4 — Контур непрерывного улучшения

   • Регулярные ретроспективы по самим инцидент‑ревью: что работает, что даёт шум?
   • Кросс‑командный разбор повторяющихся паттернов (например, постоянные сбои зависимости).
   • План работ, явно связанный с темами устойчивости из прошлых инцидентов.

К моменту, когда вы глубоко автоматизируете процесс, основную работу делают уже ваши нормы, а не шаблоны.

Автоматизация в таком случае усиливает здоровую культуру, а не цементирует дисфункциональную.

Собираем всё вместе: ремонт до того, как перевернёте страницу

Представьте свою систему дежурств — людей, процессы и софт — как здание, в котором вы живёте, параллельно перестраивая его по комнате за раз.

Каждый инцидент — это строительная инспекция.

Чтобы такие инспекции имели смысл:

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

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

Перерисуйте то, что на самом деле произошло.

Вы рисуете не просто прошлую неудачу — вы проектируете поэтажный план более устойчивого будущего.