Pokyčių valdymas: rizikos įvertinimas, grąžinimo ir priežiūros langas

Pelnas:

• Gebėjimas parengti pakeitimo prašymą, rizikos įvertinimą ir grąžinimo planą naudojant dirbtinį intelektą ir padaryti pakeitimą saugų ir nuspėjamu
• Galimybė išplėsti domeną naudojant savo priklausomybės informaciją, klasifikuoti atkuriamumą ir įgyti galimybę planuoti laipsnišką diegimą su canary.
• Gebėjimas suprasti, kad pokyčiams pritaria, planuoja ir atsakomybę prisiima žmogus, ir įgyti discipliną jų neįgyvendinti be sėkmės kriterijų ir kelio atgal.

Pokyčių valdymas: rizikos įvertinimas, grąžinimo ir priežiūros langas su AI

Didžioji dauguma gamybinių sistemų nelaimių kyla ne dėl atakos, o dėl pakeitimo: pataisa, konfigūracijos atnaujinimas, leidimo išleidimas, „smulkus“ pataisymas. Štai kodėl kiekviena brandi organizacija turi pokyčių valdymą: disciplinuojamą gamybos pakeitimo planavimo procesą, jo rizikos įvertinimą, patvirtinimą, įgyvendinimą ir prireikus atšaukimą. Tikslas yra ne užkirsti kelią pokyčiams, o padaryti juos saugius ir nuspėjamus. Čia AI yra galingas asistentas rengiant pakeitimo užklausą, išvardijant rizikas ir paveiktas sistemas, sukuriant atšaukimo plano sistemą ir parengiant diegimo kontrolinį sąrašą. Tačiau pagrindinė taisyklė išlieka: AI parengia pokyčių ir rizikos dokumentavimo planą; Asmuo, kuris patvirtina, planuoja ir prisiima atsakomybę už pokyčius.

Šiame skyriuje pateikiamos pakeitimo prašymo, rizikos įvertinimo, atšaukimo plano, priežiūros lango, kanarinio / etapinio paskirstymo ir CAB (pakeitimų patariamoji taryba) sąvokos; Sužinosite, kaip planuoti saugius pokyčius naudojant AI.

Gero pakeitimo prašymo anatomija

Nekontroliuojamas pakeitimas yra sakinys „Atnaujinau tai“; Kontroliuojamas pakeitimas yra planas. Geras pakeitimų prašymas atsako į šiuos klausimus: kas keičiasi? (apimtis), kodėl? (pagrindimas), Kurios sistemos yra paveiktos? (domenas ir priklausomybės), koks yra rizikos lygis? (žemas/vidutinis/aukštas), kada? (priežiūros langas), Kaip kreiptis? (žingsniai), Kaip patikrinti? (sėkmės kriterijus), kaip susigrąžinti, jei sugenda? (atšaukimas), kas pritaria? (valdžia). AI greitai užpildo šį skeletą, bet jūs tikrai žinote domeną ir riziką, žinote organizaciją; AI sąrašą užpildote savo žiniomis apie priklausomybę.

Patarimas: dvi dažniausiai nepastebimos pakeitimo dalys yra „atšaukimo planas“ ir „sėkmės patvirtinimo kriterijai“. Jei prieš įgyvendindami pakeitimą neturite raštiško atsakymo į klausimus „kur tiksliai su kuria komanda kreiptis, jei nepavyksta“ ir „kaip įrodyti, kad tai buvo sėkminga“, tas pakeitimas dar nėra paruoštas.

Atšaukimas: kiekvieno pakeitimo išėjimo vartai

