Preverjanje izdelka, strategije izdaje in potek dela z umetno inteligenco od konca do konca

Dobički:

• Razumevanje strategij sproščanja za zmanjševanje tveganja (modro-zelena, kanarček, značilna zastavica) in discipline preverjanja izdelka (zdravstveni pregled, test dima, spremljanje zlatega signala)
• Sposobnost izvajanja navade priprave jasnega načrta za povrnitev pred uvedbo in preverjanja kritičnih poslovnih poti po uvedbi
• Sposobnost združevanja vseh delov, pridobljenih v celotnem modulu, v potek dela od konca do konca, ki ga podpira umetna inteligenca, in uporaba načela "umetna inteligenca proizvaja, ljudje preverjajo in jamčijo" na vsakem koraku

Ta celoten modul je tekel proti eni točki: varni dostavi kode in infrastrukture v proizvodnjo (živo okolje, ki ga uporabljajo resnične stranke). Zdaj smo pri najbolj kritičnem in stresnem členu v verigi: pridobivanje spremembe v živo in preverjanje, ali tam dejansko deluje. Napaka tukaj ni abstraktna - neposredno prizadene stranko, prihodek in ugled. Zato zrele ekipe ne gredo v proizvodnjo z "upanjem", temveč s strategijami nadzorovanega sproščanja in sistematičnim preverjanjem.

V tej zadnji enoti združujemo dve stvari: (1) metode sproščanja, ki zmanjšujejo tveganje (kanarček, modro-zelena, značilna zastavica) in disciplino preverjanja izdelka; (2) kako se vsak del, ki smo se ga naučili v modulu – CI/CD, IaC, vsebnik, spremljanje, incident, stroški, skript, varnost – združi v en sam potek dela od konca do konca, ki ga poganja AI. Še zadnjič ponovimo začetni citat: umetna inteligenca ustvari in pospeši osnutke na vsakem koraku; Toda vi ste tisti, ki pritisnete gumb "To posnamem v živo" in jamčite za izid.

Strategije sproščanja, ki zmanjšujejo tveganje

Potiskanje spremembe vsem uporabnikom hkrati je najbolj tvegan način. Zrele metode:

• Modro-zelena uvedba: Ohranjata se dve enaki okolji — »modro« (v živo) in »zeleno« (nova različica). Nova različica je pripravljena in testirana v zeleni barvi, nato pa se promet nenadoma preklopi na zeleno. Če pride do težave, se promet takoj vrne v modro. Hitro vračanje nazaj je njegova največja prednost.
• Canary Deployment: nova različica je najprej izdana majhnemu odstotku uporabnikov (npr. 5 %); Če so meritve dobre, postopoma povečajte na 100 %. Težava vpliva na majhen del uporabnika, ne na celotnega uporabnika.
• Zastavica funkcije: Nova funkcija vnese kodo, vendar je blokirana z zastavico; Na zahtevo se odpre določenim uporabnikom. Obstaja razlika med uvajanjem in "sprostitvijo"; Če pride do težave, se zastavica izklopi brez povrnitve kode.

Nasvet: Najhitrejša varnostna mreža je, da imate pred vsako uvedbo pripravljeno povrnitev. "Če gre kaj narobe, kako se lahko vrnem na staro različico v 60 sekundah?" Če na vprašanje ni jasnega odgovora, niste pripravljeni na to uvedbo.

Preverjanje izdelka: delo se ne konča, ko se konča uvajanje

Samo zato, ker je uvedba videti "zelena", še ne pomeni, da deluje. Sistematsko preverjanje:

1. Pregledi zdravja: Ali storitev deluje, ali se /healthz odziva?
2. Dimni testi: Ali nekaj najbolj kritičnih uporabniških poti (prijava, plačilo, iskanje) dejansko deluje? Samodejno in hitro.
3. Bodite pozorni na zlate signale: stopnja napak po uvedbi, zakasnitev, ali je promet normalen? (Štirje signali na enoti 6.)
4. Postopoma širite: Poglejte meritve pri vsakem koraku, ko povečate odstotek Canary.
5. Okno za opazovanje: pozorno spremljajte nekaj časa (npr. 30 minut) po namestitvi; Zahrbtne težave niso takoj vidne.

