Toote kinnitamine, väljalaskestrateegiad ja täielik AI töövoog

Kasu:

• Riski vähendavate vabastamisstrateegiate (sinine-roheline, kanaarilind, funktsioonilipp) ja toote kontrollimise distsipliini (tervisekontroll, suitsutest, kuldse signaali jälgimine) mõistmine
• Võimalus rakendada harjumust koostada selge tagasipööramisplaan enne kasutuselevõttu ja kontrollida kriitilisi äriteid pärast juurutamist
• Võimalus ühendada kõik mooduli jooksul õpitud osad täielikus AI-toega töövoos ja rakendada põhimõtet „AI toodab, inimesed kontrollivad ja garanteerivad” igal sammul.

Kogu see moodul liikus ühe punkti suunas: koodi ja infrastruktuuri ohutu tarnimine tootmisse (reaalklientide kasutatav reaalajas keskkond). Nüüd oleme ahela kõige kriitilisemas ja pingelisemas lülis: muudatuse käivitamine ja kontrollimine, et see seal ka tegelikult toimib. Siinne viga ei ole abstraktne – see mõjutab otseselt klienti, tulusid ja mainet. Seetõttu ei lähe küpsed meeskonnad tootmisse mitte "lootes", vaid kontrollitud vabastamisstrateegiate ja süstemaatilise kontrollimisega.

Selles viimases üksuses ühendame kaks asja: (1) riski vähendavad vabastamismeetodid (kanaarilind, sinakasroheline, funktsioonilipp) ja toote kontrollimise distsipliini; (2) kuidas iga mooduli jooksul õpitud osa – CI/CD, IaC, konteiner, seire, vahejuhtum, kulu, skript, turvalisus – koondub üheks AI-toega täielikuks töövooks. Kordame esialgset tsitaati viimast korda: AI genereerib ja kiirendab mustandeid igal sammul; Kuid teie olete see, kes vajutab nuppu "Ma võtan selle otseülekande" ja garanteerib tulemuse.

Vabastage riski vähendavad strateegiad

Kõige riskantsem on muudatuste edastamine kõigile kasutajatele korraga. Küpsed meetodid:

• Sinine-roheline juurutamine: Säilitatakse kaks identset keskkonda - "sinine" (reaalajas) ja "roheline" (uus versioon). Uus versioon valmistatakse ette ja testitakse rohelises, seejärel lülitatakse liiklus ootamatult rohelisele. Kui tekib probleem, läheb liiklus kohe siniseks. Kiire tagasipööramine on selle suurim eelis.
• Canary juurutamine: uus versioon avaldatakse esmalt väikesele protsendile kasutajatest (nt 5%); Kui mõõdikud on head, suurendage järk-järgult 100% -ni. Probleem mõjutab väikest osa kasutajast, mitte kogu kasutajat.
• Funktsiooni lipp: uus funktsioon sisestab koodi, kuid on lipuga blokeeritud; See avatakse soovi korral teatud kasutajatele. Eristatakse kasutuselevõttu ja vabastamist; Probleemi korral lülitatakse lipp välja ilma koodi tagasi kerimata.

Näpunäide. Kiireim turvavõrk on tagasipööramine enne iga kasutuselevõttu. "Kui midagi läheb valesti, kuidas saan 60 sekundiga vana versiooni juurde tagasi pöörduda?" Kui küsimusele pole selget vastust, pole te valmis seda juurutama.

Tootekinnitus: töö ei lõpe juurutamise lõppedes

See, et juurutus näeb välja "roheline", ei tähenda, et see töötab. Süstemaatiline kontrollimine:

1. Tervisekontroll: kas teenus töötab, kas /healthz reageerib?
2. Suitsutestid: kas mõned kõige kriitilisemad kasutajateed (sisselogimine, maksmine, otsing) ka tegelikult töötavad? Automaatne ja kiire.
3. Jälgige kuldseid signaale: juurutamisjärgne veamäär, latentsus, kas liiklus on normaalne? (Neli signaali seadmel 6.)
4. Laiendage järk-järgult: Kanaari protsendi suurendamisel vaadake igal etapil mõõdikuid.
5. Vaatlusaken: jälgige tähelepanelikult teatud aja jooksul (nt 30 minutit) pärast kasutuselevõttu; Salakavalad probleemid pole kohe näha.

