Введение

Большинство команд говорят, что хотят учиться на сбоях. Они проводят разборы инцидентов, пишут постмортемы и рассылают ссылки. Потом все эти материалы исчезают где‑то в Confluence, Google Drive или в давно забытом инструменте для инцидентов.

Нельзя учиться на том, чего не видно.

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

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

В этом посте разберём:

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

Что такое каталог карточек с историями инцидентов?

Представьте себе библиотечный картотечный каталог, но каждая карточка — это инцидент:

• Продакшн‑авария
• Серьёзный «почти‑случай» в здравоохранении
• Попытка взлома или утечки
• Неудачный деплой

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

Вы строите осязаемый архив памяти системы.

Почему аналогово?

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

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

Проектируем карточку как мини‑постмортем

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

Практичная структура карточки может быть такой:

Лицевая сторона карточки

• Название – понятное человеку имя: «Вторничный утренний коллапс авторизации»
• Дата – когда произошёл инцидент
• Системы / домены – например: Auth, Payments, ОИТ, Лабораторные заказы
• Краткое описание воздействия – 1–2 предложения простым языком:
  • «Пользователи не могли залогиниться 37 минут; ~12 тыс. неуспешных попыток входа».
  • «Результаты лабораторных анализов для 23 пациентов были задержаны примерно на 3 часа».
• Основной категорийный тег – из вашей таксономии (например, Человеческий фактор → Управление вниманием)

Оборотная сторона карточки

• Что произошло (нарратив) – 3–5 предложений:
  • ключевая хронология
  • как инцидент проявился
  • как его завершили
• Почему это произошло (сопутствующие факторы) – буллеты, привязанные к вашей таксономии
• Чему мы научились – 3–5 конкретных вывода
• Дальнейшие действия – 2–3 ключевых изменения, которые сделали
• Ссылка / референс – ссылка или ID полного цифрового постмортема

Тон держите спокойным и гуманным. Фокусируйтесь на:

• Условиях, в которых люди принимали решения
• Ограничениях системы и проектных решениях
• Пробелах в инструментах, обучении или процессах

А не на:

• «Алиса забыла…»
• «Боб неправильно настроил…»

Если конкретное действие важно, опишите его в контексте: «Дежурный инженер сменился раньше обычного и получил неполные хандофф‑заметки…»

Фокус на обучении, а не на поиске виноватых

Вся цель каталога — поддерживать обучение и улучшения. Это значит:

• Никаких «охот на ведьм» – имена фигурируют только тогда, когда это необходимо для понимания ролей, а не для назначения вины.
• Системный взгляд – вопрос «Какие условия сделали такой исход вероятным?» вместо «Кто всё испортил?»
• Нормализация ошибочности – инциденты рассматриваются как ожидаемые сигналы сложной системы, а не как аномалии из‑за «плохих людей».

Закрепить это в практике можно так:

• Добавить на каждую карточку раздел «Вклад системы»:
  • например: «Нагрузка по пейджеру в ту неделю удвоилась из‑за других известных проблем».
• Избегать историй с одной «главной причиной»: требуйте не менее двух сопутствующих факторов на карточке.
• Регулярно спрашивать на разборах: «Если бы на месте этого человека был кто‑то другой, могло ли всё сложиться так же?»

Со временем сами ящики станут наглядным аргументом: это снова и снова система, в разных проявлениях.

Строим таксономию, по которой можно подшивать и искать

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

Простая верхнеуровневая структура может выглядеть так:

1. Технические факторы
   • Инфраструктура / ёмкость
   • Программные дефекты
   • Интеграции / зависимости
   • Пробелы в мониторинге / алёртинге
2. Человеческий фактор
   • Внимание / нагрузка
   • Коммуникации / ханофды
   • Обучение / опыт
   • Юзабилити интерфейсов
3. Пробелы в процессах и политиках
   • Отсутствующие или устаревшие ранбуки
   • Неясность зоны ответственности
   • Проблемы с аппрувами / change‑control
   • Неполные процедуры
