Muudatuste juhtimine: riskihindamine, tagasipööramine ja hooldusaken

Kasu:

• Võimalus koostada tehisintellektiga muudatustaotlus, riskianalüüs ja tagasipööramise plaan ning muuta muudatus ohutuks ja prognoositavaks
• Võimalus laiendada domeeni oma sõltuvusteabega, klassifitseerida taastatavust ja omandada võimalus kavandada järkjärgulist kasutuselevõttu Canaryga.
• Oskus mõista, et inimene on see, kes muutuse heaks kiidab, planeerib ja selle eest vastutab, ning omandada distsipliin seda mitte ellu viia ilma edukriteeriumideta ja tagasiteed.

Muudatuste juhtimine: riskihindamine, tagasipööramine ja hooldusaken koos tehisintellektiga

Valdav enamus tootmissüsteemide katastroofe ei tulene mitte rünnakust, vaid muudatusest: paigast, konfiguratsioonivärskendusest, väljalaske juurutamisest, „väikesest” parandusest. Seetõttu on igas küpses organisatsioonis muudatuste juhtimine: tootmismuudatuse kavandamise, selle riski hindamise, heakskiitmise, elluviimise ja vajadusel tagasilükkamise distsiplineerimisprotsess. Eesmärk ei ole muutusi ära hoida, vaid muuta need turvaliseks ja etteaimatavaks. Siin on AI võimas abiline muudatustaotluste koostamisel, riskide ja mõjutatud süsteemide loetlemisel, tagasipööramisplaani raamistiku loomisel ja juurutamise kontrollnimekirja koostamisel. Põhireegel jääb aga kehtima: AI koostab kavandi muutuste ja riskide dokumenteerimiseks; Isik, kes muudatuse heaks kiidab, ajastab ja selle eest vastutab.

Selles üksuses on mõisted muudatustaotlus, riskianalüüs, tagasipööramiskava, hooldusaken, kanalisatsioon/etapiline levitamine ja CAB (Change Advisory Board); Õpid, kuidas AI abil ohutuid muutusi planeerida.

Hea muutuse taotluse anatoomia

Kontrollimatu muudatus on lause "Ma uuendasin seda"; Kontrollitud muutus on plaan. Hea muudatustaotlus vastab järgmistele küsimustele: Mis muutub? (ulatus), miks? (põhjendus), Milliseid süsteeme see mõjutab? (domeen ja sõltuvused), Mis on riskitase? (madal/keskmine/kõrge), millal? (hooldusaken), Kuidas taotleda? (sammud), Kuidas kontrollida? (edukriteerium), Kuidas seda tagasi saada, kui see halvasti läheb? (tagasi), kes kiidab heaks? (asutus). Tehisintellekt täidab selle luustiku kiiresti – aga sina oled see, kes tõesti tunneb domeeni ja riski, kes tunneb organisatsiooni; Täiendate tehisintellekti nimekirja oma sõltuvusteadmistega.

Näpunäide. Muudatuse kaks kõige sagedamini tähelepanuta jäetud osa on tagasipööramisplaan ja edukuse kinnitamise kriteeriumid. Kui sul ei ole enne muudatuse rakendamist kirjalikku vastust küsimustele "kuhu täpselt millise käsuga pöördun, kui läheb halvasti" ja "kuidas ma tõestan, et see õnnestus", pole see muudatus veel valmis.

Tagasipööramine: iga muudatuse väljumisvärav

Muudatuste juhtimise keskmes on pöördeplaan. Igal muudatusel peab olema tagasipööramise tee: tagasipööramine, eelmise konfiguratsiooni taastamine, versiooni tagasipööramine eelmisele versioonile, tagasipööramine hetktõmmisest. Kriitiline erinevus on järgmine: mõnda muudatust on lihtne tagasi pöörata (konfiguratsioonirida), mõned on pöördumatud või väga keerulised (andmebaasi skeemi migreerimine, andmete kustutamine). Pöördumatud muudatused on kõrgeim riskiklass ja nõuavad kõige rohkem tähelepanu, kõige rohkem varukoopiaid, kõige kitsamat hooldusakent. Küsige tehisintellektilt "kas seda muudatust saab tagasi võtta ja kui ei, siis milliseid täiendavaid turvameetmeid peaksin võtma?"

Hooldusaken ja etapiviisiline juurutamine

Hooldusaken on ette teatatud ajavahemik, mille jooksul muudatus mõjutab kõige vähem kasutajaid – tavaliselt öösel või nädalavahetusel, kui liiklus on väike. Kuid õigest aja valimisest ei piisa; Muudatuse järkjärguline kasutuselevõtt vähendab riski veelgi. Canary juurutamine hõlmab esmalt muudatuse rakendamist väikesele osale (üks server, 5% kasutajatest), selle jälgimine ja probleemide puudumisel levitamine. Nii ei mõjuta viga kogu laevastikku, vaid väikest osa ja tabatakse varakult. Saate küsida tehisintellekti etapiviisilist juurutusplaani ja mõõdikuid, mida igas etapis jälgida.

