Gamybos patvirtinimas, išleidimo strategijos ir visapusiška AI darbo eiga

Pelnas:

• Supratimas apie riziką mažinančias išleidimo strategijas (mėlyna-žalia, kanarėlė, funkcijų vėliavėlė) ir produkto tikrinimo discipliną (sveikatos patikrinimas, dūmų testas, auksinio signalo stebėjimas)
• Gebėjimas įgyvendinti įprotį parengti aiškų grąžinimo planą prieš diegimą ir patikrinti svarbiausius verslo kelius po įdiegimo
• Gebėjimas sujungti visas modulyje išmoktas dalis į visapusišką dirbtinio intelekto palaikomą darbo eigą ir kiekviename žingsnyje taikyti principą „DI gamina, žmonės tikrina ir už tai garantuoja“

Visas šis modulis ėjo link vieno taško: saugaus kodo ir infrastruktūros pristatymo į gamybą (gyvą aplinką, kurią naudoja tikri klientai). Dabar esame ties kritiškiausia ir įtempčiausia grandinės grandis: pakeitimas gyvai ir patikrinimas, ar jis tikrai veikia. Klaida čia nėra abstrakti – ji tiesiogiai veikia klientą, pajamas ir reputaciją. Štai kodėl brandžios komandos pradeda gaminti ne „tikėdamos“, o su kontroliuojamomis išleidimo strategijomis ir sistemingai tikrindamos.

Šiame paskutiniame skyriuje mes deriname du dalykus: (1) išleidimo metodus, kurie sumažina riziką (kanarinė, mėlyna-žalia, funkcijų vėliavėlė) ir gaminių tikrinimo discipliną; (2) kaip kiekvienas elementas, kurį išmokome per modulį – CI/CD, IaC, konteineris, stebėjimas, incidentas, kaina, scenarijus, sauga – susijungia į vieną AI valdomą visapusišką darbo eigą. Pakartokime pradinę citatą paskutinį kartą: AI generuoja ir pagreitina juodraščius kiekviename žingsnyje; Bet jūs esate tas, kuris paspaudžia mygtuką „Aš tai gyvai“ ir laiduoja už rezultatą.

Išleiskite strategijas, kurios sumažina riziką

Pakeitimų kėlimas visiems vartotojams vienu metu yra rizikingiausias būdas. Suaugę metodai:

• Mėlynai žalias diegimas: palaikomos dvi identiškos aplinkos – „mėlyna“ (tiesiogiai) ir „žalioji“ (nauja versija). Naujoji versija ruošiama ir išbandoma žalia spalva, tada eismas staiga perjungiamas į žalią. Jei kyla problemų, eismas iš karto grįžta į mėlyną. Greitas atšaukimas yra didžiausias jo pranašumas.
• Canary Deployment: nauja versija pirmą kartą išleidžiama nedidelei vartotojų daliai (pvz., 5%); Jei rodikliai yra geri, palaipsniui didinkite iki 100%. Problema paliečia nedidelę naudotojo dalį, o ne visą vartotoją.
• Funkcijos vėliavėlė: nauja funkcija įveda kodą, bet yra blokuojama vėliavėlės; Jis atidaromas tam tikriems vartotojams, kai to paprašo. Yra skirtumas tarp diegimo ir „išleidimo“; Jei kyla problemų, vėliavėlė išjungiama neatšaukiant kodo.

Patarimas: Greičiausias apsauginis tinklas yra paruošti atšaukimą prieš kiekvieną diegimą. „Jei kas nors negerai, kaip per 60 sekundžių grįžti prie senosios versijos? Jei nėra aiškaus atsakymo į klausimą, nesate pasiruošę diegti.

Gamybos patvirtinimas: darbas nesibaigia, kai baigiasi diegimas

Vien todėl, kad diegimas atrodo „žalias“, dar nereiškia, kad jis veikia. Sisteminis patikrinimas:

1. Sveikatos patikrinimai: ar paslauga veikia, ar /healthz reaguoja?
2. Dūmų testai: ar keli svarbiausi vartotojo keliai (prisijungimas, mokėjimas, paieška) iš tikrųjų veikia? Automatiškai ir greitai.
3. Stebėkite auksinius signalus: klaidų dažnis po įdiegimo, delsa, ar eismas normalus? (Keturi signalai 6 įrenginyje.)
4. Plėskite laipsniškai: didindami Kanarų procentą, žiūrėkite kiekvieno žingsnio metrikas.
5. Stebėjimo langas: atidžiai stebėkite tam tikrą laiką (pvz., 30 min.) po įdiegimo; Klastingos problemos matomos ne iš karto.

Įspėjimas: AI gali sudaryti dūmų testų arba patikrų sąrašą, tačiau jūsų darbas yra nustatyti, kurie naudotojo keliai yra „kritiniai“. AI pateikia bendrą sąrašą; Tik jūs žinote, kad jūsų mokėjimo srautas, daugiausia pajamų generuojantis kelias, turi būti išbandytas.

Išleidimo strategijų palyginimas

strategija

Pagrindinis privalumas

Kaina / sudėtingumas

tinkamiausias

Mėlyna-Žalia

Momentinis atšaukimas

Dvi aplinkos = 2x ištekliai

Jei greitas gavimas yra labai svarbus

kanarėlė

Apriboja poveikį iki mažo gabalėlio

Reikalingas eismo valdymas

Didžiulė vartotojų bazė

Funkcijų vėliavėlė

Atskiria diegimą nuo išleidimo

Vėliavos valdymo skola

Laipsniškas / tikslinis atidarymas

Slenkantis atnaujinimas

Paprasta, tausojanti išteklius

lėtas atsukimas

Paprastos paslaugos

Visapusiška AI pagrįsta darbo eiga

Dabar sujungkime visą modulį į vieną srautą. Tarkime, kad skelbiate naują mikropaslaugą. AI kiekviename žingsnyje sukuria juodraščius; Jūs patvirtinate kiekviename žingsnyje:

1. Kodas ir konteineris (4 skyrius): AI sukuria optimizuotą, saugų „Docker“ failą; Jūs patikrinate, ar nėra paslaptis, ir dydį.
2. CI / CD (2 skyrius): rašo AI testavimo, kūrimo ir diegimo konvejerį; Jūs susiaurinate leidimus ir patikrinate slaptas nuorodas.
3. Infrastruktūra (3 skyrius): apibrėžia reikiamus išteklius naudojant AI Terraform; Jūs perskaitote plano išvestį ir neieškote netikėtų ištrynimų.
4. Orkestravimas (5 skyrius): AI sukuria Kubernetes manifestus; Jūs patikrinate išteklių limitą, zondą ir RBAC.
5. Sauga (10 skyrius): pirmenybę teikia AI nuskaitymo išvestims; Pirmiausia patraukite išnaudojamus.
6. Stebėjimas (6 skyrius): AI generuoja aliarmo taisykles ir prietaisų skydelį; Jūs išbandote slenksčius naudodami ankstesnius duomenis.
7. Išleidimas ir patvirtinimas (šis vienetas): apibūdina AI dūmų testą ir grąžinimo planą; pradedi kanarėlę, žiūrėk metrikas, paspaudi mygtuką.
8. Jei įvyksta incidentas (7 skyrius): AI sukuria hipotezę ir pomirtinį eskizą; Jūs patikrinate ir išmokstate pamokas.
9. Kaina (8 skyrius): AI stebi naujų išteklių švaistymą; Jūs priimate tinkamo dydžio sprendimus.

Kiekviename žingsnyje galioja bendra taisyklė: AI gamina ir pagreitina, žmogus tikrina ir garantuoja. Tai yra modulio esmė.

trys mini dėklai

