Verifikacija proizvoda, strategije izdavanja i tijek rada AI od kraja do kraja

Dobici:

• Razumijevanje strategija puštanja u promet koje smanjuju rizik (plavo-zelena, kanarinac, značajka) i discipline verifikacije proizvoda (provjera zdravlja, test dima, praćenje zlatnog signala)
• Sposobnost implementacije navike pripreme jasnog plana vraćanja prije implementacije i provjere kritičnih poslovnih puteva nakon implementacije
• Sposobnost kombiniranja svih dijelova naučenih tijekom modula u end-to-end tijek rada podržan AI i primjene načela 'AI proizvodi, ljudi provjeravaju i jamče za' na svakom koraku

Cijeli ovaj modul tekao je prema jednoj točki: sigurnoj isporuci koda i infrastrukture u proizvodnju (okruženje uživo koje koriste stvarni kupci). Sada smo na najkritičnijoj i najstresnijoj karici u lancu: dobivanje promjene uživo i provjera radi li tamo. Pogreška ovdje nije apstraktna - ona izravno pogađa klijenta, prihod i ugled. Zato zreli timovi ne kreću u proizvodnju "nadajući se", već sa strategijama kontroliranog puštanja i sustavnom provjerom.

U ovoj završnoj jedinici kombiniramo dvije stvari: (1) metode izdavanja koje smanjuju rizik (kanarinac, plavo-zelena, značajka zastavice) i disciplinu provjere proizvoda; (2) kako se svaki dio koji smo naučili tijekom modula – CI/CD, IaC, spremnik, nadzor, incident, trošak, skripta, sigurnost – spaja u jedan end-to-end tijek rada koji pokreće AI. Ponovimo početni citat posljednji put: AI generira i ubrzava nacrte na svakom koraku; Ali vi ste taj koji pritisne gumb "Snimam ovo uživo" i jamči za ishod.

Strategije oslobađanja koje smanjuju rizik

Guranje promjene svim korisnicima u isto vrijeme je najrizičniji način. Zrele metode:

• Plavo-zelena implementacija: Održavaju se dva identična okruženja — "plavo" (uživo) i "zeleno" (nova verzija). Nova verzija je pripremljena i testirana u zelenoj boji, a zatim se promet iznenada prebacuje na zelenu. Ako postoji problem, promet se odmah vraća na plavo. Brzo vraćanje je njegova najveća prednost.
• Canary implementacija: nova verzija se prvo izdaje malom postotku korisnika (npr. 5%); Ako su mjerni podaci dobri, postupno povećavajte do 100%. Problem utječe na mali dio korisnika, a ne na cijelog korisnika.
• Oznaka značajke: Nova značajka ulazi u kod, ali je blokirana zastavom; Otvara se određenim korisnicima na zahtjev. Postoji razlika između postavljanja i "otpuštanja"; Ako postoji problem, oznaka se isključuje bez vraćanja koda.

Savjet: Najbrža sigurnosna mreža je imati spremno vraćanje prije svake implementacije. "Ako nešto pođe po zlu, kako se mogu vratiti na staru verziju u 60 sekundi?" Ako nema jasnog odgovora na pitanje, niste spremni izvršiti tu implementaciju.

Provjera proizvoda: posao ne završava kada završi implementacija

Samo zato što implementacija izgleda "zeleno" ne znači da funkcionira. Sustavna provjera:

1. Zdravstvene provjere: Je li usluga u funkciji, reagira li /healthz?
2. Dimni testovi: radi li nekoliko najkritičnijih korisničkih putova (prijava, plaćanje, pretraživanje) doista? Automatski i brz.
3. Pazite na zlatne signale: stopa pogreške nakon postavljanja, latencija, je li promet normalan? (Četiri signala na jedinici 6.)
4. Proširujte postupno: pogledajte mjerne podatke u svakom koraku dok povećavate Canary postotak.
5. Prozor za promatranje: Pažljivo promatrajte neko vrijeme (npr. 30 minuta) nakon postavljanja; Podmukli problemi nisu odmah vidljivi.

