Incidentų valdymas ir pomirtinis: pagrindinių priežasčių analizė naudojant dirbtinį intelektą

Pelnas:

• Gebėjimas suprasti incidento gyvavimo ciklą (aptikimas, skirstymas, švelninimas, sprendimas, pomirtinis), MTTD/MTTR metriką ir principą „pirmiausia sušvelnink, o vėliau ištirk“
• Galimybė naudoti AI susiaurinti hipotezes incidento metu ir sukurti nepriekaištingą pomirtinį eskizą, patvirtinant kiekvieną pagrindinę priežastį duomenimis
• Gebėjimas taikyti rašymo discipliną kalba, kurioje nekaltinamas pomirtinis, ir dalytis įvykio duomenimis juos maskuojant.

Kiekviena sistema ilgainiui sugenda. Skirtumas yra tai, kaip geros komandos ruošiasi šiam neišvengiamam įvykiui ir kaip jos mokosi. Incidentas – tai netikėtas įvykis, kuris sutrikdo ar gali sutrikdyti paslaugos teikimą: paslaugos gedimas, greitas atsako laikas, duomenų praradimas. Incidentų valdymas – tai kuo greičiau aptikti, sušvelninti, išspręsti incidentą, o tada iš jo mokytis. Tai yra disciplina, kuri skatina DevOps ir SRE (Svetainės patikimumo inžinerijos) profesionalus dieną ir naktį.

Dvi svarbios metrikos įvertina įvykio kokybę: MTTD (vidutinis laikas iki aptikimo) ir MTTR (vidutinis atkūrimo laikas). Tikslas yra sumažinti abu. Dirbtinis intelektas čia prideda dvi dideles reikšmes: greitas žurnalų ir metrikų apibendrinimas įvykio metu, siekiant susiaurinti galimą pagrindinę priežastį, ir greitai parengti pomirtinį (tyrimo po įvykio ataskaitą) po įvykio. Tačiau sprendimai dėl įvykių eigos – kurią paslaugą išjungti, atšaukti, ką pasakyti klientui – yra jūsų.

Renginio gyvavimo ciklas

1. Aptikimas: suskamba pavojaus signalas arba gaunamas kliento skundas. Kuo greičiau, tuo geriau.
2. Triažas: kiek tai rimta? Kas yra domenas? Priskiriami sunkumo lygiai – paprastai SEV1 (kritiškiausia, visa sistema) ir SEV4 (nedidelis).
3. Surinkite savo reagavimo komandą. Kritinių incidentų metu incidento vadas prisiima koordinavimą.
4. Sušvelninkite: pirmiausia sustabdykite kraujavimą – dažnai atšaukti arba uždengti vėliavą. Priežastį sužinosite vėliau.
5. Sprendimas: pritaikykite nuolatinį pataisymą.
6. Sužinokite (po mirties): kas atsitiko, kodėl tai atsitiko, kaip užkirsti kelią, kad tai nepasikartotų?

Patarimas: viena iš brangiausių klaidų incidento metu yra kraujavimo sustabdymo atidėjimas, nes „pirmiausia išsiaiškinkime tikslią pagrindinę priežastį“. Taisyklė: pirmiausia sumažinkite (atkūrimo / atkūrimo paslauga), tada teiraukites. Grįžimas prie žinomos geros versijos dažnai yra greičiausias sušvelninimas.

Pomirtinė kultūra be kaltės

Sveikų komandų stuburas yra nepriekaištingo postmortem kultūra: tikslas yra ne „kas tai padarė“, o „kokia sistema ir procesas leido padaryti šią klaidą? yra klausimas. Žmonės slepia klaidą, jei žino, kad bus nubausti; Paslėpta klaida kartojasi. Postmortem yra ne kaltinimo ataskaita, o mokymosi dokumentas.

Geras pomirtinis tyrimas apima: santrauką, poveikį (kiek vartotojų, kiek laiko, kiek pinigų), laiko juostą, pagrindinę priežastį (-es), kas sekėsi gerai / blogai, ir veiksmų elementus – konkrečias priemones, kurių kiekvienas turi savininką ir datą.

Atsargiai: rašydami postmortems su AI, būtinai pašalinkite kaltinimus (būtent „asmuo X suklydo“). Taip pat užmaskuokite klientų ID, vidinius IP adresus ir paslaptis, kai perduodate įvykių duomenis į AI – pomirtiniais duomenimis dažnai dalijamasi plačiai.

Pagrindinės priežasties analizė: 5 priežastys ir AI