1 atvejis – kanarėlė apribojo nelaimę iki 5 proc. Komanda suteikė naują versiją 5% vartotojų, turinčių kanarėlių. AI sukurtas prietaisų skydelis iš karto parodė, kad klaidų lygis šioje dalyje šoktelėjo iki 8%. Komanda jį atsiėmė nepadidindama iki 100 %; Problema paveikė tik 5% vartotojų, ir tai truko kelias minutes. Jei diegimas būtų didžiulis, būtų paveikti visi klientai.

2 atvejis – dūmų bandymas užfiksavo trūkstamą kelią. AI pasiūlė dūmų bandymo rinkinį, tačiau jame nebuvo „mokėjimo“ srauto. Inžinierius tai pridūrė žinodamas, kad svarbiausias pajamų šaltinis yra mokėjimas. Testas po įdiegimo nutrūko iškart atsiskaitant – pasibaigė trečiosios šalies rakto galiojimo laikas. Patvirtinus per kelias minutes buvo užfiksuotas tylus pajamų praradimas.

3 atvejis – paruoštas atšaukimas išsaugotas per 90 sekundžių. Komanda, įdiegusi mėlyną-žalią versiją, pakeitė naują versiją į žalią; Po 2 minučių vėlavimas padvigubėjo. Jie per 90 sekundžių pavertė eismą mėlynu, o atšaukimą jie paruošė iš anksto. Jie rado pagrindinę priežastį (lėta užklausa naujoje versijoje) nespaudę, o tada ramiai. Paruoštas atšaukimo kelias padarė pertraukimą beveik nepastebimą.

Keturi kopijuojami šablonai

1) Išleidimo strategijos pasirinkimas:

Pateiksiu šią paslaugą: [PASLAUGA/KONTEKSTAS: vartotojų skaičius, tolerancija gedimams, infrastruktūra]. Kurią rekomenduotumėte tarp mėlynai žalių, kanarėlių ir išskirtinių vėliavų? Šiame kontekste palyginkite kiekvieno privalumus, išlaidas ir grąžinimo greitį. Pateikite pasiūlymą, bet nurodykite, kad galutinį sprendimą priimsiu aš.

2) Dūmų bandymo / patikros sąrašas:

Sukurti [SERVICE] dūmų testo ir patikros sąrašo juodraštį, kurį paleisiu po įdiegimo: būklės patikrinimas, svarbiausi naudotojų keliai, kurią metriką turėčiau stebėti kiek minučių? Tarkime, kad pažymėsiu svarbiausius verslo kelius ir paliksiu tą lauką tuščią.

3) Atšaukimo planas:

Naudoju [DEPLOY METHOD]. Parašykite man aiškų atkūrimo planą: su kuria komanda/veiksmu grįžti prie senosios versijos, kiek tai užtrunka, kokia yra pačio atšaukimo rizika (pvz., duomenų bazės migracijos negalima atšaukti), ką turėčiau patikrinti prieš atšaukimą?

4) Nuo galo iki galo leidimo kontrolinis sąrašas:

Sukurkite visapusį pasirengimo leidimo naujam [SERVICE] projektui kontrolinį sąrašą: kodo / vaizdo saugumas, vamzdynas, infrastruktūros planas, stebėjimas ir įspėjimas, saugos nuskaitymas, išleidimo strategija, atšaukimas ir patikrinimas. Patikrinkite kiekvieną elementą su klausimu "Ar aš pasiruošęs?" Paverskite tai klausimu.

Silpnas raginimas / Stiprus raginimas

Silpnas: „Kaip tai paversti prod?

Rezultatas: nėra konteksto; AI išvardija bendruosius diegimo veiksmus, jame neatsižvelgiama į jūsų rizikos toleranciją, naudotojo mastą ir atšaukimo poreikį.