Oprez: AI može proizvesti popis dimnih testova ili verifikacija, ali vaš je posao odrediti koji su korisnički putovi "kritični". AI daje opći popis; Samo vi znate da se vaš tijek plaćanja, put koji najviše donosi prihod, mora testirati.

Usporedba strategija izdavanja

strategija

Glavna prednost

Trošak/složenost

najprikladniji

Plavo-zelena

Instant rollback

Dva okruženja = 2x resursa

Ako je brzo pronalaženje kritično

kanarinac

Ograničava utjecaj na mali komad

Potrebno upravljanje prometom

Ogromna baza korisnika

FeatureFlag

Odvaja implementaciju od izdanja

Dug upravljanja zastavom

Postupno/ciljano otvaranje

Tekuće ažuriranje

Jednostavan, pristupačan resursima

sporo vraćanje unazad

Jednostavne usluge

End-to-end tijek rada koji pokreće AI

Kombinirajmo sada cijeli modul u jedan tijek. Recimo da objavljujete novu mikroservis. AI proizvodi nacrte u svakom koraku; provjeravate na svakom koraku:

1. Kod i spremnik (Jedinica 4): AI proizvodi optimiziranu, sigurnu Dockerfile; Vi provjerite tajnost i veličinu.
2. CI/CD (Jedinica 2): piše AI ​​test-build-deploy cjevovod; Sužavate dopuštenja i provjeravate tajne reference.
3. Infrastruktura (Jedinica 3): Definira potrebne resurse pomoću AI Terraforma; Čitate izlaz plana i ne tražite neočekivana brisanja.
4. Orkestracija (jedinica 5): AI proizvodi Kubernetes manifeste; provjerite ograničenje resursa, sondu i RBAC.
5. Sigurnost (Jedinica 10): daje prioritet rezultatima AI skeniranja; Prvo zgrabite one koje možete iskoristiti.
6. Nadzor (Jedinica 6): AI generira pravila alarma i nadzornu ploču; Pragove testirate svojim prošlim podacima.
7. Izdanje i provjera valjanosti (ova jedinica): ocrtava AI dimni test i plan povratka; pokreneš Canary, gledaš metriku, pritisneš gumb.
8. Ako se incident dogodi (Jedinica 7): AI generira hipotezu i posmrtnu skicu; Provjeravate i učite lekcije.
9. Trošak (jedinica 8): AI prati rasipanje novih resursa; Vi donosite prave odluke o veličini.

Na svakom koraku, zajedničko pravilo ostaje nepromijenjeno: AI proizvodi i ubrzava, ljudi provjeravaju i jamče. Ovo je suština modula.

tri mini kućišta

Slučaj 1 — kanarinac je ograničio katastrofu na 5%. Tim je dao novu verziju za 5% korisnika s Canary. Nadzorna ploča koju je AI proizvela odmah je pokazala da je stopa pogreške skočila na 8% u ovom dijelu. Tim ga je vratio bez povećanja na 100%; Problem je zahvatio samo 5% korisnika, i to na nekoliko minuta. Da je došlo do implementacije velikog praska, svi bi kupci bili pogođeni.

Slučaj 2 — dimni test uhvatio je stazu koja nedostaje. AI je ponudio set za ispitivanje dima, ali nije imao tok "plaćanja". Inženjer je to dodao, znajući da je najkritičniji tok prihoda plaćanje. Testiranje nakon implementacije pokvarilo se odmah na koraku naplate — ključ treće strane je istekao. Provjera je uhvatila tihi gubitak prihoda u roku od nekoliko minuta.