Ettevaatust: AI võib koostada suitsutestide või kontrollimiste loendi, kuid teie ülesanne on kindlaks teha, millised kasutajateed on "kriitilised". AI annab üldise loetelu; Ainult teie teate, et teie maksevoogu, teie kõige tulusamat teed, tuleb testida.

Väljalaskestrateegiate võrdlus

strateegia

Peamine eelis

Maksumus/keerukus

kõige sobivam

Sinine-Roheline

Kohene tagasipööramine

Kaks keskkonda = 2x ressurssi

Kui kiire otsimine on kriitiline

kanaarilind

Piirab mõju väikesele lõigule

Vajalik liikluskorraldus

Tohutu kasutajaskond

Funktsioonilipp

Eraldab juurutamise väljalaskest

Lipu haldamise võlg

Järkjärguline/sihipärane avamine

Jooksev värskendus

Lihtne, ressursisõbralik

aeglane tagasipööramine

Lihtsad teenused

AI-toega täielik töövoog

Nüüd ühendame kogu mooduli üheks vooluks. Oletame, et avaldate uue mikroteenuse. AI toodab igal etapil mustandeid; te kontrollite igal sammul:

1. Kood ja konteiner (üksus 4): AI loob optimeeritud ja turvalise Dockerfile'i; Kontrollite mittesaladust ja suurust.
2. CI/CD (üksus 2): kirjutab AI-test-build-deploy konveieri; Kitsendate õigusi ja kontrollite salajasi viiteid.
3. Infrastruktuur (üksus 3): määratleb AI Terraformiga vajalikud ressursid; Loed plaani väljundit ja ei otsi ootamatuid kustutamisi.
4. Orkestreerimine (Unit 5): AI toodab Kubernetese manifeste; kontrollite ressursipiirangut, proovi ja RBAC-i.
5. Turvalisus (üksus 10): eelistab tehisintellekti skannimise väljundeid; Kõigepealt haarake ära ekspluateeritavad.
6. Seire (üksus 6): AI genereerib häirereeglid ja armatuurlaua; Testite lävesid oma varasemate andmetega.
7. Vabastamine ja kinnitamine (see üksus): kirjeldab tehisintellekti suitsutesti ja tagasipööramise plaani; alustad kanaari, vaata mõõdikuid, vajuta nuppu.
8. Juhtumi korral (üksus 7): AI loob hüpoteesi ja surmajärgse visandi; Kontrollite ja õpite õppetunnid.
9. Maksumus (üksus 8): AI jälgib uute ressursside raiskamist; Teete õigeid otsuseid.

Üldine reegel jääb igal sammul samaks: AI toodab ja kiirendab, inimene kontrollib ja garanteerib. See on mooduli olemus.

kolm minikarpi

Juhtum 1 – kanaarilind piiras katastroofi 5%-ga. Meeskond andis uue versiooni 5% kasutajatest, kellel on kanaarilind. AI toodetud armatuurlaud näitas kohe, et veamäär hüppas selles osas 8%-ni. Meeskond võttis selle tagasi, suurendamata seda 100%-ni; Probleem puudutas vaid 5% kasutajatest ja see kestis paar minutit. Kui kasutuselevõtt toimuks suure hooga, mõjutaks see kõiki kliente.

Juhtum 2 — suitsukatse tabas puuduva tee. AI pakkus suitsutesti komplekti, kuid sellel polnud "maksevoogu". Insener lisas selle, teades, et kõige kriitilisem tuluvoog on maksmine. Juurutamisjärgne test läks katki kohe kassatapis – kolmanda osapoole võti oli aegunud. Kinnitamine tuvastas mõne minuti jooksul vaikiva tulude kaotuse.