Güçlü: "Pateiksiu mokėjimo paslaugą su 10 milijonų vartotojų, mano tolerancija prastovoms yra labai maža. Ar rekomenduojate Canary arba Blue-Green, kodėl? Kuriuos svarbius kelius turėčiau išbandyti po įdiegimo, kokius rodiklius turėčiau stebėti kiek minučių ir koks turėtų būti 60 sekundžių grąžinimo planas? Aš priimsiu galutinį sprendimą."

Skirtumas: antrasis raginimas nurodo mastą, toleranciją ir atšaukimo lūkesčius; Tam reikia strategijos + patikrinimo + atšaukimo, o sprendimas paliekamas žmogui.

Dažnos klaidos

• Diegimas be atšaukimo plano. Jei kelio atgal nėra, kiekvienas dislokavimas yra azartas.
• Didelis sprogimas. Suteikus jį visam vartotojui iš karto padidina riziką.
• Darant prielaidą, kad „žalia = veikia“. Sveikatos patikrinimą įveikusi tarnyba gali būti pažeista kritiniame kelyje.
• Galvodami, kad svarbius verslo kelius paliekate dirbtiniam intelektui. Turite pažymėti tokius būdus kaip mokėjimas.
• Nestebimas po įdiegimo. Klastingos problemos iškyla ne pirmą minutę; būtinas stebėjimo langas.
• Mąstantis duomenų bazės perkėlimas yra grįžtamas. Kai kurie pakeitimai neatšaukiami; planuojama atskirai.

Apibendrinant

Perėjimas prie gamybos yra svarbiausia grandinės grandis ir tai daroma ne „tikiantis“, o naudojant kontroliuojamas strategijas: mėlyna-žalia spalva nedelsiant atšaukiama, apribodama kanarėlės efektą iki nedidelio gabalo, atskirdama funkcijos vėliavėlės diegimą nuo išleidimo. Darbas nesibaigia, kai diegimas baigtas; Būtinas sistemingas patikrinimas atliekant sveikatos patikrinimus, dūmų testus ir auksinio signalo stebėjimą. AI generuoja ir pagreitina juodraščius kiekviename viso modulio žingsnyje – nuo ​​„Dockerfile“ iki vamzdyno, nuo „Terraform“ iki aliarmo taisyklės, nuo postmortem iki išlaidų analizės. Tačiau lieka kompetentingas asmuo, kuris patikrina kiekvieną žingsnį, paspaudžia mygtuką „Go live“ ir garantuoja rezultatą. Tai auksinė visiško dirbtinio intelekto „DevOps“ taisyklė.

Taikymo užduotis

Pasirinkite paslaugą (tikrą ar išgalvotą), kurioje norite skelbti. (1) Pasirinkite strategiją, atitinkančią jūsų kontekstą, naudodami šabloną „Išleidimo strategijos pasirinkimas“ ir parašykite kodėl. (2) Turėkite patvirtinimo sąrašą, sugeneruotą naudojant šabloną „Dūmų testas / patvirtinimo sąrašas“, ir patys pridėkite svarbiausius verslo kelius. (3) Paruoškite 60 sekundžių atšaukimo planą naudodami šabloną „Atšaukimo planas“ ir patikrinkite, ar jame nėra kokių nors negrįžtamų veiksmų.

kontrolinis sąrašas

• [ ] Pasirinkau mano kontekstą atitinkančią išleidimo strategiją (kanarinė/mėlyna-žalia/vėliava).
• [ ] Turiu aiškų ir greitą atšaukimo planą paruošęs prieš diegiant.
• [ ] Pats įtraukiau svarbiausius verslo kelius (pvz., mokėjimą) į savo Dūmų testus.
• [ ] Po dislokavimo aš stebiu auksinius signalus per stebėjimo langą.
• [ ] Taip pat planavau negrįžtamus žingsnius (duomenų bazių perkėlimas ir pan.).
• [ ] Aš tikrinau AI projektą kiekviename žingsnyje; Priėmiau sprendimą pradėti transliuoti.