Klasikinė technika yra "5 Kodėl": paklauskite "kodėl?" prie problemos. Klausdami vėl ir vėl, jūs pereinate nuo paviršutiniško simptomo prie tikrosios šaknies. "Paslauga sudužo. Kodėl? Trūksta atminties. Kodėl? Įvyko nutekėjimas. Kodėl? Bibliotekos atnaujinimas..." AI greitai sukuria šią grandinę ir siūlo galimas atšakas, tačiau kiekvieną "kodėl" turite patikrinti savo duomenimis; AI taip pat gali sukurti pagrįstą, bet neteisingą grandinę.

Sunkumo lentelė

Lygis

Poveikis

pavyzdys

intervencija

SEV1

Visa sistema / kritinis verslo praradimas

Mokėjimas visiškai sumažėjo

Iškart visa komanda, vadas

SEV2

Didelis funkcijos sutrikimas

Prisijungimai nepavyko

Greitas, iškvietimas + palaikymas

SEV3

Dalinis / ribotas poveikis

Pranešimas atidėtas

darbo valandomis

SEV4

mažas/kosmetinis

rašybos klaida

įprastą darbo eilę

trys mini dėklai

1 atvejis – MTTR nuo 45 minučių iki 8 minučių. Sugedo mokėjimo paslauga. Budintis inžinierius perdavė AI užmaskuotus žurnalus ir paskutinę dislokavimo informaciją ir paklausė: „Koks greičiausiai paleidiklis per pastarąsias 20 minučių? – paklausė jis. AI parodė, kad žlugimas prasidėjo tą pačią minutę kaip ir paskutinis dislokavimas. Inžinierius iš karto atšaukė tą versiją; Paslauga grįžo per 8 minutes. Tada buvo patogiai ištirta pagrindinė priežastis (ryšio baseino klaida naujoje versijoje).

2 atvejis – pomirtinis eskizas per 20 minučių. Po SEV2 komanda buvo pavargusi ir neturėjo jėgų parašyti ataskaitą; dažnai ataskaita vėluodavo savaites. Šį kartą jie AI pateikė laiko juostą ir incidentų pastabas ir sukūrė pomirtinį eskizą be nusikaltimų. AI sukūrė tvarkingą poveikio, laiko juostos ir veiksmų elementų sistemą; Komanda užpildė jį faktais ir paskelbė per 20 minučių. Pamoka nebuvo prarasta.

3 atvejis – užfiksuota klaidinga pagrindinė priežastis. Vienu atveju AI pasakė „pagrindinės priežasties duomenų bazės perkrovimas“ ir tai atrodė pagrįsta. Tačiau inžinierius patvirtino metrikas: įvykio metu duomenų bazės apkrova buvo normali. Tikroji priežastis buvo išorinė DNS problema. Pradinė AI hipotezė buvo sklandi, bet klaidinga; Patvirtinimas naudojant duomenis neleido paskelbti ataskaitos su neteisinga išvada.

Keturi kopijuojami šablonai

1) Greitas suskirstymas įvykio metu:

Išgyvename gamybinį renginį. Užmaskuoti simptomai: [SIMPTOMAS]. Paskutiniai pakeitimai: [LAST DEPLOY/CHANGE]. Pateikite man: (1) 3 labiausiai tikėtinas pagrindinės priežasties hipotezes pagal tikimybę, (2) komandą / metriką, kuri kiekvieną patikrins per 1 minutę, (3) greičiausią SAUGUS švelninimo veiksmą (pvz., atšaukimą). Griežtai kalbant; Nurodykite, kad turiu patikrinti kiekvieną hipotezę.

2) Nekaltas pomirtinis eskizas:

Parašykite nepriekaištingą pomirtinį eskizą iš toliau pateiktų incidento užrašų. Skiltys: Santrauka, Poveikis (vartotojas / trukmė / kaina), Laiko juosta, Pagrindinė priežastis (-ės), Kas sekėsi gerai, Kas buvo blogai, Veiksmų elementai (kiekvienas su savininku + datos laukeliu). Sutelkite dėmesį į pavadinimų suteikimą, procesą ir sistemą. Pastabos: [MASKED]

3) 5 Kodėl analizė:

Sukurkite „5 Kodėl“ grandinę, pradedant šiuo simptomu: [SIMPTOMAS]. Parodykite, ar kiekviename žingsnyje yra daugiau nei viena galima šaka. Prie kiekvieno „kodėl“ parašykite įrodymus (logą/metriką), kuriuos peržiūrėsiu, kad patikrinčiau. Pabaigoje pažymėkite, kurie veiksmai dar nepatvirtinti.

