Отказ как управленческий сценарий: кто принимает решение в первые 30 минут

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

Я заметил, что большинство компаний готовы к инцидентам технически - есть мониторинг, есть дежурный инженер, есть какой-то процесс. Но управленческий сценарий не прописан. Именно в разрыве между гарантиями SLA поставщика и тем, что нужно бизнесу, и проявляется необходимость такого сценария. Кто принимает решение остановить деплой? Кто говорит клиентам? Кто решает, когда переключить трафик на резерв?

Почему первые 30 минут управленческие, а не только технические

В первые полчаса инженеры ещё не знают, что именно сломалось. Это нормально. Диагностика требует времени. Но именно в этот период параллельно должны происходить другие вещи:

• кто-то должен оценить, нужна ли немедленная коммуникация с клиентами;
• кто-то должен принять решение об эскалации или отсутствии необходимости в ней;
• кто-то должен убедиться, что команда не работает вразнобой без общей картины.

Если это не прописано заранее - каждый делает то, что кажется логичным ему. Результат обычно предсказуем: несколько человек звонят в техподдержку одновременно, кто-то пишет клиентам до того как диагноз поставлен, инженеры тратят время на объяснения вместо восстановления.

Три роли, которые нужны в инциденте

Мне удобна простая схема из трёх ролей:

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

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

Коммуникатор - человек, который в нужный момент информирует: руководство, клиентов, партнёров. Он берёт информацию у командира инцидента, а не у инженеров.

В маленькой компании все три роли может совмещать один человек. В большой - должны быть разными людьми. Главное, чтобы это было решено заранее, а не в момент аварии.

Единый источник правды при инциденте

Самая распространённая проблема при инцидентах - информация расползается по разным каналам. Кто-то пишет в мессенджер, кто-то в тикет, кто-то звонит. Через 20 минут никто не знает текущий статус.

Решение простое, но его нужно договориться заранее: один канал является источником правды во время инцидента. Всё остальное - производное от него. Командир инцидента обновляет этот канал каждые N минут, даже если обновление звучит как "диагностируем, новых данных нет".

Это кажется бюрократией. На практике это то, что позволяет руководителю в 3 часа ночи понять ситуацию за 60 секунд, не звоня дежурному инженеру.

Эскалация: кто решает и по каким критериям

Эскалация - это передача решения на уровень выше. Она нужна не всегда, но критерии должны быть определены до инцидента:

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

Если эти критерии не прописаны, каждый инженер будет решать по-своему, когда звонить руководителю. Одни будут звонить слишком рано, другие слишком поздно.

Простой тест готовности

Задайте команде три вопроса прямо сейчас:

1. Если сегодня в 23:00 что-то серьёзно упадёт - кто является командиром инцидента?
2. В какой канал мы пишем текущий статус, чтобы все видели одно и то же?
3. По каким критериям мы будите звонить руководителю или собственнику?

Если ответы на все три вопроса быстрые и одинаковые у всей команды - всё хорошо. Если есть паузы или разные версии - вот где начинается работа.

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