Modulio egzaminas

1. Kuri iš toliau nurodytų dalykų yra geriausia DevOps ir AI padėtis debesyje?

• A) Dirbtinis intelektas yra asistentas ir sprendimų palaikymo įrankis; Žmonės yra atsakingi už svarbius sprendimus, turinčius įtakos produktui ✔
• B) Dirbtinis intelektas gali užbaigti gaminių diegimą ir slaptą sukimąsi be žmogaus sutikimo
• C) Dirbtinis intelektas naudingas tik dokumentacijai rašyti, jis neturi nieko bendra su infrastruktūra
• D) Auditas nereikalingas, nes dirbtinis intelektas visada pateikia patikimesnes komandas nei inžinierius

Aprašymas: tai asistentas ir sprendimų palaikymo įrankis, pagreitinantis daug teksto reikalaujančias užduotis, pvz., dirbtinio intelekto dujotiekį, konfigūraciją, scenarijų ir žurnalą. Atsakomybė už sprendimus, turinčius įtakos prastovoms, pinigams ir saugumui, pavyzdžiui, gamybos išleidimas, slaptas valdymas ir galutinis pritaikymas, tenka kompetentingam inžinieriui.

2. Kuri yra tiksliausia patikros disciplinos išraiška prieš diegiant DevOps komandą arba dirbtinio intelekto sukurtą konfigūraciją?

• A) Jei išvestis atrodo sklandžiai ir užtikrintai, ją galima paleisti tiesiogiai gaminant
• B) Išvestis yra saugi tik tuo atveju, jei nėra sintaksės klaidų, papildomų patikrinimų nereikia
• C) Prijunkite išvestį prie šaltinio, suplanuokite/sausai paleiskite ir filtruokite pagal savo sistemos kontekstą; tada kreipkis ✔
• D) Greičiausias patikrinimas yra pirmasis bandymas tiesiogiai gaminyje ir rezultato stebėjimas

Paaiškinimas: Trijų etapų patvirtinimas yra būtinas: išvesties prijungimas prie šaltinio (ar komanda / vėliavėlė iš tikrųjų yra oficialiuose dokumentuose), paleisti ją sausai (pažiūrėti, kas atsitiks su planu/--dry-run) ir perleisti per sistemos filtrą (ar jis atitinka savo architektūrinį ir saugos kontekstą). Sklandumas nereiškia tikslumo.

3. Koks yra teisingas požiūris klausiant dirbtinio intelekto apie klaidą arba diegimo problemą naudojant .env failą, kuriame yra tikras duomenų bazės slaptažodis?

• A) Užmaskuokite tikras paslaptis su <PLACEHOLDER>; bendrinkite tik užmaskuotą klaidą ir kontekstą ✔
• B) Įklijavus visą .env failą tokį, koks yra, problema išsprendžiama greičiau
• C) Kadangi paslaptys jau yra base64, įklijuoti paprasta
• D) Slaptažodžio įklijavimas yra saugus, nes dirbtinis intelektas jo niekada neišsaugo

Aprašymas: Į AI raginimą neįklijuojama jokių tikrų paslapčių. Reikšmės, tokios kaip slaptažodžiai ir prieigos raktai, yra užmaskuotos <PLACEHOLDER>; bendrinamas tik klaidos pranešimas ir būtinas kontekstas. Jei Paslaptis jau buvo nutekėjusi, ją reikia nedelsiant atšaukti ir pasukti.

4. Kuris iš šių dalykų yra teisingas paslapčių (slaptažodžio, prieigos rakto) valdymas CI/CD konvejeryje?

• A) Jis saugomas platformos slaptojoje saugykloje ir iškviečiamas pagal nuorodą (pvz., ${{ secrets.X }}), neparašytas paprastu tekstu ✔
• B) Patogumui parašyta paprastu tekstu į YAML konvejerį
• C) Tai patikrinama kiekvienos užduoties pradžioje paspaudus echo ir log.
• D) Jei apibrėžta turint plačiausią leidimą (rašyti viską), saugumas padidėja