Pokyčių valdymo esmė yra apyvartos planas. Kiekvienas pakeitimas turi turėti atkūrimo kelią: atšaukti pataisą, atkurti ankstesnę konfigūraciją, grąžinti versiją į ankstesnę versiją, grąžinti iš momentinės nuotraukos. Esminis skirtumas yra toks: kai kuriuos pakeitimus lengva grąžinti (konfigūracijos eilutė), kai kurie yra negrįžtami arba labai sudėtingi (duomenų bazės schemos perkėlimas, duomenų ištrynimas). Negrįžtami pokyčiai yra aukščiausios rizikos klasė ir reikalauja daugiausiai dėmesio, daugiausiai atsarginių kopijų, siauriausio priežiūros lango. Paklauskite AI „ar šį pakeitimą galima atšaukti, o jei ne, kokių papildomų saugumo priemonių turėčiau imtis?

Priežiūros langas ir laipsniškas diegimas

Priežiūros laikotarpis yra iš anksto paskelbtas laikotarpis, per kurį pakeitimas paveiks mažiausiai vartotojų – paprastai naktį arba savaitgalį, kai srautas mažas. Tačiau gerai pasirinkti laiką neužtenka; Palaipsniui diegiant pakeitimą rizika dar labiau sumažinama. „Canary“ diegimas yra pirmiausia pritaikyti pakeitimą nedidelei daliai (vienam serveriui, 5% vartotojų), jį stebėti ir platinti, jei nėra problemų. Tokiu būdu klaida paveiks ne visą laivyną, o nedidelę dalį ir bus sugauta anksti. Galite paprašyti dirbtinio intelekto dėl etapinio diegimo plano ir metrikos, kurią būtų galima stebėti kiekviename etape.

Žingsnis po žingsnio: DI padedami pokyčiai

1. Sudarykite prašymo projektą. Dokumentuokite pakeitimą naudodami AI aukščiau esančiose antraštėse.
2. Išplėskite poveikį. Užpildykite AI paveiktų sistemų sąrašą naudodami savo priklausomybės žemėlapį; „Kas dar susiję su šia paslauga?
3. Klasifikuokite riziką. Žemas/vidutinis/aukštas ir grįžtamasis? Tam reikalingas griežčiausias procesas, kuris yra aukštas ir negrįžtamas.
4. Parašykite atšaukimą ir išbandykite. Užrašykite atšaukimo veiksmus ir, jei įmanoma, pabandykite atšaukti bandymo aplinką – „atšaukimo planas“, kurio negalima atšaukti, nelaikomas planu.
5. Suplanuokite langus ir lygius. Apibrėžkite priežiūros langą ir kanalo etapus bei metriką, kurią reikia stebėti kiekviename etape.
6. Patvirtinimas ir bendravimas. Gaukite institucijos patvirtinimą (jei reikia, CAB), informuokite paveiktus asmenis, įgyvendinkite, stebėkite, patikrinkite.

trys mini dėklai

1 atvejis – atšaukimo planas išgelbėjo naktį. Viena komanda pritaikė žiniatinklio serverio pataisą; Pleistras netikėtai nutraukė priklausomybę ir svetainė pradėjo rodyti 500 klaidą. Tačiau pakeitimo užklausoje buvo parengtas aiškus atšaukimo veiksmas su AI: „pašalinkite pataisą, atkurkite ankstesnį paketą, iš naujo įkelkite paslaugą“. Komanda grįžo po 6 min. Be atšaukimo plano gedimas būtų trukęs valandas, vidury nakties ieškant pagrindinės priežasties.

2 atvejis – Kanarai užfiksavo 5 proc. Bus platinama nauja versija. Komanda paprašė AI sudaryti laipsnišką diegimo planą: pirmiausia 1 serveris, laikrodis, tada 25%, tada viskas. Kanarų serveryje atsakymo laikas padvigubėjo; platinimas buvo sustabdytas. Klaida išliko tik viename serveryje, 95% vartotojų nepaveikė. Jei ji būtų išplitusi iš karto, visa paslauga būtų žlugusi.

