Сейчас 02:14 вторника. Платёжный сервис лежит, в военном совете четырнадцать человек, и никто не может сказать, кто решает, откатываться ли назад. Два инженера параллельно отлаживают на одном и том же хосте, продакт-менеджер каждые четыре минуты спрашивает про ETA, а публичная страница статуса всё ещё показывает «investigating», потому что коммуникациями никто не владеет. Четыре часа спустя сервис снова работает. Постмортем назначают, потом отменяют. Пять недель спустя происходит то же самое, и те же четырнадцать человек открывают тот же звонок.
Если вы когда-нибудь были в таком звонке, вы уже знаете, что проблема не в технических навыках. Это процесс реагирования на инциденты — критичность, ответственность, эскалация, коммуникация и разбор, который порождает отслеживаемые действия, а не документ, который никто не читает. ITIL 4 Managing Professional (MP) — это уровень, на котором такая машинерия строится как следует, и самые важные части находятся в практиках Create, Deliver & Support и в ITIL Incident Management. Начать можно здесь: ITIL 4 Managing Professional (MP).
Как выглядит настоящий разбор Sev-1 час за часом?
Возьмём конкретный случай: API оформления заказа возвращает 500 примерно на 30% запросов. Вот последовательность, которая действительно снижает MTTR, и что ломается, если пропустить шаг.
Минуты 0–5: обнаружение и классификация. Срабатывает алерт, и дежурный инженер открывает канал инцидента по фиксированному шаблону: критичность, затронутый сервис, влияние на клиентов, имя командира инцидента. Решает матрица критичности, а не самый громкий голос. Если позволить людям спорить о критичности в первые пять минут, вы сжигаете самое дешёвое время, которое у вас есть.
Минуты 5–10: назначение одного командира инцидента. Не лучшего отладчика — человека, который владеет решениями, хронологией и передачей дел. Это единственное изменение с наибольшим рычагом, которое делает большинство команд. Командир не прикасается к терминалу. Если прикасается, решения застревают, потому что человек с клавиатурой никогда не тот, у кого есть общая картина.
Минуты 10–25: диагностика и решение. Максимум два направления работы, у каждого — названный владелец и заявленная гипотеза. На 20-й минуте командир задаёт единственный важный вопрос: мы знаем причину или откатываемся? Откат — это решение, а не провал, и он должен быть предварительно авторизован на первые 30 минут, иначе вы потратите час на поиск утверждающего.
Каждые 15 минут: коммуникация. Один человек публикует обновление статуса во внутреннем канале и на клиентской странице с фиксированной периодичностью, даже если обновление — «без изменений». Именно молчание превращает сбой в инцидент доверия.
Триггеры эскалации, записанные на бумаге. Если за 30 минут нет корневой причины, вызывайте владельца сервиса. Если появляется риск целостности данных, вызывайте юридический отдел и службу безопасности. Если исправление требует изменения схемы, командир эскалирует к органу, отвечающему за изменения, вместо импровизации в продакшене.
Какие метрики доказывают, что это сработало, — а какие лгут?
Отслеживайте три и отслеживайте их по полосам критичности, а не как одно среднее:
| Метрика | Что она говорит | Частая ловушка |
|---|---|---|
| MTTR | Как быстро вы восстанавливаете сервис | Усреднение Sev-1 с Sev-4 скрывает всё |
| MTTD | Как быстро вы заметили | Шум алертов незаметно завышает её |
| Доля повторных инцидентов | Действительно ли вы устранили причины | Никто не считает её без правила |
MTTR сам по себе — ловушка. Команда может снизить его, немедленно откатывая всё и никогда не находя причин, — число улучшается, а доля повторных инцидентов растёт. Правду говорит именно пара: быстрое восстановление плюс падающие повторы означают, что процесс работает.
Где управление инцидентами ломается, даже когда процесс существует?
Режим отказа 1: инфляция критичности. Всё становится Sev-1, потому что эскалация кажется безопаснее. В течение квартала вызовы Sev-1 начинают игнорировать, как любой другой алерт. Замечайте это рано: если больше небольшой доли инцидентов — Sev-1, у вашей матрицы нет зубов. Исправление: определяйте критичность по влиянию на клиентов и масштабу поражения и требуйте письменного обоснования для повышения.
Режим отказа 2: разбор инцидента, который ищет виноватых. Первый разбор, на котором кого-то спрашивают «почему ты это задеплоил?», навсегда убивает откровенные разборы. «Без обвинений» не означает «без ответственности» — это означает, что пункты действий привязаны к системам и процессам, а не к имени человека в документе.
Режим отказа 3: действия без владельца или срока. Разбор порождает одиннадцать рекомендаций, ни одна из которых не имеет дедлайна. Три месяца спустя — тот же инцидент. Работающее правило: не более трёх действий на разбор, у каждого — один владелец и дата, и их проверяют в следующем спринте.
Режим отказа 4: пути эскалации, существующие только на бумаге. Люди не эскалируют, потому что боятся выглядеть некомпетентными. Исправление — сделать эскалацию рутиной: командир запрашивает её по таймеру, и она перестаёт быть личным признанием.
Как люди на самом деле этому учатся — и сколько стоит каждый путь?
Самостоятельное изучение публикаций ITIL 4 бесплатно и работает, если вы уже управляете инцидентами и вам нужен только словарь. Цена — время и отсутствие обратной связи: вы можете читать про матрицы критичности целый вечер и всё равно построить такую, которая рухнет при реальном сбое, потому что никто не проверил ваши решения.
Практика — сильнейший учитель, но ошибки там дороги. Плохо спроектированный триггер эскалации стоит вам реального клиента. Курсы находятся посередине: структурированные, с кейсами и сценариями, которые можно обсудить до того, как вы окажетесь на дежурстве в 02:14. Компромисс честный — курс стоит денег и не заменяет военный совет; он сокращает количество военных советов, на которых вам нужно учиться. Здесь и вписывается ITIL 4 Managing Professional (MP): он прорабатывает практики Create, Deliver & Support и практики инцидентов, проблем и изменений на кейс-сценариях, так что матрица критичности и правила эскалации проверяются на ситуациях, а не заучиваются.
Кому это подходит, а кому стоит пропустить?
Подходит тимлидам, владельцам сервисов, SRE и операционным менеджерам, а также всем, кто случайно оказывался командиром в военном совете и хочет, чтобы эта роль была осознанной. Не подходит тому, кто ищет чисто техническое погружение, — здесь речь о том, как решения, коммуникация и обучение структурируются вокруг сбоев. Если в вашей организации вообще нет процесса управления инцидентами и нет полномочий его изменить, материал опишет мир, который вы пока не можете построить; начните с одной команды и одной матрицы критичности.
Проверка проста: если в вашем последнем Sev-1 не было названного командира, периодичности коммуникаций и отслеживаемых действий месяц спустя, проблема — в процессе. Начните с матрицы критичности и роли командира на этой неделе. Курс проходит через те же решения со сценариями и даёт обратную связь о том, как вы о них рассуждаете, — подробности на странице ITIL 4 Managing Professional (MP).