Nasusunog ang production sa pag-develop — ano ito, mga dahilan at algorithm ng pagkilos

Ano ang ibig sabihin ng "nasusunog ang production" at anong mga pagkasira ang mayroon

Ang pariralang "nasusunog ang production" (production is on fire, everything is down) ay naglalarawan ng sitwasyon kung saan ang kapaligiran ng production ay hindi gumagana nang tama at ito ay nakaapekto sa mga user. Ang pagkasira ay maaaring magpakita bilang kumpletong hindi pag-access ng app (blank screen, error 502), bahagyang hindi pag-access (hindi gumagana ang module ng pagbabayad ngunit available ang ibang function), o pagbaba ng performance (napakatagal na pag-load). Ang severity ng insidente ay tinutukoy ng porsyento ng mga apektadong user at tagal ng pagkasira.

Ayon sa Atlassian Statuspage (2025), ang average downtime para sa mga mobile app noong 2024 ay 27 minuto bawat insidente. Ang pinakakaraniwang dahilan: regression ng code pagkatapos ng deploy (34%), pagbagsak ng cloud provider (22%), problema sa database (18%), error sa configuration (15%) at DDoS attack (11%). Pangunahing konklusyon: karamihan sa mga pagkasira ay nauugnay sa mga pagbabagong ginawa mismo ng team, hindi sa panlabas na mga salik.

Mahalagang pag-iba-ibahin ang crash (pagbagsak ng app sa panig ng kliyente) at backend outage (hindi accessible ang server). Ang crash ay karaniwang naaayos sa pamamagitan ng hotfix ng client code, habang ang backend outage sa pamamagitan ng pagbabago sa imprastraktura o redeploy ng serbisyo. Mga sukatan ng pagsubaybay: para sa kliyente — crash-free rate, para sa server — error rate 5xx at p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — tumutulong upang mabilis na matukoy ang uri ng pagkasira.

Mga antas ng severity ng insidente: P0, P1, P2 at pamantayan sa pag-uuri

Ang pare-parehong pag-uuri ng severity ay pundasyon ng mabilis na pagtugon. Kung wala ito, ang team ay nag-aaksaya ng oras sa pagtalakay kung gaano ito ka-apura sa halip na kumilos. Ang klasikong antas: P0 (critical) — ganap na hindi accessible ang app o tumutulo ang data ng user, oras ng pagtugon — kaagad; P1 (high) — hindi gumagana ang kritikal na functionality para sa 50%+ ng mga user, oras ng pagtugon — 15 minuto; P2 (medium) — hindi accessible ang hindi kritikal na functionality para sa ilang user, oras ng pagtugon — 1 oras.

Ang P0 ay nangangailangan ng agarang pag-eskalada: ang naka-duty na inhinyero ay humihinto sa anumang kasalukuyang trabaho at lumipat sa insidente. Kung pagkatapos ng 10 minuto ay hindi pa nalulutas ang problema — sasama ang tech lead. Kung pagkatapos ng 30 minuto — pag-eskalada sa engineering manager. Para sa mga insidenteng P0, pinapayagan ang paglabag sa anumang proseso: hotfix nang walang kumpletong code review, direct deploy sa production, pagbalewala sa mga patakaran ng branch protection. Emergency override ay dapat na napagkasunduan nang maaga sa antas ng team.

Talaan ng severity

Napakahalaga na huwag magkamali sa severity pababa. Ang P0 + P1 na nauuri bilang P2 ay humahantong sa naantalang pagtugon at pagtaas ng downtime. Panuntunan: kung may pagdududa — itakda ang P0. Ang Over-classification ay mas mabuti kaysa under-classification: mas mabuting magpatawag ng dagdag na meeting kaysa mawalan ng isang oras na oras ng pagbawi.

Unang 10 minuto: algorithm ng pagkilos sa pagkasira

Timer starts: mula sa sandaling dumating ang alert o mensahe mula sa user. Ang unang 10 minuto — ang pinakamahalaga. Algorithm: 1) confirm the issue — tiyaking totoo ang problema (hindi maling alarma); 2) stop the bleeding — agad na bawasan ang epekto (rollback, feature toggle, harangan ang endpoint); 3) communicate — sumulat sa pangkalahatang channel na #incident ng status: ano ang nangyari, severity, ano ang ginagawa. Ang unang 10 minuto ay hindi ginugugol sa pagsusuri ng pangunahing dahilan.

Kasabay ng pagtigil ng pagdurugo, isang inhinyero ang nagsisimula ng diagnosis, ang pangalawa — komunikasyon. Mga channel ng komunikasyon: Slack #incident channel (para sa team), status page (para sa mga user), email/SMS na pag-eskalada (para sa pamamahala). Bawat 15 minuto — update ng status na may impormasyon: ano ang nalalaman, ano ang ginagawa, tinantyang oras ng pagbawi. Status page (StatuPage, Statuspal) ay nagpapakita ng uptime at kasaysayan ng insidente para sa panlabas na mga user.

Paano itigil ang pagdurugo: rollback, feature toggle at hotfix

Ang una at pinakamahalagang panuntunan: huwag subukang ayusin ang problema sa production. Kung ang bagong release ay naging sanhi ng pagkasira — rollback sa nakaraang matatag na bersyon. Kung ang pagkasira ay sanhi ng isang partikular na feature na hindi pinagana sa pamamagitan ng feature toggle — patayin lang ang toggle. Kung hindi available ang rollback o toggle — hotfix na may pinakamaliit na diff. Rollback — ang pinakaligtas na opsyon, dahil babalik tayo sa isang estado na gumana na.