Juhtum 3 – valmis tagasipööramine salvestatakse 90 sekundiga. Sinise-rohelise installinud meeskond muutis uue versiooni roheliseks; 2 minuti pärast kahekordistus viivitus. Eelnevalt ettevalmistatud tagasikäiguga muutsid nad liikluse siniseks 90 sekundiga. Nad leidsid algpõhjuse (uues versioonis aeglane päring) mitte surve all, siis rahulikult. Valmis tagasipööramise tee muutis katkestuse peaaegu nähtamatuks.

Neli kopeeritavat malli

1) Väljalaskestrateegia valik:

Pakun järgmist teenust: [TEENUS/KONTEKST: kasutajate arv, katkestuste tolerants, infrastruktuur]. Millist sini-rohelise, kanaari ja erilippude vahel soovitate? Võrrelge selles kontekstis igaühe eeliseid, kulusid ja tagasipööramise kiirust. Tehke ettepanek, kuid teatage, et lõpliku otsuse teen mina.

2) Suitsutestide/kontrollide nimekiri:

Kas koostada [SERVICE] suitsutesti ja kinnitusloendite mustand, mida käitan pärast juurutamist: tervisekontroll, kõige kriitilisemad kasutajateed, milliseid mõõdikuid peaksin mitu minutit jälgima? Oletame, et märgin kõige kriitilisemad äriteed ja jätan selle välja tühjaks.

3) Taastamise plaan:

Ma kasutan [DEPLOY METHOD]. Kirjutage mulle selge tagasipööramise plaan: millise käsu/sammuga vanale versioonile tagasi kerin, kui kaua see aega võtab, millised on tagasipööramise enda riskid (nt andmebaasi migratsiooni ei saa tagasi pöörata), mida peaksin enne tagasipööramist kontrollima?

4) Täielik väljalaske kontroll-loend:

Koostage täielik ettevalmistamise kontrollnimekiri uue [SERVICE] projekti väljastamiseks: koodi/kujutise turvalisus, torujuhe, infrastruktuuriplaan, jälgimine ja alarmeerimine, turvaskaneerimine, väljalaskestrateegia, tagasivõtmine ja kontrollimine. Kontrollige iga üksust küsimusega "Kas ma olen valmis?" Muutke see küsimuseks.

Nõrk viip / Tugev viip

Nõrk: "Kuidas ma saan selle tooteks?"

Tulemus: kontekst puudub; AI loetleb üldised juurutamise etapid, see ei käsitle teie riskitaluvust, kasutaja ulatust ega tagasipööramisvajadust.

Güçlü: "Tootan 10 miljoni kasutajaga makseteenust, minu taluvus seisakute suhtes on väga madal. Kas soovitate Canary või Blue-Greeni, miks? Milliseid kriitilisi teid peaksin pärast juurutamist testima, milliseid mõõdikuid peaksin mitu minutit jälgima ja milline peaks olema 60-sekundiline tagasipööramise plaan? Lõpliku otsuse teen mina."

Erinevus: teine ​​viip annab skaala, tolerantsi ja tagasipööramise ootuse; See nõuab strateegiat + kontrollimist + tühistamist ja jätab otsuse inimese teha.

Levinud vead

• Juurutamine ilma tagasivõtmise plaanita. Kui tagasiteed pole, on iga kasutuselevõtt õnnemäng.
• Suure pauguga kasutuselevõtt. Selle korraga kogu kasutajale andmine suurendab riski.
• Eeldusel "roheline = töötab". Tervisekontrolli läbinud teenus võib kriitilisel teel katkeda.
• Arvates, et jätate kriitilised äriteed AI hooleks. Peate märkima sellised viisid nagu makse.
• Ei jälgi pärast kasutuselevõttu. Salakavalad probleemid ei ilmne esimese minutiga; vaatlusaken on vajalik.
• Mõeldes andmebaasi migratsioonile on pöörduv. Mõned muudatused ei taandu; on planeeritud eraldi.

Kokkuvõttes

