Prod verifikācija, izlaišanas stratēģijas un pilnīga AI darbplūsma

Ieguvumi:

• Izpratne par risku mazinošām izlaišanas stratēģijām (zili zaļš, kanārijputniņš, iezīmes karogs) un produktu pārbaudes disciplīnas (veselības pārbaude, dūmu tests, zelta signāla uzraudzība)
• Spēja īstenot ieradumu sagatavot skaidru atcelšanas plānu pirms izvietošanas un pārbaudīt kritiskos biznesa ceļus pēc izvietošanas
• Spēja apvienot visas moduļa laikā apgūtās daļas pilnīgā AI atbalstītā darbplūsmā un katrā solī piemērot principu “AI rada, cilvēki pārbauda un garantē”

Viss šis modulis virzījās uz vienu punktu: droša koda un infrastruktūras piegāde ražošanai (dzīvā vide, ko izmanto reāli klienti). Tagad mēs esam viskritiskākajā un saspringtākajā ķēdes posmā: izmaiņu iegūšana tiešsaistē un pārbaude, vai tās patiešām darbojas. Kļūda šeit nav abstrakta — tā tieši ietekmē klientu, ieņēmumus un reputāciju. Tāpēc nobriedušas komandas sāk ražot nevis "cerot", bet gan ar kontrolētām izlaišanas stratēģijām un sistemātisku pārbaudi.

Šajā pēdējā daļā mēs apvienojam divas lietas: (1) izlaišanas metodes, kas samazina risku (kanārijputniņš, zili zaļš, iezīmes karogs) un prod verifikācijas disciplīnu; (2) kā katrs modulī apgūtais elements — CI/CD, IaC, konteiners, uzraudzība, incidents, izmaksas, skripts, drošība — tiek apvienots vienā ar AI darbināmā darbplūsmā. Atkārtosim sākotnējo citātu pēdējo reizi: AI ģenerē un paātrina melnrakstus katrā solī; Bet jūs esat tas, kurš nospiež pogu "Es uzņemu šo tiešraidi" un garantē rezultātu.

Atlaidiet stratēģijas, kas samazina risku

Riskantākais veids ir izmaiņu nodošana visiem lietotājiem vienlaikus. Nobriedušas metodes:

• Zili zaļa izvietošana: tiek uzturētas divas identiskas vides — “zilā” (tiešraidē) un “zaļā” (jaunā versija). Jaunā versija tiek sagatavota un testēta zaļā krāsā, pēc tam satiksme pēkšņi tiek pārslēgta uz zaļu. Ja rodas problēma, satiksme nekavējoties atgriežas zilā krāsā. Ātra atgriešana ir tā lielākā priekšrocība.
• Canary Deployment: jaunā versija vispirms tiek izlaista nelielai lietotāju daļai (piemēram, 5%); Ja rādītāji ir labi, pakāpeniski palieliniet līdz 100%. Problēma skar nelielu lietotāja daļu, nevis visu lietotāju.
• Līdzekļa karogs: jaunā funkcija ievada kodu, bet to bloķē karodziņa; Tas tiek atvērts noteiktiem lietotājiem pēc pieprasījuma. Ir atšķirība starp izvietošanu un "izlaišanu"; Ja rodas problēma, karodziņš tiek izslēgts, neatgriežot kodu.

Padoms. Visātrākais drošības tīkls ir pirms katras izvietošanas sagatavot atcelšanu. "Ja kaut kas noiet greizi, kā es varu atgriezties pie vecās versijas 60 sekundēs?" Ja uz jautājumu nav skaidras atbildes, jūs neesat gatavs veikt šo izvietošanu.

Prod verifikācija: darbs nebeidzas, kad beidzas izvietošana

Tas, ka izvietošana izskatās “zaļa”, nenozīmē, ka tā darbojas. Sistemātiska pārbaude:

