Вы знаете этот запах. Запах крупного инцидента. Лежит ядро сети или упал прод или отвалилась критичная база. И чат. Чат, который бежит со скоростью десяти сообщений в секунду. А потом в чат врывается бизнес. Капсом. «ЧТО ПРОИСХОДИТ?! КОГДА ПОЧИНИТЕ?!»

Инженеры в стрессе начинают метаться: дёргать конфиги, смотреть рандомные логи, предлагать «а давайте просто всё ребутнем» (не надо!). Чем больше паники, тем дольше лежит система. А когда система лежит, деньги компании сгорают вместе с твоим KPI.

В этот момент от руководителя ждут, что он сядет за консоль и героически всё починит. Это худшее, что вы можете сделать.

В зрелых компаниях есть роль Incident Commander. Человек, который при аварии не лезет в консоль руками. Вообще. Ни разу. Его работа не починить сервер, а остановить панику. Люди под эмоциональным давлением принимают абсолютно нелогичные, порой губительные решения.

Когда начинается пожар, я перехожу в режим «Иммунитет к хаосу». Делаю три вещи. И ни одна из них не связана с железом и техникой.

Для начала выгоняю СЕО\CIO\CISO и прочих C-level из технического чата. Буквально. Как они вообще туда попали? Инженер не может чинить сеть, пока над ним стоит большой начальник и как галчонок из Простоквашино спрашивает «ну что там?!» 60 раз в минуту. Я беру на себя все наружные переговоры: «Упало то-то, чинят такие-то, следующий апдейт во столько-то». Технарь должен работать в тишине и безотрывно, а не писать статусы каждые пять минут.

Далее я беру под контроль суету. И первые 3–5 минут я вообще не требую героизма. Мы быстро синхронизируемся: что точно сломалось, кто ведёт инцидент, что сейчас не трогаем, кто даёт следующий апдейт и по какому каналу работаем. Пять минут на такую сборку почти никогда не убивают систему. Зато отлично убивает систему хаотичный ремонт в десять рук без общего плана.

В стрессе даже у сильного и опытного инженера включается туннельное зрение, и он может снести соседнюю систему, пытаясь починить текущую. Поэтому каждое действие озвучивается вслух: «Что делаем? Зачем? Как откатим, если станет хуже?». Нет чёткого ответа, мы этого не делаем. Никаких «а вдруг поможет».

Ну и конечно, я не путаю две разные задачи: восстановить сервис и объяснить, почему он упал. В момент аварии мой фокус на локализации, безопасном откате и возврате системы в рабочее состояние. У меня в команде есть люди, которые знают систему глубже меня. Я собираю этих людей, организую параллельные проверки гипотез и слежу, чтобы никто не сидел три часа над одной проблемой без прогресса. Если за 30 минут нет подтверждённого движения, локализации, рабочей гипотезы или безопасного плана отката, значит, мы меняем тактику, а не героически копаемся дальше. Эти 30 - просто таймбокс, после которого я не позволяю команде закапываться в одну версию без результата. Полный разбор причин и выводов делается позже, когда инцидент уже стабилизирован.

Чем больше в инциденте героизма и беготни, тем выше MTTR. Я люблю, когда процесс выглядит убийственно скучно: все сидят, сосредоточившись на проблеме, и говорят «делаем X, потому что Y». Никакой магии, никаких «вжух и заработало».

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

А у вас при падении прода руководитель сидит с вами в консоли или стоит у двери с секирой, не давая топам войти?