Pozor: umetna inteligenca lahko ustvari seznam testov dima ali preverjanj, vendar je vaša naloga, da ugotovite, katere uporabniške poti so "kritične". AI daje splošen seznam; Samo vi veste, da je treba vaš tok plačil, vašo pot do največjega prihodka, preizkusiti.

Primerjava strategij izdaje

Strategija

Glavna prednost

Stroški/zapletenost

najbolj primeren

Modro-zelena

Takojšnje vrnitev nazaj

Dve okolji = 2x viri

Če je hitro iskanje kritično

kanarček

Omejuje vpliv na majhne rezine

Potrebno je upravljanje prometa

Ogromna baza uporabnikov

FeatureFlag

Ločuje uvedbo od izdaje

Dolg upravljanja zastave

Postopno/ciljno odpiranje

Tekoča posodobitev

Enostavno, virom prijazno

počasno vračanje nazaj

Enostavne storitve

Potek dela, ki ga poganja AI od konca do konca

Sedaj pa združimo celoten modul v en sam tok. Recimo, da objavljate novo mikrostoritev. AI ustvari osnutke na vsakem koraku; na vsakem koraku preverite:

1. Koda in vsebnik (Enota 4): AI ustvari optimizirano, varno datoteko Docker; Preveriš no-skrivnost in velikost.
2. CI/CD (enota 2): piše cevovod AI test-build-deploy; Omejite dovoljenja in preverite tajne reference.
3. Infrastruktura (Enota 3): Definira potrebne vire z AI Terraform; Preberete izhod načrta in ne iščete nepričakovanih izbrisov.
4. Orkestracija (enota 5): AI proizvaja manifeste Kubernetes; preverite omejitev vira, sondo in RBAC.
5. Varnost (enota 10): daje prednost rezultatom skeniranja AI; Najprej zgrabiš tiste, ki jih je mogoče izkoriščati.
6. Spremljanje (enota 6): umetna inteligenca ustvari pravila za alarme in nadzorno ploščo; Mejne vrednosti preizkusite s preteklimi podatki.
7. Izdaja in validacija (ta enota): orisuje preizkus dima in načrt za povrnitev AI; zaženeš kanarčka, gledaš metriko, pritisneš gumb.
8. Če pride do incidenta (Enota 7): AI ustvari hipotezo in posmrtno skico; Preverjate in se naučite lekcij.
9. Stroški (enota 8): AI spremlja zapravljanje novih virov; Sprejemate prave odločitve glede velikosti.

Na vsakem koraku ostaja skupno pravilo nespremenjeno: AI proizvaja in pospešuje, človek preverja in jamči. To je bistvo modula.

trije mini kovčki

Primer 1 – kanarček je omejil katastrofo na 5 %. Ekipa je novo različico dala 5 % uporabnikov s kanarčkom. Nadzorna plošča, ki jo je izdelala umetna inteligenca, je takoj pokazala, da je stopnja napak v tej rezini poskočila na 8 %. Ekipa ga je vzela nazaj, ne da bi ga povečala na 100 %; Težava je prizadela le 5 % uporabnikov, in to za nekaj minut. Če bi prišlo do velikega poka, bi bile prizadete vse stranke.

Primer 2 — dimni preizkus je ujel manjkajočo pot. AI je ponudil komplet za testiranje dima, vendar ni imel "plačilnega" toka. Inženir ga je dodal, saj je vedel, da je najbolj kritičen tok prihodkov plačilo. Preizkus po uvedbi se je pokvaril takoj na koraku nakupa – ključ tretje osebe je potekel. Preverjanje je v nekaj minutah zaznalo tiho izgubo prihodka.