Feature toggle (aka feature flag) — isang makapangyarihang tool para sa stop-the-bleeding nang walang deploy. Kung ang module ng pagbabayad ay bumagsak ngunit hindi pinagana sa pamamagitan ng toggle — hindi lang nakikita ng mga user ang button ng pagbabayad, hindi sila nakakakuha ng error screen. Ang toggle ay hindi nangangailangan ng paggawa ng build, hindi nangangailangan ng review ng tindahan, gumagana sa ilang segundo. Ang bawat kritikal na feature ay dapat nasa ilalim ng feature toggle na may kakayahang i-disable sa antas ng server (remote config). Feature flag — unang linya ng depensa.

Kung hindi posible ang rollback (halimbawa dahil sa hindi maibabalik na migration ng BD) at hindi available ang toggle — huling paraan: hotfix na may pinakamababang pag-aayos. Ang hotfix ay ginawa mula sa huling release tag, naglalaman lamang ng mga linyang kailangan upang alisin ang pagkasira at sumasailalim sa fast-track deploy (tingnan ang artikulong "Hotfix — agarang pag-aayos"). Golden rule: pagkatapos ng pagpapatatag, palaging gumawa ng root cause analysis, kahit na tila halata ang dahilan.

Diagnosis ng mga dahilan: log, metrics at alarm

Pagkatapos ihinto ang pagdurugo (o parallel, kung pinapayagan ng bilang ng mga inhinyero) magsisimula ang diagnosis. Unang source — mga log. Ang sentralisadong pag-log (ELK, Grafana Loki, Datadog Logs) ay nagpapahintulot na mahanap ang error sa pamamagitan ng timestamp, ID ng user, o ID ng request. Mahalaga: ang mga log ay dapat naka-istruktura (JSON) upang mabilis na gumana ang grep. Structured logging — sapilitang kinakailangan para sa lahat ng serbisyo.

Ikalawang source — metrics. Ipinapakita ng Grafana, Datadog, New Relic kung kailan naganap ang spike ng mga error, sa anong mga endpoint, na may anong mga status code. Ang paghahambing ng metrics bago at pagkatapos ng deploy ay tumutulong upang i-localize ang problema sa isang partikular na serbisyo o endpoint. RED metrics (Rate, Errors, Duration) — pamantayan sa pagsubaybay ng mga microservice.

Ikatlong source — distributed tracing. Ipinapakita ng Jaeger, Zipkin, Datadog APM ang landas ng request sa pamamagitan ng mga microservice at tinutukoy kung saan eksaktong naganap ang pagkaantala o error. Ang tracing ay lalong kapaki-pakinabang sa mga cascade failure, kapag ang error sa isang serbisyo ay nagdudulot ng mga error sa lahat ng umaasang serbisyo. Trace ID ay dapat ipasa mula sa kliyente patungo sa lahat ng backend na serbisyo.

# Mabilis na halimbawa ng diagnostic gamit ang kubectl at log
# Ilista ang mga pod na may error
kubectl get pods --field-selector=status.phase!=Running

# Suriin ang log ng crash na pod
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Maghanap ng mga error sa serbisyo sa nakaraang 30 minuto
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Mahalaga: huwag subukang i-diagnose ang dahilan bago ihinto ang pagdurugo. Kung 50% ng mga user ay nakakakita ng crash — rollback muna, pagkatapos ay analysis. Maliban kung: kung ang rollback ay mas tatagal kaysa sa direktang hotfix (halimbawa sa kaso ng hindi pagkakatugma ng data). Sa kasong ito, ang hotfix ay inilapat kaagad, at ang post-mortem ay isinasagawa pagkatapos ng pagpapatatag. Diagnosis before fix — mapanganib na pattern na nagpapataas ng downtime.

Post-mortem: paano suriin ang mga insidente nang hindi naghahanap ng may kasalanan

Post-mortem (tinatawag ding incident review) — isang nakabalangkas na pagsusuri ng insidente na isinasagawa 24-72 oras pagkatapos ng paglutas nito. Layunin: maunawaan kung bakit naganap ang pagkasira, bakit hindi ito nahuli ng pagsubaybay at mga pagsubok bago ang production, at kung ano ang babaguhin sa mga proseso upang maiwasan ang pag-ulit. Blameless culture — pangunahing prinsipyo: tinatalakay ng post-mortem ang mga proseso, tool at komunikasyon, hindi ang mga pagkakamali ng mga partikular na tao.

Istruktura ng dokumento ng post-mortem: timeline (kronolohiya ng mga pangyayari na may timestamp), impact (mga apektadong user, tagal, pagkalugi sa pananalapi), root cause (teknikal na pangunahing dahilan), detection (paano natuklasan, bakit hindi nahuli nang mas maaga), response (ano ang ginawa, ano ang maaaring nagawa nang mas mabilis), action items (mga kongkretong gawain na may responsableng tao at deadline). Action items ay dapat S.M.A.R.T.: specific, measurable, assignable, realistic, time-bound.

Mga tipikal na action items pagkatapos ng pagkasira ng production: magdagdag ng pagsubaybay at alert para sa metrik na tahimik; palawakin ang coverage ng pagsubok para sa hindi nakuha na kaso; magdagdag ng pahina sa runbook na may step-by-step na algorithm para sa katulad na sitwasyon; magsagawa ng training ng team para sa tool na ginamit nang hindi tama. Ang bawat action item ay isang konkretong pagbabago na nagbabawas ng posibilidad ng pag-ulit ng insidente.