3 часа ночи. Прилетает алерт. Production лежит. И каждая клеточка тела кричит одно: делай хоть что-нибудь. Рестартни сервис. Откати деплой. Поправь конфиг. Что угодно, сейчас же.
Этот инстинкт — враг. В первые 5 минут инцидента проигрывает тот, у кого быстрее руки. Я столько раз видел, как паникующий инженер превращал 30-минутную заминку в 8-часовой пожар, что сбился со счёта, — и первые годы карьеры этим инженером был я сам. Спасает в 3 ночи не скорость. Спасает протокол, который ты отрепетировал, пока было скучно.
Вот четыре шага, которые я прогоняю на дежурстве всегда, строго по порядку.
Шаг 1: STOP — остановись
Ничего не делай 30 секунд. Серьёзно — убери руки с клавиатуры.
Звучит как безумие, когда всё горит. Но паника — паршивый инженер. Она заставляет рестартнуть не тот сервис, и вот у тебя сломано уже две вещи вместо одной. Эти 30 секунд нужны, чтобы адреналин вытек из пальцев и мозг снова включился. Инцидент за полминуты никуда не денется. Важно не как быстро ты начал, а что именно сделаешь дальше.
Шаг 2: ASSESS — разберись
Пойми, что сломано на самом деле, — а не что похоже на поломку.
500-е — это симптом. «База не отвечает» — уже теплее. «Connection pool исчерпан» — вот причина. Если рестартнуть приложение на 500-х, ты почувствуешь себя молодцом ровно четыре минуты, а потом оно снова ляжет — потому что ты лечил симптом. Пройди по цепочке до того, что реально отваливается, прежде чем что-то трогать. Залеченный симптом — это просто отложенный инцидент.
Шаг 3: COMMUNICATE — напиши
Вот чему тебя никто не учит, и именно это либо строит доверие, либо сжигает его.
Напиши одно сообщение. Не абзац, не разбор корневой причины — одну строчку: «Разбираюсь. Апдейт через 10 минут». По моему опыту, эта фраза снимает тревогу у стейкхолдеров процентов на 80. Работает вот почему: люди нормально переживают проблемы. Чего они не выносят — так это тишины, пока production горит. Тишина заставляет их представлять худшее, а потом писать тебе в личку по одному — и вот ты отвечаешь на сообщения вместо того, чтобы чинить.
Плохая новость вовремя лучше хорошей с опозданием. Всегда.
Шаг 4: ACT — действуй
Вот теперь — действуй. И даже здесь побеждает дисциплина.
- Одно изменение за раз. Не три «на всякий случай».
- Проверяй после каждого. Помогло? Измерь, а не надейся.
- Не помогло? Откатывай сразу, до следующей попытки.
- Записывай каждое действие по ходу.
Последний пункт — самый коварный. Лог того, что ты пробовал, — это и есть твой postmortem. Через три дня никто не вспомнит, ты передёрнул поды до правки конфига или после. Если записал вживую — тебе не надо восстанавливать инцидент по памяти, у тебя уже есть таймлайн.
Почему коммуникация важнее скорости
Вот контринтуитивная правда, к которой я возвращаюсь снова и снова: грамотно отработанный часовой инцидент строит больше доверия, чем молчаливый 20-минутный фикс, которого никто не понял.
Молчаливый фикс кажется геройством. Ворвался, разрулил, вышел. Но твои стейкхолдеры прожили эти 20 минут, не понимая, горит компания или нет. Этот страх не испаряется от того, что ты починил быстро. Он копится. В следующий раз, когда что-то отвалится, они не верят ни системе, ни тебе.
Медленный, но проговорённый инцидент — наоборот. Люди видели, что ты в теме. Получали свои апдейты каждые 10 минут. Смотрели, как профессионал разбирает проблему. Вот репутация, которая тебе на самом деле нужна.
Репетируй, пока скучно
У инженеров, которые сохраняют спокойствие в 3 ночи, есть одно общее: свои runbook'и они написали, когда всё было тихо. Подготовка невидима ровно до того момента, когда она тебя спасает.
Если твои postmortem'ы всё время заканчиваются фразой «рестартнул сервис, и оно поднялось» — у тебя нет процесса. У тебя есть везение, а оно кончается. Герои выгорают. Процессы масштабируются.
Так что отрепетируй это на трезвую голову, чтобы сработало на панике: STOP. ASSESS. COMMUNICATE. ACT. Сохрани туда, где найдёшь в 3 ночи. Потому что в 3 ночи это тебе понадобится.