Під час падіння технічна проблема рідко є складною частиною. Складна — координація. Ось послідовність, яка не дає малій команді зробити гірше.
Більшість малих команд погано проходять своє перше серйозне падіння — не через некомпетентність, а тому що всі дебажать одночасно, ніхто не говорить із клієнтами, а двоє викочують суперечливі виправлення. Наведений плейбук існує, щоб цього не сталося.
Перші десять хвилин
- Оголосіть це. Скажіть слово «інцидент» уголос у командному каналі. Невизначеність щодо серйозності коштує більше часу, ніж будь-який технічний крок.
- Призначте ведучого інциденту. Одну людину, явно. Вона не дебажить — вона координує, вирішує і веде хронологію.
- Оцініть радіус ураження: кого зачепило, чи рухаються гроші неправильно, чи є ризик для даних. Це визначає все подальше.
- Зупиніть кровотечу до пошуку причини. Відкат, вимкнення фічі, сторінка обслуговування. Розуміння може зачекати; вплив на клієнта — ні.
- Опублікуйте статус. Навіть «ми розбираємося» краще за мовчання — саме мовчання перетворює падіння на проблему довіри.
Ролі, навіть у команді з чотирьох
| Роль | Робить | НЕ робить |
|---|---|---|
| Ведучий інциденту | Вирішує, координує, веде хронологію | Дебажить — щойно почне, координація зупиняється |
| Дослідник | Знаходить і усуває причину | Говорить із клієнтами |
| Комунікації | Оновлює статус-сторінку, клієнтів, внутрішню команду | Публічно спекулює про причину |
У малій команді одна людина може мати дві ролі — але ведучий інциденту і дослідник ніколи не мають бути однією людиною під час серйозного інциденту.
Що казати клієнтам
- Швидко підтвердити, навіть без відповідей — «ми знаємо і розбираємося» протягом хвилин
- Описати вплив їхніми словами: чого вони зараз не можуть зробити, а не який сервіс деградував
- Назвати час наступного оновлення і дотриматися його, навіть якщо нічого не змінилося
- Ніколи не спекулювати про непідтверджену причину — спростування коштують більше довіри, ніж коштувало б мовчання
- Чітко сказати, коли вирішено, і додати письмове пояснення, якщо вплив був суттєвим
Після: частина, яку всі пропускають
Постмортем протягом 48 годин, поки пам'ять точна. Без пошуку винних — не з ввічливості, а тому що звинувачення змушують людей приховувати інформацію, і наступний інцидент стає важче попередити.
- Хронологія: що сталося, коли, хто що робив — лише факти
- Вплив: тривалість, зачеплені користувачі, наслідки для грошей або даних
- Сприятливі чинники, у множині — одна першопричина майже завжди спрощення
- Дії з власниками і датами; пункти без обох — це декорація
- Що спрацювало добре — виявлення чи реакція, що спрацювали, варті підсилення
Ви не піднімаєтеся до рівня свого плану реагування на інциденти. Ви падаєте до рівня того, який справді відпрацювали.
Підготовка до того, як це станеться
- Алерти на симптоми, які відчувають клієнти (не проходить оплата), а не лише на метрики інфраструктури (високий CPU)
- Відкат, що вміщується в одну команду і відпрацьований у спокійних умовах
- Статус-сторінка, яка існує до того, як знадобиться
- Письмова ескалація: кому дзвонять о 3-й ночі і кому, якщо той не відповідає
- Одна навчальна тривога — навмисно зламайте щось на staging і пройдіть плейбук
Підтверджуйте відновлення реальними сценаріями
Зменшення помилок може приховувати неузгоджені дані. Визначте докази відновлення до закриття інциденту.
- Зафіксуйте вплив, останній робочий стан і недавні зміни.
- Оберіть зворотну дію з відповідальним та умовою зупинки.
- Перевірте головні шляхи, затримані завдання й звірку даних.
Часті запитання
Що робити першим, коли продакшн упав?
Оголосити інцидент і призначити одну людину ведучим, а потім пом'якшувати, а не діагностувати — відкат, вимкнення зламаної фічі або режим обслуговування. Відновлення сервісу йде першим; розуміння причини — задача на потім, коли клієнти знову працюють.
Чи треба одразу повідомляти клієнтів?
Так. Підтвердіть протягом хвилин, опишіть вплив у термінах того, чого вони не можуть зробити, і назвіть час наступного оновлення. Мовчання під час падіння шкодить довірі більше, ніж саме падіння, а спекуляція, яку потім спростовуєте, гірша за обидва варіанти.
Чи потрібен постмортем після кожного інциденту?
Для всього, що зачепило клієнтів — так, і його слід написати протягом 48 годин, поки спогади точні. Тримайте його без пошуку винних: команди, які призначають винних, отримують менш чесну інформацію, а це робить наступний інцидент імовірнішим, а не рідшим.
Чи завжди потрібно відкочувати підозрілий реліз?
Ні. Спочатку перевірте зміни даних і зовнішні наслідки. Відкат коду може їх не скасувати та погіршити інцидент.
Просто зараз в інциденті?
Ми робимо аварійне технічне реагування — тріаж, пом'якшення, першопричина і постмортем після.
Читати далі за темою
Постмортем: як написати той, який справді читають
Більшість постмортемів — це археологія: точний запис того, що ніхто не змінить. Корисний дає невелику кількість речей, які справді робляться.
Технічний аудит MVP: що ми перевіряємо в перші 48 годин
Більшість аудитів MVP закінчуються документом. Корисний закінчується рішеннями: що горить, що може почекати і скільки коштує виправлення.