Продакшн горить у розробці — що це, причини та алгоритм дій

Що означає «продакшн горить» і які бувають збої

Вислів «продакшн горить» (production is on fire, everything is down) описує ситуацію, коли production-середовище працює некоректно, і це торкнулося користувачів. Збій може проявлятися як повна недоступність додатка (blank screen, 502 помилка), часткова недоступність (не працює платіжний модуль, але інші функції доступні), або деградація продуктивності (екстремально довге завантаження). Severity інциденту визначається відсотком постраждалих користувачів і тривалістю збою.

За даними Atlassian Statuspage (2025), середній downtime для мобільних додатків у 2024 році склав 27 хвилин на інцидент. Найчастіші причини: регресія коду після деплою (34%), відмова хмарного провайдера (22%), проблеми з базою даних (18%), помилки конфігурації (15%) та DDoS-атаки (11%). Key takeaway: більшість збоїв пов'язані зі змінами, які команда сама внесла, а не із зовнішніми факторами.

Важливо розрізняти crash (падіння додатка на клієнті) та backend outage (недоступність сервера). Crash зазвичай виправляється хотфіксом клієнтського коду, а backend outage — через інфраструктурні зміни або редеплой сервісу. Метрики відстеження: для клієнта — crash-free rate, для сервера — error rate 5xx та p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — допомагає швидко визначити тип збою.

Severity інцидентів: P0, P1, P2 та критерії класифікації

Єдина класифікація severity — основа швидкої реакції. Без неї команда витрачає час на обговорення «наскільки це терміново» замість дій. Класична шкала: P0 (critical) — додаток повністю недоступний або витікають користувацькі дані, час реакції — негайно; P1 (high) — критичний функціонал не працює у 50%+ користувачів, час реакції — 15 хвилин; P2 (medium) — некритичний функціонал недоступний у частини користувачів, час реакції — 1 година.

P0 вимагає негайної ескалації: черговий інженер перериває будь-яку поточну роботу і перемикається на інцидент. Якщо через 10 хвилин проблему не вирішено — підключається tech lead. Якщо через 30 хвилин — escalation to engineering manager. Для P0 інцидентів допустимо порушувати будь-які процеси: робити хотфікс без повного code review, деплоїти безпосередньо в продакшен, ігнорувати branch protection rules. Emergency override повинен бути заздалегідь узгоджений на рівні команди.

Таблиця severity

Вкрай важливо не помилитися з severity в меншу сторону. P0 + P1, класифіковані як P2, призводять до запізнілої реакції та збільшення downtime. Правило: якщо сумніваєшся — став P0. Over-classification краще under-classification: краще зібрати зайву зустріч, ніж втратити годину відновлення.

Перші 10 хвилин: алгоритм дій при збої

Timer starts: з моменту, коли прийшов alert або повідомлення від користувача. Перші 10 хвилин — найважливіші. Алгоритм: 1) confirm the issue — переконатися, що проблема реальна (не хибний alarm); 2) stop the bleeding — негайно знизити impact (rollback, feature toggle, блокування ендпоінта); 3) communicate — написати в загальний канал #incident статус: що сталося, severity, що робиться. Перші 10 хвилин не витрачаються на аналіз першопричини.

Паралельно з зупинкою кровотечі один інженер починає діагностику, другий — комунікацію. Канали комунікації: Slack #incident channel (для команди), статусна сторінка (для користувачів), email/SMS ескалації (для менеджменту). Кожні 15 хвилин — статус-апдейт з інформацією: що відомо, що робиться, ETA відновлення. Status page (StatusPage, Statuspal) відображає uptime та історію інцидентів для зовнішніх користувачів.

Як зупинити кровотечу: rollback, feature toggle та hotfix

Перше і найважливіше правило: не намагатися виправити проблему на продакшені. Якщо новий реліз викликав збій — rollback до попередньої стабільної версії. Якщо збій викликаний конкретною фічею, яка відключена feature toggle — просто вимкнути toggle. Якщо ні rollback, ні toggle недоступні — hotfix мінімальним diff. Rollback — найбезпечніший варіант, тому що ми повертаємося до стану, який вже працював.

