Ieguvumi:
- Spēja izprast incidenta dzīves ciklu (atklāšana, šķirošana, mazināšana, atrisināšana, pēcnāves), MTTD/MTTR metriku un principu “vispirms mazināt, izmeklēt vēlāk”
- Spēja izmantot AI, lai sašaurinātu hipotēzes incidenta laikā un izveidotu nevainojamu pēcnāves skici, apstiprinot katru galveno cēloni ar datiem
- Spēja pielietot rakstīšanas disciplīnu valodā, kas nevaino pēcnāves gadījumu, un dalīties ar notikumu datiem, tos maskējot.
Katra sistēma galu galā sabojājas. Atšķirība ir tajā, kā labas komandas gatavojas šim neizbēgamajam notikumam un kā viņi mācās. Incidents ir neparedzēts notikums, kas traucē vai draud pārtraukt pakalpojuma darbību: pakalpojuma avārija, reakcijas laika straujš pieaugums, datu zudums. Incidentu pārvaldība nozīmē incidenta atklāšanu, mazināšanu, atrisināšanu pēc iespējas ātrāk un pēc tam mācīšanos no tā. Šī ir disciplīna, kas virza DevOps un SRE (Site Reliability Engineering) profesionāļus dienu un nakti.
Divi kritiskie rādītāji mēra notikuma kvalitāti: MTTD (vidējais noteikšanas laiks) un MTTR (vidējais atkopšanas laiks). Mērķis ir samazināt abus. AI šeit pievieno divas lielas vērtības: ātru žurnālu un metrikas apkopošanu notikuma laikā, lai sašaurinātu iespējamo galveno cēloni, un ātri pēc notikuma pēcnāves (pēcnotikuma izmeklēšanas ziņojuma) sastādīšanu. Taču lēmumi par notikumu gaitu – kuru pakalpojumu atslēgt, atcelt, ko teikt klientam – ir jūsu ziņā.
Notikuma dzīves cikls
- Atklāšana: atskan trauksmes signāls vai klienta sūdzība. Jo ātrāk, jo labāk.
- Šķirošana: cik tas ir nopietni? Kas ir domēns? Tiek piešķirti smaguma līmeņi — parasti SEV1 (viskritiskākā, visa sistēma) līdz SEV4 (mazsvarīga).
- Salieciet savu atbildes komandu. Kritiskos incidentos incidenta komandieris uzņemas koordināciju.
- Samazināt: vispirms apturiet asiņošanu — bieži vien atceļot vai aizsedzot karogu. Pamatcēloņu jūs atradīsit vēlāk.
- Risinājums: lietojiet pastāvīgu labojumu.
- Mācieties (pēcnāves): kas notika, kāpēc tas notika, kā novērst tā atkārtošanos?
Padoms: viena no visdārgākajām kļūdām incidenta laikā ir asiņošanas apturēšanas aizkavēšana, jo "vispirms tiksim pie precīza pamatcēloņa". Noteikums: vispirms samaziniet (atjaunošanas/atjaunošanas pakalpojums), pēc tam jautājiet. Atgriešanās pie zināmās labās versijas bieži vien ir ātrākais mazināšanas līdzeklis.
Pēcnāves kultūra bez vainas
Veselīgu komandu mugurkauls ir nevainojama pēcnāves kultūra: mērķis nav "kurš to izdarīja", bet gan "kāda sistēma un process pieļāva šo kļūdu?" ir jautājums. Cilvēki slēpj kļūdu, ja zina, ka tiks sodīti; Slēptā kļūda atkārtojas. Postmortem nav apsūdzības ziņojums, bet mācību dokuments.
Labā pēcnāves pārbaudē ietilpst: kopsavilkums, ietekme (cik lietotāju, cik ilgi, cik daudz naudas), laika skala, galvenais(-ie) iemesls(-i), kas gāja labi/slikti, un darbības vienumi — konkrēti pasākumi, katram no kuriem ir savs īpašnieks un datums.
Uzmanību! Rakstot pēcnāves ziņojumus ar AI, noteikti izslēdziet apsūdzošu valodu (proti, “persona X kļūdījās”). Maskējiet arī klientu ID, iekšējos IP un noslēpumus, ievadot notikumu datus AI — pēcnāves gadījumi bieži tiek plaši izplatīti.
Pamatcēloņu analīze: 5 iemesli un AI
Klasisks paņēmiens ir "5 Kāpēc": jautājiet "kāpēc?" uz problēmu. Jautājot atkal un atkal, jūs nokļūstat no virspusējā simptoma līdz patiesajai saknei. "Pakalpojums avarēja. Kāpēc? Trūkst atmiņas. Kāpēc? Bija noplūde. Kāpēc? Bibliotēkas atjauninājums..." AI ātri izveido šo ķēdi un iesaka iespējamos atzarus, taču jums ir jāpārbauda katrs "kāpēc" ar saviem datiem; AI var arī izveidot saprātīgu, bet nepareizu ķēdi.
Smaguma tabula
Līmenis
Ietekme
piemērs
iejaukšanās
SEV1
Visa sistēma/kritiski biznesa zaudējumi
Maksājums pilnībā atkrita
Uzreiz visa komanda, komandieris
SEV2
Liela disfunkcija
Pieteikšanās neizdevās
Ātrs, dežūrs + atbalsts
SEV3
Daļējs/ierobežots efekts
Ziņojums kavējas
darba laikā
SEV4
mazs/kosmētisks
drukas kļūda
parastā darba rinda
trīs mini futrāļi
1. gadījums — MTTR no 45 minūtēm līdz 8 minūtēm. Maksājumu pakalpojums avarēja. Dežūrējošais inženieris nodeva AI maskētos žurnālus un pēdējo izvietošanas informāciju un jautāja: "Kas ir visticamākais trigeris pēdējo 20 minūšu laikā?" viņš jautāja. AI parādīja, ka sabrukums sākās tajā pašā minūtē, kad tika veikta pēdējā izvietošana. Inženieris nekavējoties atcēla šo versiju; Pakalpojums atgriezās 8 minūtēs. Pēc tam tika ērti izpētīts galvenais iemesls (savienojuma pūla kļūda jaunajā versijā).
2. gadījums — pēcnāves skice 20 minūšu laikā. Pēc SEV2 komanda bija nogurusi un nebija spēka uzrakstīt ziņojumu; bieži ziņojums tika aizkavēts nedēļām. Šoreiz viņi AI sniedza laika grafiku un piezīmes par incidentiem un izveidoja beznoziedzības pēcnāves skici. AI izveidoja kārtīgu ietvaru ietekmei, laika skalai un darbības vienumiem; Komanda to piepildīja ar faktiem un publicēja to 20 minūšu laikā. Mācība netika zaudēta.
3. gadījums — konstatēts nepareizs cēlonis. Vienā gadījumā AI teica "bāzes cēlonis datu bāzes pārslodzei", un tas šķita saprātīgi. Bet inženieris apstiprināja metriku: datu bāzes slodze incidenta laikā bija normāla. Patiesais iemesls bija ārēja DNS problēma. Sākotnējā AI hipotēze bija mainīga, bet nepareiza; Apstiprināšana ar datiem neļāva publicēt ziņojumu ar nepareizu secinājumu.
Četras kopējamas veidnes
1) Ātra šķirošana incidenta laikā:
Pieredzam ražošanas notikumu. Maskēti simptomi: [SIMPTOMS]. Pēdējās izmaiņas: [PĒDĒJĀ IZVEIDOŠANA/IZMAIŅA]. Sniedziet man: (1) 3 visticamākās pamatcēloņa hipotēzes varbūtības secībā, (2) komandu/metriku, kas katru pārbaudīs 1 minūtē, (3) ātrāko DROŠO mazināšanas darbību (piemēram, atcelšana). Stingri sakot; Nosakiet, ka man ir jāpārbauda katra hipotēze.
2) Nevainīga pēcnāves skice:
Uzrakstiet nevainojamu pēcnāves skici no tālāk norādītajām incidenta piezīmēm. Sadaļas: Kopsavilkums, Ietekme (lietotājs/ilgums/izmaksas), Laika skala, Pamatcēlonis(-i), Kas noritēja labi, Kas gāja slikti, Darbības vienumi (katram ir īpašnieka + datuma lauks). Koncentrējieties uz nosaukumu piešķiršanu, procesu un sistēmu. Piezīmes: [MASKED]
3) 5 iemeslu analīze:
Izveidojiet ķēdi "5 Kāpēc", sākot ar šādu simptomu: [SIMPTOMS]. Parādiet, vai katrā solī ir vairāk nekā viens iespējamais zars. Blakus katram “kāpēc” ierakstiet pierādījumus (log/metriku), ko es apskatīšu, lai to pārbaudītu. Beigās atzīmējiet, kuras darbības vēl nav pārbaudītas.
4) Izstrādājamu vienumu izveide:
Ņemot vērā šo pamatcēloņu, iesakiet vienumus, par kuriem var rīkoties, kas neļaus vienam un tam pašam notikumam atkārtoties. Klasificējiet katru vienumu pēc: (a) novēršanas, atklāšanas vai samazināšanas, (b) paredzamās piepūles, (c) ietekmes. Kārtot pēc lielākās ietekmes/piepūles attiecības. Galvenais iemesls: [X]
Vāja uzvedne / spēcīga uzvedne
Vāji: "Pakalpojums ir avarējis, kas man jādara?"
Rezultāts: nav konteksta; AI var sniegt vispārīgus ieteikumus, kas neatbilst jūsu gadījumam, un var pat noteikt galīgo galveno iemeslu.
Spēcīgs: "Ražošanas maksājumu pakalpojums ir sniedzis 5xx 5 minūtes. Pēdējā izvietošana notika pirms 6 minūtēm. Norādiet 3 visticamākās pamatcēloņa hipotēzes iespējamības secībā, pasakiet komandu, kas pārbaudīs katru no tām, un iesakiet ātrāko drošu mazināšanas līdzekli. Neesiet precīzs, norādiet, ka man ir jāpārbauda."
Atšķirība: otrā uzvedne norāda simptomu, laiku un pēdējās izmaiņas; tas prasa hipotēzi + pārbaudi + samazināšanu un saglabā AI neprecīzu.
Biežas kļūdas
- Pirms mazināšanas meklējiet precīzu galveno cēloni. Tas aizkavē asiņošanas apturēšanu un palielina MTTR.
- Pirmās AI hipotēzes publicēšana, to nepārbaudot. Ziņojumā nokļūst šķidrs, bet viltus pamatcēloņi.
- Apsūdzības valoda. Anonīmi rakstītais pēcnāves periods veicina slēpšanu un atkārtotu kļūdu.
- Uz darbību vērsts ziņojums bez aizzīmēm. Piedāvājums bez īpašnieka un datuma nekad netiks īstenots.
- Notikuma datu kopīgošana, tos neslēpjot. Postmortem iet uz plašu auditoriju; slepenie/personas dati ir nopludināti.
- Iepriekš nesagatavojot atcelšanas ceļu. Ja apvēršana nav praktiska, samazināšana tiek palēnināta.
Rezumējot
Incidentu pārvaldība ir ātra neizbēgamu notikumu atklāšana, mazināšana, atrisināšana un mācīšanās no tiem; MTTD un MTTR ir galvenie rādītāji. Zelta likums ir "vispirms mazināt, izmeklēt vēlāk", un atgriešanās pie zināmās labās versijas bieži vien ir ātrākais mazināšanas līdzeklis. AI ir nenovērtējams, apkopojot žurnālus notikuma laikā, sašaurinot hipotēzes un veidojot nevainojamas pēcnāves skices pēc notikuma, taču jūs esat atbildīgs par katras pamatcēloņa hipotēzes apstiprināšanu, izmantojot datus, vainošanas valodu un maskējot notikumu datus.
Lietojumprogrammas uzdevums
Apsveriet pagātnes (vai izdomātu) notikumu. (1) Ļaujiet AI ģenerēt hipotēzes un pārbaudes darbības, izmantojot veidni “ātrā šķirošana uz vietas”; Ņemiet vērā, kuru hipotēzi var apstiprināt ar datiem. (2) Ieskicējiet ziņojumu, izmantojot veidni “nav vainīgs pēcnāves izklāsts”, un aizpildiet to ar faktiem. (3) Identificējiet vismaz divus vienumus, par kuriem var rīkoties, un katram piešķiriet īpašnieku un datumu.
kontrolsaraksts
- [ ] Notikuma brīdī es vispirms domāju par mazināšanu (atcelšanu/izslēgšanu) un atstāju galveno cēloni uz vēlāku laiku.
- [ ] Es pārbaudīju katru AI pamatcēloņa hipotēzi ar log/metriku.
- [ ] Es to uzrakstīju valodā, kas nevaino pēcnāves, koncentrējoties uz procesu un sistēmu.
- [ ] Katram apstrīdējamam vienumam es piešķīru īpašnieku un datumu.
- [ ] Es maskēju slepeno un personisko informāciju no notikumu datiem, ko nodevu AI.
- [ ] Es pareizi piešķīru smaguma pakāpi atbilstoši triecienam.