Paaiškinimas: paslaptys neįrašomos į YAML paprastu tekstu; Jis laikomas platformos slaptojoje saugykloje ir iškviečiamas su tokiomis nuorodomis kaip ${{ secrets.X }}. Be to, taikant mažiausio autoriteto principą, žetonų leidimai susiaurinami, o slaptas žurnalas neįrašomas.

5. Koks yra svarbiausias žingsnis valdant infrastruktūrą naudojant Terraform prieš įgyvendinant pakeitimą gyvai?

• A) Tiesioginis „Terraform App“ paleidimas; planas yra laiko švaistymas
• B) Valstybės failo atsarginės kopijos kūrimas viešoje saugykloje
• C) Vykdykite „terraform planą“ ir patikrinkite išvesties eilutes sunaikinti / pakeisti, tada pritaikykite ✔
• D) Pašalinkite teikėjo versiją ir įsitikinkite, kad naujausia versija ateina automatiškai

Paaiškinimas: „terraform plan“ turi būti paleistas prieš „terraform taikyti“. Plane parodyta ką pridėti, ką keisti, o ypač ką ištrinti (sunaikinti), nieko nedarant. Jei matote netikėtą sunaikinimo ar pakeitimo liniją, tepti nereikėtų.

6. Ką tai reiškia ir ką daryti, jei „Terraform“ plano išvestyje atsiranda gamybos duomenų bazės eilutė „-/+ pakeisti“?

• A) Šaltinis bus tiesiog atnaujintas vietoje, nėra jokios rizikos
• B) Išteklius bus ištrintas ir sukurtas iš naujo; Kyla duomenų praradimo pavojus, taikymas turėtų būti sustabdytas, jei nesitikima ✔
• C) Pridedant naują šaltinį, esama duomenų bazė nebus paveikta
• D) Tai tik įspėjimas, jo galima drąsiai ignoruoti

Paaiškinimas: „-/+ pakeitimas“ reiškia, kad išteklius bus ištrintas ir sukurtas iš naujo; Duomenų bazei tai reiškia duomenų praradimą. Jei nesitikima, taikymas turėtų būti sustabdytas, pakeitimas turi būti pakeistas į saugų metodą arba nepakeičiamas laukas turėtų būti nepaliestas.

7. Kuris iš šių teiginių yra teisingas, kai Dockerfile yra paruoštas gamybai, atsižvelgiant į jo saugumą ir dydį?

• A) Kad būtų patogiau, paslaptį įterpkite į vaizdą naudodami ENV ir paleiskite kaip root
• B) Visada naudokite žymą „:latest“ ir palikite kuo didesnį pagrindinį vaizdą
• C) Vieno etapo kūrimas ir visų kūrimo įrankių palikimas galutiniame vaizde
• D) Neįterpti paslapties, dirbti su neteisėtu USER, naudojant mažą ir stabilų pagrindinį vaizdą ir kelių etapų kūrimą ✔

Aprašymas: gamybai paruoštas vaizdas: neįdeda paslapties (įveda ją vykdymo metu), veikia su neteisėtu USER, o ne root, naudoja mažą ir versijas turintį bazinį vaizdą (plonas/alpiniškas, o ne :naujausias) ir yra sumažintas naudojant kelių etapų kūrimą. Taip pat prieš paskelbiant jis nuskaitomas, ar nėra pažeidžiamumų.

8. Kokia yra svarbiausia rizika neapibrėžus išteklių apribojimų diegimui Kubernetes?

• A) Pod niekada neprasideda, nes limitas yra privalomas laukas
• B) Stebėjimo plokštėje rodomas tik įspėjimas, veikimas neturi įtakos
• C) „Kubernetes“ automatiškai nustato saugias numatytąsias ribas, jokios rizikos
• D) Ankštis gali neribotai augti ir eikvoti mazgo išteklius, todėl sugenda kaimyninės paslaugos ✔

