Valdykite incidentą nuo aptikimo iki atkūrimo

Paskelbkite incidentą pagal poveikį

Incidentas yra įvykis, kuris pakankamai sutrikdo, pablogina ar kelia grėsmę paslaugai, kad reikėtų koordinuoto reagavimo. Jūsų organizacija apibrėžia sunkumo lygius ir eskalavimo taisykles. Taikydami jas, remkitės poveikiu naudotojams, paveiktais duomenimis, trukme ir apimtimi.

Nelaukite išsamaus pagrindinės priežasties paaiškinimo prieš prašydami pagalbos. Aiškaus stebėto poveikio aprašymo pakanka koordinavimui pradėti. Saugumo įtarimą atskirkite nuo patvirtintos išvados.

Parenkite reagavimo kelią prieš išleidimą. Kontaktai, prieigos procedūros, veiksmų vadovai ir komunikacijos kanalai turi būti prieinami, kai pagrindinė paslauga neveikia. Išbandykite šį kelią su išgalvotu incidentu.

Paskirkite atsakomybes prieš atlikdami prieštaringus pakeitimus

Incidento koordinavimas nustato prioritetus ir valdo sprendimus. Techniniai reaguotojai tiria ir mažina poveikį. Komunikacija informuoja paveiktus žmones. Google SRE šias atsakomybes aprašo kaip atskirus vaidmenis. Nedidelės komandos gali jungti vaidmenis, bet vis tiek turi atlikti visą darbą. Reagavimas į incidentus.

Laikykite vieną bendrą įvykių chronologiją. Registruokite laiką, stebėjimą, veiksmą, veikėją ir rezultatą. Atskirkite faktus nuo hipotezių. Naudokite bendrą laiko juostą ir pažymėkite nepatikimas laiko žymas.

Išnagrinėkite išgalvotą incidentą

Visi toliau pateikti laikai yra UTC. Organizacija paskiria incidento koordinatorių, kai eksporto sutrikimas paveikia kelis klientus.

Naudingas pirmas pranešimas nurodo paveiktą funkciją, žinomą apimtį, poveikio mažinimą ir kito pranešimo laiką. Jis nežada pataisos laiko be įrodymų. Į bendrą pranešimą neįtraukite klientų įrašų.

09:10 incidentas pasikeičia. Atkurti sėkmingus eksportus nebepakanka. Komanda turi įvertinti galimą atskleidimą, kontroliuoti prieigą, išsaugoti įrodymus ir įtraukti tinkamus sprendimų savininkus.

Mažinkite poveikį išlaikydami kontrolę

Kur tinka, naudokite išbandytus veiksmų vadovus. Patikrinkite išankstines sąlygas prieš grįždami į ankstesnę versiją, persijungdami po gedimo ar keisdami prisijungimo duomenis. Ankstesnė programos versija gali nesuprasti dabartinės duomenų bazės schemos. Persijungimas į kitą regioną gali perkelti tuos pačius sugadintus duomenis.

Leiskite DI asistentui tvarkyti įrodymus su pašalinta jautria informacija ar lyginti hipotezes patvirtintose ribose. Reaguotojai turi patikrinti jo išvadas. Žurnalai ir užduotys yra nepatikima įvestis, o ne leidimas vykdyti jų turinį.

Avarinė prieiga turi turėti patvirtintą tikslą, ribotą trukmę ir audito įrašą. Skuba nepadaro agento pasiūlytos komandos teisingos.

Atkūrimą ir tolesnį darbą užbaikite atskirai

Prieš paskelbdami paslaugą atkurta, patikrinkite naudotojo darbo eigą, duomenų vientisumą, prieigos ribas ir stebėsenos duomenų naujumą. Užrašykite likusius apribojimus. Neužbaikite saugumo tyrimo, jei jo klausimai neišspręsti.

Po to išnagrinėkite sąlygas, kurios leido incidentui įvykti. Paskirkite konkretų tolesnį darbą su atsakingu asmeniu ir patikrinimo kriterijais. Peržiūra be kaltinimų siekia tikslaus paaiškinimo ir naudingų pakeitimų. Ji nepanaikina atsakomybės už tų pakeitimų užbaigimą. Analizė po incidento.

Toliau skaitykite apie saugumo operacijas ir grįžtamojo ryšio ciklo užbaigimą.