Slučaj 3 — spreman povratak spremljen za 90 sekundi. Tim koji je instalirao plavo-zelenu prenio je novu verziju na zelenu; Nakon 2 minute kašnjenje se udvostručilo. Promet su u 90 sekundi zaplavili unaprijed pripremljenom povratnicom. Pronašli su temeljni uzrok (spor upit u novoj verziji) ne pod pritiskom, nego smireno. Spremna staza povratka učinila je prekid gotovo nevidljivim.

Četiri predloška za kopiranje

1) Odabir strategije izdavanja:

Promovirati ću sljedeću uslugu: [USLUGA/KONTEKST: broj korisnika, tolerancija ispada, infrastruktura]. Koju preporučate između plavo-zelene, kanarinčeve i značajne zastave? Usporedite prednosti, troškove i brzinu vraćanja svakog od njih u ovom kontekstu. Dajte prijedlog, ali navedite da ću ja donijeti konačnu odluku.

2) Ispitivanje dimom/potvrdni popis:

Napraviti nacrt dimnog testa i verifikacijski popis za [USLUGU] koji ću pokrenuti nakon implementacije: provjera stanja, najkritičnije korisničke staze, koje metrike trebam pratiti koliko minuta? Pretpostavimo da ću označiti najkritičnije poslovne putove i ostaviti to polje praznim.

3) Plan vraćanja:

Koristim [DEPLOY METHOD]. Napišite mi jasan plan vraćanja: kojom naredbom/korakom se vraćam na staru verziju, koliko dugo to traje, koji su rizici samog vraćanja (npr. migracija baze podataka ne može se vratiti), što trebam provjeriti prije vraćanja?

4) Kontrolni popis za izdanje od kraja do kraja:

Izradite kontrolnu listu pripreme od kraja do kraja za puštanje u novi [SERVICE] projekt: sigurnost koda/slike, cjevovod, infrastrukturni plan, nadzor i alarmiranje, sigurnosno skeniranje, strategija izdanja, vraćanje i provjera. Provjerite svaku stavku pitanjem "Jesam li spreman?" Pretvorite to u pitanje.

Slab upit / Jak upit

Slabo: "Kako da ovo stavim u proizvod?"

Rezultat: bez konteksta; AI navodi opće korake implementacije, ne bavi se vašom tolerancijom na rizik, skalom korisnika i potrebom vraćanja.

Güçlü: "Producirat ću uslugu plaćanja s 10 milijuna korisnika, moja tolerancija na vrijeme prekida rada je vrlo niska. Preporučate li Canary ili Blue-Green, zašto? Koje kritične putove trebam testirati nakon implementacije, koje metrike trebam pratiti koliko minuta i kakav bi trebao biti plan vraćanja od 60 sekundi? Ja ću donijeti konačnu odluku."

Razlika: drugi prompt daje skalu, toleranciju i očekivano vraćanje; Zahtijeva strategiju + provjeru + poništavanje i odluku prepušta čovjeku.

Uobičajene greške

• Implementacija bez plana vraćanja. Ako nema povratka, svako raspoređivanje je kockanje.
• Raspoređivanje velikog praska. Davanje cijelom korisniku odjednom povećava rizik.
• Pod pretpostavkom "zeleno = radi". Usluga koja je prošla provjeru ispravnosti može se pokvariti na kritičnom putu.
• Misleći da kritične poslovne putove prepuštate umjetnoj inteligenciji. Morate označiti metode kao što je plaćanje.
• Ne prati se nakon postavljanja. Podmukli problemi ne pojavljuju se u prvoj minuti; potreban je prozor za promatranje.
• Misleći da je migracija baze podataka reverzibilna. Neke se promjene ne vraćaju; planiraju se zasebno.

Ukratko

