Продакшн горит в разработке — что это, причины и алгоритм действий

Что значит «продакшн горит» и какие бывают сбои

Выражение «продакшн горит» (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 (StatuPage, 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-сервисов.

# Quick diagnostic example using kubectl and logs
# List pods with errors
kubectl get pods --field-selector=status.phase!=Running

# Check logs of crashed pod
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Search errors in service for the last 30 minutes
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 — бетонное изменение, уменьшающее вероятность повторения инцидента.