Paaiškinimas: Pod, neturintis išteklių apribojimo, gali neribotai augti, sunaudoti visus mazgo, kuriame jis veikia, išteklius ir, pavyzdžiui, dėl atminties nutekėjimo, sugenda kaimyninės paslaugos. Štai kodėl užklausų / apribojimų apibrėžimas yra tvirtumo pagrindas.

9. Kaip išvengti „perspėjimo nuovargio“ stebint ir nustatant signalizaciją?

• A) Nustatykite aliarmus pagal kiek įmanoma daugiau metrikų ir generuokite įspėjimus dėl kiekvieno svyravimo.
• B) Nustatykite visus pavojaus signalus į aukščiausią sunkumo lygį
• C) Pavojaus signalų suaktyvinimas su momentinėmis reikšmėmis nenustatant laiko (for)
• D) Pavojaus signalų laikymasis orientuotas į veiksmus ir reikiamos skubos, tikrinti slenksčius su istoriniais duomenimis, sujungti nereikalingus ✔

Aprašymas: kiekvienas pavojaus signalas turi būti veiksmingas ir tinkamos skubos; Informacija, kuri nereikalauja veiksmų, rodoma lentoje, ji nieko nepažadina. Pavojaus slenksčiai tikrinami pagal sistemos istorinius duomenis, o nereikalingi / pasikartojantys pavojaus signalai yra konsoliduojami. Taip tikrasis signalizatorius nepasiklys triukšme.

10. Koks yra geriausias prioritetinis užsakymas gamybos incidento metu?

• A) Pirmiausia suraskite tikslią pagrindinę priežastį ir sumažinkite ją tik tada, kai priežastis yra aiški.
• B) Pirmiausia parašykite postmortem ataskaitą, tada palieskite paslaugą
• C) Pirmiausia sumažinkite (atkūrimo / atkūrimo paslauga), palikdami pagrindinės priežasties analizę vėliau ✔
• D) Pirmiausia suraskite už incidentą atsakingą asmenį ir praneškite apie jį

Paaiškinimas: Auksinė taisyklė yra „pirmiausia sumažink, vėliau tyrinėk“. Tikslas yra pirmiausia atkurti paslaugą arba grąžinti ją į žinomą gerą versiją (sumažinti); Pagrindinės priežasties analizė atliekama ramiai po to, kai sumažėja slėgis. Laukiant tikslios pagrindinės priežasties nustatymo, pailgėja atkūrimo laikas (MTTR).

11. Koks yra pagrindinis nepriekaištingos pomirtinės kultūros tikslas?

• A) Nurodykite asmenį, kuris padarė klaidą, ir perkelkite jam atsakomybę
• B) Dėmesys sistemoms ir procesams bei mokymosi skatinimas; ✔ Mokymasis pamokų, kurios neleidžia kartotis, o ne kaltina
• C) Niekada nepraneškite apie incidentą ir įsitikinkite, kad jis bus pamirštas
• D) Rašykite tik technines detales ir nepridėkite reikalingų elementų

Paaiškinimas: Nekaltas postmortem dėmesys sutelkiamas į klausimą „kuri sistema ir procesas leido padaryti šią klaidą“, o ne „kas tai padarė“. Žmonės atvirai dalijasi klaida, jei žino, kad nebus nubausti; Paslėpta klaida kartojasi. Ataskaita nėra kaltinimo ataskaita, o mokymosi dokumentas, pilnas į veiksmus orientuotų dalykų.

12. Koks yra logiškiausias žingsnis optimizuojant debesų sąnaudas (FinOps) prieš pereinant prie įsipareigojimų nuolaidų (rezervuotas / taupymo planas)?

