Izmaiņu pārvaldība: riska novērtēšana, atcelšanas un uzturēšanas logs

Ieguvumi:

• Spēja izstrādāt izmaiņu pieprasījumu, riska novērtējumu un atcelšanas plānu ar mākslīgo intelektu un padarīt izmaiņas drošas un paredzamas
• Iespēja paplašināt domēnu ar savu atkarības informāciju, klasificēt atgūstamību un iegūt iespēju plānot pakāpenisku izvietošanu ar kanārijputnu.
• Spēju saprast, ka cilvēks ir tas, kurš apstiprina, ieplāno un uzņemas atbildību par izmaiņām, un apgūt disciplīnu tās neieviest bez veiksmes kritērijiem un atpakaļceļa.

Izmaiņu pārvaldība: riska novērtēšana, atcelšanas un uzturēšanas logs ar AI

Lielākā daļa katastrofu ražošanas sistēmās rodas nevis uzbrukuma, bet gan izmaiņu dēļ: ielāps, konfigurācijas atjauninājums, laidiena izlaišana, "neliels" labojums. Tāpēc katrai nobriedušai organizācijai ir izmaiņu vadība: ražošanas izmaiņu plānošanas, riska novērtēšanas, apstiprināšanas, ieviešanas un vajadzības gadījumā atcelšanas process. Mērķis nav novērst pārmaiņas, bet gan padarīt tās drošas un paredzamas. Šeit AI ir spēcīgs palīgs izmaiņu pieprasījuma sastādīšanā, risku un ietekmēto sistēmu uzskaitīšanā, atcelšanas plāna ietvara izveidē un izvietošanas kontrolsaraksta sagatavošanā. Taču pamatnoteikums paliek spēkā: AI izstrādā projektu izmaiņu un risku dokumentēšanai; Persona, kas apstiprina, plāno un uzņemas atbildību par izmaiņām.

Šajā nodaļā izmaiņu pieprasījuma jēdzieni, riska novērtējums, atcelšanas plāns, apkopes periods, kanāra/pakāpju izplatīšana un CAB (Izmaiņu konsultatīvā padome); Jūs uzzināsit, kā plānot drošas izmaiņas, izmantojot AI.

Labas maiņas pieprasījuma anatomija

Nekontrolētas izmaiņas ir teikums "Es atjaunināju šo"; Kontrolētas izmaiņas ir plāns. Labs izmaiņu pieprasījums atbild uz šiem jautājumiem: Kas mainās? (joma), kāpēc? (pamatojums), Kuras sistēmas tiek ietekmētas? (domēns un atkarības), kāds ir riska līmenis? (zems/vidējs/augsts), kad? (apkopes logs), Kā pieteikties? (soļi), Kā pārbaudīt? (veiksmes kritērijs), kā to atgūt, ja sabojājas? (atcelšana), kurš apstiprina? (iestāde). AI ātri aizpilda šo skeletu, taču jūs patiešām zināt domēnu un risku, pazīstat organizāciju; Jūs aizpildāt AI sarakstu ar savām zināšanām par atkarību.

Padoms. Divas visbiežāk aizmirstās izmaiņu daļas ir “atcelšanas plāns” un “veiksmes verifikācijas kritēriji”. Ja pirms izmaiņu ieviešanas jums nav rakstiskas atbildes uz jautājumiem "kur tieši ar kuru komandu man griezties, ja tas sabojājas" un "kā pierādīt, ka tas bija veiksmīgs", šīs izmaiņas vēl nav gatavas.

Atcelšana: katras izmaiņas izejas vārti

