Большой инцидент заканчивается не тогда, когда сервис подняли Он заканчивается, когда компания не только подняла сервис, но и разобрала причину, назначила меры и дотащила их до результата.
Большой инцидент - это не размер сбоя. Это цена последствий для бизнеса.
Когда встают кассы, склад или сайт, почти везде начинается один и тот же ритуал. Чат на 30 человек. Инженеры ищут причину. Руководители хотят прогноз. Бизнес не понимает, можно ли работать дальше. Деньги уходят. А решения никто не собирает в одну точку.
Я видел это очень предметно. В одном контуре техническая проблема лечилась меньше часа. Но при разборе картина оказалась другой: дольше всего жили не ошибка в системе, а согласования, параллельные команды и отсутствие человека с правом командовать восстановлением.
В большой аварии сначала нужен не поиск виноватого. Нужен единый командир инцидента. Тот, кто принимает решения, коммуницирует и контролирует. Кто останавливает лишние изменения, назначает владельцев и даёт бизнесу один официальный статус: что происходит, что делается, когда будет результат.
Первая задача - остановить потери, а не красиво обсуждать причины.
А дальше начинается часть, которую многие проваливают.
Если через 24 часа нет разбора с таймлайном, потерями и конкретным планом - что делается, кто отвечает, в какой срок - компания не управляла инцидентом. Она его пережила. И следующий - вопрос времени.
Каждая мера закрыта. Каждый владелец отчитался. Только тогда инцидент закрыт.
Для собственника и CEO это прямой инструмент. Потребовать такой план - нормально и правильно. Это единственный способ убедиться, что деньги потеряли один раз, а не превратили это в традицию.
И это работает не только в ИТ. Срыв поставки, остановка производства, сбой в логистике - механика одна и та же. Командир, разбор, план, владельцы, сроки. Или снова чат на 30 человек.
Чат без командира - это не управление. Это коллективная форма паники.
Кто у вас в компании руководит большим инцидентом в первые 15 минут - лучший инженер, ИТ-директор, операционный директор или никто?
· 21.04
Прекрасный текст!
Видно, что пишите, как практик.
Каждый зафиксированный сбой должен быть разобран и должен стать точкой роста!
ответить
коммент удалён
· 21.04
Спасибо! "Кровью и потом"
ответить
ответ удалён