4. Организационные факторы
   • Штат / покрытие смен
   • Конфликтующие цели или стимулы
   • Культурные нормы (например, героизм, силосы)

Физически это можно отразить так:

• Отдельные ящики или секции под каждый верхнеуровневый раздел
• Разделители для подкатегорий
• Алфавитная или хронологическая сортировка внутри подкатегорий

Один инцидент может затрагивать несколько категорий. Физически это решается так:

• Карточка подшивается под основную категорию, а
• Для вторичных категорий ставятся маленькие цветные точки или стикеры (например, синий = человеческий фактор, красный = технический).

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

Заимствуем идеи из HFACS‑Healthcare и похожих фреймворков

Необязательно придумывать схему классификации с нуля. Структурированные фреймворки вроде HFACS‑Healthcare (Human Factors Analysis and Classification System) дают надёжную основу для разбиения сопутствующих факторов.

HFACS обычно делит факторы на уровни:

• Небезопасные действия (ошибки, нарушения)
• Предпосылки небезопасных действий (усталость, коммуникации, среда)
• Небезопасное руководство
• Организационные влияния (культура, управление ресурсами)

Для среды разработки ПО или здравоохранения это можно адаптировать так:

• «Небезопасные действия» маппятся на фронтовые действия и проектные решения
• «Предпосылки» — на инструменты, нагрузку, окружение, интерфейсы
• «Небезопасное руководство» — на организацию он‑колла, практики ревью, управленческие решения
• «Организационные влияния» — на культуру, политики, финансирование, приоритеты

На каждой карточке можно добавить небольшой раздел:

Уровни HFACS: Предпосылки, Организационные влияния

Это даёт два эффекта:

1. Анализ остаётся повторяемым и структурированным со временем.
2. Выявляются паттерны вроде: «Ого, 60% наших инцидентов имеют организационные влияния, о которых мы обычно не говорим».

Можно заимствовать и из других фреймворков (STAMP, SEIPS и др.), но поля на физической карточке должны оставаться настолько простыми, чтобы её можно было заполнить за 5–10 минут.

Делаем каталог притягательным для просмотра

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

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

И встроите листание в рутины:

• Еженедельный «Flip‑Through по сбоям»: 10 минут в конце стендапа; кто‑то наугад достаёт карточку и пересказывает историю.
• Перед деплоем: перед рисковым изменением просматривайте карточки, связанные с этой системой или категорией.
• Онбординг: новички проводят час за просмотром и выбирают 3 инцидента для обсуждения с ментором.

Цель — чтобы каталог ощущался не архивом, а библиотекой историй, которой команда гордится.

Превращаем инсайты в реальные изменения

Красивый каталог бесполезен, если он не влияет на то, как вы работаете.

Свяжите ящики с реальными решениями:

• Периодические обзоры паттернов (ежемесячно или ежеквартально):
  • посчитайте, сколько карточек попадает в каждую категорию;
  • ищите кластеры: «У нас 7 инцидентов, связанных с ханофдами, за 3 месяца»;
  • сформулируйте 2–3 системные темы.
• Связь с трекингом работ:
  • под каждую тему заводите конкретные улучшения: правки ранбуков, обучающие сессии, дизайн‑ревью, изменения в процессах;
  • помечайте карточки маленьким значком, когда фоллоу‑апы доведены до конца.
• Питание обучения и ранбуков:
  • используйте реальные инциденты для сценарного обучения;
  • встраивайте «уроки из карточки X» прямо в ранбуки и дизайн‑стандарты.

Со временем вы начнёте видеть «до / после»:

• Меньше карточек в какой‑то подкатегории после внедрения нового инструмента или обучения.
• Более короткую длительность воздействия по мере улучшения практик он‑колла.

Вот тогда каталог перестаёт быть новинкой и становится ключевым активом для обучения.

Заключение

Аналоговый каталог историй инцидентов выглядит почти комично простым в мире дашбордов, ИИ и real‑time аналитики. Но его сила как раз в том, чего часто не хватает цифровым инструментам: осязаемость, нарратив и совместное внимание.

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

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

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

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