Primer 3 — pripravljen povrnitev nazaj, shranjen v 90 sekundah. Ekipa, ki je namestila modro-zeleno, je novo različico spremenila v zeleno; Po 2 minutah se je zamuda podvojila. Promet so v 90 sekundah spremenili v modro z vnaprej pripravljenim povratkom. Ugotovili so glavni vzrok (počasna poizvedba v novi različici) ne pod pritiskom, potem pa mirno. Zaradi pripravljene povratne poti je bila prekinitev skoraj nevidna.

Štiri predloge za kopiranje

1) Izbira strategije izdaje:

Predlagal bom naslednjo storitev: [STORITEV/KONTEKST: število uporabnikov, toleranca izpadov, infrastruktura]. Katero priporočate med modro-zeleno, kanarčkovo in funkcijsko zastavo? Primerjajte prednosti, stroške in hitrost povrnitve vsakega v tem kontekstu. Podajte predlog, vendar povejte, da bom jaz sprejel končno odločitev.

2) Preskus dima/verifikacijski seznam:

Izdelati osnutek preskusa dima in seznam preverjanja za [STORITEV], ki ga bom izvedel po uvedbi: pregled stanja, najbolj kritične uporabniške poti, katere meritve naj spremljam koliko minut? Predpostavimo, da bom označil najbolj kritične poslovne poti in pustil to polje prazno.

3) Načrt povrnitve:

Uporabljam [DEPLOY METHOD]. Napišite mi jasen načrt za povrnitev: s katerim ukazom/korakom se vrnem na staro različico, koliko časa traja, kakšna so tveganja same povrnitve (npr. selitve baze podatkov ni mogoče povrniti), kaj naj preverim pred povrnitvijo?

4) Kontrolni seznam za izdajo od konca do konca:

Izdelajte kontrolni seznam priprave od konca do konca za objavo v novem projektu [SERVICE]: varnost kode/slike, cevovod, načrt infrastrukture, spremljanje in alarmiranje, varnostno skeniranje, strategija izdaje, povrnitev in preverjanje. Vsak element preverite z vprašanjem "Ali sem pripravljen?" Spremeni to v vprašanje.

Šibek poziv/močan poziv

Slabo: "Kako naj to spravim v prod?"

Rezultat: brez konteksta; AI navaja splošne korake uvajanja, ne obravnava vaše tolerance tveganja, obsega uporabnika in potrebe po povrnitvi.

Güçlü: "Izdelal bom plačilno storitev z 10 milijoni uporabnikov, moja toleranca za izpade je zelo nizka. Ali priporočate Canary ali Blue-Green, zakaj? Katere kritične poti naj preizkusim po uvedbi, katere meritve naj spremljam koliko minut in kakšen naj bo 60-sekundni načrt za povrnitev prejšnjega stanja? Končno odločitev bom sprejel jaz."

Razlika: drugi poziv daje lestvico, toleranco in pričakovano povrnitev; Zahteva strategijo + preverjanje + razveljavitev in odločitev prepušča človeku.

Pogoste napake

• Uvajanje brez načrta za povrnitev. Če poti nazaj ni, je vsaka uvedba igra na srečo.
• Postavitev velikega poka. Dajanje celotnemu uporabniku naenkrat poveča tveganje.
• Ob predpostavki "zeleno = delujoče". Storitev, ki je opravila pregled zdravja, se lahko pokvari na kritični poti.
• Mislite, da kritične poslovne poti prepuščate AI. Označiti morate načine, kot je plačilo.
• Brez spremljanja po uvedbi. Zahrbtne težave se ne pojavijo v prvi minuti; potrebno je opazovalno okno.
• Razmišljanje o selitvi baze podatkov je reverzibilno. Nekatere spremembe se ne povrnejo; so načrtovani ločeno.

Če povzamem