1. Veselības pārbaudes: vai pakalpojums darbojas, vai /healthz reaģē?
2. Dūmu testi: vai daži vissvarīgākie lietotāju ceļi (pieteikšanās, maksājums, meklēšana) patiešām darbojas? Automātiski un ātri.
3. Vērojiet zelta signālus: kļūdu līmenis pēc izvietošanas, latentums, vai satiksme ir normāla? (Četri signāli 6. blokā.)
4. Paplašiniet pakāpeniski: skatiet rādītājus katrā solī, palielinot Kanāriju procentuālo daļu.
5. Novērošanas logs: rūpīgi novērojiet kādu laiku (piemēram, 30 minūtes) pēc izvietošanas; Viltīgas problēmas nav uzreiz pamanāmas.

Uzmanību: AI var izveidot dūmu pārbaužu vai verifikāciju sarakstu, taču jūsu uzdevums ir noteikt, kuri lietotāju ceļi ir "kritiski". AI sniedz vispārīgu sarakstu; Tikai jūs zināt, ka ir jāpārbauda jūsu maksājumu plūsma, kas ir jūsu vislielāko ieņēmumu gūšanas ceļš.

Izlaiduma stratēģiju salīdzinājums

stratēģija

Galvenā priekšrocība

Izmaksas/sarežģītība

vispiemērotākais

Zili-zaļš

Tūlītēja atcelšana

Divas vides = 2x resursi

Ja ātra izgūšana ir kritiska

kanārijputniņš

Ierobežo ietekmi uz nelielu šķēli

Nepieciešama satiksmes vadība

Milzīga lietotāju bāze

Funkciju karogs

Atdala izvietošanu no izlaišanas

Karoga pārvaldības parāds

Pakāpeniska/mērķtiecīga atvēršana

Ritošais atjauninājums

Vienkārši, resursiem draudzīgi

lēna atgriešana

Vienkārši pakalpojumi

Pilnīga ar AI darbināma darbplūsma

Tagad apvienosim visu moduli vienā plūsmā. Pieņemsim, ka publicējat jaunu mikropakalpojumu. AI veido melnrakstus katrā solī; jūs pārbaudāt katrā solī:

1. Kods un konteiners (4. vienība): AI rada optimizētu, drošu Dockerfile; Jūs pārbaudāt beznoslēpumu un izmēru.
2. CI/CD (2. vienība): raksta AI testa-build-deploy cauruļvadu; Jūs sašaurināt atļaujas un pārbaudiet slepenās atsauces.
3. Infrastructure (Unit 3): definē nepieciešamos resursus ar AI Terraform; Jūs izlasiet plāna izvadi un nemeklējat negaidītas dzēšanas.
4. Orķestrācija (5. vienība): AI rada Kubernetes manifestus; jūs pārbaudāt resursu ierobežojumu, pārbaudi un RBAC.
5. Drošība (10. nodaļa): piešķir prioritāti AI skenēšanas izvadēm; Vispirms jūs satverat ekspluatējamos.
6. Uzraudzība (6. nodaļa): AI ģenerē trauksmes noteikumus un informācijas paneli; Jūs pārbaudāt sliekšņus ar saviem pagātnes datiem.
7. Izlaišana un apstiprināšana (šī vienība): izklāsta AI dūmu testu un atcelšanas plānu; tu sāc Kanāriju, skaties metriku, nospiediet pogu.
8. Ja notiek incidents (7. nodaļa): AI ģenerē hipotēzi un pēcnāves skici; Jūs pārbaudāt un apgūstat mācības.
9. Izmaksas (8. vienība): AI uzrauga jaunu resursu izšķērdēšanu; Jūs pieņemat pareizos lēmumus par izmēru.

Katrā solī vispārējais noteikums paliek nemainīgs: AI rada un paātrina, cilvēks pārbauda un garantē. Tāda ir moduļa būtība.

trīs mini futrāļi