Izmaiņu vadības pamatā ir apgrozījuma plāns. Katrai izmaiņai ir jābūt atcelšanas ceļam: atcelšanas ielāps, iepriekšējās konfigurācijas atjaunošana, versijas atgriešana uz iepriekšējo versiju, atcelšana no momentuzņēmuma. Būtiskākā atšķirība ir šāda: dažas izmaiņas ir viegli atgriezt (konfigurācijas līnija), dažas ir neatgriezeniskas vai ļoti sarežģītas (datu bāzes shēmas migrācija, datu dzēšana). Neatgriezeniskas izmaiņas ir augstākā riska klase un prasa vislielāko uzmanību, visvairāk rezerves kopiju, šaurāko apkopes logu. Pajautājiet AI “vai šīs izmaiņas var atsaukt, un, ja nē, kādi papildu drošības pasākumi man būtu jāveic?”

Apkopes logs un pakāpeniska izvietošana

Apkopes periods ir iepriekš paziņots laika periods, kurā izmaiņas ietekmēs vismazāko lietotāju skaitu — parasti naktī vai nedēļas nogalē, kad satiksme ir maza. Bet ar pareizu laika izvēli nepietiek; Pakāpeniska izmaiņu ieviešana vēl vairāk samazina risku. Kanāriju izvietošanai vispirms ir jāpiemēro izmaiņas nelielai daļai (vienam serverim, 5% lietotāju), tās jāuzrauga un jāizplata, ja nav problēmu. Tādā veidā kļūda neietekmēs visu floti, bet gan nelielu daļu, un tā tiks noķerta agri. Varat lūgt AI pakāpenisku izvietošanas plānu un metriku, ko izsekot katrā posmā.

Soli pa solim: AI atbalstītas izmaiņas

1. Sagatavojiet pieprasījuma projektu. Dokumentējiet izmaiņas, izmantojot AI augstāk esošajos virsrakstos.
2. Paplašiniet ietekmi. Pabeidziet AI ietekmēto sistēmu sarakstu ar savu atkarības karti; "Kas vēl ir saistīts ar šo pakalpojumu?"
3. Klasificējiet risku. Zems/vidējs/augsts un atgriezenisks? Tam nepieciešams visstingrākais process, kas ir augsts un neatgriezenisks.
4. Uzrakstiet atcelšanu un pārbaudiet to. Pierakstiet atcelšanas darbības un, ja iespējams, mēģiniet atgriezties testa vidē — “atcelšanas plāns”, kuru nevar atsaukt, netiek uzskatīts par plānu.
5. Plānojiet logus un līmeņus. Definējiet apkopes logu un kanāriju posmus, kā arī metriku, kas jāpārrauga katrā posmā.
6. Apstiprināšana un saziņa. Saņemt iestādes apstiprinājumu (ja nepieciešams, CAB), informēt skartos, ieviest, uzraudzīt, pārbaudīt.

trīs mini futrāļi

1. gadījums — atcelšanas plāns izglāba nakti. Viena komanda lietoja tīmekļa servera ielāpu; Plāksteris negaidīti pārtrauca atkarību, un vietne sāka rādīt kļūdu 500. Bet izmaiņu pieprasījumā bija skaidrs atcelšanas solis, kas tika sagatavots ar AI: "noņemiet ielāpu, atjaunojiet iepriekšējo pakotni, atkārtoti ielādējiet pakalpojumu." Komanda atgriezās pēc 6 minūtēm. Bez atcelšanas plāna pārtraukums būtu ilgs stundām, nakts vidū meklējot galveno cēloni.

2. gadījums — Kanārija noķēra kļūdu pie 5%. Tiks izplatīta jauna versija. Komanda lūdza AI izstrādāt pakāpenisku izvietošanas plānu: vispirms 1 serveris, pulkstenis, pēc tam 25%, tad viss. Tika novērots, ka Kanāriju serverī atbildes laiks ir dubultojies; izplatīšana ir apturēta. Kļūda saglabājās tikai vienā serverī, un 95% lietotāju netika ietekmēti. Ja tas būtu izplatījies uzreiz, viss pakalpojums būtu sabrukts.