Prijelaz na proizvodnju je najkritičnija karika u lancu i ne radi se "nadajući se", već kontroliranim strategijama: plavo-zelena omogućuje trenutno vraćanje, ograničavajući učinak kanarinca na mali dio, odvajajući implementaciju oznake značajke od izdanja. Posao nije gotov kada je raspoređivanje završeno; Bitna je sustavna provjera kroz zdravstvene preglede, testove na dim i praćenje zlatnog signala. AI generira i ubrzava nacrte na svakom koraku kroz cijeli modul — od Dockerfilea do cjevovoda, od Terraforma do pravila alarma, od postmortem do analize troškova. Ali ostaje nadležna osoba koja provjerava svaki korak, pritišće gumb za pokretanje i jamči za ishod. Ovo je zlatno pravilo end-to-end DevOps-a koji pokreće AI.

Zadatak aplikacije

Odaberite uslugu (stvarnu ili izmišljenu) za objavljivanje. (1) Odaberite strategiju koja odgovara vašem kontekstu s predloškom "Odabir strategije objavljivanja" i napišite zašto. (2) Generirajte verifikacijski popis s predloškom "Test dima / verifikacijski popis" i sami dodajte najkritičnije poslovne putove. (3) Pripremite plan vraćanja od 60 sekundi s predloškom "Plan vraćanja" i provjerite ima li u njemu nepovratnih koraka.

popis za provjeru

• [ ] Izabrao sam strategiju izdavanja (kanarinac/plavo-zelena/zastava) koja odgovara mom kontekstu.
• [ ] Imam jasan i brz plan povratka spreman prije implementacije.
• [ ] Sam sam dodao najkritičnije poslovne putove (npr. plaćanje) svojim Smoke testovima.
• [ ] Nakon postavljanja, pratim zlatne signale kroz prozor za promatranje.
• [ ] Također sam planirao nepovratne korake (migracija baze podataka, itd.).
• [ ] Provjeravao sam AI nacrt na svakom koraku; Odlučila sam ići uživo.

Modul ispit

1. Što je od sljedećeg najbolje pozicioniranje za DevOps i AI u oblaku?

• A) Umjetna inteligencija je pomoćnik i alat za podršku odlučivanju; Ljudi su odgovorni za ključne odluke koje utječu na proizvod ✔
• B) Umjetna inteligencija može dovršiti implementaciju proizvoda i tajnu rotaciju bez ljudskog odobrenja
• C) Umjetna inteligencija je korisna samo za pisanje dokumentacije, nema veze s infrastrukturom
• D) Revizija je nepotrebna jer umjetna inteligencija uvijek proizvodi pouzdanije naredbe od inženjera

Opis: To je pomoćnik i alat za podršku odlučivanju koji ubrzava tekstualno intenzivne zadatke kao što su cjevovod umjetne inteligencije, konfiguracija, skripta i dnevnik. Odgovornost za odluke koje utječu na vrijeme zastoja, novac i sigurnost, poput puštanja u proizvodnju, tajnog upravljanja i konačne primjene, ostaje na nadležnom inženjeru.

2. Koji je najtočniji izraz za disciplinu verifikacije prije implementacije DevOps naredbe ili konfiguracije koju je proizvela umjetna inteligencija?

• A) Ako rezultat izgleda glatko i pouzdano, može se pokrenuti izravno u prod
• B) Izlaz je siguran samo ako nema grešaka u sintaksi, nisu potrebne daljnje provjere
• C) Povežite izlaz s izvorom, isplanirajte/isprobajte i filtrirajte ga prema kontekstu vašeg sustava; zatim nanesite ✔
• D) Prvi pokušaj izravno u proizvodu i gledanje rezultata je najbrža provjera

Objašnjenje: Provjera u tri koraka je bitna: povezivanje izlaza s izvorom (je li naredba/zastavica zapravo u službenim dokumentima), pokretanje na suho (vidjeti što se događa s planom/--suhim radom) i prolazak kroz filter sustava (uklapa li se u svoj arhitektonski i sigurnosni kontekst). Tečnost ne znači točnost.

