Mga nadagdag:
- Kakayahang maunawaan ang cycle ng buhay ng isang insidente (detection, triage, mitigation, resolution, postmortem), MTTD/MTTR metrics at ang prinsipyo ng 'magaan muna, mag-imbestiga sa ibang pagkakataon'
- Kakayahang gumamit ng AI upang paliitin ang mga hypotheses sa oras ng insidente at gumawa ng walang kapintasang postmortem sketch, na nagpapatunay sa bawat ugat na sanhi gamit ang data
- Kakayahang ilapat ang disiplina sa pagsulat sa isang wika na hindi sinisisi ang postmortem at pagbabahagi ng data ng kaganapan sa pamamagitan ng pag-mask nito.
Ang bawat sistema ay nasira sa kalaunan. Ang pagkakaiba ay kung gaano kahusay ang paghahanda ng mga koponan para sa hindi maiiwasang kaganapang ito at kung paano sila natututo. Ang insidente ay isang hindi inaasahang kaganapan na nakakaabala o nagbabantang maabala ang serbisyo: isang pag-crash ng serbisyo, ang mga oras ng pagtugon ay tumataas, isang pagkawala ng data. Ang pamamahala ng insidente ay nangangahulugan ng pag-detect, pagpapagaan, paglutas ng insidente sa lalong madaling panahon, at pagkatapos ay matuto mula dito. Ito ang disiplina na nagtutulak sa mga propesyonal sa DevOps at SRE (Site Reliability Engineering) araw at gabi.
Dalawang kritikal na sukatan ang sumusukat sa kalidad ng kaganapan: MTTD (Mean Time To Detect) at MTTR (Mean Time To Recover). Ang layunin ay upang paliitin ang pareho. Nagdagdag ang AI ng dalawang malalaking halaga dito: mabilis na pagbubuod ng mga log at sukatan sa oras ng kaganapan upang paliitin ang posibleng ugat na sanhi, at mabilis na pagbalangkas ng postmortem (ulat sa pagsisiyasat pagkatapos ng kaganapan) pagkatapos ng kaganapan. Ngunit ang mga desisyon tungkol sa takbo ng mga kaganapan - kung aling serbisyo ang isasara, rollback, kung ano ang sasabihin sa customer - ay sa iyo.
Siklo ng buhay ng isang kaganapan
- Detection: Tumunog ang alarm o may dumating na reklamo ng customer. Ang mas maaga ay mas mabuti.
- Triage: Gaano ito kaseryoso? Ano ang domain? Ang mga antas ng kalubhaan ay itinalaga—karaniwang SEV1 (pinaka kritikal, buong sistema) sa SEV4 (menor).
- Buuin ang iyong pangkat ng pagtugon. Sa mga kritikal na insidente, ang isang komandante ng insidente ay nagpapalagay ng koordinasyon.
- Bawasan: Itigil muna ang pagdurugo — madalas na rollback o nagtatakip ng bandila. Malalaman mo ang ugat sa ibang pagkakataon.
- Resolve: Ilapat ang permanenteng pag-aayos.
- Alamin (postmortem): Ano ang nangyari, bakit nangyari ito, paano natin ito mapipigilan na mangyari muli?
Tip: Ang isa sa pinakamamahal na pagkakamali sa oras ng insidente ay ang pagkaantala sa paghinto ng pagdurugo dahil "kumuha muna tayo sa eksaktong dahilan." Panuntunan: unang pagbabawas (ibalik/ibalik ang serbisyo), pagkatapos ay magtanong. Ang pagbabalik sa isang kilalang-mahusay na bersyon ay kadalasan ang pinakamabilis na pagpapagaan.
Kultura ng postmortem na walang kasalanan
Ang gulugod ng malusog na mga koponan ay isang kultura ng walang kapintasang postmortem: ang layunin ay hindi "sino ang gumawa nito," ngunit "anong sistema at proseso ang nagpapahintulot sa pagkakamaling ito?" ay ang tanong. Itinatago ng mga tao ang pagkakamali kung alam nilang paparusahan sila; Nauulit ang nakatagong error. Ang postmortem ay hindi isang ulat ng akusasyon, ngunit isang dokumento sa pag-aaral.
Ang isang mahusay na postmortem ay kinabibilangan ng: buod, epekto (kung gaano karaming gumagamit, gaano katagal, gaano karaming pera), timeline, (mga) sanhi, kung ano ang naging maayos/masama, at mga item ng pagkilos—mga kongkretong hakbang, bawat isa ay may may-ari at petsa.
Pag-iingat: Kapag nagsusulat ng mga postmortem gamit ang AI, siguraduhing alisin ang mapang-akit na pananalita (ibig sabihin, "nagkamali ang taong X"). I-mask din ang mga client ID, panloob na IP, at mga lihim kapag nagpapakain ng data ng kaganapan sa AI — madalas na malawak na ibinabahagi ang mga postmortem.
Pagsusuri sa ugat: 5 Bakit at AI
Ang isang klasikong pamamaraan ay "5 Bakit": magtanong ng "bakit?" sa isang problema. Sa pamamagitan ng paulit-ulit na pagtatanong, nakukuha mo mula sa mababaw na sintomas hanggang sa tunay na ugat. "Nag-crash ang serbisyo. Bakit? Out of memory. Bakit? Nagkaroon ng leak. Bakit? A library update..." Ang AI ay mabilis na bumuo ng chain na ito at magmungkahi ng mga posibleng sangay — ngunit dapat mong i-verify ang bawat "bakit" sa iyong data; Ang AI ay maaari ding bumuo ng isang makatwirang ngunit maling chain.
Talahanayan ng kalubhaan
Antas
Epekto
halimbawa
interbensyon
SEV1
Buong sistema/kritikal na pagkawala ng negosyo
Bumagsak ang bayad
Instantly, ang buong team, ang commander
SEV2
Major dysfunction
Nabigo ang mga pag-login
Mabilis, on-call + suporta
SEV3
Bahagyang/limitadong epekto
Naantala ang isang ulat
sa oras ng trabaho
SEV4
maliit/kosmetiko
typo
ordinaryong pila sa trabaho
tatlong mini case
Case 1 — MTTR mula 45 minuto hanggang 8 minuto. Nag-crash ang serbisyo sa pagbabayad. Ibinigay ng engineer na naka-duty ang mga naka-mask na log at ang huling impormasyon sa pag-deploy sa AI at nagtanong "Ano ang pinaka-malamang na trigger sa huling 20 minuto?" tanong niya. Ipinakita ng AI na nagsimula ang pagbagsak sa parehong minuto ng huling pag-deploy. Agad na binawi ng inhinyero ang bersyong iyon; Bumalik ang serbisyo pagkalipas ng 8 minuto. Ang ugat na sanhi (isang koneksyon sa pool bug sa bagong bersyon) ay maginhawang naimbestigahan.
Case 2—postmortem sketch sa loob ng 20 minuto. Pagkatapos ng SEV2, ang koponan ay pagod at walang lakas na magsulat ng isang ulat; madalas ang ulat ay naantala ng ilang linggo. Sa pagkakataong ito, ibinigay nila ang timeline at mga tala ng insidente sa AI at gumawa ng postmortem sketch na walang krimen. Gumawa ang AI ng maayos na balangkas para sa epekto, timeline at mga item ng pagkilos; Pinuno ito ng koponan ng mga katotohanan at inilathala ito sa loob ng 20 minuto. Hindi nawala ang aral.
Kaso 3 — maling ugat na dahilan ang nahuli. Sa isang kaso, sinabi ng AI "root cause database overload" at tila makatwiran. Ngunit kinumpirma ng engineer ang mga sukatan: normal ang pag-load ng database sa oras ng insidente. Ang tunay na dahilan ay isang panlabas na problema sa DNS. Ang paunang hypothesis ng AI ay tuluy-tuloy ngunit mali; Ang pagpapatunay na may data ay humadlang sa ulat na mai-publish na may maling konklusyon.
Apat na maaaring kopyahin na mga template
1) Mabilis na pagsubok sa oras ng insidente:
Nararanasan namin ang isang production event. Mga naka-mask na sintomas: [SYMPTOM].Mga huling pagbabago: [HULING I-DEPLOY/BABAGO]. Bigyan mo ako:(1) ang 3 pinaka-malamang na root cause hypotheses ayon sa probabilidad,(2) ang command/metric na magbe-verify sa bawat isa sa loob ng 1 minuto,(3) ang pinakamabilis na SAFE mitigation step (hal. rollback). Sabihin na dapat kong i-verify ang bawat hypothesis.
2) Inosenteng postmortem sketch:
Sumulat ng walang kapintasang postmortem sketch mula sa mga tala ng insidente sa ibaba. Mga Seksyon: Buod, Epekto (user/tagal/gastos), Timeline, (Mga) Root cause, Ano ang naging maayos, Ano ang nangyaring masama, Mga item ng aksyon (bawat isa ay may field ng may-ari + petsa). Tumutok sa pagpapangalan, proseso at sistema. Mga Tala: [MASKED]
3) 5 Bakit pagsusuri:
Bumuo ng chain na "5 Whys", simula sa sumusunod na sintomas: [SYMPTOM].Ipakita kung mayroong higit sa isang posibleng sangay sa bawat hakbang. Sa tabi ng bawat "bakit" isulat ang ebidensya (log/metric) na titingnan ko para ma-verify ito. Sa dulo, markahan kung aling mga hakbang ang hindi pa nabe-verify.
4) Paglikha ng mga naaaksyunan na item:
Ayon sa root cause na ito, magmungkahi ng mga naaaksyunan na item na pipigil sa parehong kaganapan na maulit. Uriin ang bawat item ayon sa: (a) pag-iwas, pagtuklas o pagbabawas, (b) tinantyang pagsisikap, (c) epekto. Pagbukud-bukurin ayon sa pinakamataas na ratio ng epekto/pagsisikap. Pinagmulan: [X]
Mahinang prompt / Malakas na prompt
Mahina: "Nag-crash ang serbisyo, ano ang dapat kong gawin?"
Resulta: walang konteksto; Maaaring gumawa ang AI ng mga pangkalahatang rekomendasyon na hindi akma sa iyong kaso, at maaari pa ngang makabuo ng isang tiyak na dahilan.
Strong: "Ang serbisyo sa pagbabayad ng produksyon ay nagbibigay ng 5xx sa loob ng 5 minuto. Ang huling deployment ay 6 na minuto ang nakalipas. Ibigay ang 3 pinaka-malamang na root cause hypotheses ayon sa posibilidad, sabihin ang command na magbe-verify sa bawat isa sa kanila, at magmungkahi ng pinakamabilis na ligtas na pagpapagaan. Huwag maging partikular, sabihin na kailangan kong i-verify."
Pagkakaiba: ang pangalawang prompt ay nagbibigay ng sintomas, timing, at huling pagbabago; hinihingi nito ang hypothesis + verification + reduction at pinananatiling hindi tumpak ang AI.
Mga karaniwang pagkakamali
- Hinahanap ang eksaktong ugat na dahilan bago pagaanin. Naaantala nito ang paghinto ng pagdurugo at pinapataas ang MTTR.
- Ini-publish ang unang hypothesis ng AI nang hindi ito bini-verify. Ang likido ngunit maling ugat ay nagiging sanhi ng pagtagas sa ulat.
- Wikang paratang. Ang postmortem na isinulat nang hindi nagpapakilala ay nagtataguyod ng pagtatago at paulit-ulit na pagkakamali.
- Ulat na nakatuon sa aksyon na walang mga bullet point. Ang isang panukala na walang may-ari at petsa ay hindi kailanman ipapatupad.
- Pagbabahagi ng data ng kaganapan nang hindi tinatago ito. Ang postmortem ay napupunta sa malawak na madla; sikreto/personal na data ay na-leak.
- Hindi inihahanda nang maaga ang landas ng rollback. Kung ang pagbabalik ay hindi praktikal, ang pagbabawas ay mabagal.
Sa buod
Ang pamamahala ng insidente ay tungkol sa mabilis na pagtuklas, pagpapagaan, paglutas at pagkatuto mula sa mga hindi maiiwasang pangyayari; Ang MTTD at MTTR ay mga pangunahing sukatan. Ang ginintuang tuntunin ay "magbawas muna, mag-imbestiga sa ibang pagkakataon" at ang pagbabalik sa kilalang-mahusay na bersyon ay kadalasan ang pinakamabilis na pagpapagaan. Napakahalaga ng AI sa pagbubuod ng mga log sa oras ng kaganapan, pagpapaliit ng mga hypothesis, at paggawa ng walang kapintasang postmortem sketch pagkatapos ng kaganapan — ngunit responsibilidad mong patunayan ang bawat root cause hypothesis gamit ang data, purga language of blame, at mask data ng kaganapan.
Gawain ng aplikasyon
Isaalang-alang ang isang nakaraan (o kathang-isip) na kaganapan. (1) Hayaang bumuo ang AI ng mga hypotheses at mga hakbang sa pag-verify gamit ang template na "on-the-scene rapid triage"; Tandaan kung aling hypothesis ang maaaring kumpirmahin ng data. (2) Mag-sketch ng isang ulat gamit ang template na “not guilty postmortem outline” at punan ito ng mga katotohanan. (3) Tukuyin ang hindi bababa sa dalawang bagay na naaaksyunan at magtalaga ng may-ari at petsa sa bawat isa.
checklist
- [ ] Sa oras ng insidente, naisip ko munang magpagaan (rollback/shutdown) at iniwan ang ugat hanggang sa huli.
- [ ] Na-verify ko ang bawat root cause hypothesis ng AI na may log/metric.
- [ ] Isinulat ko ito sa isang wika na hindi sinisisi ang postmortem, na nakatuon sa proseso at sistema.
- [ ] Nagtalaga ako ng may-ari at petsa sa bawat naaaksyunan na item.
- [ ] Tinakpan ko ang sikreto at personal na impormasyon mula sa data ng kaganapan na ibinigay ko sa AI.
- [ ] Itinalaga ko nang tama ang antas ng kalubhaan ayon sa epekto.