• A) Pirmiausia prisiimkite ilgesnį įmanomą įsipareigojimą, vėliau galvokite apie atliekas
• B) Pirmiausia išvalykite atliekas (uždarymas tuščiąja eiga, tinkamo dydžio nustatymas), tada įsipareigojkite naudoti pagal paskirtį ✔
• C) Nedelsdami perkelkite visus išteklius į „Spot“ pajėgumą
• D) Brangiausios prekės ištrynimas neperžiūrėjus sąskaitos faktūros duomenų

Paaiškinimas: pirmiausia reikia išvalyti atliekas (uždaryti tuščius išteklius, sumažinti perteklinius išteklius). Priešingu atveju 1-3 metams užblokuosite tuščią naudojimą su nuolaida. Tinkamo dydžio nustatymas ir valymas tuščiąja eiga nereikalauja jokių įsipareigojimų ir yra beveik nerizikingi.

13. Kokia yra svarbiausia saugumo priemonė, jei AI siūlomame scenarijuje yra eilutė „rm -rf „$DIR“/?

• A) Scenarijaus paleidimas tiesiogiai prod, jo neskaitant, pagreitės
• B) Pridėkite set -euo pipefail ir tuščią kintamojo valdymą ir pirmiausia pabandykite su sausuoju paleidimu ✔
• C) Pakanka sutrumpinti kintamojo pavadinimą
• D) Naudojant rm -rf --force vietoj rm, problema išsprendžiama

Paaiškinimas: Jei $DIR yra tuščias, šis sakinys gali bandyti ištrinti šakninį katalogą. Sustojus prie neapibrėžto kintamojo su „set -u“ ir patikrinus, ar kintamasis nėra tuščias prieš jį ištrinant (pvz., [ -n "$DIR" ] || exit 1), išvengiama nelaimės. Be to, destruktyvios operacijos pirmiausia turėtų būti išbandytos naudojant sausą paleidimą.

14. Ką pirmiausia reikia padaryti, jei debesies prieigos raktas netyčia nuteka į viešąją saugyklą?

• A) Nedelsdami atšaukite ir atnaujinkite (pasukite) raktą; Vien ištrinti neužtenka ✔
• B) Tiesiog ištrinkite failą iš saugyklos ir raktas bus saugus
• C) Nieko nedaryti, nes niekas to nematė
• D) Padarius saugyklą privačią, nebereikia pasukti rakto

Paaiškinimas: nutekėjusią paslaptį reikia nedelsiant panaikinti ir pasukti. Vien tik failo ištrynimo neužtenka, nes paslaptis lieka „Git“ istorijoje, o viešąsias saugyklas robotai nuskaito per kelias sekundes. Po atšaukimo / grąžinimo įvertinamas poveikis ir pridedamas slaptas skaitytuvas, kad būtų išvengta pasikartojimo.

15. Kuris iš šių metodų sumažina riziką išleidžiant naują „Prod“ versiją?

• A) Naujos versijos teikimas visiems vartotojams vienu metu (didysis sprogimas) ir nerengiamas atšaukimo planas
• B) Manoma, kad diegimas baigtas, kai tik pasirodys „žali“, papildomos patikros neatlikimas
• C) Naudojant kontroliuojamą strategiją, pvz., kanarėlių / mėlynai žalią / funkcijų vėliavėlę, paruoštą atšaukimo planą ir dūmų testą + metrinę stebėseną po įdiegimo ✔
• D) Kritinių verslo kelių testavimą palikti dirbtiniam intelektui ir jų visai nenustatyti.

Paaiškinimas: kontroliuojamos išleidimo strategijos (pradedant nuo nedidelio procento su canary, nedelsiant atšaukiant mėlynai žalią, atskiriant diegimą nuo išleidimo naudojant funkcijos vėliavėlę) riboja riziką. Be to, būtinas aiškus atšaukimo planas prieš diegimą ir auksinio signalo stebėjimas su dūmų bandymu po įdiegimo; „atrodo žaliai“ nereiškia, kad tai veikia.