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 ночі це тобі знадобиться.