Tootmisele minek on ahela kõige kriitilisem lüli ja seda ei tehta mitte "lootes", vaid kontrollitud strateegiatega: sinine-roheline tagab kohese tagasilöögi, piirates kanaari efekti väikese lõiguga, eraldades funktsioonilipu juurutamise vabastamisest. Töö ei ole lõppenud, kui kasutuselevõtt on lõppenud; Süstemaatiline kontrollimine tervisekontrolli, suitsutestide ja kuldse signaali jälgimise kaudu on hädavajalik. AI genereerib ja kiirendab mustandeid igal sammul kogu mooduli ulatuses – alates Dockerfile'ist kuni konveierini, alates Terraformist kuni häirereegliteni, alates surmajärgsest kuni kuluanalüüsini. Kuid pädev isik jääb alles, kes kontrollib iga sammu, vajutab otseülekande nuppu ja garanteerib tulemuse. See on täieliku AI-toega DevOpsi kuldreegel.

Rakenduse ülesanne

Valige avaldamiseks teenus (päris või väljamõeldud). (1) Valige malliga „Avalda strateegia valik” strateegia, mis sobib teie kontekstiga, ja kirjutage, miks. (2) Laske luua malliga „Suitsukatse/kinnitusloend” kinnitusloend ja lisage ise kõige kriitilisemad äriteed. (3) Valmistage ette 60-sekundiline tagasipööramise plaan malliga "Tagastusplaan" ja kontrollige, kas selles pole pöördumatuid samme.

kontrollnimekiri

• [ ] Valisin väljalaskestrateegia (kanaari/sini-roheline/lipp), mis sobib minu kontekstiga.
• [ ] Mul on enne juurutamist selge ja kiire tagasipööramise plaan valmis.
• [ ] Lisasin ise oma Smoke testidesse kõige kriitilisemad äriteed (nt maksed).
• [ ] Pärast kasutuselevõttu jälgin kuldseid signaale läbi vaatlusakna.
• [ ] Planeerisin ka pöördumatuid samme (andmebaasi migratsioon jne).
• [ ] Kontrollisin tehisintellekti kavandit igal sammul; Tegin otsuse otseülekandeks minna.

Mooduli eksam

1. Milline järgmistest on DevOpsi ja AI jaoks parim positsioneerimine pilves?

• A) Tehisintellekt on abi- ja otsustusabivahend; Inimesed vastutavad toodet mõjutavate kriitiliste otsuste eest ✔
• B) Tehisintellekt võib viia lõpule tootmisseadmete juurutamise ja salajase rotatsiooni ilma inimese nõusolekuta
• C) Tehisintellekt on kasulik ainult dokumentatsiooni kirjutamisel, sellel pole infrastruktuuriga mingit pistmist
• D) Audit pole vajalik, sest tehisintellekt annab alati usaldusväärsemaid käske kui insener

Kirjeldus: see on assistent ja otsustustoe tööriist, mis kiirendab tekstimahukaid ülesandeid, nagu tehisintellekti konveier, konfiguratsioon, skript ja logi. Vastutus seisakuid, raha ja turvalisust mõjutavate otsuste eest, nagu tootmise vabastamine, salajane haldamine ja lõpprakendus, jääb pädevale insenerile.

2. Milline on kontrollimise distsipliini täpseim väljend enne tehisintellekti loodud DevOpsi käsu või konfiguratsiooni rakendamist?

• A) Kui väljund näeb välja sujuv ja enesekindel, saab seda käivitada otse tootmisrežiimis
• B) Väljund on ohutu ainult siis, kui süntaksivigu pole, täiendavaid kontrolle pole vaja
• C) Ühendage väljund allikaga, planeerige/kuivkäivitage ja filtreerige see oma süsteemi kontekstiga; siis kandideeri ✔
• D) Esimese katse tegemine otse tootes ja tulemuse vaatamine on kiireim kontrollimine

Selgitus: Kolmeastmeline kinnitamine on oluline: väljundi ühendamine allikaga (kas käsk/lipp on ametlikes dokumentides tegelikult olemas), selle kuivalt käivitamine (vaadake, mis juhtub plaaniga/--dry-run) ja selle läbilaskmine süsteemifiltrist (kas see mahub oma arhitektuuri- ja turbekonteksti). Sujuvus ei tähenda täpsust.

