Fitimet:
- Aftësia për të kuptuar ciklin jetësor të një incidenti (zbulimi, triazhi, zbutja, zgjidhja, postmortem), matjet MTTD/MTTR dhe parimi i "zbutni së pari, hetoni më vonë"
- Aftësia për të përdorur AI për të ngushtuar hipotezat në kohën e incidentit dhe për të prodhuar një skicë të pafajshme pas vdekjes, duke vërtetuar çdo shkak rrënjësor me të dhëna
- Aftësia për të zbatuar disiplinën e të shkruarit në një gjuhë që nuk fajëson postmortem dhe ndarjen e të dhënave të ngjarjeve duke e maskuar atë.
Çdo sistem prishet përfundimisht. Dallimi është se si ekipet e mira përgatiten për këtë ngjarje të pashmangshme dhe si mësojnë. Incidenti është një ngjarje e papritur që ndërpret ose kërcënon të ndërpresë shërbimin: një përplasje shërbimi, koha e reagimit rritet në qiell, një humbje e të dhënave. Menaxhimi i incidentit nënkupton zbulimin, zbutjen, zgjidhjen e incidentit sa më shpejt që të jetë e mundur dhe më pas mësimin prej tij. Kjo është disiplina që drejton profesionistët e DevOps dhe SRE (Site Reliability Engineering) ditë e natë.
Dy metrikë kritikë matin cilësinë e ngjarjes: MTTD (Koha mesatare për të zbuluar) dhe MTTR (Koha mesatare për të rikuperuar). Qëllimi është tkurrja e të dyjave. AI shton dy vlera të mëdha këtu: përmbledhjen e shpejtë të regjistrave dhe metrikave në kohën e ngjarjes për të kufizuar shkakun e mundshëm rrënjësor dhe hartimin e shpejtë të një postmortemi (raporti hetimor pas ngjarjes) pas ngjarjes. Por vendimet për rrjedhën e ngjarjeve - cilin shërbim të çaktivizoni, rikthimin, çfarë t'i thoni klientit - janë tuajat.
Cikli jetësor i një ngjarjeje
- Zbulimi: Dëgjohet një alarm ose vjen një ankesë e klientit. Sa më shpejt aq më mirë.
- Triage: Sa serioz është? Çfarë është domeni? Nivelet e ashpërsisë caktohen - zakonisht SEV1 (më kritike, i gjithë sistemi) në SEV4 (të vogla).
- Mblidhni ekipin tuaj të përgjigjes. Në incidente kritike, një komandant incidenti merr përsipër koordinimin.
- Zbutja: Së pari ndaloni gjakderdhjen - shpesh një kthim prapa ose duke mbuluar një flamur. Do ta gjeni shkakun rrënjësor më vonë.
- Zgjidhja: Aplikoni rregullim të përhershëm.
- Mësoni (postmortem): Çfarë ndodhi, pse ndodhi, si ta parandalojmë që të mos përsëritet?
Këshillë: Një nga gabimet më të kushtueshme në momentin e incidentit është vonimi i ndalimit të gjakderdhjes sepse "le të arrijmë së pari te shkaku i saktë rrënjësor". Rregulli: fillimisht zvogëloni (shërbimin e restaurimit/rikthimit), më pas pyesni. Kthimi në një version të njohur-të mirë është shpesh zbutja më e shpejtë.
Kulturë pas vdekjes pa faj
Shtylla kurrizore e skuadrave të shëndetshme është një kulturë e pas vdekjes së pafajshme: qëllimi nuk është "kush e bëri atë", por "çfarë sistemi dhe procesi e lejoi këtë gabim?" është pyetja. Njerëzit e fshehin gabimin nëse e dinë se do të ndëshkohen; Gabimi i fshehur përsëritet. Pas vdekjes nuk është një raport akuze, por një dokument mësimor.
Një postmortem i mirë përfshin: përmbledhjen, ndikimin (sa përdorues, sa kohë, sa para), afatin kohor, shkakun(et), çfarë shkoi mirë/keq dhe artikujt e veprimit—masat konkrete, secila me një pronar dhe datë.
Kujdes: Kur shkruani postmortem me AI, sigurohuni që të eliminoni gjuhën akuzuese (domethënë "personi X bëri një gabim"). Gjithashtu maskoni ID-të e klientëve, IP-të e brendshme dhe sekretet kur ushqeni të dhënat e ngjarjeve në AI - postmortemat shpesh ndahen gjerësisht.
Analiza e shkakut rrënjësor: 5 Pse dhe AI
Një teknikë klasike është "5 Pse": pyesni "pse?" ndaj një problemi. Duke pyetur vazhdimisht, ju kaloni nga simptoma sipërfaqësore në rrënjën e vërtetë. "Shërbimi u rrëzua. Pse? Pa memorie. Pse? Kishte një rrjedhje. Pse? Një përditësim bibliotekë..." AI është i shpejtë për të ndërtuar këtë zinxhir dhe sugjeron degë të mundshme — por ju duhet të verifikoni çdo "pse" me të dhënat tuaja; AI gjithashtu mund të ndërtojë një zinxhir të arsyeshëm, por të gabuar.
Tabela e ashpërsisë
Niveli
Ndikimi
shembull
ndërhyrja
SEV1
I gjithë sistemi/humbja kritike e biznesit
Pagesa ra plotësisht
Menjëherë, i gjithë ekipi, komandanti
SEV2
Mosfunksionim i madh
Identifikimi dështoi
I shpejtë, në thirrje + mbështetje
SEV3
Efekt i pjesshëm/i kufizuar
Një raport është vonuar
gjatë orarit të punës
SEV4
i vogël/kozmetik
gabim shtypi
radha e zakonshme e punës
tre mini kuti
Rasti 1 - MTTR nga 45 minuta në 8 minuta. Shërbimi i pagesës u ndërpre. Inxhinieri në detyrë i dha regjistrat e maskuar dhe informacionin e fundit të vendosjes tek AI dhe pyeti "Cili është shkaktari më i mundshëm në 20 minutat e fundit?" pyeti ai. Inteligjenca artificiale tregoi se kolapsi filloi në të njëjtën minutë me vendosjen e fundit. Inxhinieri e ktheu menjëherë atë version; Shërbimi u kthye në 8 minuta. Shkaku kryesor (një defekt i grupit të lidhjes në versionin e ri) u hetua më pas.
Rasti 2 - skicë pas vdekjes në 20 minuta. Pas një SEV2, ekipi ishte i lodhur dhe nuk kishte forcë të shkruante një raport; shpesh raporti vonohej me javë të tëra. Këtë herë, ata i dhanë AI afatin kohor dhe shënimet e incidentit dhe prodhuan një skicë pas vdekjes pa krime. AI krijoi një kornizë të pastër për artikujt e ndikimit, afatit kohor dhe veprimit; Ekipi e mbushi me fakte dhe e publikoi në 20 minuta. Mësimi nuk humbi.
Rasti 3 - kapur shkakun rrënjësor të gabuar. Në një rast, AI tha "mbingarkesa e bazës së të dhënave shkaktare rrënjësore" dhe dukej e arsyeshme. Por inxhinieri konfirmoi matjet: ngarkimi i bazës së të dhënave ishte normale në kohën e incidentit. Shkaku i vërtetë ishte një problem i jashtëm DNS. Hipoteza fillestare e AI ishte e rrjedhshme, por e gabuar; Vleresimi me te dhena pengoi publikimin e raportit me konkluzion te pasakte.
Katër shabllone të kopjueshëm
1) Trajtimi i shpejtë në momentin e incidentit:
Ne jemi duke përjetuar një ngjarje prodhimi. Simptomat e maskuara: [SIMPTOMA]. Ndryshimet e fundit: [SHPËRNDARJA/NDRYSHIMI I FUNDIT]. Më jep: (1) 3 hipotezat më të mundshme për shkakun rrënjësor sipas probabilitetit, (2) komandën/metrikën që do të verifikojë secilën në 1 minutë, (3) hapin më të shpejtë të zbutjes SIGURTË (p.sh. kthim prapa). Në mënyrë rigoroze; Thuaj se duhet të verifikoj çdo hipotezë.
2) Skicë e pafajshme pas vdekjes:
Shkruani një skicë të pafajshme pas vdekjes nga shënimet e incidentit më poshtë. Seksionet: Përmbledhja, Ndikimi (përdoruesi/kohëzgjatja/kostoja), Afati kohor, Shkaku(et) rrënjësor, Çfarë shkoi mirë, Çfarë shkoi keq, Artikuj veprimi (secili me zotëruesin + fushën e datës). Përqendrohuni në emërtimin, procesin dhe sistemin. Shënime: [MASKUR]
3) 5 analiza pse:
Ndërtoni një zinxhir "5 Pse", duke filluar me simptomat e mëposhtme: [SIMPTOMA]. Trego nëse ka më shumë se një degë të mundshme në çdo hap. Pranë çdo "pse" shkruaj dëshminë (log/metrik) që do të shikoj për ta verifikuar. Në fund, shënoni cilat hapa nuk janë verifikuar ende.
4) Krijimi i artikujve të veprimit:
Sipas këtij shkaku rrënjësor, sugjeroni artikuj të zbatueshëm që do të parandalojnë përsëritjen e së njëjtës ngjarje. Klasifikoni çdo artikull sipas: (a) parandalimit, zbulimit ose reduktimit, (b) përpjekjeve të vlerësuara, (c) ndikimit. Rendit sipas raportit më të lartë ndikim/përpjekje. Shkaku kryesor: [X]
Prompt i dobët / Prompt i fortë
I dobët: "Shërbimi është rrëzuar, çfarë duhet të bëj?"
Rezultati: pa kontekst; Inteligjenca artificiale mund të bëjë rekomandime të përgjithshme që nuk i përshtaten rastit tuaj dhe madje mund të dalë me një shkak rrënjësor përfundimtar.
Strong: "Shërbimi i pagesës së prodhimit ka dhënë 5xx për 5 minuta. Dislokimi i fundit ishte 6 minuta më parë. Jepni 3 hipotezat më të mundshme të shkakut rrënjësor sipas probabilitetit, tregoni komandën që do të verifikojë secilën prej tyre dhe sugjeroni zbutjen më të shpejtë të sigurt. Mos jini specifik, deklaroni se duhet të verifikoj."
Diferenca: prompti i dytë jep simptomat, kohën dhe ndryshimin e fundit; kërkon hipotezë + verifikim + reduktim dhe e mban AI të pasaktë.
Gabimet e zakonshme
- Duke kërkuar për shkakun e saktë rrënjësor përpara se të zbutet. Ajo vonon ndalimin e gjakderdhjes dhe rrit MTTR.
- Publikimi i hipotezës së parë të AI pa e verifikuar atë. Rrënjë e lëngshme, por e rreme, shkakton rrjedhje në raport.
- Gjuha akuzuese. Postmortem i shkruar në mënyrë anonime nxit fshehjen dhe përsëritjen e gabimeve.
- Raport i orientuar drejt veprimit pa pika. Një propozim pa pronar dhe datë nuk do të zbatohet kurrë.
- Ndarja e të dhënave të ngjarjes pa i maskuar ato. Postmortem shkon në një audiencë të gjerë; zbulohen të dhëna sekrete/personale.
- Mos përgatitja paraprakisht e shtegut të kthimit. Nëse kthimi nuk është praktik, reduktimi ngadalësohet.
Në përmbledhje
Menaxhimi i incidentit ka të bëjë me zbulimin e shpejtë, zbutjen, zgjidhjen dhe mësimin nga ngjarjet e pashmangshme; MTTD dhe MTTR janë metrikë kyç. Rregulli i artë është "zbutni së pari, hetoni më vonë" dhe kthimi në versionin e njohur-mirë është shpesh zbutja më e shpejtë. AI është e paçmuar në përmbledhjen e regjistrave në kohën e ngjarjes, ngushtimin e hipotezave dhe prodhimin e skicave të pafajshme pas vdekjes pas ngjarjes - por është përgjegjësia juaj të vërtetoni çdo hipotezë të shkakut rrënjësor me të dhëna, të pastroni gjuhën e fajit dhe të maskoni të dhënat e ngjarjeve.
Detyra e aplikimit
Merrni parasysh një ngjarje të kaluar (ose imagjinare). (1) Kërkoni që AI të gjenerojë hipoteza dhe hapa verifikimi me shabllonin "trajtimi i shpejtë në vendngjarje"; Vini re se cila hipotezë mund të konfirmohet nga të dhënat. (2) Skiconi një raport duke përdorur shabllonin "i pafajshëm pas vdekjes" dhe mbusheni me fakte. (3) Identifikoni të paktën dy objekte të veprimit dhe caktoni një pronar dhe datë për secilin.
listë kontrolli
- [ ] Në momentin e incidentit, fillimisht mendova të zbutja (kthimin/mbylljen) dhe e lashë shkakun kryesor për më vonë.
- [ ] Kam verifikuar çdo hipotezë të shkakut rrënjësor të AI me log/metrik.
- [ ] E shkrova në një gjuhë që nuk fajëson pas vdekjes, duke u fokusuar te procesi dhe sistemi.
- [ ] I caktova çdo artikulli të veprimit një pronar dhe një datë.
- [ ] Unë maskova informacionin sekret dhe personal nga të dhënat e ngjarjes që i dhashë AI.
- [ ] E caktova saktë nivelin e ashpërsisë sipas ndikimit.