Ég a produckció a fejlesztésben — mi ez, okai és cselekvési algoritmus

Mit jelent az „ég a produckció” és milyen meghibásodások léteznek

Az „ég a produckció” kifejezés (production is on fire, everything is down) azt a helyzetet írja le, amikor a produckciós környezet hibásan működik, és ez érinti a felhasználókat. A meghibásodás megnyilvánulhat az alkalmazás teljes elérhetetlenségeként (blank screen, 502-es hiba), részleges elérhetetlenségeként (a fizetési modul nem működik, de más funkciók elérhetők), vagy teljesítményromlásként (extrém hosszú betöltés). Az incidens severity szintjét az érintett felhasználók százalékos aránya és a meghibásodás időtartama határozza meg.

Az Atlassian Statuspage (2025) szerint a mobilalkalmazások átlagos állásideje 2024-ben 27 perc volt incidenesenként. A leggyakoribb okok: kódregresszió deploy után (34%), felhőszolgáltató leállása (22%), adatbázisproblémák (18%), konfigurációs hibák (15%) és DDoS-támadások (11%). Fő következtetés: a meghibásodások többsége a csapat által végrehajtott változtatásokkal függ össze, nem külső tényezőkkel.

Fontos különbséget tenni a crash (alkalmazás összeomlása a kliens oldalon) és a backend outage (szerver elérhetetlensége) között. A crash-t általában a klienskód hotfix-szel javítják, a backend outage-t infrastruktúra-változtatásokkal vagy a szolgáltás újratelepítésével. Követendő metrikák: kliens esetén — crash-free rate, szerver esetén — error rate 5xx és p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — segít gyorsan meghatározni a meghibásodás típusát.

Incidensek severity szintjei: P0, P1, P2 és osztályozási kritériumok

Az egységes severity osztályozás a gyors reakció alapja. Enélkül a csapat időt veszít azon vitatkozással, hogy „mennyire sürgős” ahelyett, hogy cselekedne. A klasszikus skála: P0 (critical) — az alkalmazás teljesen elérhetetlen vagy felhasználói adatok szivárognak, reakcióidő — azonnal; P1 (high) — kritikus funkció nem működik a felhasználók 50%+ánál, reakcióidő — 15 perc; P2 (medium) — nem kritikus funkció elérhetetlen a felhasználók egy részénél, reakcióidő — 1 óra.

A P0 azonnali eszkalációt igényel: az ügyeletes mérnök megszakít minden aktuális munkát és az incidensre vált. Ha 10 perc után nincs megoldva a probléma — a tech lead csatlakozik. Ha 30 perc után — eszkaláció az engineering managerhez. P0 incidenseknél bármilyen folyamat megszegése megengedett: hotfix teljes code review nélkül, közvetlen deploy a produckcióba, branch protection szabályok figyelmen kívül hagyása. Emergency override előre egyeztetve kell legyen csapatszinten.

Severity táblázat

Rendkívül fontos, hogy ne tévedjünk severity-ben lefelé. A P2-ként osztályozott P0 + P1 késleltetett reakcióhoz és hosszabb állásidőhöz vezet. Szabály: ha kétségeid vannak — állítsd P0-ra. Az over-classification jobb, mint az under-classification: jobb egy plusz megbeszélést összehívni, mint egy óra helyreállítási időt elveszíteni.

Az első 10 perc: cselekvési algoritmus meghibásodás esetén

Timer starts: attól a pillanattól, amikor az alert vagy a felhasználói üzenet megérkezik. Az első 10 perc — a legfontosabb. Algoritmus: 1) confirm the issue — győződj meg róla, hogy a probléma valós (nem hamis riasztás); 2) stop the bleeding — azonnal csökkentsd a hatást (rollback, feature toggle, endpoint blokkolása); 3) communicate — írd meg az általános #incident csatornára a státuszt: mi történt, severity, mit tesznek. Az első 10 percet nem szabad a kiváltó ok elemzésére fordítani.

A vérzés megállításával párhuzamosan az egyik mérnök megkezdi a diagnosztikát, a másik a kommunikációt. Kommunikációs csatornák: Slack #incident channel (a csapatnak), státuszoldal (a felhasználóknak), e-mail/SMS eszkaláció (a vezetőségnek). 15 percenként — státuszfrissítés információkkal: mit tudunk, mit teszünk, helyreállítás várható ideje. Status page (StatuPage, Statuspal) az uptime-ot és az incidensek előzményeit mutatja a külső felhasználók számára.

Hogyan állítsuk meg a vérzést: rollback, feature toggle és hotfix

Az első és legfontosabb szabály: ne próbáld megjavítani a problémát a produckcióban. Ha az új kiadás okozta a meghibásodást — rollback az előző stabil verzióra. Ha a meghibásodást egy adott funkció okozza, amely ki van kapcsolva egy feature toggle segítségével — egyszerűen kapcsold ki a toggle-t. Ha sem rollback, sem toggle nem elérhető — hotfix minimális diff-fel. A rollback a legbiztonságosabb megoldás, mert visszatérünk egy már működő állapothoz.