3. Milline on õige lähenemine tehisintellektilt küsimisel tõelist andmebaasi parooli sisaldava .env-faili vea või juurutusprobleemi kohta?

• A) Maskeerige tõelised saladused funktsiooniga <PLACEHOLDER>; jagage ainult varjatud viga ja konteksti ✔
• B) Kogu .env-faili kleepimine sellisel kujul lahendab probleemi kiiremini
• C) Kuna saladused on juba base64, on tavaline kleepimine ohutu
• D) Parooli kleepimine on ohutu, sest tehisintellekt ei salvesta seda kunagi

Kirjeldus: AI-viipale pole kleebitud tõelisi saladusi. Väärtused, nagu paroolid ja märgid, on maskeeritud märgiga <PLACEHOLDER>; jagatakse ainult veateadet ja vajalikku konteksti. Kui saladus on juba lekkinud, tuleks see kohe tühistada ja pöörata.

4. Milline järgmistest on CI/CD konveieri saladuste (parool, luba) õige haldamine?

• A) Seda hoitakse platvormi salajases hoidlas ja kutsutakse välja viitega (nt ${{ secrets.X }}), mitte kirjutatud lihttekstina ✔
• B) Mugavuse huvides kirjutatud lihttekstina YAML-i konveierisse
• C) Seda kontrollitakse, vajutades iga töö alguses kaja ja logi.
• D) Kui see on määratletud kõige laiema loaga (kirjuta kõik), suureneb turvalisus

Selgitus: saladusi ei kirjutata YAML-i lihttekstina; Seda hoitakse platvormi salajases hoidlas ja kutsutakse välja selliste viidetega nagu ${{ secrets.X }}. Lisaks on vähima volituse põhimõttel kitsendatud lubade õigusi ja salajast logi ei salvestata.

5. Mis on taristu haldamisel Terraformiga kõige kriitilisem samm enne muudatuse reaalajas rakendamist?

• A) „Terraformi rakenduse” otse käivitamine; plaan on ajaraisk
• B) Osariigi faili varundamine avalikku hoidlasse
• C) Käivitage 'terraform plan' ja kontrollige väljundis hävitamise/asendamise ridu, seejärel rakendage ✔
• D) Desinstallige teenusepakkuja versioon ja veenduge, et uusim versioon tuleb automaatselt

Selgitus: enne terraformi rakendamist tuleb käivitada 'terraform plan'. Plaan näitab, mida lisada, mida muuta ja eriti mida kustutada (hävitada), ilma midagi tegemata. Kui näete ootamatut hävitamise või asendamise joont, ei tohiks rakendust rakendada.

6. Mida see tähendab ja mida teha, kui Terraformi plaani väljundis ilmub tootmisandmebaasi rida „-/+ asenda”?

• A) Allikat värskendatakse lihtsalt kohapeal, ohtu pole
• B) Ressurss kustutatakse ja luuakse uuesti; Esineb andmete kaotsimineku oht, taotlemine tuleks katkestada, kui seda pole oodata ✔
• C) Uue ressursi lisamine ei mõjuta olemasolevat andmebaasi
• D) See on lihtsalt hoiatus, seda võib julgelt ignoreerida

Selgitus: „-/+ asendus” tähendab, et ressurss kustutatakse ja luuakse uuesti; Andmebaasi jaoks tähendab see andmete kadumist. Kui seda pole oodata, tuleks rakendamine peatada, muudatus teisendada turvalisele meetodile või jätta muutumatu väli puutumata.

7. Milline alljärgnevast kehtib Dockerfile'i puhul, mis on oma turvalisuse ja suuruse poolest tootmisvalmis?