3. gadījums — neatgriezenisku izmaiņu papildu pasākums. Bija plānota datu bāzes shēmas migrācija — izmaiņas, kuras būtu ļoti grūti atgriezt. Inženieris jautāja AI par risku; YZ paziņoja, ka izmaiņas ir neatgriezeniskas, un ieteica izveidot pilnu dublējumu, atsevišķu testa darbību un šauru logu. Komanda izveidoja pilnu dublējumu tieši pirms migrācijas, vispirms izmēģināja to kopijā. Migrēšanas laikā radās problēma, taču, pateicoties dublējumam, konsekvence tika atjaunota 20 minūšu laikā.

Četras kopējamas veidnes

1) Izmaiņu pieprasījuma melnraksts:

Jūsu loma: pārmaiņu vadības speciālists. Sagatavojiet izmaiņu pieprasījumu šādām izmaiņām: [mainīt]. Virsraksti: Kas/Kāpēc, Ietekmētās sistēmas un atkarības, Riska līmenis (zems/vidējs/augsts + pamatojums), Vai tas ir atcelšana, ieviešanas soļi, veiksmes pārbaudes kritēriji, atcelšanas soļi, apkopes loga ieteikums, nepieciešamais apstiprinājums. Atzīmējiet atkarību, par kuru neesat pārliecināts, kā "verificēt".

2) Riska un ietekmes novērtējums:

Novērtējiet šādas izmaiņas riska izteiksmē: [izmaiņas]. (1) Uzskaitiet sistēmas, kuras var tieši un netieši ietekmēt, (2) kāds ir sliktākais scenārijs, (3) vai tas ir atgriezenisks, ja nē, kādi papildu pasākumi man jāveic, (4) jāpamato riska līmenis. Paskaidrojiet, ka šis ir sākotnējais novērtējums un lēmums ir mans.

3) Atcelšanas plāna izveide:

Uzrakstiet soli pa solim atcelšanas plānu [mainīt]. Pārliecinieties, vai katru darbību var kopēt un pārbaudīt. Ja izmaiņās ir neatgriezeniskas daļas, skaidri norādiet to un pierakstiet, kura rezerves kopija man būtu jāveic. Pievienojiet, kā pārbaudīt atcelšanas panākumus.

4) Pakāpeniskās izplatīšanas (kanārijputniņu) plāns:

Iesakiet [izvietošanas] pakāpenisku plānu šādai izvietošanai: kuras fāzes (piemēram, 1 serveris —> 25% —> visas), cik ilgi man jāgaida katrā fāzē un KĀDIEM rādītājiem man vajadzētu izsekot (reakcijas laiks, kļūdu līmenis utt.)? Kāds slieksnis ir jāpārtrauc un jāatceļ izvietošana, ja tas tiek pārsniegts? Skaidri uzrakstiet savus lēmuma punktus.

Vāja uzvedne / spēcīga uzvedne

Vāja uzvedne:

Vai man vajadzētu lietot šo plāksteri?

Bez konteksta, bez ietekmes, bez atlaišanas, bez logiem. AI nezina ne jūsu sistēmu, ne risku; Tas "jā/nē" ir bezatbildīgs minējums.

Spēcīga uzvedne:

Jūsu loma: pārmaiņu vadības speciālists. Es uzlikšu drošības ielāpu ražošanas procesā esošu tīmekļa serveru parkam (8 serveri, aiz slodzes līdzsvarotāja). Sniedziet man: (1) izmaiņu pieprasījuma melnrakstu šīm izmaiņām, (2) atkarības, kuras var ietekmēt (es apstiprināšu), (3) atcelšanas darbības, (4) kanāriju plānu kā 1 serveri —> 25% —> visu un metriku, ko es pārraudzīšu katrā posmā. Pamatojiet riska līmeni. Es apstiprinu un izlemju.

Mainīt funkciju

zems risks

augsts risks

atgriezeniskums

viegla atgriešana

neatsaucami/grūti

domēns

Viena serve, izolēta

Daudzpakalpojumu, atkarības ķēde

Izplatīšana

var būt tieša

Obligāti kanārijputniņš + šaurs logs

Apstiprināšana

komandas ietvaros