3. Koji je ispravan pristup kada pitate umjetnu inteligenciju o pogrešci ili problemu implementacije s .env datotekom koja sadrži pravu lozinku baze podataka?

• A) Maskirajte prave tajne pomoću <PLACEHOLDER>; dijeli samo maskiranu pogrešku i kontekst ✔
• B) Lijepljenje cijele .env datoteke kakva jest brže rješava problem
• C) Budući da su tajne već base64, sigurno je zalijepiti obične
• D) Lijepljenje lozinke je sigurno jer je umjetna inteligencija nikada ne pohranjuje

Opis: nikakve prave tajne nisu zalijepljene u AI prompt. Vrijednosti kao što su lozinke i tokeni maskirane su s <PLACEHOLDER>; dijeli se samo poruka o pogrešci i potreban kontekst. Ako je tajna već procurila, treba je odmah otkazati i rotirati.

4. Što je od sljedećeg ispravno upravljanje tajnama (lozinka, token) u CI/CD cjevovodu?

• A) Čuva se u tajnom repozitoriju platforme i poziva referencom (npr. ${{ secrets.X }}), nije napisana u običnom tekstu ✔
• B) Napisano u otvorenom tekstu u cjevovodu YAML radi praktičnosti
• C) Provjerava se pritiskom na echo i log na početku svakog posla.
• D) Ako se definira s najširim dopuštenjem (write-all), sigurnost se povećava

Objašnjenje: Tajne se ne pišu u YAML u običnom tekstu; Čuva se u tajnom repozitoriju platforme i poziva s referencama kao što je ${{ secrets.X }}. Osim toga, uz načelo najmanje ovlasti, dopuštenja tokena su sužena i tajni dnevnik se ne bilježi.

5. U upravljanju infrastrukturom s Terraformom, koji je najkritičniji korak poduzeti prije implementacije promjene uživo?

• A) Izravno pokretanje 'terraform apply'; plan je gubljenje vremena
• B) Sigurnosno kopiranje datoteke stanja u javno spremište
• C) Pokrenite 'terraform plan' i provjerite linije za uništavanje/zamjenu u izlazu, zatim primijenite ✔
• D) Deinstalirajte verziju dobavljača i osigurajte da najnovija verzija dolazi automatski

Objašnjenje: 'terraform plan' se mora pokrenuti prije 'terraform apply'. Plan pokazuje što dodati, što promijeniti, a posebno što izbrisati (uništiti), a da se ništa ne radi. Ako se vidi neočekivana linija za uništavanje ili zamjenu, primijeniti se ne bi trebalo.

6. Što to znači i što treba učiniti ako se linija '-/+ replace' za proizvodnu bazu podataka pojavi u izlazu plana Terraform?

• A) Izvor će se samo ažurirati na licu mjesta, nema rizika
• B) Resurs će biti izbrisan i ponovno kreiran; Postoji rizik od gubitka podataka, primjenu treba zaustaviti ako se ne očekuje ✔
• C) Dodavanje novog resursa, postojeća baza podataka nije zahvaćena
• D) Ovo je samo upozorenje, može se slobodno zanemariti

Objašnjenje: '-/+ zamijeni' znači da će resurs biti izbrisan i ponovno kreiran; Za bazu podataka to znači gubitak podataka. Ako se ne očekuje, primjenu treba zaustaviti, promjenu treba pretvoriti u sigurnu metodu ili nepromjenjivo polje ostaviti netaknuto.

7. Što je od sljedećeg točno za Dockerfile da bude spreman za proizvodnju u smislu njegove sigurnosti i veličine?

• A) Radi praktičnosti, ugradite tajnu u sliku pomoću ENV-a i pokrenite je kao root
• B) Uvijek koristite oznaku ':latest' i neka osnovna slika bude što je moguće veća
• C) Izrada u jednoj fazi i ostavljanje svih alata za izradu u konačnoj slici
• D) Neugrađivanje Tajne, rad s neovlaštenim KORISNIKOM, korištenje male i stabilne osnovne slike i višestupanjske izgradnje ✔