1. gadījums — kanārijputniņš ierobežoja katastrofu līdz 5%. Komanda iedeva jauno versiju 5% lietotāju ar kanārijputniņiem. AI radītais informācijas panelis nekavējoties parādīja, ka kļūdu līmenis šajā daļā palielinājās līdz 8%. Komanda to atņēma, nepalielinot to līdz 100%; Problēma skāra tikai 5% lietotāju, un tas bija dažas minūtes. Ja notiktu liela mēroga izvietošana, tiktu ietekmēti visi klienti.

2. gadījums — dūmu pārbaude notvēra trūkstošo ceļu. AI piedāvāja dūmu pārbaudes komplektu, taču tam nebija "maksājumu" plūsmas. Inženieris to pievienoja, zinot, ka vissvarīgākā ieņēmumu plūsma bija maksājumi. Pārbaude pēc izvietošanas tika pārtraukta tieši norēķināšanās posmā — bija beidzies trešās puses atslēgas derīguma termiņš. Verifikācija dažu minūšu laikā konstatēja klusu ieņēmumu zudumu.

3. gadījums — gatavs atcelšana, kas saglabāta 90 sekundēs. Komanda, kas instalēja zili zaļo versiju, pārņēma jauno versiju uz zaļu; Pēc 2 minūtēm kavēšanās dubultojās. Viņi 90 sekunžu laikā padarīja satiksmi zilā krāsā, izmantojot iepriekš sagatavoto atcelšanu. Viņi atrada galveno cēloni (jaunajā versijā lēns vaicājums) bez spiediena, tad mierīgi. Gatavs atkāpšanās ceļš padarīja pārtraukumu gandrīz neredzamu.

Četras kopējamas veidnes

1) Izlaiduma stratēģijas izvēle:

Es piedāvāšu šādu pakalpojumu: [SERVISS/KONTEKSTS: lietotāju skaits, pārtraukumu pielaide, infrastruktūra]. Kuru jūs ieteiktu starp zili zaļajiem, kanārijputniem un mākslas karogiem? Šajā kontekstā salīdziniet katra priekšrocības, izmaksas un atgriešanas ātrumu. Sniedziet ieteikumu, bet paziņojiet, ka es pieņemšu galīgo lēmumu.

2) Dūmu testa/pārbaudes saraksts:

Izveidot [SERVICE] dūmu pārbaudes un verifikācijas saraksta uzmetumu, ko es izpildīšu pēc izvietošanas: veselības pārbaude, vissvarīgākie lietotāju ceļi, kuri metriku cik minūtes man vajadzētu pārraudzīt? Pieņemsim, ka es atzīmēšu vissvarīgākos biznesa ceļus un atstāju šo lauku tukšu.

3) Atcelšanas plāns:

Es izmantoju [DEPLOY METHOD]. Uzrakstiet man skaidru atcelšanas plānu: ar kuru komandu/soli jāatgriežas pie vecās versijas, cik ilgi tas aizņem, kādi ir pašas atgriešanas riski (piemēram, datu bāzes migrāciju nevar atsaukt), kas jāpārbauda pirms atgriešanas?

4) Pilnīga laidiena kontrolsaraksts:

Izveidojiet visaptverošu sagatavošanas kontrolsarakstu izlaišanai jaunam [SERVICE] projektam: koda/attēla drošība, cauruļvads, infrastruktūras plāns, uzraudzība un trauksme, drošības skenēšana, izlaišanas stratēģija, atcelšana un pārbaude. Pārbaudiet katru vienumu ar jautājumu "Vai esmu gatavs?" Pārvērtiet to par jautājumu.

Vāja uzvedne / spēcīga uzvedne

Vājš: "Kā to panākt prod?"

Rezultāts: nav konteksta; AI uzskaitīti vispārīgi izvietošanas soļi, tas neattiecas uz jūsu riska toleranci, lietotāja mērogu un atcelšanas nepieciešamību.

