Аналоговое колесо историй об инцидентах: смена перспектив через один и тот же сбой

Когда вы внутри инцидента, всё ощущается хаотичным. А когда позже читаете post-incident отчёт — картина странно плоская. Таймлайны, метрики и root cause необходимы, но они часто упускают живой опыт: кто что чувствовал и когда; как фактически принимались решения; где на самом деле ломалась коммуникация.

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

Используемое как часть Post-Incident Review (PIR), «колесо» превращает один болезненный инцидент в устойчивый источник обучения, эмпатии и улучшения надёжности.

Почему именно колесо обозрения?

Колесо обозрения — отличный образ для одного инцидента:

• Одна конструкция, разные виды: все едут на одном аттракционе (инцидент), но то, что вы видите, зависит от вашего кресла (роли).
• Вращение перспектив: целиком увидеть картину из одного кресла невозможно — нужно «прокрутиться» и сравнить виды.
• Предсказуемый ритуал: у поездки есть понятные начало, круг и завершение — как и у хорошего post-incident процесса.

У большинства команд уже есть технические ритуалы — таймлайны инцидентов, разбор метрик, root cause analysis. «Колесо» добавляет к ним социально-эмоциональный и перспективный слой, помогая командам:

• Выстраивать эмпатию между ролями
• Улучшать коммуникационные протоколы
• Прояснять зоны ответственности за принятие решений
• Реже повторять одни и те же ошибки, понимая не только что произошло, но и как это ощущалось и почему люди поступали именно так

Как колесо инцидента встраивается в Post-Incident Review

Представьте ваш PIR из трёх частей:

1. Факты и сигналы – Что произошло? Когда? Что показывали системы?
2. Решения и потоки действий – Кто что сделал? На основании какой информации и в каких ограничениях?
3. Перспективы и влияние – Как разные роли переживали одни и те же события?

«Колесо» живёт в части 3, но подсвечивает части 1 и 2. Вы по‑прежнему проводите обычный post-incident разбор (таймлайн, импакт, причины). Затем вы:

• Выбираете один конкретный инцидент для анализа
• Определяете 4–6 ключевых ролей (кресла на колесе обозрения)
• Проходите по инциденту с точки зрения каждого кресла
• Фиксируете инсайты и улучшения, полезные для всех

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

Подготовка вашего аналогового колеса

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

Шаг 1: Определите кресла (роли)

Выберите перспективы, наиболее релевантные для этого инцидента. Например:

• On-call инженер / incident commander
• Клиент (или конечный пользователь)
• Поддержка / customer success
• Продуктовый менеджер
• Руководство (VP / CTO)
• SRE / platform / reliability инженер

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

Шаг 2: Обозначьте стадии жизненного цикла инцидента

По верхнему или боковому краю доски (или вниз по странице шаблона) определите стадии жизненного цикла:

1. Ранние сигналы – первые намёки, что что‑то не так
2. Осознание – момент, когда это уже точно инцидент
3. Эскалация – привлечение новых людей / объявление severity
4. Митигация – активная работа по снижению импакта
5. Разрешение – системы в норме / инцидент закрыт
6. Последствия – коммуникация, фоллоу‑апы, эмоциональный «шлейф»

История каждой роли будет проходить через эти же стадии.

Шаг 3: «Прокрутите» каждое кресло

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

Важное правило: одновременно «говорит» только одно кресло. Остальные слушают и делают пометки.

Распечатанные подсказки для каждого кресла

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

Кресло 1: On-call инженер / Incident Commander

Подсказки по стадиям (повторяются для каждой стадии):

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

Линза надёжности:

• Где инструменты помогли, а где мешали?
• Где коммуникация была понятной / непонятной?
• Понимал(а) ли ты, у кого есть полномочия решить X?

Кресло 2: Клиент / конечный пользователь

В комнате может не быть реального клиента, но его перспективу всё равно можно реконструировать.

Подсказки по стадиям:

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

Линза надёжности:

• Был ли импакт описан языком клиента, а не внутренним жаргоном?
• Задали ли мы реалистичные ожидания по срокам и рискам?

Кресло 3: Поддержка / Customer Success

Подсказки по стадиям:

• Что говорили клиенты на этой стадии?
• Какая информация у меня была, чтобы им ответить?
• Насколько совпадали внутренние апдейты с тем, что я говорил(а) клиентам?
• Где я чувствовал(а) себя в тупике или «под ударом»?
• Какой шаблон, плейбук или данные помогли бы?

Линза надёжности:

• Есть ли стандартные шаблоны коммуникации на время инцидентов?
• Есть ли чёткое выравнивание между статус‑страницей, support‑макросами и внутренними обновлениями?

Кресло 4: Продуктовый менеджер

Подсказки по стадиям:

• Какие риски или компромиссы по этой системе мы уже знали заранее?
• О чём я беспокоился(лась), когда рос импакт? (SLA, roadmap, контракты)
• Какие решения по митигации я поддержал(а)?
• Как инцидент повлиял на приоритеты после него?

Линза надёжности:

• Сбалансированы ли надёжность и фичерная разработка в планировании?
• Выявил ли инцидент отсутствие SLI/SLO или неясные обязательства перед пользователями?

Кресло 5: Руководство (VP / CTO)

Подсказки по стадиям:

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

Линза надёжности:

• Понятны ли определения уровней severity и критерии эскалации?
• Есть ли стандартная, надёжная «частота и формат» коммуникации во время крупных инцидентов?

Кресло 6: SRE / Platform / Reliability инженер

Подсказки по стадиям:

• Чему этот инцидент научил меня о реальном поведении системы vs нашей ментальной модели?
• Где observability помогла, а где подвела?
• Какой фундаментальный технический или процессный долг всплыл?
• Какие устойчивые улучшения реально можно внедрить?

Линза надёжности:

• Какие защитные механизмы не сработали (или отсутствовали)?
• Какие изменения сильнее всего снизят вероятность повтора или масштаб ущерба?

Как сделать процесс безобвинительным и эмоционально безопасным

«Колесо» работает только если люди чувствуют себя в безопасности, рассказывая правду о том, что:

• Они были в замешательстве
• Пропустили сигналы
• Чувствовали перегруз или страх
• Принимали решения «наугад» в условиях неопределённости

Чтобы защитить эту честность:

1. Чётко задайте рамку

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

2. Запретите язык задним числом

   • Избегайте: «Ты должен был понять…»
   • Заменяйте на: «Исходя из того, что было видно тогда, какие опции казались доступными?»

3. Считайте эмоции данными

   • Перегруз, замешательство, тревога или скука — это сигналы дизайна системы, а не личной слабости.

4. Фиксируйте выводы на уровне системы

   • «Нам нужен более понятный путь эскалации»
   • «Нужны лучшие дашборды для сервиса X»
   • «Нужен support‑макрос для сценария Y»

Превращаем перспективы в конкретные улучшения надёжности

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

• Кресло инженера → лучшие runbook’и и роли
  Путаница вокруг того, кто может принять решение о rollback, приводит к обновлённой схеме ролей в инциденте и более ясной политике откатов.

• Кресло клиента → понятная коммуникация
  Осознание, что статус‑сообщения были бессмысленны для пользователей («elevated 5xx errors»), ведёт к новым шаблонам статус‑апдейтов на простом языке.

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

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

• Кресло SRE → меньше повторяющихся инцидентов
  Обнаружение recurring‑паттерна отказов приводит к приоритизации работ по устойчивости: rate limiting, circuit breaker’ы, лучшие пороги алертов.

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

Развитие социально-эмоциональных навыков в инженерных командах

Хотя всё выглядит как процессное упражнение, «колесо» — это ещё и тихая тренировка в:

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

Можно усилить эффект с помощью заключительного круга:

• «Что больше всего удивило тебя из перспективы другого кресла?»
• «Что одно ты лично сделаешь иначе в следующий инцидент?»
• «Какое обязательство мы как команда должны взять, чтобы лучше поддерживать друг друга?»

Зафиксируйте это в виде одностраничных обязательств и вернитесь к ним на следующем разборе инцидента.

Заключение: один аттракцион, много видов, общие улучшения

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

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

• Превращаете индивидуальный стресс в коллективное знание
• Обнаруживаете разрывы в коммуникации, инструментах и ролях
• Связываете эмоциональную реальность с техническими и процессными изменениями
• Формируете культуру, где надёжность — общая ответственность

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