Opis: Slika spremna za proizvodnju: ne ugrađuje tajnu (ubacuje je tijekom izvođenja), radi s neovlaštenim KORISNIKOM umjesto s root-om, koristi malu osnovnu sliku s verzijama (slim/alpine, ne :latest) i smanjena je s višestupanjskom nadogradnjom. Prije objavljivanja također se skenira radi otkrivanja ranjivosti.

8. Koji je najvažniji rizik nedefiniranja ograničenja resursa za implementaciju u Kubernetesu?

• A) Pod nikada ne počinje jer je ograničenje obavezno polje
• B) Na nadzornoj ploči pojavljuje se samo upozorenje, to ne utječe na rad
• C) Kubernetes automatski provodi sigurne zadane granice, bez rizika
• D) Pod može neograničeno rasti i trošiti resurse čvora, čime se ruše susjedne usluge ✔

Objašnjenje: Pod koji nema ograničenje resursa može neograničeno rasti, potrošiti sve resurse čvora na kojem radi i srušiti susjedne usluge, na primjer, s curenjem memorije. Zato je definiranje zahtjeva/ograničenja osnova robusnosti.

9. Kako izbjeći 'zamor od upozorenja' u nadzoru i postavljanju alarma?

• A) Postavite alarme na što je moguće više mjernih podataka i generirajte upozorenja sa svakom fluktuacijom.
• B) Postavite sve alarme na najvišu razinu ozbiljnosti
• C) Pokretanje alarma s trenutnim vrijednostima bez postavljanja vremena (za)
• D) Održavanje alarma orijentiranih na akciju i u pravoj hitnosti, testiranje pragova s povijesnim podacima, spajanje nepotrebnih ✔

Opis: svaki alarm mora biti djelotvoran i odgovarajuće hitnosti; Informacije koje ne zahtijevaju akciju prikazane su na ploči, nikoga ne probude. Pragovi alarma se testiraju u odnosu na povijesne podatke sustava, a nepotrebni/ponavljajući alarmi se konsolidiraju. Tako se pravi alarm neće izgubiti u buci.

10. Koji je najbolji redoslijed prioriteta tijekom proizvodnog incidenta?

• A) Prvo pronađite točan glavni uzrok i smanjite ga tek kada je uzrok jasan.
• B) Prvo napišite obdukciju, a zatim dodirnite uslugu
• C) Prvo smanjite (usluga vraćanja/vraćanja), ostavljajući analizu uzroka za kasnije ✔
• D) Prvo pronađite osobu odgovornu za incident i prijavite je

Objašnjenje: Zlatno pravilo je 'prvo smanji, kasnije istraži'. Cilj je prvo obnoviti uslugu ili je vratiti na poznatu dobru verziju (ublažavanje); Analiza temeljnog uzroka provodi se smireno nakon što pritisak popusti. Čekanje da se pronađe točan glavni uzrok povećava vrijeme oporavka (MTTR).

11. Koja je glavna svrha besprijekorne postmortem kulture?

• A) Identificiranje osobe koja je pogriješila i stavljanje odgovornosti na nju/nju
• B) Fokusiranje na sustave i procese i poticanje učenja; ✔ Učenje lekcija koje sprječavaju ponavljanje umjesto okrivljavanja
• C) Nikada nemojte prijaviti incident i pobrinite se da se zaboravi
• D) Pisanje samo tehničkih detalja bez dodavanja korisnih stavki

Objašnjenje: Besprijekorna obdukcija usredotočuje se na pitanje 'koji je sustav i proces dopustio ovu pogrešku', a ne 'tko je to učinio'. Ljudi otvoreno dijele pogrešku ako znaju da neće biti kažnjeni; Skrivena greška se ponavlja. Izvješće nije izvješće o optužbama, već dokument za učenje pun stavki usmjerenih na akciju.