Güçlü: "Es piedāvāšu maksājumu pakalpojumu ar 10 miljoniem lietotāju, mana pielaide dīkstāvei ir ļoti zema. Vai jūs iesakāt Canary vai Blue-Green, kāpēc? Kurus kritiskos ceļus man vajadzētu pārbaudīt pēc izvietošanas, kādi rādītāji man jāuzrauga, cik minūtes ir jāuzrauga un kādam jābūt 60 sekunžu atcelšanas plānam? Es pieņemšu galīgo lēmumu."

Atšķirība: otrā uzvedne norāda mērogu, pielaidi un atcelšanas cerības; Tam nepieciešama stratēģija + pārbaude + atsaukšana, un lēmums paliek cilvēka ziņā.

Biežas kļūdas

• Izvietošana bez atcelšanas plāna. Ja atpakaļceļa nav, katra izvietošana ir azarts.
• Lielā sprādziena izvietošana. Piešķirot to visam lietotājam uzreiz, tiek palielināts risks.
• Pieņemot, ka "zaļš = darbojas". Pakalpojums, kas izturējis veselības pārbaudi, var tikt salauzts uz kritiskā ceļa.
• Domājot, ka kritiskos biznesa ceļus atstājat AI. Jums ir jāatzīmē tādas metodes kā maksājums.
• Nav uzraudzības pēc izvietošanas. Viltīgas problēmas neparādās pirmajā minūtē; ir nepieciešams novērošanas logs.
• Domāšanas datu bāzes migrācija ir atgriezeniska. Dažas izmaiņas netiek atceltas; tiek plānoti atsevišķi.

Rezumējot

Pāreja uz prod ir viskritiskākais posms ķēdē, un tas tiek veikts nevis "cerot", bet gan ar kontrolētām stratēģijām: zili zaļā krāsa nodrošina tūlītēju atcelšanu, ierobežojot kanārijas efektu līdz nelielai daļai, atdalot funkcijas karoga izvietošanu no izlaišanas. Darbs nav beidzies, kad izvietošana ir pabeigta; Būtiska ir sistemātiska pārbaude, veicot veselības pārbaudes, dūmu testus un zelta signāla uzraudzību. AI ģenerē un paātrina melnrakstus katrā posmā visā modulī — no Dockerfile līdz konveijeram, no Terraform līdz trauksmes likumam, no pēcnāves līdz izmaksu analīzei. Bet kompetentā persona paliek, kas pārbauda katru soli, nospiež pogu “Go live live” un garantē rezultātu. Šis ir ar AI darbināmu DevOps zelta likums.

Lietojumprogrammas uzdevums

Izvēlieties pakalpojumu (īstu vai izdomātu), kurā publicēt. (1) Izvēlieties savam kontekstam atbilstošu stratēģiju, izmantojot veidni “Izlaides stratēģijas atlase”, un uzrakstiet, kāpēc. (2) Izveidojiet verifikācijas sarakstu, izmantojot veidni "Dūmu pārbaudes/verifikācijas saraksts", un pats pievienojiet vissvarīgākos uzņēmējdarbības ceļus. (3) Sagatavojiet 60 sekunžu atcelšanas plānu, izmantojot veidni “Atcelšanas plāns”, un pārbaudiet, vai tajā nav neatgriezenisku darbību.

kontrolsaraksts

• [ ] Es izvēlējos savam kontekstam atbilstošu izlaišanas stratēģiju (kanārijputniņš/zili-zaļš/karogs).
• [ ] Pirms izvietošanas man ir gatavs skaidrs un ātrs atcelšanas plāns.
• [ ] Pats saviem Smoke testiem pievienoju vissvarīgākos uzņēmējdarbības ceļus (piemēram, maksājumus).
• [ ] Pēc izvietošanas es uzraugu zelta signālus caur novērošanas logu.
• [ ] Plānoju arī neatgriezeniskus soļus (datu bāzes migrācija utt.).
• [ ] Es pārbaudīju AI projektu katrā solī; Es pieņēmu lēmumu sākt tiešraidi.

Moduļa eksāmens