3 atvejis. Papildomas negrįžtamo pokyčio matas. Buvo suplanuotas duomenų bazės schemos perkėlimas – pakeitimas, kurį būtų labai sunku grąžinti. Inžinierius paklausė AI apie riziką; YZ pareiškė, kad pakeitimas buvo negrįžtamas, ir rekomendavo sukurti visą atsarginę kopiją, atskirą bandomąjį paleidimą ir siaurą langą. Komanda padarė visą atsarginę kopiją prieš pat perkėlimą, pirmiausia išbandė ją kopijoje. Perkėlimo metu kilo problema, tačiau dėl atsarginės kopijos nuoseklumas buvo atkurtas per 20 minučių.

Keturi kopijuojami šablonai

1) Pakeisti užklausos juodraštį:

Jūsų vaidmuo: pokyčių valdymo specialistas. Sudarykite pakeitimo užklausą dėl šio pakeitimo: [pakeitimas]. Antraštės: Kas/Kodėl, Paveiktos sistemos ir priklausomybės, Rizikos lygis (žemas/vidutinis/didelis + pagrindimas), Ar tai grąžinimas, Diegimo žingsniai, Sėkmės patvirtinimo kriterijai, Atšaukimo veiksmai, Priežiūros lango rekomendacija, Reikalingas patvirtinimas. Pažymėkite priklausomybę, dėl kurios nesate tikri, kaip „patvirtinti“.

2) Rizikos ir poveikio vertinimas:

Įvertinkite šį pokytį rizikos požiūriu: [pakeitimas]. (1) Išvardykite sistemas, kurios gali būti tiesiogiai ir netiesiogiai paveiktos, (2) koks yra blogiausias scenarijus, (3) ar jis yra grįžtamas, jei ne, kokių papildomų priemonių turėčiau imtis, (4) pagrįsti rizikos lygį. Paaiškinkite, kad tai yra preliminarus įvertinimas ir sprendimas yra mano.

3) Sukurkite atšaukimo planą:

Parašykite nuoseklų [pakeitimo] atkūrimo planą. Įsitikinkite, kad kiekvieną veiksmą galima nukopijuoti ir patikrinti. Jei yra negrįžtamų pakeitimo dalių, aiškiai nurodykite ir užsirašykite, kurią atsarginę kopiją turėčiau daryti. Pridėkite, kaip patikrinti atšaukimo sėkmę.

4) Laipsniško platinimo (kanarėlių) planas:

Pasiūlykite [diegimo] etapų planą tokiam diegimui: kurie etapai (pvz., 1 serveris -> 25% -> visi), kiek laiko turėčiau laukti kiekvienoje fazėje ir KOKIĄ metriką turėčiau stebėti (atsakymo laikas, klaidų dažnis ir kt.)? Kokią slenkstį turėčiau sustabdyti ir atšaukti diegimą, jei jis viršytas? Aiškiai parašykite savo sprendimo taškus.

Silpnas raginimas / Stiprus raginimas

Silpnas raginimas:

Ar turėčiau pritaikyti šį pleistrą?

Jokio konteksto, jokio poveikio, jokio pertekliaus, jokių langų. AI nežino nei jūsų sistemos, nei jūsų rizikos; „Taip / ne“ yra neatsakingas spėjimas.

Galingas raginimas:

Jūsų vaidmuo: pokyčių valdymo specialistas. Taikysiu saugos pataisą gamybinių žiniatinklio serverių parkui (8 serveriai, už apkrovos balansavimo priemonės). Pateikite man: (1) šio pakeitimo pakeitimo užklausos juodraštį, (2) priklausomybes, kurios gali būti paveiktos (patvirtinsiu), (3) atšaukimo veiksmus, (4) planą kaip 1 serveris -> 25% -> viską ir metriką, kurią stebėsiu kiekviename etape. Pagrįskite rizikos lygį. Pritariu ir nusprendžiu.

Keisti funkciją

maža rizika

didelė rizika

grįžtamumas

lengvas atšaukimas

neatšaukiamas/sunkus

domenas

Viena patiekiama, izoliuota

Kelių paslaugų, priklausomybės grandinė

Paskirstymas

gali būti tiesioginis