Feature toggle (más néven feature flag) — egy hatékony eszköz a stop-the-bleedinghez deploy nélkül. Ha a fizetési modul összeomlott, de ki van kapcsolva egy toggle segítségével — a felhasználók egyszerűen nem látják a fizetés gombot, nem kapnak hibaképernyőt. A toggle nem igényel build készítést, nem igényel bolt ellenőrzést, másodpercek alatt működik. Minden kritikus funkciónak feature toggle alatt kell lennie, szerver szintű kikapcsolási lehetőséggel (remote config). A feature flag az első védelmi vonal.

Ha a rollback lehetetlen (például visszafordíthatatlan adatbázis-migráció miatt) és a toggle nem biztosított — végső megoldás: hotfix minimális javítással. A hotfix az utolsó release tag-től készül, csak a meghibásodás elhárításához szükséges sorokat tartalmazza, és fast-track deploy-on megy keresztül (lásd a „Hotfix — sürgős javítások” cikket). Golden rule: a stabilizálás után mindig végezz root cause analysis-t, még akkor is, ha az ok nyilvánvalónak tűnik.

Okok diagnosztizálása: naplók, metrikák és riasztások

A vérzés megállítása után (vagy párhuzamosan, ha a mérnökök száma lehetővé teszi) megkezdődik a diagnosztika. Az első forrás — a naplók. Központosított naplózás (ELK, Grafana Loki, Datadog Logs) lehetővé teszi a hiba megtalálását timestamp, felhasználói azonosító vagy kérésazonosító alapján. Fontos: a naplóknak strukturáltnak kell lenniük (JSON), hogy a grep gyorsan működjön. A strukturált naplózás kötelező követelmény minden szolgáltatás számára.

A második forrás — a metrikák. A Grafana, Datadog, New Relic megmutatja, mikor történt a hibák kiugrása, mely végpontokon, milyen státuszkódokkal. A metrikák összehasonlítása deploy előtt és után segít a probléma lokalizálásában egy adott szolgáltatásra vagy végpontra. A RED metrics (Rate, Errors, Duration) a mikroszolgáltatások monitorozásának szabványa.

A harmadik forrás — a distributed tracing. A Jaeger, Zipkin, Datadog APM megmutatja a kérés útját a mikroszolgáltatásokon keresztül, és azonosítja, hol pontosan történt a késleltetés vagy hiba. A tracing különösen hasznos láncreakció-szerű meghibásodásoknál, amikor egy szolgáltatás hibája hibákat okoz az összes függő szolgáltatásban. A Trace ID továbbítva kell legyen a klienstől az összes backend szolgáltatás felé.

# Gyors diagnosztikai példa kubectl és naplók használatával
# Hibás podok listázása
kubectl get pods --field-selector=status.phase!=Running

# Összeomlott pod naplóinak ellenőrzése
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Hibák keresése a szolgáltatásban az elmúlt 30 percben
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Fontos: ne próbáld diagnosztizálni az okot a vérzés megállítása előtt. Ha a felhasználók 50%-a crash-t lát — először rollback, aztán elemzés. Kivétel: ha a rollback hosszabb ideig tartana, mint egy közvetlen hotfix (például adatinkompatibilitás esetén). Ebben az esetben a hotfix azonnal alkalmazandó, a post-mortem pedig a stabilizálás után történik. A diagnosis before fix veszélyes minta, amely növeli az állásidőt.

Post-mortem: hogyan elemezzük az incidenseket hibáztatás nélkül

A post-mortem (más néven incident review) — az incidens strukturált elemzése, amelyet a megoldás után 24-72 órával végeznek. Cél: megérteni, miért történt a meghibásodás, miért nem fogták el a megfigyelés és a tesztek a produckció előtt, és mit kell változtatni a folyamatokon a megismétlődés megelőzése érdekében. A hibáztatásmentes kultúra (blameless culture) az alapelv: a post-mortem folyamatokról, eszközökről és kommunikációról beszél, nem konkrét emberek hibáiról.

A post-mortem dokumentum felépítése: timeline (események időrendje timestamp-ekkel), impact (érintett felhasználók, időtartam, pénzügyi veszteségek), root cause (technikai kiváltó ok), detection (hogyan fedezték fel, miért nem fogták el korábban), response (mit tettek, mit lehetett volna gyorsabban csinálni), action items (konkrét feladatok felelősökkel és határidőkkel). Az action itemek legyenek S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Tipikus action itemek produckciós meghibásodás után: monitorozás és riasztás hozzáadása ahhoz a metrikához, amely hallgatott; tesztlefedettség kiterjesztése a kihagyott esetre; oldal hozzáadása a runbookhoz lépésről lépésre algoritmussal hasonló helyzetre; csapat képzése arról az eszközről, amelyet helytelenül használtak. Minden action item egy konkrét változtatás, amely csökkenti az incidens megismétlődésének valószínűségét.