1. Kurš no šiem ir vislabākais DevOps un AI izvietojums mākonī?

• A) Mākslīgais intelekts ir palīgs un lēmumu atbalsta instruments; Cilvēki ir atbildīgi par kritiskiem lēmumiem, kas ietekmē produktu ✔
• B) Mākslīgais intelekts var pabeigt produktu izvietošanu un slepenu rotāciju bez cilvēka apstiprinājuma
• C) Mākslīgais intelekts noder tikai dokumentācijas rakstīšanai, tam nav nekāda sakara ar infrastruktūru
• D) Audits nav nepieciešams, jo mākslīgais intelekts vienmēr rada uzticamākas komandas nekā inženieris

Apraksts: tas ir palīgs un lēmumu atbalsta rīks, kas paātrina teksta ietilpīgus uzdevumus, piemēram, mākslīgā intelekta cauruļvadu, konfigurāciju, skriptu un žurnālu. Atbildība par lēmumiem, kas ietekmē dīkstāves laiku, naudu un drošību, piemēram, ražošanas izlaišanu, slepeno pārvaldību un galīgo pielietojumu, paliek kompetentā inženiera ziņā.

2. Kura ir visprecīzākā verifikācijas disciplīnas izteiksme pirms DevOps komandas vai mākslīgā intelekta radītas konfigurācijas ieviešanas?

• A) Ja izvade izskatās gluda un pārliecinoša, to var palaist tieši prod
• B) Izvade ir droša tikai tad, ja nav sintakses kļūdu, nav nepieciešamas papildu pārbaudes
• C) Savienojiet izvadi ar avotu, plānojiet/dry-run un filtrējiet to atbilstoši jūsu sistēmas kontekstam; tad piesakies ✔
• D) Ātrākā pārbaude ir pirmā mēģinājuma veikšana tieši produkcijā un rezultāta skatīšanās

Paskaidrojums: trīspakāpju pārbaude ir būtiska: izvades pievienošana avotam (vai komanda/karodziņa faktiski ir oficiālajos dokumentos), tā palaišana sausā veidā (redzot, kas notiek ar plānu/--dry-run) un izvadīšana caur sistēmas filtru (vai tas atbilst tā arhitektūras un drošības kontekstam). Raidums nenozīmē precizitāti.

3. Kāda ir pareizā pieeja, jautājot mākslīgajam intelektam par kļūdu vai izvietošanas problēmu .env failā, kas satur reālu datu bāzes paroli?

• A) Maskējiet īstus noslēpumus ar <PLACEHOLDER>; kopīgojiet tikai maskētu kļūdu un kontekstu ✔
• B) Ielīmējot visu .env failu, kā tas ir, problēma tiek atrisināta ātrāk
• C) Tā kā noslēpumi jau ir base64, ir droši ielīmēt vienkāršu
• D) Paroles ielīmēšana ir droša, jo mākslīgais intelekts to nekad neuzglabā

Apraksts: AI uzvednē netiek ielīmēti īsti noslēpumi. Vērtības, piemēram, paroles un marķieri, tiek maskētas ar <PLACEHOLDER>; tiek koplietots tikai kļūdas ziņojums un nepieciešamais konteksts. Ja noslēpums jau ir nopludināts, tas ir nekavējoties jāatceļ un jāpagriež.

4. Kurš no šiem ir pareizais noslēpumu (paroles, marķiera) pārvaldība CI/CD konveijerā?

• A) Tas tiek glabāts platformas slepenajā repozitorijā un tiek izsaukts ar atsauci (piemēram, ${{ secrets.X }}), nevis rakstīts vienkāršā tekstā ✔
• B) Ērtības labad tas ir rakstīts vienkāršā tekstā uz konveijera YAML
• C) To pārbauda, katra darba sākumā nospiežot echo un log.
• D) Ja definēts ar visplašāko atļauju (rakstīt visu), drošība palielinās