Prehod na prod je najbolj kritičen člen v verigi in se ne izvaja z "upanjem", ampak z nadzorovanimi strategijami: modro-zelena zagotavlja takojšnjo vrnitev nazaj, omejuje kanarčkov učinek na majhen delček in ločuje uvedbo zastavice funkcije od izdaje. Delo ni končano, ko je uvajanje končano; Bistveno je sistematično preverjanje s pregledi zdravstvenega stanja, testi dima in spremljanjem zlatega signala. Umetna inteligenca ustvari in pospeši osnutke na vsakem koraku v celotnem modulu – od Dockerfile do cevovoda, od Terraforma do alarmnega pravila, od postmortem do analize stroškov. Ostaja pa pristojna oseba, ki preveri vsak korak, pritisne gumb go live in jamči za izid. To je zlato pravilo DevOps od konca do konca, ki ga poganja AI.

Aplikacijska naloga

Izberite storitev (resnično ali izmišljeno) za objavo. (1) S predlogo »Izbira strategije izdaje« izberite strategijo, ki ustreza vašemu kontekstu, in napišite, zakaj. (2) Ustvarjajte verifikacijski seznam s predlogo »Smoke test / verification list« in sami dodajte najbolj kritične poslovne poti. (3) Pripravite 60-sekundni načrt za povrnitev s predlogo »Načrt za povrnitev« in preverite, ali so v njem kakršni koli nepovratni koraki.

kontrolni seznam

• [ ] Izbral sem strategijo izdaje (kanarček/modro-zelena/zastavica), ki ustreza mojemu kontekstu.
• [ ] Pred uvedbo imam pripravljen jasen in hiter načrt za povrnitev.
• [ ] Svojim testom Smoke sem dodal najbolj kritične poslovne poti (npr. plačilo).
• [ ] Po uvedbi spremljam zlate signale skozi opazovalno okno.
• [ ] Načrtoval sem tudi nepovratne korake (selitev baze podatkov itd.).
• [ ] Na vsakem koraku sem preveril načrt AI; Odločil sem se, da grem v živo.

Modulni izpit

1. Kaj od naslednjega je najboljše pozicioniranje za DevOps in AI v oblaku?

• A) Umetna inteligenca je pomočnik in orodje za podporo odločanju; Ljudje so odgovorni za ključne odločitve, ki vplivajo na izdelek ✔
• B) Umetna inteligenca lahko dokonča namestitve izdelkov in skrivno rotacijo brez človeške odobritve
• C) Umetna inteligenca je uporabna le za pisanje dokumentacije, z infrastrukturo nima nič
• D) Revizija je nepotrebna, ker umetna inteligenca vedno proizvede bolj zanesljive ukaze kot inženir

Opis: Je pomočnik in orodje za podporo odločanju, ki pospešuje besedilno intenzivna opravila, kot so cevovod umetne inteligence, konfiguracija, skript in dnevnik. Odgovornost za odločitve, ki vplivajo na čas izpadov, denar in varnost, kot je sprostitev proizvodnje, tajno upravljanje in končna aplikacija, ostaja pri pristojnem inženirju.

2. Kateri je najnatančnejši izraz za disciplino preverjanja pred implementacijo ukaza DevOps ali konfiguracije, ki jo ustvari umetna inteligenca?

• A) Če je rezultat videti gladek in samozavesten, ga je mogoče zagnati neposredno v prod
• B) Izhod je varen samo, če ni napak v sintaksi, nadaljnja preverjanja niso potrebna
• C) Povežite izhod z virom, načrtujte/preizkusite in ga filtrirajte s kontekstom vašega sistema; potem se prijavi ✔
• D) Prvi poskus neposredno v izdelku in ogled rezultata je najhitrejše preverjanje

Pojasnilo: Preverjanje v treh korakih je bistvenega pomena: povezovanje izhoda z virom (je ukaz/zastavica dejansko v uradnih dokumentih), zagon na suho (videti, kaj se zgodi z načrtom/--suhi zagon) in podajanje skozi sistemski filter (ali ustreza njegovemu arhitekturnemu in varnostnemu kontekstu). Tekočnost ne pomeni natančnosti.

