Продукцията гори в разработката — какво е това, причини и алгоритъм за действие

Какво означава „продукцията гори” и какви видове повреди има

Изразът „продукцията гори” (production is on fire, everything is down) описва ситуация, при която продукционната среда работи неправилно и това е засегнало потребителите. Повредата може да се прояви като пълна недостъпност на приложението (blank screen, грешка 502), частична недостъпност (платежният модул не работи, но останалите функции са достъпни) или влошаване на производителността (изключително бавно зареждане). Severity на инцидента се определя от процента засегнати потребители и продължителността на повредата.

Според Atlassian Statuspage (2025), средният downtime за мобилни приложения през 2024 г. е бил 27 минути на инцидент. Най-честите причини: регресия на код след deploy (34%), отказ на облачен доставчик (22%), проблеми с база данни (18%), грешки в конфигурацията (15%) и DDoS атаки (11%). Ключов извод: повечето повреди са свързани с промени, които екипът сам е направил, а не с външни фактори.

Важно е да се прави разлика между crash (срив на приложението от страна на клиента) и backend outage (недостъпност на сървъра). Crash обикновено се поправя с hotfix на клиентския код, а backend outage чрез инфраструктурни промени или redeploy на услугата. Метрики за проследяване: за клиента — 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 минути — ескалация до engineering manager. За P0 инциденти е позволено нарушаване на всякакви процеси: hotfix без пълен code review, директен deploy в продукция, игнориране на правилата за branch protection. Emergency override трябва да бъде предварително съгласуван на ниво екип.

Таблица на severity

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

Първите 10 минути: алгоритъм за действие при повреда

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

Паралелно със спиране на кръвотечението, един инженер започва диагностика, вторият — комуникация. Комуникационни канали: Slack #incident channel (за екипа), статус страница (за потребителите), имейл/SMS ескалация (за ръководството). На всеки 15 минути — актуализация на статуса с информация: какво се знае, какво се прави, очаквано време за възстановяване. Status page (StatuPage, Statuspal) показва uptime и история на инцидентите за външни потребители.

Как да спрем кръвотечението: rollback, feature toggle и hotfix

Първото и най-важно правило: не се опитвайте да поправите проблема в продукция. Ако новият release е причинил повредата — rollback към предишната стабилна версия. Ако повредата е причинена от конкретна функция, която е изключена чрез feature toggle — просто изключете toggle. Ако нито rollback, нито toggle са налични — hotfix с минимален diff. Rollback е най-безопасният вариант, защото се връщаме към състояние, което вече е работило.

Feature toggle (известен още като feature flag) — мощен инструмент за stop-the-bleeding без deploy. Ако платежният модул се е сринал, но е изключен чрез toggle — потребителите просто не виждат бутона за плащане, не получават екран с грешка. Toggle не изисква изграждане на build, не изисква преглед от магазина, действа за секунди. Всяка критична функция трябва да бъде под feature toggle с възможност за изключване на сървърно ниво (remote config). Feature flag — първата линия на защита.

Ако rollback е невъзможен (например поради необратима миграция на БД) и toggle не е предвиден — последно средство: hotfix с минимална корекция. Hotfix се създава от последния release tag, съдържа само редовете, необходими за отстраняване на повредата, и преминава fast-track deploy (вижте статията „Hotfix — спешни корекции”). Golden rule: след стабилизиране винаги правете root cause analysis, дори ако причината изглежда очевидна.

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

След спиране на кръвотечението (или паралелно, ако броят на инженерите позволява) започва диагностика. Първият източник — логовете. Централизирано логиране (ELK, Grafana Loki, Datadog Logs) позволява намиране на грешка по timestamp, ID на потребител или ID на заявка. Важно: логовете трябва да са структурирани (JSON), за да работи grep бързо. Структурираното логиране (structured logging) е задължително изискване за всички услуги.

Вторият източник — метриките. Grafana, Datadog, New Relic показват кога е настъпил пик на грешки, на кои endpoints, с какви статус кодове. Сравнението на метрики преди и след deploy помага да се локализира проблемът до конкретна услуга или endpoint. RED метриките (Rate, Errors, Duration) са стандартът за мониторинг на микроуслуги.

Третият източник — distributed tracing. Jaeger, Zipkin, Datadog APM показват пътя на заявката през микроуслугите и идентифицират къде точно е настъпило забавянето или грешката. Tracing е особено полезен при каскадни повреди, когато грешка в една услуга причинява грешки във всички зависими услуги. Trace ID трябва да се предава от клиента до всички backend услуги.

# Бърз пример за диагностика с kubectl и логове
# Списък на pod-ове с грешки
kubectl get pods --field-selector=status.phase!=Running

# Проверка на логовете на сринат pod
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 (наричан още incident review) — структуриран анализ на инцидента, проведен 24-72 часа след неговото разрешаване. Цел: да разберем защо е настъпила повредата, защо мониторингът и тестовете не са я хванали преди продукция и какво да променим в процесите, за да предотвратим повторение. Blameless culture — основен принцип: post-mortem обсъжда процеси, инструменти и комуникация, а не грешки на конкретни хора.

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

Типични action items след продукционна повреда: добавяне на мониторинг и alert за метриката, която е мълчала; разширяване на тестовото покритие за пропуснатия случай; добавяне на страница в runbook с алгоритъм стъпка по стъпка за подобна ситуация; провеждане на обучение на екипа за инструмента, който е бил използван неправилно. Всеки action item е конкретна промяна, която намалява вероятността от повторение на инцидента.