Paskaidrojums: YAML noslēpumi netiek rakstīti vienkāršā tekstā; Tas tiek glabāts platformas slepenajā repozitorijā un tiek izsaukts ar atsaucēm, piemēram, ${{ secrets.X }}. Turklāt, ievērojot mazākās pilnvaras principu, marķiera atļaujas tiek sašaurinātas un slepenais žurnāls netiek reģistrēts.

5. Kas ir vissvarīgākais solis infrastruktūras pārvaldībā ar Terraform pirms izmaiņu ieviešanas tiešraidē?

• A) Tieši palaist “terraform piemērot”; plāns ir laika izšķiešana
• B) Valsts faila dublēšana publiskā repozitorijā
• C) Palaidiet 'terraform plan' un pārbaudiet izvadā esošās iznīcināšanas/aizvietošanas līnijas, pēc tam lietojiet ✔
• D) Atinstalējiet pakalpojumu sniedzēja versiju un pārliecinieties, ka jaunākā versija tiek piegādāta automātiski

Paskaidrojums: “terraform plan” ir jāpalaiž pirms “terraform piemērot”. Plānā ir parādīts, ko pievienot, ko mainīt, un jo īpaši, ko dzēst (iznīcināt), neko nedarot. Ja ir redzama neparedzēta iznīcināšanas vai nomaiņas līnija, lietot nevajadzētu.

6. Ko tas nozīmē un kas jādara, ja Terraform plāna izvadā parādās rinda "-/+ aizstāt" ražošanas datu bāzei?

• A) Avots tiks atjaunināts uz vietas, nav riska
• B) Resurss tiks dzēsts un izveidots no jauna; Pastāv datu zaudēšanas risks, pieteikšanās jāpārtrauc, ja tas nav gaidāms ✔
• C) Pievienojot jaunu resursu, esošā datu bāze netiek ietekmēta
• D) Tas ir tikai brīdinājums, to var droši ignorēt

Paskaidrojums: “-/+ aizstāšana” nozīmē, ka resurss tiks dzēsts un izveidots no jauna; Attiecībā uz datu bāzi tas nozīmē datu zudumu. Ja tas nav sagaidāms, piemērošana ir jāpārtrauc, izmaiņas jāpārvērš par drošu metodi vai arī nemainīgais lauks ir jāatstāj neskarts.

7. Kurš no šiem apgalvojumiem attiecas uz Dockerfile, kas ir gatavs ražošanai tās drošības un izmēra ziņā?

• A) Ērtības labad ieguliet noslēpumu attēlā ar ENV un palaidiet to kā root
• B) Vienmēr izmantojiet tagu ":latest" un saglabājiet pamata attēlu pēc iespējas lielāku
• C) Vienpakāpes izveide un visu veidošanas rīku atstāšana galīgajā attēlā
• D) Noslēpuma neiegulšana, darbs ar nesankcionētu LIETOTĀJU, maza un stabila bāzes attēla izmantošana un daudzpakāpju uzbūve ✔

Apraksts: Ražošanai gatavs attēls: netiek iegults noslēpums (ievada to izpildlaikā), darbojas ar nesankcionētu LIETOTĀJU, nevis saknes, izmanto mazu un versijas bāzes attēlu (slim/alpine, nevis :jaunāko) un tiek samazināts ar vairākpakāpju būvējumu. Pirms publicēšanas tajā tiek arī pārbaudītas ievainojamības.

8. Kāds ir vissvarīgākais risks, ja Kubernetes izvietošanai netiek definēti resursu ierobežojumi?

• A) Pod nekad nesākas, jo ierobežojums ir obligāts lauks
• B) Uzraudzības panelī parādās tikai brīdinājums, darbība netiek ietekmēta
• C) Kubernetes automātiski ievieš drošus noklusējuma ierobežojumus, bez riska
• D) Pāksts var neierobežoti augt un patērēt mezgla resursus, tādējādi avarējot blakus esošos pakalpojumus ✔