3. Kakšen je pravilen pristop, ko sprašujete umetno inteligenco o napaki ali težavi pri uvajanju z datoteko .env, ki vsebuje pravo geslo baze podatkov?

• A) Zakrijte resnične skrivnosti z <PLACEHOLDER>; deli samo prikrito napako in kontekst ✔
• B) Če prilepite celotno datoteko .env, kot je, težavo hitreje rešite
• C) Ker so skrivnosti že base64, je varno prilepiti navaden
• D) Lepljenje gesla je varno, ker ga umetna inteligenca nikoli ne shrani

Opis: v poziv AI niso prilepljene nobene prave skrivnosti. Vrednosti, kot so gesla in žetoni, so prikrite z <PLACEHOLDER>; v skupni rabi sta le sporočilo o napaki in potreben kontekst. Če je skrivnost že razkrita, jo je treba preklicati in nemudoma zamenjati.

4. Kaj od naslednjega je pravilno upravljanje skrivnosti (geslo, žeton) v cevovodu CI/CD?

• A) Hrani se v tajnem repozitoriju platforme in se kliče s sklicevanjem (npr. ${{ secrets.X }}), ni napisano v navadnem besedilu ✔
• B) Napisano v navadnem besedilu v cevovod YAML zaradi priročnosti
• C) Preveri se s pritiskom na echo in log na začetku vsakega opravila.
• D) Če je definirano z najširšim dovoljenjem (write-all), se varnost poveča

Pojasnilo: skrivnosti niso zapisane v YAML v navadnem besedilu; Hrani se v tajnem repozitoriju platforme in se kliče s sklici, kot je ${{ secrets.X }}. Poleg tega so z načelom najmanjše avtoritete dovoljenja za žeton zožena in tajni dnevnik se ne beleži.

5. Kateri je najpomembnejši korak pri upravljanju infrastrukture s Terraformom, preden izvedete spremembo v živo?

• A) Neposredno zagon 'terraform apply'; načrt je izguba časa
• B) Varnostno kopiranje državne datoteke v javno skladišče
• C) Zaženite 'terraform načrt' in preverite vrstice za uničenje/zamenjavo v izhodu, nato uporabite ✔
• D) Odstranite različico ponudnika in poskrbite, da bo najnovejša različica na voljo samodejno

Pojasnilo: 'terraform načrt' je treba zagnati pred 'terraform apply'. Načrt prikazuje, kaj dodati, kaj spremeniti in predvsem, kaj izbrisati (uničiti), ne da bi naredili karkoli. Če je prikazana nepričakovana vrstica za uničenje ali zamenjavo, se aplikacija ne sme uporabiti.

6. Kaj pomeni in kaj je treba storiti, če se v izhodu načrta Terraform pojavi vrstica '-/+ zamenjaj' za proizvodno bazo podatkov?

• A) Vir bo samo posodobljen na mestu, ni tveganja
• B) Vir bo izbrisan in ponovno ustvarjen; Obstaja nevarnost izgube podatkov, aplikacijo je treba ustaviti, če ni pričakovana ✔
• C) Dodajanje novega vira, obstoječa zbirka podatkov ni prizadeta
• D) To je le opozorilo, ki ga lahko mirno prezrete

Pojasnilo: '-/+ zamenjaj' pomeni, da bo vir izbrisan in znova ustvarjen; Za bazo podatkov to pomeni izgubo podatkov. Če ni pričakovano, je treba uporabo ustaviti, spremembo pretvoriti v varno metodo ali pa nespremenljivo polje pustiti nedotaknjeno.

7. Kaj od naslednjega velja za datoteko Docker, ki je glede na varnost in velikost pripravljena za proizvodnjo?

• A) Zaradi priročnosti vdelajte skrivnost v sliko z ENV in jo zaženite kot root
• B) Vedno uporabite oznako ':latest' in naj bo osnovna slika čim večja
• C) Enostopenjska izdelava in opustitev vseh gradbenih orodij v končni podobi
• D) Brez vdelave skrivnosti, delo z nepooblaščenim UPORABNIKOM, uporaba majhne in stabilne osnovne slike in večstopenjske gradnje ✔