12. U optimizaciji troškova u oblaku (FinOps), koji je najlogičniji korak poduzeti prije prelaska na obvezujuće popuste (rezervirano/uštedni plan)?

• A) Prvo preuzmite najdužu moguću obvezu, o rasipanju razmišljajte kasnije
• B) Najprije počistite otpad (zatvaranje u mirovanju, odgovarajuća veličina), a zatim se posvetite predanoj upotrebi ✔
• C) Odmah premjestite sve resurse u Spot kapacitet
• D) Brisanje najskupljeg artikla bez pregleda podataka računa

Objašnjenje: Otpad se prvo mora očistiti (zatvaranje neaktivnih resursa, smanjenje prevelikih resursa). U suprotnom ćete zaključati uzaludnu upotrebu po sniženoj cijeni na 1-3 godine. Pravo dimenzioniranje i čišćenje u praznom hodu ne zahtijevaju nikakve obveze i gotovo su bez rizika.

13. Koja je najvažnija sigurnosna mjera ako skripta koju predlaže AI ima redak 'rm -rf "$DIR"/'?

• A) Pokretanje skripte izravno u proizvodu bez čitanja će ubrzati
• B) Dodajte set -euo pipefail i praznu kontrolu varijable i prvo pokušajte s radom na suho ✔
• C) Dovoljno je skratiti naziv varijable
• D) Upotreba rm -rf --force umjesto rm rješava problem

Objašnjenje: Ako je $DIR prazan, ova izjava može pokušati obrisati korijenski direktorij. Zaustavljanjem na nedefiniranoj varijabli s 'set -u' i provjerom da varijabla nije prazna prije brisanja (npr. [ -n "$DIR" ] || izlaz 1) izbjegava se katastrofa. Osim toga, destruktivne operacije treba prvo pokušati s radom na suho.

14. Što je prva stvar koju treba učiniti ako ključ za pristup oblaku slučajno iscuri u javno spremište?

• A) Odmah poništiti i obnoviti (rotirati) ključ; Samo brisanje nije dovoljno ✔
• B) Samo izbrišite datoteku iz pohrane i ključ je siguran
• C) Ne radi ništa jer to nitko nije vidio
• D) Učiniti pohranu privatnom eliminira potrebu za rotiranjem ključa

Objašnjenje: Procurila tajna mora se odmah poništiti i rotirati. Samo brisanje datoteke nije dovoljno jer tajna ostaje u Git povijesti, a javna spremišta skeniraju botovi u roku od nekoliko sekundi. Nakon otkazivanja/vraćanja, učinak se procjenjuje i dodaje se tajni skener kako bi se spriječilo ponavljanje.

15. Koji od sljedećih pristupa minimizira rizik prilikom izdavanja nove verzije Prod-a?

• A) Davanje nove verzije svim korisnicima u isto vrijeme (veliki prasak) i ne pripremanje plana vraćanja
• B) Smatrajući da je implementacija završena čim se pojavi 'zeleno', bez provođenja dodatne provjere
• C) Korištenje kontrolirane strategije kao što je kanarinac/plavo-zelena/značajka zastave, gotov plan vraćanja i dimni test + praćenje metrike nakon postavljanja ✔
• D) U potpunosti prepustiti testiranje kritičnih poslovnih putova umjetnoj inteligenciji i uopće ih ne odrediti.

Objašnjenje: Strategije kontroliranog izdanja (počevši s malim postotkom s Canary, trenutnim vraćanjem na staro stanje s plavo-zelenom, odvajanjem postavljanja od izdanja s oznakom značajke) ograničavaju rizik. Osim toga, bitan je jasan plan vraćanja prije postavljanja i praćenje zlatnog signala s ispitivanjem dima nakon postavljanja; 'izgledati zeleno' ne znači da funkcionira.