Paskaidrojums: Pod, kuram nav resursu ierobežojuma, var neierobežoti augt, patērēt visus tā mezgla resursus, kurā tas darbojas, un avarēt blakus esošos pakalpojumus, piemēram, atmiņas noplūdes dēļ. Tāpēc pieprasījumu/limitu noteikšana ir robustuma pamats.

9. Kā izvairīties no "trauksmes noguruma" uzraudzībā un trauksmes iestatīšanā?

• A) Iestatiet trauksmes signālus pēc iespējas vairāk metrikas un ģenerējiet brīdinājumus par katru svārstību.
• B) Iestatiet visus trauksmes signālus uz augstāko smaguma pakāpi
• C) Trauksmes aktivizēšana ar momentānām vērtībām, neiestatot laiku (par)
• D) Uzturēt trauksmes signālus, kas ir vērsti uz darbību un steidzami, sliekšņu pārbaude ar vēsturiskajiem datiem, nevajadzīgo apvienošana ✔

Apraksts: Katram trauksmes signālam jābūt iedarbināmam un ar atbilstošu steidzamību; Informācija, kas neprasa darbību, tiek parādīta uz tāfeles, tā nevienu nepamodina. Trauksmes sliekšņi tiek pārbaudīti, salīdzinot ar sistēmas vēsturiskajiem datiem, un tiek konsolidēti nevajadzīgi/atkārtoti trauksmes signāli. Tādā veidā īstais trauksmes signāls nepazudīs troksnī.

10. Kāds ir labākais prioritārais pasūtījums ražošanas incidenta laikā?

• A) Vispirms atrodiet precīzu galveno cēloni un samaziniet to tikai tad, kad cēlonis ir skaidrs.
• B) Vispirms uzrakstiet pēcnāves ziņojumu, pēc tam pieskarieties pakalpojumam
• C) Vispirms samaziniet (atjaunošanas/atjaunošanas pakalpojums), atstājot pamatcēloņa analīzi vēlākai ✔
• D) Vispirms atrodiet par incidentu atbildīgo personu un ziņojiet par to

Paskaidrojums: zelta likums ir “vispirms samazini, vēlāk izmeklē”. Mērķis ir vispirms atjaunot pakalpojumu vai atgriezt to uz zināmu labu versiju (mazināt); Pamatcēloņu analīze tiek veikta mierīgi pēc spiediena samazināšanās. Gaidīšana, lai atrastu precīzu galveno cēloni, palielina atveseļošanās laiku (MTTR).

11. Kāds ir nevainojamās pēcnāves kultūras galvenais mērķis?

• A) Kļūdu pieļāvušās personas identificēšana un atbildības uzlikšana viņai/viņai
• B) Koncentrēšanās uz sistēmām un procesiem un mācīšanās veicināšana; ✔ Apgūstiet nodarbības, kas novērš atkārtošanos, nevis vaino
• C) Nekad neziņojiet par incidentu un pārliecinieties, ka tas tiek aizmirsts
• D) Rakstiet tikai tehniskas detaļas un nepievienojiet vienumus, par kuriem var rīkoties

Paskaidrojums: Nevainojams pēcnāves periods koncentrējas uz jautājumu “kura sistēma un process pieļāva šo kļūdu”, nevis “kurš to izdarīja”. Cilvēki atklāti dalās savā kļūdā, ja zina, ka netiks sodīti; Slēptā kļūda atkārtojas. Ziņojums nav apsūdzības ziņojums, bet gan mācību dokuments, kas pilns ar uz darbību vērstiem priekšmetiem.

12. Kas ir loģiskākais solis, kas jāveic mākoņa izmaksu optimizācijā (FinOps), pirms pāriet uz noteiktām atlaidēm (Rezervētais/uzkrājumu plāns)?