Opis: Slika, pripravljena za proizvodnjo: ne vdela skrivnosti (vstavi jo med izvajanjem), izvaja se z nepooblaščenim UPORABNIKOM namesto s korenom, uporablja majhno osnovno sliko z različicami (slim/alpine, ne :latest) in je pomanjšana z večstopenjsko gradnjo. Pred objavo je tudi pregledan glede ranljivosti.

8. Kakšno je najpomembnejše tveganje, če ne določite omejitev virov za uvedbo v Kubernetesu?

• A) Pod se nikoli ne zažene, ker je limit obvezno polje
• B) Na nadzorni plošči se prikaže samo opozorilo, to ne vpliva na delovanje
• C) Kubernetes samodejno uveljavi varne privzete omejitve, brez tveganja
• D) Pod lahko neomejeno raste in porabi vire vozlišča ter tako zruši sosednje storitve ✔

Pojasnilo: Pod brez omejitve virov lahko raste neomejeno, porabi vse vire vozlišča, na katerem se izvaja, in zruši sosednje storitve, na primer z uhajanjem pomnilnika. Zato je definiranje zahtev/omejitev osnova robustnosti.

9. Kako se izogniti "utrujenosti opozarjanja" pri spremljanju in nastavitvi alarma?

• A) Nastavite alarme za čim več metrik in ustvarite opozorila ob vsakem nihanju.
• B) Nastavite vse alarme na najvišjo stopnjo resnosti
• C) Sprožitev alarmov s trenutnimi vrednostmi brez nastavitve časa (za)
• D) Ohranjanje alarmov, usmerjenih k ukrepanju in ob pravi nujnosti, testiranje pragov s preteklimi podatki, združevanje nepotrebnih ✔

Opis: Vsak alarm mora biti izvedljiv in mora biti ustrezno nujen; Informacije, ki ne zahtevajo ukrepanja, so prikazane na tabli in nikogar ne zbudijo. Mejne vrednosti alarmov se testirajo glede na zgodovinske podatke sistema, nepotrebni/ponavljajoči alarmi pa se konsolidirajo. Tako se pravi alarm ne bo izgubil v hrupu.

10. Kateri je najboljši prednostni vrstni red med proizvodnim incidentom?

• A) Najprej poiščite natančen glavni vzrok in ga zmanjšajte šele, ko je vzrok jasen.
• B) Najprej napišite mrliško poročilo, nato se dotaknite storitve
• C) Najprej zmanjšajte (storitev obnovitve/obnovitve), analizo vzroka pa pustite za pozneje ✔
• D) Najprej poiščite osebo, odgovorno za incident, in jo prijavite

Pojasnilo: Zlato pravilo je 'najprej zmanjšaj, nato razišči'. Cilj je najprej obnoviti storitev ali jo povrniti na znano dobro različico (blažitev); Analiza temeljnega vzroka se opravi mirno, ko pritisk popusti. Čakanje na odkritje natančnega vzroka podaljša čas okrevanja (MTTR).

11. Kaj je glavni namen neoporečne posmrtne kulture?

• A) Identifikacija osebe, ki je naredila napako, in nalaganje odgovornosti nanjo
• B) Osredotočanje na sisteme in procese ter spodbujanje učenja; ✔ Učenje lekcij, ki preprečujejo ponavljanje namesto obtoževanja
• C) Nikoli ne poročajte o incidentu in poskrbite, da bo pozabljen
• D) Pisanje samo tehničnih podrobnosti in ne dodajanje predmetov, ki jih je mogoče izvesti

Pojasnilo: Blameless postmortem se osredotoča na vprašanje, 'kateri sistem in proces sta dovolila to napako', ne 'kdo jo je storil'. Ljudje odkrito delijo napako, če vedo, da ne bodo kaznovani; Skrita napaka se ponavlja. Poročilo ni poročilo o obtožbah, temveč učni dokument, poln elementov, usmerjenih k ukrepanju.

