🪟 Почему команда не может быть себе судьей

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

В итоге работа с инцидентами — становится практиками про доверие.
Потому что пока все работает — мы строим, разрабатываем, масштабируем.
Но как только что-то ломается — система (и организационная, и техническая) показывает, где у нее слабые места.

Проблема в том, что команды часто воспринимают инцидент как:
⚙️ техническую неисправность в своей зоне ответственности,
🔥 которую нужно по-быстрому потушить,
🤐 и как можно меньше о ней говорить.

Но инцидент не заканчивается на устранении влияния на прод, это только начало.
А дальше идет план митигации:
— краткосрочный (чтобы система не падала снова через 5 минут),
— и долгосрочный (архитектурные или процессные изменения).
И вот тут начинается самое интересное.

Почему нельзя разбирать инцидент только внутри команды?
1️⃣Оптика искажения
Команда видит мир через призму своего контекста.
➤ Риски: не увидят пересечений, недооценят масштаб, пропустят системную причину.

2️⃣Конфликт интересов
Инциденты бьют по репутации. Команда заинтересована «исправить быстро и забыть», а не «разобраться до дна». Это нормальный человеческий механизм — защищать свою зону. И стоит незабывать про страх наказания.
➤ Риски: поверхностный разбор, уход от настоящей причины, повторение инцидента в будущем.

3️⃣Отсутвие прав на технилогическую волю
Команда отвечает только за свой кусок. Но инциденты часто возникают на стыках — между сервисами, командами, техдолгами, фичами и процессами.
➤ Риски: никто не берет ответственность за весь сценарий, решение становится «размазанным».

📌 Пример:
Падает прод-авторизация
— Команда А говорит, что их сервис авторизации работает, но по-новому.
— Команда В, которая отвечает за интеграцию мерчатов, говорит что не в курсе изменений.
— Команда С, которая катила фичу, и катнула случайно новый флоу, говорит, что деплой был плановый.
— А пользователи не могут зайти в ваш продукт уже 40 минут.

🧭 Что с этим делать?
Создать структурированный и централизованный подход к инцидент-менеджменту, в котором есть два критически важных элемента:

1. Внешний наблюдатель (incident-лид, мониторинг, 3я линия)
Это не контролер и не прокурор.
Это нейтральная сторона, чья задача:
— видеть инцидент целиком;
— задавать неудобные, но нужные вопросы;
— фиксировать все, что обычно забывается;
обеспечивать, чтобы разбор был не для галочки, а с эффектом.

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

🧠 Что считается «завершенным» инцидентом?
Не тогда, когда все снова заработало.
Это — только уборка последствий.

Завершенный инцидент — это когда:
1️⃣ Устранено влияние на прод (в рамках SLA)
2️⃣ Принят и согласован план митигации:
— краткосрочный (временное решение, обход, перестройка нагрузки);
— долгосрочный (архитектурные/процессные изменения, доработка мониторинга, новый алерт).
3️⃣ Проведен анализ (вариант - тот самый PIR), и выводы заложены в продуктовую или техническую стратегию.

🎯 Зачем все это?
Инцидент — это не ошибка.
Это сигнал, что система работает не так, как мы думали.

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

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