• A) Vispirms uzņemieties pēc iespējas ilgāku apņemšanos, vēlāk domājiet par izšķērdēšanu
• B) Vispirms iztīriet atkritumus (dīkstāves aizvēršana, pareiza izmēra noteikšana), pēc tam apņemieties to izmantot ✔
• C) Nekavējoties pārvietojiet visus resursus uz Spot kapacitāti
• D) Dārgākās preces dzēšana, nepārskatot rēķina datus

Paskaidrojums: vispirms ir jāsavāc atkritumi (aizverot dīkstāves resursus, samazinot negabarīta resursus). Pretējā gadījumā jūs bloķēsit nelietderīgu lietošanu ar atlaidi uz 1-3 gadiem. Pareiza izmēra noteikšana un tīrīšana tukšgaitā neprasa nekādas saistības un ir gandrīz bezriska.

13. Kāds ir vissvarīgākais drošības pasākums, ja AI ieteiktajam skriptam ir rinda "rm -rf "$DIR"/'?

• A) Paātrinās skripta palaišana tieši prod, neizlasot to
• B) Pievienojiet set -euo pipefail un tukšu mainīgo kontroli un vispirms mēģiniet ar sauso darbību ✔
• C) Pietiek ar mainīgā nosaukuma saīsināšanu
• D) Izmantojot rm -rf --force, nevis rm, problēma tiek atrisināta

Paskaidrojums: Ja lauks $DIR ir tukšs, šis paziņojums var mēģināt dzēst saknes direktoriju. Apstājoties pie nedefinēta mainīgā ar 'set -u' un pārbaudot, vai mainīgais nav tukšs pirms tā dzēšanas (piemēram, [ -n "$DIR" ] || izeja 1), izvairās no katastrofas. Turklāt destruktīvas darbības vispirms jāizmēģina ar sauso darbību.

14. Kas ir pirmā lieta, kas jādara, ja mākoņa piekļuves atslēga nejauši nokļūst publiskajā repozitorijā?

• A) Nekavējoties atceliet un atjaunojiet (pagrieziet) atslēgu; Ar dzēšanu vien nepietiek ✔
• B) Vienkārši izdzēsiet failu no krātuves, un atslēga ir drošībā
• C) Neko nedarīt, jo neviens to neredzēja
• D) Padarot krātuvi privātu, nav nepieciešams pagriezt atslēgu

Paskaidrojums: Nopludinātais noslēpums ir nekavējoties jāatceļ un jāpagriež. Ar faila dzēšanu vien nepietiek, jo noslēpums paliek Git vēsturē un publiskās krātuves tiek skenētas ar robotprogrammatūru dažu sekunžu laikā. Pēc atcelšanas/atgriešanas ietekme tiek novērtēta un tiek pievienots slepenais skeneris, lai novērstu atkārtošanos.

15. Kura no šīm pieejām samazina risku, izlaižot jaunu Prod versiju?

• A) Jaunās versijas piešķiršana visiem lietotājiem vienlaikus (lielais sprādziens) un atcelšanas plāna nesagatavošana
• B) Uzskatot, ka izvietošana ir pabeigta, tiklīdz tā parādās “zaļa”, papildu pārbaude netiek veikta
• C) Izmantojot kontrolētu stratēģiju, piemēram, kanārijputnu/zili-zaļo/funkciju karogu, gatavu atcelšanas plānu un dūmu testu + metrisko uzraudzību pēc izvietošanas ✔
• D) kritisko biznesa ceļu testēšanu pilnībā atstāt mākslīgā intelekta ziņā un to nenoteikt vispār.

Paskaidrojums: kontrolētas izlaišanas stratēģijas (sākot ar nelielu procentuālo daļu ar kanārijputnu, tūlītēja atcelšana ar zili zaļu krāsu, izvietošanas atdalīšana no izlaišanas ar funkcijas karogu) ierobežo risku. Turklāt svarīgs ir skaidrs atcelšanas plāns pirms izvietošanas un zelta signāla uzraudzība ar dūmu testu pēc izvietošanas; “Izskatās zaļš” nenozīmē, ka tas darbojas.