4) Veiksmingų elementų kūrimas:

Atsižvelgdami į šią pagrindinę priežastį, pasiūlykite veiksmų, kurie neleis tam pačiam įvykiui pasikartoti. Klasifikuokite kiekvieną elementą pagal: a) prevenciją, nustatymą arba sumažinimą, b) numatomas pastangas, c) poveikį. Rūšiuoti pagal didžiausią poveikio ir pastangų santykį. Pagrindinė priežastis: [X]

Silpnas raginimas / Stiprus raginimas

Silpnas: "Servis sugedo, ką turėčiau daryti?"

Rezultatas: nėra konteksto; AI gali pateikti bendrų rekomendacijų, kurios netinka jūsų atveju, ir netgi gali sugalvoti galutinę pagrindinę priežastį.

Stiprus: "Gamybos mokėjimo paslauga duoda 5xx 5 minutes. Paskutinį kartą buvo įdiegta prieš 6 minutes. Pateikite 3 labiausiai tikėtinų pagrindinių priežasčių hipotezes pagal tikimybę, pasakykite komandą, kuri patikrins kiekvieną iš jų, ir pasiūlykite greičiausią saugų sušvelninimą. Nebūkite konkretūs, nurodykite, kad turiu patikrinti."

Skirtumas: antrasis raginimas nurodo simptomą, laiką ir paskutinį pakeitimą; tai reikalauja hipotezės + patikrinimo + sumažinimo ir išlaiko AI netikslų.

Dažnos klaidos

• Prieš švelnindami ieškokite tikslios pagrindinės priežasties. Tai atitolina kraujavimo sustabdymą ir padidina MTTR.
• Pirmosios AI hipotezės paskelbimas jos nepatikrinus. Į ataskaitą patenka skystos, bet klaidingos pagrindinės priežastys.
• Kaltinamoji kalba. Anonimiškai parašytas postmortem skatina nuslėpti ir kartoti klaidas.
• Į veiksmą orientuota ataskaita be ženklelių. Pasiūlymas be savininko ir datos niekada nebus įgyvendintas.
• Dalijimasis įvykių duomenimis jų neužmaskuojant. Postmortem eina į plačią auditoriją; slapti/asmens duomenys nutekinami.
• Iš anksto neruošia atšaukimo kelio. Jei atsukimas nepraktiškas, mažinimas sulėtėja.

Apibendrinant

Incidentų valdymas – tai greitas neišvengiamų įvykių aptikimas, sušvelninimas, sprendimas ir mokymasis iš jų; MTTD ir MTTR yra pagrindiniai rodikliai. Auksinė taisyklė yra „pirmiausia sušvelnink, ištirk vėliau“, o grįžimas prie žinomos geros versijos dažnai yra greičiausias sušvelninimas. Dirbtinis intelektas yra neįkainojamas apibendrinant žurnalus įvykio metu, siaurinant hipotezes ir sukuriant nepriekaištingus pomirtinius eskizus po įvykio, tačiau jūs esate atsakingi už kiekvienos pagrindinės priežasties hipotezės patvirtinimą naudojant duomenis, išvalant kaltės kalbą ir užmaskuojant įvykių duomenis.

Taikymo užduotis

Apsvarstykite praeities (arba išgalvotą) įvykį. (1) Tegul dirbtinis intelektas generuoja hipotezes ir patikrinimo veiksmus naudojant „greito skirstymo vietoje“ šabloną; Atkreipkite dėmesį, kurią hipotezę galima patvirtinti duomenimis. (2) Nubraižykite ataskaitą naudodami šabloną „nekaltas pomirtinis kontūras“ ir užpildykite jį faktais. (3) Nurodykite bent du elementus, kurių galima imtis, ir kiekvienam priskirkite savininką bei datą.

kontrolinis sąrašas

• [ ] Įvykio metu pirmiausia galvojau apie sušvelninimą (atšaukimą / išjungimą) ir palikau pagrindinę priežastį vėliau.
• [ ] Patikrinau kiekvieną pagrindinės AI hipotezę su log / metrika.
• [ ] Rašiau kalba, kuri nekaltina postmortem, sutelkdama dėmesį į procesą ir sistemą.
• [ ] Kiekvienam elementui, dėl kurio galima imtis veiksmų, priskyriau savininką ir datą.
• [ ] Užmaskavau slaptą ir asmeninę informaciją iš įvykių duomenų, kuriuos pateikiau AI.
• [ ] Teisingai priskyriau sunkumo lygį pagal smūgį.