• A) Mugavuse huvides manustage saladus pildile ENV-ga ja käivitage see juurfailina
• B) Kasutage alati märgendit ":latest" ja hoidke põhipilt võimalikult suurena
• C) Üheastmeline ehitamine ja kõigi ehitustööriistade jätmine lõppkujutisse
• D) Saladuse mitte manustamine, volitamata KASUTAJAGA töötamine, väikese ja stabiilse põhipildi ning mitmeastmelise ehituse kasutamine ✔

Kirjeldus: Tootmisvalmis pilt: ei manusta saladust (sisestab selle käitusajal), töötab rooti asemel volitamata KASUTAJAGA, kasutab väikest ja versioonidega põhipilti (slim/alpine, mitte : uusim) ja seda vähendatakse mitmeastmelise järguga. Samuti kontrollitakse seda enne avaldamist turvaaukude suhtes.

8. Mis on kõige olulisem oht, kui Kubernetesis juurutamisel ei määrata ressursipiiranguid?

• A) Pod ei käivitu kunagi, sest limiit on kohustuslik väli
• B) Järelevalvepaneelile ilmub ainult hoiatus, see ei mõjuta tööd
• C) Kubernetes jõustab automaatselt ohutud vaikepiirangud, ilma riskita
• D) Kaun võib piiramatult kasvada ja tarbida sõlme ressursse, põhjustades sellega naaberteenuste krahhi ✔

Selgitus: Pod, millel pole ressursipiirangut, võib piiramatult kasvada, tarbida kõiki selle sõlme ressursse, milles see töötab, ja näiteks mälulekke tõttu naaberteenustes krahhi. Seetõttu on taotluste/piirangute määratlemine robustsuse aluseks.

9. Kuidas vältida "häireväsimust" jälgimisel ja häire seadistamisel?

• A) Määrake häired võimalikult paljudele mõõdikutele ja genereerige hoiatusi iga kõikumise korral.
• B) Seadke kõik häired kõrgeimale raskusastmele
• C) Häirete käivitamine hetkeväärtustega ilma aega määramata (for)
• D) Häirete tegevusele orienteeritud ja õige kiireloomulisuse hoidmine, lävede testimine ajalooliste andmetega, mittevajalike ühendamine ✔

Kirjeldus: iga häire peab olema rakendatav ja õige kiireloomulisusega; Infot, mis tegevust ei nõua, kuvatakse tahvlile, see ei ärata kedagi üles. Häireläve testitakse süsteemi ajalooliste andmetega ja mittevajalikud/korduvad häired koondatakse. Nii ei kao päris äratus müra kätte.

10. Milline on parim prioriteetne järjekord tootmisintsidendi ajal?

• A) Esmalt leidke täpne algpõhjus ja vähendage seda alles siis, kui põhjus on selge.
• B) Esmalt kirjutage surmajärgne aruanne, seejärel puudutage teenust
• C) Esmalt vähendage (taastamise/taastamise teenus), jättes algpõhjuste analüüsi hilisemaks ✔
• D) Esmalt leidke juhtumi eest vastutav isik ja teatage sellest

Selgitus: Kuldne reegel on "vähenda kõigepealt, uuri hiljem". Eesmärk on esmalt teenus taastada või teadaolevale heale versioonile tagasi pöörata (leevendada); Algpõhjuse analüüs tehakse rahulikult pärast rõhu langemist. Täpse algpõhjuse leidmise ootamine pikendab taastumisaega (MTTR).

11. Mis on laitmatu surmajärgse kultuuri peamine eesmärk?

• A) Vea teinud isiku tuvastamine ja vastutuse panemine talle
• B) Süsteemidele ja protsessidele keskendumine ning õppimise soodustamine; ✔ Õppige õppetunde, mis hoiavad pigem ära kordamist kui süüdistavad
• C) Ärge kunagi teatage juhtumist ja veenduge, et see unustataks
• D) Kirjutage ainult tehnilisi üksikasju ja ärge lisage toiminguid

Seletus: Süütu surmajärgne surmajärgne küsimus keskendub küsimusele „milline süsteem ja protsess selle vea lubas”, mitte „kes seda tegi”. Inimesed jagavad viga avalikult, kui nad teavad, et neid ei karistata; Varjatud viga kordub. Raport ei ole süüdistusaruanne, vaid õppedokument, mis on täis tegevusele suunatud punkte.