12. Kaj je najbolj logičen korak pri optimizaciji stroškov v oblaku (FinOps), preden preidete na zavezane popuste (Reserved/Savings Plan)?

• A) Najprej se zavežite čim dlje, o zapravljanju razmišljajte pozneje
• B) Najprej pospravite odpadke (prosto zapiranje, pravilna velikost), nato pa se zavežite k predani uporabi ✔
• C) Takoj premaknite vse vire v kapaciteto Spot
• D) Brisanje najdražjega artikla brez pregleda podatkov na računu

Pojasnilo: Odpadke je treba najprej očistiti (zapreti nedejavne vire, zmanjšati prevelike vire). V nasprotnem primeru boste zaklenili nepotrebno uporabo po znižani ceni za 1-3 leta. Pravilna velikost in čiščenje v mirovanju ne zahtevata nobenih obveznosti in sta skoraj brez tveganja.

13. Kateri je najpomembnejši varnostni ukrep, če ima skript, ki ga predlaga AI, vrstico 'rm -rf "$DIR"/'?

• A) Zagon skripta neposredno v produktu brez branja bo pospešil
• B) Dodajte set -euo pipefail in prazen nadzor spremenljivke ter poskusite najprej s suhim tekom ✔
• C) Zadostuje skrajšanje imena spremenljivke
• D) Uporaba rm -rf --force namesto rm reši težavo

Pojasnilo: Če je $DIR prazen, lahko ta stavek poskuša izbrisati korenski imenik. Če se ustavite pri nedefinirani spremenljivki z 'set -u' in preverite, ali spremenljivka ni prazna, preden jo izbrišete (npr. [ -n "$DIR" ] || izhod 1), se izognete katastrofi. Poleg tega je treba destruktivne operacije najprej poskusiti s suhim tekom.

14. Kaj je prva stvar, ki jo morate storiti, če ključ za dostop do oblaka pomotoma uhaja v javno skladišče?

• A) Takoj prekličite in obnovite (rotirajte) ključ; Samo brisanje ni dovolj ✔
• B) Samo izbrišite datoteko iz pomnilnika in ključ je varen
• C) Ne naredi ničesar, ker tega nihče ni videl
• D) Nastavitev zasebnega shrambe odpravi potrebo po obračanju ključa

Pojasnilo: Razkrito skrivnost je treba takoj preklicati in rotirati. Samo brisanje datoteke ni dovolj, ker skrivnost ostane v zgodovini Git, javna skladišča pa v nekaj sekundah pregledajo roboti. Po preklicu/vračilu se učinek oceni in doda skrivni skener, da se prepreči ponovitev.

15. Kateri od naslednjih pristopov zmanjša tveganje pri izdaji nove različice Prod?

• A) Dajanje nove različice vsem uporabnikom hkrati (big-bang) in brez priprave načrta za povrnitev
• B) Uvedba se šteje za končano takoj, ko se prikaže »zeleno«, brez izvajanja dodatnega preverjanja
• C) Uporaba nadzorovane strategije, kot je kanarček/modro-zelena/funkcijska zastavica, že pripravljen načrt za povrnitev nazaj in dimni test + spremljanje metrike po uvedbi ✔
• D) Preizkušanje kritičnih poslovnih poti v celoti prepustiti umetni inteligenci in jih sploh ne določati.

Pojasnilo: strategije nadzorovane izdaje (začetek z majhnim odstotkom s kanarčkom, takojšnja vrnitev nazaj z modro-zeleno, ločevanje uvajanja od izdaje z zastavico funkcije) omejujejo tveganje. Poleg tega sta bistvena jasen načrt za povrnitev pred uvedbo in spremljanje zlatega signala s testiranjem dima po uvedbi; "videti zeleno" ne pomeni, da deluje.