Samm-sammult: AI-abiga muudatus

1. Koostage taotlus. Dokumenteerige muudatus ülaltoodud pealkirjades tehisintellektiga.
2. Laiendage mõju. Täiendage AI mõjutatud süsteemide loendit oma sõltuvuskaardiga; "Mis on veel selle teenusega seotud?"
3. Klassifitseerige risk. Madal/keskmine/kõrge ja pööratav? See nõuab kõige rangemat protsessi, mis on kõrge ja pöördumatu.
4. Kirjutage tagasikäik ja testige seda. Kirjutage üles tagasipööramise sammud ja proovige võimalusel testkeskkonnas tagasi kerida – "tagasiplaani", mida ei saa tagasi pöörata, ei lähe plaanina arvesse.
5. Planeerige aknad ja tasemed. Määrake hooldusaken ja kanaari etapid ning mõõdikud, mida igas etapis jälgida.
6. Kinnitus ja suhtlus. Hankige asutuse luba (vajadusel CAB), teavitage mõjutatud isikuid, rakendage, jälgige, kontrollige.

kolm minikarpi

Juhtum 1 – tagasipööramisplaan päästis öö. Üks meeskond rakendas veebiserveri paiga; Plaaster katkestas ootamatult sõltuvuse ja sait hakkas andma 500 viga. Kuid muudatustaotluses oli AI-ga koostatud selge tagasipööramise samm: "eemaldage plaaster, taastage eelmine pakett, laadige teenus uuesti." Meeskond naasis 6 minuti pärast. Ilma tagasipööramisplaanita oleks katkestus keset ööd algpõhjust otsides kestnud tunde.

Juhtum 2 – Canary tabas 5% vea. Levitaks uus versioon. Meeskond palus AI-lt järkjärgulist juurutusplaani: kõigepealt 1 server, kell, seejärel 25%, seejärel kõik. Canary serveris oli reageerimisaeg kahekordistunud; levitamine on peatatud. Viga püsis ainult ühes serveris, 95% kasutajatest ei olnud mõjutatud. Kui see oleks korraga levinud, oleks kogu teenus kokku kukkunud.

Juhtum 3 – pöördumatu muutuse lisameede. Kavas oli andmebaasiskeemi migreerimine – muudatus, mida oleks väga raske tagasi pöörata. Insener küsis AI-lt riski kohta; YZ teatas, et muudatus oli pöördumatu, ja soovitas täielikku varukoopiat, eraldi testimist ja kitsast akent. Meeskond tegi vahetult enne migreerimist täieliku varukoopia ja proovis seda esmalt koopiaga. Migreerimisel tekkis probleem, kuid tänu varukoopiale taastus järjepidevus 20 minutiga.

Neli kopeeritavat malli

1) Muudatustaotluse mustand:

Sinu roll: muudatuste juhtimise spetsialist. Koostage muudatustaotlus järgmise muudatuse jaoks: [muuda]. Pealkirjad: Mis/Miks, Mõjutatud süsteemid ja sõltuvused, Riskitase (madal/keskmine/kõrge + põhjendus), Kas see on tagasivõtmine, juurutamisetapid, Edukuse kontrolli kriteeriumid, Tagastamisetapid, Hooldusakna soovitus, Nõutav kinnitus. Märkige sõltuvus, milles te pole kindel, "kinnita".

2) Riski- ja mõjuhinnang:

Hinda riski seisukohalt järgmist muutust: [muutus]. (1) Loetlege süsteemid, mida võib otseselt ja kaudselt mõjutada, (2) milline on halvim stsenaarium, (3) kas see on pöörduv, kui ei, siis milliseid lisameetmeid peaksin võtma, (4) põhjendama riskitaset. Selgitage, et see on esialgne hinnang ja otsus on minu.

3) Tagastamisplaani koostamine:

Kirjutage [muuda] jaoks samm-sammult tagasipööramise plaan. Veenduge, et iga sammu saab kopeerida ja kontrollida. Kui muudatuses on pöördumatuid osi, öelge see selgelt ja kirjutage üles, millise varukoopia peaksin nende jaoks tegema. Lisage, kuidas tagasipööramise edukust kontrollida.

4) etapiviisilise levitamise (kanaari) plaan:

Soovitage [juurutamise] etapiviisilist plaani järgmise juurutamise jaoks: millised etapid (nt 1 server -> 25% -> kõik), kui kaua ma peaksin igas etapis ootama ja MILLISEID mõõdikuid peaksin jälgima (reageerimisaeg, veamäär jne)? Millise läve peaksin peatama ja juurutamise tagasi tõmbama, kui see ületatakse? Kirjutage selgelt oma otsustuspunktid.