Feature toggle (aka feature flag) — потужний інструмент для stop-the-bleeding без деплою. Якщо платіжний модуль упав, але відключений через toggle — користувачі просто не бачать кнопку оплати, а не отримують error screen. Toggle не вимагає збірки білда, не вимагає рев'ю стора, спрацьовує за секунди. Кожна критична фіча повинна бути під feature toggle з можливістю відключення на рівні сервера (remote config). Feature flag — перша лінія оборони.

Якщо rollback неможливий (наприклад, через незворотну міграцію БД) і toggle не передбачений — останній засіб: hotfix з мінімальним виправленням. Hotfix створюється від останнього релізного тега, містить лише рядки, необхідні для усунення збою, і проходить fast-track деплой (див. статтю «Hotfix — термінові виправлення»). Golden rule: після стабілізації — завжди робити root cause analysis, навіть якщо здається, що причина очевидна.

Діагностика причин: логи, метрики та аларми

Після зупинки кровотечі (або паралельно, якщо дозволяє кількість інженерів) починається діагностика. Перше джерело — логи. Централізоване логування (ELK, Grafana Loki, Datadog Logs) дозволяє знайти помилку за timestamp, user ID або request ID. Важливо: логи повинні бути структурованими (JSON), щоб grep працював швидко. Structured logging — обов'язкова вимога для всіх сервісів.

Друге джерело — метрики. Grafana, Datadog, New Relic показують, коли відбувся spike помилок, на яких ендпоінтах, з якими status codes. Порівняння метрик до і після деплою допомагає локалізувати проблему до конкретного сервісу або ендпоінта. RED metrics (Rate, Errors, Duration) — стандарт моніторингу мікросервісів.

Третє джерело — розподілена трасування (distributed tracing). Jaeger, Zipkin, Datadog APM показують шлях запиту через мікросервіси і виявляють, де саме сталася затримка або помилка. Трасування особливо корисне при каскадних відмовах, коли збій в одному сервісі викликає помилки у всіх залежних. Trace ID повинен передаватися від клієнта до всіх backend-сервісів.

# Швидкий приклад діагностики за допомогою kubectl та логів
# Список подів з помилками
kubectl get pods --field-selector=status.phase!=Running

# Перевірка логів поду, що впав
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Пошук помилок у сервісі за останні 30 хвилин
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Важливо: не намагатися діагностувати причину до зупинки кровотечі. Якщо 50% користувачів бачать crash — спочатку rollback, потім розбір. Виняток: якщо rollback зайняв би більше часу, ніж прямий hotfix (наприклад, при несумісності даних). У цьому випадку hotfix застосовується негайно, а post-mortem проводиться після стабілізації. Diagnosis before fix — небезпечний патерн, що збільшує downtime.

Post-mortem: як розбирати інциденти без пошуку винних

Post-mortem (також called incident review) — структурований розбір інциденту, що проводиться через 24-72 години після його вирішення. Мета: зрозуміти, чому стався збій, чому моніторинг і тести не зловили його до продакшену, і що змінити в процесах, щоб запобігти повторенню. Blameless culture — фундаментальний принцип: post-mortem обговорює процеси, інструменти та комунікацію, а не помилки конкретних людей.

Структура post-mortem документа: timeline (хронологія подій з timestamps), impact (постраждалі користувачі, тривалість, фінансові втрати), root cause (технічна першопричина), detection (як виявили, чому не зловили раніше), response (що зробили, що можна було зробити швидше), action items (конкретні завдання з відповідальними та дедлайнами). Action items повинні бути S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Типові action items після production збою: додати моніторинг та alert на метрику, яка мовчала; розширити тестове покриття на пропущений кейс; додати сторінку в runbook з покроковим алгоритмом для аналогічної ситуації; провести training команди по інструменту, який використовувався неправильно. Кожен action item — бетонна зміна, що зменшує ймовірність повторення інциденту.