CAB / augšējais apstiprinājums

rezerves

Standarta

Papildus pilna dublēšana + testa palaišana

Biežas kļūdas

• Īstenošana bez atcelšanas plāna. Pārmaiņas ir azarts, ja atpakaļceļš nav pierakstīts.
• Ietekmes sfēras šaura saglabāšana. Apejot pakalpojumam pievienotās slēptās atkarības, radīsies neparedzēti sānu pārtraukumi.
• Jaukt neatgriezeniskas izmaiņas ar parasto. Izmaiņām, piemēram, shēmas migrācijai un datu dzēšanai, ir nepieciešams visstingrākais process un pilnīga dublēšana.
• Izplatot to uz visu floti uzreiz. Ja nebūtu Canary, kļūda skartu visus lietotājus uzreiz.
• Nav definēts veiksmes kritērijs. Ja nav uzrakstīts, kas nozīmē "veiksmīgs", jūs varat sajaukt bojātas izmaiņas ar "pabeigts".

Uzmanību: AI izveidotais ietekmēto sistēmu saraksts ir provizorisks, nevis pilnīgs. AI nezina jūsu organizācijas atkarības; Precīza atbilde uz jautājumu "Ja šis pakalpojums avarē, kas vēl avarēs?" slēpjas jūsu uzņēmuma zināšanās. Pieņemsim, ka AI saraksts ir nepilnīgs, un paplašiniet to.

Rezumējot

Lielākā daļa ražošanas katastrofu rodas pārmaiņu, nevis uzbrukuma rezultātā; Izmaiņu vadība nenovērš pārmaiņas, tā padara tās drošas un paredzamas. AI; Ātri sagatavo izmaiņu pieprasījumus, riska novērtējumus, atcelšanas plānus un pakāpeniskas izvietošanas kontrolsarakstus. Bet paplašiniet domēnu ar savām reālajām atkarības zināšanām, klasificējiet atgriezeniskumu, ierakstiet atcelšanu un pārbaudiet to, ja iespējams, sadaliet risku, izmantojot apkopes logu un kanāriju, definējiet veiksmes kritērijus. Cilvēks ir tas, kurš apstiprina, ieplāno izmaiņas un ir par tām atbildīgs; AI ir partneris, kas paātrina plānu.

Lietojumprogrammas uzdevums

Atlasiet ražošanas izmaiņas, kuras plānojat veikt drīz (vai nesen esat veicis). Lūdziet AI sagatavot pilnīgu izmaiņu pieprasījumu, izmantojot iepriekš norādīto veidni "Mainību pieprasījuma melnraksts". Paplašiniet AI izveidoto "ietekmēto sistēmu" sarakstu vismaz par diviem vienumiem, norādot savu atkarības informāciju. Izdrukājiet atcelšanas darbības, izmantojot veidni “Izveidot atcelšanas plānu”, un nosakiet, vai ir kāda izmaiņu daļa, kuru nevar atsaukt. Visbeidzot, izdomājiet kanāriju plānu. Apkopojiet visu plānu 6 punktos un atzīmējiet, kuri apstiprinājumi ir nepieciešami.

kontrolsaraksts

• [ ] Vai esmu sagatavojis izmaiņu pieprasījumu, kurā ietverts kas/kāpēc, ietekme, risks, darbības, pārbaude un atcelšana?
• [ ] Vai esmu paplašinājis AI ietekmēto sistēmu sarakstu ar savu atkarības informāciju?
• [ ] Vai esmu klasificējis, vai izmaiņas ir atgriezeniskas vai neatgriezeniskas?
• [ ] Es uzrakstīju atcelšanas darbības un izmēģināju to testa vidē, ja iespējams?
• [ ] Vai esmu noteicis apkopes periodu un kanāriju izvietošanas plānu un uzraudzības rādītājus katrai fāzei?
• [ ] Vai esmu definējis panākumu pārbaudes kritērijus un saņēmis nepieciešamos apstiprinājumus?