Продукција гори у развоју — шта је то, узроци и алгоритам деловања

Шта значи „продукција гори” и које врсте отказа постоје

Израз „продукција гори” (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 — одмах смањи impact (rollback, feature toggle, блокирање endpoint-а); 3) communicate — напиши на општем каналу #incident статус: шта се догодило, severity, шта се ради. Првих 10 минута се не троши на анализу основног узрока.

Паралелно са заустављањем крварења, један инжењер почиње дијагностику, други — комуникацију. Канали комуникације: Slack #incident channel (за тим), статусна страница (за кориснике), емаил/SMS ескалација (за менаџмент). Сваких 15 минута — ажурирање статуса са информацијама: шта се зна, шта се ради, процењено време опоравка. 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 без 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 показују када се догодио spike грешака, на којим endpoint-има, са којим статусним кодовима. Поређење метрика пре и после deploy-а помаже да се проблем лоцира до одређеног сервиса или endpoint-а. RED metrics (Rate, Errors, Duration) — стандард за праћење микросервиса.

Трећи извор — distributed tracing. Jaeger, Zipkin, Datadog APM показују пут захтева кроз микросервисе и идентификују где је тачно дошло до кашњења или грешке. Tracing је посебно користан код каскадних отказа, када грешка у једном сервису изазива грешке у свим зависним сервисима. 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 (такође назван 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 са алгоритамом корак по корак за сличну ситуацију; спровести training тима за алат који је коришћен неправилно. Сваки action item је конкретна промена која смањује вероватноћу понављања инцидента.