Nõrk viip / Tugev viip

Nõrk viip:

Kas ma peaksin selle plaastri peale panema?

Pole konteksti, pole mõju, pole koondamist ega aknaid. AI ei tunne teie süsteemi ega teie riske; "Jah/ei", mille see annaks, on vastutustundetu oletus.

Võimas viip:

Sinu roll: muudatuste juhtimise spetsialist. Rakendan turvapaiga tootmises olevatele veebiserveritele (8 serverit, koormuse tasakaalustaja taga). Andke mulle: (1) selle muudatuse muudatustaotluse mustand, (2) sõltuvused, mida see võib mõjutada (kinnitan), (3) tagasipööramise etapid, (4) kanaari plaan 1 serverina -> 25% -> kõik ja mõõdikud, mida igas etapis jälgin. Põhjendage riskitaset. Kiidan heaks ja otsustan.

Funktsiooni muutmine

madal risk

kõrge risk

pöörduvus

lihtne tagasipööramine

pöördumatu/raske

domeeni

Üks serveering, isoleeritud

Multiteenus, sõltuvusahel

Levitamine

võib olla otsene

Kohustuslik kanaari + kitsas aken

Heakskiit

meeskonna sees

CAB / ülemine kinnitus

tagavaraks

Standardne

Täiendav täielik varukoopia + proovitöö

Levinud vead

• Rakendamine ilma tagasipööramisplaanita. Muutus on õnnemäng, kui tagasiteed pole kirja pandud.
• Mõjusfääri kitsas hoidmine. Teenusega seotud varjatud sõltuvustest möödahiilimine toob kaasa ootamatud külgkatkestused.
• Seoses pöördumatu muutusega tavalisega. Muudatused, nagu skeemi migreerimine ja andmete kustutamine, nõuavad kõige rangemat protsessi ja täielikku varundamist.
• Jaotades selle korraga kogu laevastikule. Ilma Canaryta tabaks viga kõiki kasutajaid korraga.
• Ei määratle edukriteeriume. Kui pole kirjas, mida "edukas" tähendab, võite katkise muudatuse ekslikult pidada sõnaga "täielik".

Tähelepanu: AI koostatud mõjutatud süsteemide loend on esialgne, mitte täielik loetelu. AI ei tea teie organisatsiooni sõltuvusi; Täpne vastus küsimusele "Kui see teenus jookseb kokku, siis mis veel jookseb kokku?" peitub teie ettevõtte teadmistes. Oletame, et tehisintellekti loend on puudulik ja laiendage seda.

Kokkuvõttes

Enamik tootmiskatastroofe tuleneb muutustest, mitte rünnakust; Muudatuste juhtimine ei takista muutusi, vaid muudab need turvaliseks ja etteaimatavaks. AI; Koostab kiiresti muudatustaotlused, riskihinnangud, tagasivõtmise plaanid ja etapiviisilise juurutamise kontrollnimekirjad. Kuid laiendage domeeni oma tegelike sõltuvusteadmistega, klassifitseerige pöörduvust, kirjutage tagasi ja võimalusel testige seda, jagage riske hooldusakna ja kanaariga, määrake edukriteeriumid. Inimene on see, kes muudatuse heaks kiidab, kavandab ja selle eest vastutab; AI on partner, kes plaani kiirendab.

Rakenduse ülesanne

Valige tootmismuudatus, mille kavatsete peagi teha (või olete hiljuti teinud). Laske tehisintellektil koostada täielik muudatustaotlus, kasutades ülalolevat malli „Muudatustaotluse mustand”. Laiendage tehisintellekti loodud "mõjutatud süsteemide" loendit vähemalt kahe üksuse võrra teie enda sõltuvusteabega. Printige välja tagasipööramise etapid malliga „Loo tagasipööramisplaan” ja tehke kindlaks, kas muudatuses on mõni osa, mida ei saa tagasi pöörata. Lõpuks mõtle välja kanaari plaan. Võtke kogu plaan kokku 6 punktiga ja märkige, millised kooskõlastused on vajalikud.

kontrollnimekiri

• [ ] Kas olen koostanud muudatuse taotluse, mis sisaldab mida/miks, mõju, riski, samme, kontrollimist ja tagasivõtmist?
• [ ] Kas ma olen laiendanud tehisintellekti mõjutatud süsteemide loendit oma sõltuvusteabega?
• [ ] Kas olen klassifitseerinud, kas muutus on pöörduv või pöördumatu?
• [ ] Kirjutasin tagasipööramise sammud ja proovisin võimalusel testkeskkonnas?
• [ ] Kas olen kindlaks määranud iga etapi hooldusakna ja kanaari kasutuselevõtuplaani ning seiremõõdikud?
• [ ] Kas olen määratlenud edukuse kontrollimise kriteeriumid ja saanud vajalikud kinnitused?