12. Mis on pilvekulude optimeerimise (FinOps) puhul kõige loogilisem samm enne pühendunud allahindlustele üleminekut (reserveeritud/säästuplaan)?

• A) Võtke esmalt võimalikult pikk kohustus, mõelge raiskamisele hiljem
• B) Esmalt koristage jäätmed (tühikäigu sulgemine, õige suurus), seejärel võtke kasutusele sihipärane kasutamine ✔
• C) Liigutage kõik ressursid koheselt Spot võimsusele
• D) Kalleima kauba kustutamine ilma arve andmeid üle vaatamata

Selgitus: Esmalt tuleb koristada jäätmed (sulgeda seisvad ressursid, vähendada ülegabariidilisi ressursse). Vastasel juhul lukustate raisatud kasutuse soodushinnaga 1-3 aastaks. Õige suuruse määramine ja tühikäigupuhastus ei nõua pühendumist ja on peaaegu riskivabad.

13. Mis on kõige olulisem turvameede, kui tehisintellekti soovitatud skriptil on rida 'rm -rf "$DIR"/'?

• A) Skripti käivitamine otse tootmisprogrammis ilma seda lugemata kiirendab
• B) Lisa set -euo pipefail ja tühjenda muutuja juhtimine ning proovi esmalt kuivkäivitamisega ✔
• C) Piisab muutuja nime lühendamisest
• D) rm -rf --force kasutamine rm asemel lahendab probleemi

Selgitus: Kui $DIR on tühi, võib see lause üritada juurkataloogi kustutada. Peatumine määramata muutuja juures koos 'set -u' ja kontrollimine, et muutuja poleks enne selle kustutamist tühi (nt [ -n "$DIR" ] || väljumine 1), väldib katastroofi. Lisaks tuleks esmalt proovida destruktiivseid operatsioone kuivkäivitamisega.

14. Mida teha esimese asjana, kui pilve juurdepääsuvõti lekib kogemata avalikku hoidlasse?

• A) Tühistage ja uuendage (pöörake) võti viivitamatult; Ainult kustutamisest ei piisa ✔
• B) Lihtsalt kustutage fail mälust ja võti on ohutu
• C) Ei tee midagi, sest keegi ei näinud seda
• D) Salvestusruumi privaatseks muutmine välistab vajaduse võtit pöörata

Selgitus: lekkinud saladus tuleb kohe tühistada ja pöörata. Ainult faili kustutamisest ei piisa, sest saladus jääb Giti ajalukku ja avalikke hoidlaid skannivad robotid mõne sekundi jooksul. Pärast tühistamist/tagastamist hinnatakse mõju ja lisatakse salajane skanner, et vältida kordumist.

15. Milline järgmistest lähenemisviisidest minimeerib toote Prodi uue versiooni väljalaskmisel riski?

• A) Uue versiooni andmine kõigile kasutajatele korraga (suur pauk) ja tagasipööramisplaani koostamata jätmine
• B) Arvestades, et juurutamine on lõppenud niipea, kui see ilmub "roheline", lisakontrolli ei teostata
• C) Kasutades kontrollitud strateegiat, nagu kanaarilind/sini-roheline/funktsiooni lipp, valmis tagasipööramisplaan ja suitsutest + meetriline jälgimine pärast kasutuselevõttu ✔
• D) Kriitiliste äriteede testimise jätmine täielikult tehisintellekti hooleks ja nende määramata jätmine.

Selgitus: Kontrollitud väljalaskestrateegiad (alates väikesest protsendist kanaaripuust, kohene tagasipööramine sinakasrohelisega, eraldades kasutuselevõtu väljalaskest funktsioonilipuga) piiravad riski. Lisaks on oluline selge tagasipööramise plaan enne kasutuselevõttu ja kuldse signaali jälgimine koos suitsutestiga pärast kasutuselevõttu; "roheline väljanägemine" ei tähenda, et see töötab.