Privaloma kanarėlė + siauras langas

Patvirtinimas

komandos viduje

CAB / viršutinis patvirtinimas

atsarginis

Standartinis

Papildoma pilna atsarginė kopija + bandomasis paleidimas

Dažnos klaidos

• Įgyvendinimas be atšaukimo plano. Pokyčiai yra azartas, jei kelias atgal neužrašytas.
• Išlaikyti siaurą įtakos sferą. Apeinant paslėptas priklausomybes, susijusias su paslauga, atsiras netikėtų šalutinių trikdžių.
• Negrįžtamus pokyčius painiojame su įprastais. Tokiems pakeitimams kaip schemos perkėlimas ir duomenų ištrynimas reikalauja griežčiausio proceso ir visos atsarginės kopijos.
• Paskleisti jį visam laivynui vienu metu. Be Canary klaida iš karto ištiktų visus vartotojus.
• Neapibrėžia sėkmės kriterijų. Jei neparašyta, kas reiškia „sėkmingas“, sugadintą pakeitimą galite supainioti su „baigtas“.

Dėmesio: AI sudarytas paveiktų sistemų sąrašas yra preliminarus, o ne visas sąrašas. AI nežino jūsų organizacijos priklausomybių; Tikslus atsakymas į klausimą "Jei ši paslauga sugenda, kas dar suges?" slypi jūsų įmonės žiniose. Tarkime, kad AI sąrašas yra neišsamus, ir išplėskite jį.

Apibendrinant

Dauguma gamybos nelaimių kyla dėl pokyčių, o ne dėl atakos; Pokyčių valdymas netrukdo pokyčiams, jis daro juos saugius ir nuspėjamus. AI; Greitai parengia pakeitimų užklausas, rizikos vertinimus, atšaukimo planus ir etapinio diegimo kontrolinius sąrašus. Tačiau išplėskite domeną su savo tikrosiomis priklausomybės žiniomis, klasifikuokite grįžtamumą, parašykite atšaukimą ir, jei įmanoma, išbandykite, paskirstykite riziką su priežiūros langu ir kanarėlėmis, apibrėžkite sėkmės kriterijus. Žmogus yra tas, kuris pritaria pokyčiams, suplanuoja ir prisiima atsakomybę už pokyčius; AI yra partneris, kuris pagreitina planą.

Taikymo užduotis

Pasirinkite gamybos pakeitimą, kurį planuojate atlikti netrukus (arba neseniai atlikote). Paprašykite dirbtinio intelekto paruošti visą pakeitimo užklausą naudodami anksčiau pateiktą šabloną „Keisti užklausos juodraštį“. Išplėskite „paveiktų sistemų“, kurias sukuria AI, sąrašą bent dviem elementais su savo priklausomybės informacija. Išspausdinkite atšaukimo veiksmus naudodami šabloną „Generuoti atšaukimo planą“ ir nustatykite, ar nėra pakeitimo dalies, kurios negalima atšaukti. Galiausiai sugalvokite kanarėlės planą. Apibendrinkite visą planą į 6 punktus ir pažymėkite, kokių patvirtinimų reikia.

kontrolinis sąrašas

• [ ] Ar parengiau pakeitimo užklausą, apimančią kas/kodėl, poveikį, riziką, veiksmus, patikrinimą ir atšaukimą?
• [ ] Ar išplėčiau AI paveiktų sistemų sąrašą įtraukdamas savo priklausomybės informaciją?
• [ ] Ar klasifikavau, ar pokytis yra grįžtamas, ar negrįžtamas?
• [ ] Parašiau atšaukimo veiksmus ir išbandžiau bandomojoje aplinkoje, jei įmanoma?
• [ ] Ar nustačiau priežiūros langą ir kanarėlių diegimo planą bei stebėjimo metrikas kiekvienam etapui?
• [ ] Ar apibrėžiau sėkmės patvirtinimo kriterijus ir gavau reikiamus patvirtinimus?