Verifikácia produktu, stratégie vydania a úplný pracovný postup AI

zisky:

• Pochopenie stratégií uvoľňovania znižujúcich riziko (modrá-zelená, kanáriková, vlajka funkcie) a disciplíny pri overovaní produktu (zdravotná kontrola, test dymu, monitorovanie zlatého signálu)
• Schopnosť implementovať zvyk pripraviť jasný plán návratu pred nasadením a overiť kritické obchodné cesty po nasadení
• Schopnosť kombinovať všetky časti naučené v rámci modulu v komplexnom pracovnom postupe podporovanom AI a aplikovať princíp „AI vyrába, ľudia overujú a ručia“ v každom kroku

Celý tento modul smeroval k jednému bodu: bezpečnému dodaniu kódu a infraštruktúry do výroby (živé prostredie používané skutočnými zákazníkmi). Teraz sme pri najkritickejšom a najstresujúcejšom článku v reťazci: dostať zmenu naživo a overiť si, že tam skutočne funguje. Chyba tu nie je abstraktná – zasahuje priamo zákazníka, príjmy a povesť. To je dôvod, prečo vyspelé tímy idú do výroby nie s „dúfaním“, ale so stratégiami riadeného uvoľňovania a systematickým overovaním.

V tejto záverečnej časti kombinujeme dve veci: (1) metódy uvoľnenia, ktoré znižujú riziko (kanárik, modrozelená, príznak funkcie) a disciplínu overovania produktov; (2) ako sa každý kúsok, ktorý sme sa naučili v rámci modulu – CI/CD, IaC, kontajner, monitorovanie, incident, náklady, skript, bezpečnosť – spája do jedného komplexného pracovného postupu poháňaného AI. Zopakujme si ešte poslednýkrát úvodný citát: AI generuje a urýchľuje koncepty na každom kroku; Ale vy ste ten, kto stlačí tlačidlo „Beriem to naživo“ a ručíte za výsledok.

Uvoľnite stratégie, ktoré znižujú riziko

Tlačiť zmenu všetkým používateľom súčasne je najrizikovejší spôsob. Vyspelé metódy:

• Modro-zelené nasadenie: Udržiavajú sa dve identické prostredia — „modré“ (živé) a „zelené“ (nová verzia). Nová verzia sa pripravuje a testuje v zelenej farbe, potom sa premávka zrazu prepne na zelenú. Ak sa vyskytne problém, premávka sa okamžite vráti na modrú. Rýchly návrat je jeho najväčšou výhodou.
• Canary Deployment: Nová verzia je najprv uvoľnená pre malé percento používateľov (napr. 5 %); Ak sú metriky dobré, postupne zvyšujte na 100 %. Problém ovplyvňuje malú časť používateľa, nie celého používateľa.
• Príznak funkcie: Nová funkcia zadá kód, ale je zablokovaná príznakom; Na požiadanie sa otvorí určitým používateľom. Existuje rozdiel medzi nasadením a „uvoľnením“; Ak sa vyskytne problém, príznak sa vypne bez vrátenia kódu späť.

Tip: Najrýchlejšou záchrannou sieťou je mať pripravený rollback pred každým nasadením. "Ak sa niečo pokazí, ako sa môžem vrátiť k starej verzii za 60 sekúnd?" Ak na túto otázku neexistuje jasná odpoveď, nie ste pripravení vykonať toto nasadenie.

Overenie produktu: práca nekončí, keď sa skončí nasadenie

To, že nasadenie vyzerá „zeleno“, ešte neznamená, že funguje. Systematické overovanie:

1. Zdravotné kontroly: Služba funguje, reaguje /healthz?
2. Dymové testy: Funguje skutočne niekoľko najdôležitejších ciest používateľa (prihlásenie, platba, vyhľadávanie)? Automaticky a rýchlo.
3. Sledujte zlaté signály: Chybovosť po nasadení, latencia, je prevádzka normálna? (Štyri signály na jednotke 6.)
4. Rozširujte postupne: Pozrite sa na metriky v každom kroku, keď zvyšujete percento Canary.
5. Pozorovacie okno: Pozorne sledujte určitý čas (napr. 30 minút) po nasadení; Zákerné problémy nie sú okamžite viditeľné.

Upozornenie: AI ​​môže vytvoriť zoznam dymových testov alebo overení, ale je vašou úlohou určiť, ktoré cesty používateľa sú „kritické“. AI poskytuje všeobecný zoznam; Len vy viete, že váš platobný tok, vaša cesta, ktorá najviac generuje výnosy, musíte otestovať.

Porovnanie stratégií vydania

Stratégia

Hlavná výhoda

Cena/zložitosť

najvhodnejšie

Modro-zelená

Okamžité vrátenie späť

Dve prostredia = 2x zdroje

Ak je rýchle vyhľadávanie kritické

kanárik

Obmedzuje vplyv na malý plátok

Vyžaduje sa riadenie dopravy

Obrovská užívateľská základňa

FeatureFlag

Oddeľuje nasadenie od vydania

Dlh správy vlajky

Postupné/cielené otváranie

Priebežná aktualizácia

Jednoduché, šetrné k zdrojom

pomalý návrat späť

Jednoduché služby

Kompletný pracovný postup založený na AI

Teraz spojme celý modul do jedného toku. Povedzme, že zverejňujete novú mikroslužbu. AI vytvára koncepty v každom kroku; v každom kroku overíte:

1. Kód a kontajner (jednotka 4): AI vytvára optimalizovaný a bezpečný súbor Dockerfile; Overíte netajnosť a veľkosť.
2. CI/CD (jednotka 2): Zapíše kanál testovania, zostavovania a nasadenia AI; Zúžite povolenia a skontrolujete tajné referencie.
3. Infrastructure (Unit 3): Definuje požadované zdroje pomocou AI Terraform; Čítate výstup plánu a nehľadáte neočakávané vymazania.
4. Orchestration (Unit 5): AI produkuje Kubernetes manifesty; overíte limit prostriedkov, sondu a RBAC.
5. Zabezpečenie (jednotka 10): Uprednostňuje výstupy skenovania AI; Najprv sa chopte zneužiteľných.
6. Monitorovanie (Jednotka 6): AI generuje pravidlá alarmu a dashboard; Prahové hodnoty otestujete pomocou svojich minulých údajov.
7. Release & validation (táto jednotka): Načrtáva AI ​​smoke test a plán návratu; spustíte canary, sledujte metriky, stlačte tlačidlo.
8. Ak dôjde k incidentu (jednotka 7): AI generuje hypotézu a posmrtný náčrt; Overíte si a naučíte sa lekcie.
9. Náklady (jednotka 8): AI monitoruje plytvanie novými zdrojmi; Robíte správne rozhodnutia o veľkosti.

Spoločné pravidlo zostáva na každom kroku konštantné: AI produkuje a urýchľuje, človek overuje a ručí. Toto je podstata modulu.

tri mini prípady

Prípad 1 – kanárik obmedzil katastrofu na 5 %. Tím dal novú verziu 5 % používateľov s kanárikom. Prístrojová doska, ktorú vytvorila AI, okamžite ukázala, že chybovosť v tomto plátku vyskočila na 8 %. Tím to vzal späť bez toho, aby to zvýšil na 100 %; Problém sa týkal iba 5 % používateľov a trvalo to niekoľko minút. Ak by došlo k nasadeniu veľkého tresku, postihlo by to všetkých zákazníkov.

Prípad 2 – dymový test zachytil chýbajúcu cestu. AI ponúkala súpravu na testovanie dymu, ale nemala „platobný“ tok. Inžinier to pridal, pretože vedel, že najdôležitejším zdrojom príjmov sú platby. Test po nasadení sa prerušil hneď pri pokladni – platnosť kľúča tretej strany vypršala. Overenie zachytilo tichú stratu výnosov v priebehu niekoľkých minút.

Prípad 3 – pripravený návrat uložený za 90 sekúnd. Tím, ktorý nainštaloval modro-zelenú, zmenil novú verziu na zelenú; Po 2 minútach sa meškanie zdvojnásobilo. Premávku zmenili na modrú za 90 sekúnd pomocou rollbacku, ktorý si vopred pripravili. Našli hlavnú príčinu (pomalý dopyt v novej verzii) nie pod tlakom, potom pokojne. Pripravená cesta návratu spôsobila, že prerušenie bolo takmer neviditeľné.

Štyri kopírovateľné šablóny

1) Výber stratégie vydania:

Poskytnem nasledujúcu službu: [SERVIS/KONTEXT: počet užívateľov, tolerancia výpadku, infraštruktúra]. Ktorú odporúčate medzi modro-zelené, kanárske a celovečerné vlajky? V tomto kontexte porovnajte výhody, náklady a rýchlosť návratu každého z nich. Dajte návrh, ale uveďte, že konečné rozhodnutie urobím ja.

2) Dymový test / overovací zoznam:

Vytvorte koncept testu dymu a overovacieho zoznamu pre [SERVICE], ktorý spustím po nasadení: kontrola stavu, najdôležitejšie cesty používateľa, ktoré metriky by som mal sledovať koľko minút? Predpokladajme, že označím najkritickejšie obchodné cesty a toto pole ponechám prázdne.

3) Plán vrátenia:

Používam [METÓDA ROZSAHU]. Napíšte mi jasný plán vrátenia: ktorým príkazom/krokom sa vrátim späť na starú verziu, ako dlho to trvá, aké sú riziká samotného vrátenia (napr. migrácia databázy sa nedá vrátiť späť), čo mám skontrolovať pred vrátením späť?

4) Kompletný kontrolný zoznam vydania:

Vytvorte komplexný kontrolný zoznam prípravy na uvoľnenie do nového projektu [SERVICE]: zabezpečenie kódu/obrazu, kanál, plán infraštruktúry, monitorovanie a alarmovanie, bezpečnostné skenovanie, stratégia uvoľnenia, vrátenie späť a overenie. Skontrolujte každú položku otázkou "Som pripravený?" Premeňte to na otázku.

Slabá výzva / Silná výzva

Slabý: "Ako to dostanem do produktu?"

Výsledok: bez kontextu; AI uvádza všeobecné kroky nasadenia, nerieši vašu toleranciu rizika, rozsah používateľov a potrebu vrátenia.

Güçlü: "Budem produkovať platobnú službu s 10 miliónmi používateľov, moja tolerancia prestojov je veľmi nízka. Odporúčate Canary alebo Blue-Green, prečo? Ktoré kritické cesty by som mal otestovať po nasadení, ktoré metriky by som mal sledovať koľko minút a aký by mal byť 60-sekundový plán návratu? Urobím konečné rozhodnutie."

Rozdiel: druhá výzva udáva rozsah, toleranciu a očakávané vrátenie; Vyžaduje stratégiu + overenie + zrušenie a rozhodnutie ponecháva na človeka.

Časté chyby

• Nasadenie bez plánu vrátenia. Ak niet cesty späť, každé nasadenie je hazard.
• Nasadenie veľkého tresku. Ak ho dáte celému používateľovi naraz, riziko sa maximalizuje.
• Za predpokladu, že „zelená = funguje“. Služba, ktorá prešla kontrolou stavu, môže byť narušená na kritickej ceste.
• Myslieť si, že kritické obchodné cesty prenechávate AI. Musíte označiť spôsoby, ako je platba.
• Nemonitorovanie po nasadení. Zákerné problémy sa neobjavia v prvej minúte; je potrebné pozorovacie okno.
• Myslenie na migráciu databázy je reverzibilné. Niektoré zmeny sa nevrátia späť; sa plánujú samostatne.

V súhrne

Prejsť na produkt je najkritickejším článkom v reťazci a neuskutočňuje sa v „dúfaní“, ale pomocou kontrolovaných stratégií: modro-zelená poskytuje okamžitý rollback, obmedzuje efekt kanárika na malý kúsok a oddeľuje nasadenie príznaku funkcie od vydania. Po dokončení nasadenia sa práca nekončí; Systematické overovanie prostredníctvom zdravotných kontrol, dymových testov a monitorovania zlatého signálu je nevyhnutné. Umelá inteligencia generuje a urýchľuje koncepty na každom kroku v celom module – od súboru Dockerfile po potrubie, od Terraformu po pravidlo alarmu, od postmortem po analýzu nákladov. Zostáva však kompetentná osoba, ktorá každý krok overí, stlačí tlačidlo spustiť naživo a ručí za výsledok. Toto je zlaté pravidlo komplexných DevOps poháňaných AI.

Aplikačná úloha

Vyberte službu (skutočnú alebo fiktívnu), ktorú chcete zverejniť. (1) Vyberte si stratégiu, ktorá vyhovuje vášmu kontextu, pomocou šablóny „Výber stratégie vydania“ a napíšte prečo. (2) Nechajte si vygenerovať overovací zoznam pomocou šablóny "Smoke test / overovací zoznam" a sami pridajte najdôležitejšie obchodné cesty. (3) Pripravte si 60-sekundový plán vrátenia so šablónou „Plán vrátenia“ a skontrolujte, či v ňom nie sú nejaké nezvratné kroky.

kontrolný zoznam

• [ ] Zvolil som stratégiu vydania (kanárik/modro-zelená/vlajka), ktorá vyhovuje môjmu kontextu.
• [ ] Pred nasadením mám pripravený jasný a rýchly plán návratu.
• [ ] Najkritickejšie obchodné cesty (napr. platba) som pridal do testov Smoke sám.
• [ ] Po nasadení sledujem zlaté signály cez pozorovacie okno.
• [ ] Plánoval som aj nezvratné kroky (migrácia databázy a pod.).
• [ ] Overil som plán AI na každom kroku; Rozhodol som sa ísť naživo.

Modulová skúška

1. Ktorá z nasledujúcich možností je najlepšie umiestnenie pre DevOps a AI v cloude?

• A) Umelá inteligencia je pomocníkom a nástrojom na podporu rozhodovania; Ľudia sú zodpovední za kritické rozhodnutia ovplyvňujúce produkt ✔
• B) Umelá inteligencia môže dokončiť rozmiestnenie produktov a tajnú rotáciu bez súhlasu človeka
• C) Umelá inteligencia je užitočná len na písanie dokumentácie, nemá nič spoločné s infraštruktúrou
• D) Audit je zbytočný, pretože umelá inteligencia vždy produkuje spoľahlivejšie príkazy ako inžinier

Popis: Ide o pomocný nástroj a nástroj na podporu rozhodovania, ktorý urýchľuje textovo náročné úlohy, ako sú kanály umelej inteligencie, konfigurácia, skript a denník. Zodpovednosť za rozhodnutia ovplyvňujúce prestoje, peniaze a bezpečnosť, ako je spustenie výroby, správa tajných informácií a konečná aplikácia, zostáva na kompetentnom inžinierovi.

2. Aký je najpresnejší výraz pre disciplínu overovania pred implementáciou príkazu alebo konfigurácie DevOps vytvorenej umelou inteligenciou?

• A) Ak výstup vyzerá hladko a spoľahlivo, môže sa spustiť priamo v produkte
• B) Výstup je bezpečný len vtedy, ak nie sú žiadne syntaktické chyby, nie sú potrebné žiadne ďalšie kontroly
• C) Pripojte výstup k zdroju, naplánujte/spustite ho nasucho a filtrujte ho podľa kontextu vášho systému; potom aplikujte ✔
• D) Urobiť prvý pokus priamo v produkte a sledovať výsledok je najrýchlejšie overenie

Vysvetlenie: Overenie v troch krokoch je nevyhnutné: pripojenie výstupu k zdroju (je to príkaz/príznak v skutočnosti v oficiálnych dokumentoch), jeho spustenie nasucho (pozrieť sa, čo sa stane s plánom/--dry-run) a prejsť cez systémový filter (zapadá do jeho architektonického a bezpečnostného kontextu). Plynulosť neznamená presnosť.

3. Aký je správny prístup, keď sa umelej inteligencie pýtate na chybu alebo problém s nasadením so súborom .env, ktorý obsahuje skutočné heslo databázy?

• A) Maskovanie skutočných tajomstiev pomocou <PLACEHOLDER>; zdieľať iba maskovanú chybu a kontext ✔
• B) Vloženie celého súboru .env tak, ako je, problém vyrieši rýchlejšie
• C) Keďže tajomstvá sú už base64, je bezpečné ich prilepiť ako obyčajné
• D) Vloženie hesla je bezpečné, pretože umelá inteligencia ho nikdy neuloží

Popis: Do výzvy AI nie sú vložené žiadne skutočné tajomstvá. Hodnoty, ako sú heslá a tokeny, sú maskované pomocou <PLACEHOLDER>; zdieľa sa iba chybové hlásenie a potrebný kontext. Ak už Tajomstvo uniklo, treba ho zrušiť a okamžite otočiť.

4. Ktorá z nasledujúcich možností je správna správa tajomstiev (heslo, token) v potrubí CI/CD?

• A) Uchováva sa v tajnom úložisku platformy a volá sa odkazom (napr. ${{ secrets.X }}), nie je napísaný ako obyčajný text ✔
• B) Napísané v otvorenom texte do kanála YAML pre pohodlie
• C) Overí sa stlačením tlačidla echo a log na začiatku každej úlohy.
• D) Ak je definované s najširším oprávnením (zapisovať všetko), bezpečnosť sa zvyšuje

Vysvetlenie: Tajomstvá sa nezapisujú do YAML vo forme obyčajného textu; Uchováva sa v tajnom úložisku platformy a volá sa s odkazmi ako ${{ secrets.X }}. Okrem toho, s princípom najmenšieho oprávnenia, oprávnenia tokenov sú zúžené a tajný protokol sa nezaznamenáva.

5. Aký je najdôležitejší krok v správe infraštruktúry s Terraformom pred realizáciou zmeny naživo?

• A) Spustenie „terraform apply“ priamo; plán je strata času
• B) Zálohovanie štátneho súboru na verejné úložisko
• C) Spustite „plán terraform“ a skontrolujte riadky zničenia/nahradenia vo výstupe, potom použite ✔
• D) Odinštalujte verziu poskytovateľa a uistite sa, že najnovšia verzia príde automaticky

Vysvetlenie: „Plán terraform“ musí byť spustený pred „Plánom terraform“. Plán ukazuje, čo pridať, čo zmeniť a najmä čo vymazať (zničiť), bez toho, aby ste niečo urobili. Ak sa objaví neočakávaná čiara zničenia alebo výmeny, aplikácia by sa nemala aplikovať.

6. Čo to znamená a čo treba urobiť, ak sa vo výstupe plánu Terraform objaví riadok „-/+ nahradiť“ pre databázu výroby?

• A) Zdroj bude len aktualizovaný na mieste, neexistuje žiadne riziko
• B) Zdroj bude vymazaný a znovu vytvorený; Existuje riziko straty údajov, aplikáciu treba zastaviť, ak sa neočakáva ✔
• C) Pridanie nového zdroja, existujúca databáza nie je ovplyvnená
• D) Toto je len varovanie, ktoré môžete pokojne ignorovať

Vysvetlenie: '-/+ nahradiť' znamená, že zdroj bude vymazaný a znovu vytvorený; Pre databázu to znamená stratu dát. Ak sa to neočakáva, aplikácia by sa mala zastaviť, zmena by sa mala previesť na bezpečnú metódu alebo by sa nemenné pole malo ponechať nedotknuté.

7. Čo z nasledujúceho platí pre Dockerfile, aby bol pripravený na produkciu z hľadiska bezpečnosti a veľkosti?

• A) Pre pohodlie vloženie tajomstva do obrazu pomocou ENV a jeho spustenie ako root
• B) Vždy používajte značku ':latest' a udržujte základný obrázok čo najväčší
• C) Jednostupňové zostavenie a ponechanie všetkých nástrojov na zostavenie vo finálnom obrázku
• D) Nevkladanie tajomstva, práca s neoprávneným POUŽÍVATEĽOM, používanie malého a stabilného základného obrazu a viacstupňového zostavenia ✔

Popis: Obraz pripravený na produkciu: nevkladá tajomstvo (vloží ho za behu), beží s neautorizovaným USER namiesto root, používa malý a verziovaný základný obraz (slim/alpine, nie :najnovší) a je zmenšený pomocou viacstupňového zostavenia. Pred zverejnením sa tiež kontroluje, či neobsahuje zraniteľné miesta.

8. Aké je najdôležitejšie riziko nedefinovania limitov zdrojov pre nasadenie v Kubernetes?

• A) Pod sa nikdy nespustí, pretože limit je povinné pole
• B) Na monitorovacej doske sa zobrazí iba varovanie, prevádzka nie je ovplyvnená
• C) Kubernetes automaticky presadzuje bezpečné predvolené limity, žiadne riziko
• D) Modul môže neobmedzene rásť a spotrebovať zdroje uzla, čím sa zrútia susedné služby ✔

Vysvetlenie: Pod, ktorý nemá žiadne obmedzenie prostriedkov, môže rásť neobmedzene, spotrebovať všetky prostriedky uzla, na ktorom beží, a zlyhať susedné služby, napríklad kvôli úniku pamäte. Preto je definovanie požiadaviek/limitov základom robustnosti.

9. Ako sa vyhnúť „únave z varovania“ pri monitorovaní a nastavovaní alarmu?

• A) Nastavte alarmy na čo najviac metrík a generujte upozornenia pri každom kolísaní.
• B) Nastavte všetky alarmy na najvyššiu úroveň závažnosti
• C) Spustenie alarmov s okamžitými hodnotami bez nastavenia času (pre)
• D) Udržiavanie alarmov orientovaných na akciu a v správnej naliehavosti, testovanie prahových hodnôt s historickými údajmi, zlučovanie nepotrebných ✔

Popis: Každý alarm musí byť použiteľný a musí mať správnu naliehavosť; Informácie, ktoré nevyžadujú akciu, sa zobrazujú na tabuli, nikoho to nezobudí. Prahové hodnoty alarmov sa testujú oproti historickým údajom systému a nepotrebné/opakujúce sa alarmy sa konsolidujú. Takto sa skutočný alarm nestratí v hluku.

10. Aká je najlepšia priorita objednávky počas výrobného incidentu?

• A) Najprv nájdite presnú hlavnú príčinu a znížte ju až vtedy, keď je príčina jasná.
• B) Najprv napíšte správu o postmorte a potom sa dotknite služby
• C) Najprv zredukujte (obnovte/obnovte službu), analýzu hlavnej príčiny nechajte na neskôr ✔
• D) Najprv nájdite osobu zodpovednú za incident a nahláste to

Vysvetlenie: Zlaté pravidlo znie „najskôr zredukujte, neskôr preskúmajte“. Cieľom je najprv obnoviť službu alebo ju vrátiť späť na známu-dobrú verziu (zmierniť); Analýza koreňovej príčiny sa robí pokojne po odznení tlaku. Čakanie na nájdenie presnej hlavnej príčiny predlžuje čas obnovy (MTTR).

11. Aký je hlavný účel bezúhonnej posmrtnej kultúry?

• A) Identifikácia osoby, ktorá urobila chybu, a uloženie zodpovednosti na ňu
• B) Zameranie sa na systémy a procesy a podpora učenia sa; ✔ Učte sa lekcie, ktoré bránia opakovaniu, a nie obviňovaniu
• C) Nikdy nenahlasujte incident a zabezpečte, aby sa naň zabudlo
• D) Písanie len technických detailov a nepridávanie akčných položiek

Vysvetlenie: Bezúhonná pitva sa zameriava na otázku „ktorý systém a proces umožnil túto chybu“, nie na otázku „kto to urobil“. Ľudia otvorene zdieľajú chybu, ak vedia, že nebudú potrestaní; Skrytá chyba sa opakuje. Správa nie je správa o obvinení, ale učebný dokument plný vecí zameraných na akciu.

12. Aký je najlogickejší krok pri optimalizácii nákladov na cloud (FinOps) pred prechodom na záväzné zľavy (plán rezervácií/úspor)?

• A) Najprv si vezmite čo najdlhší záväzok, na odpad myslite až neskôr
• B) Najprv vyčistite odpad (uzatváranie naprázdno, správne nastavenie veľkosti), potom sa zaviažte k záväzku ✔
• C) Okamžite presuňte všetky zdroje do kapacity Spot
• D) Vymazanie najdrahšej položky bez kontroly údajov faktúry

Vysvetlenie: Odpad musí byť najskôr vyčistený (zatvorenie nečinných zdrojov, zníženie nadrozmerných zdrojov). V opačnom prípade zablokujete premárnené použitie za zvýhodnenú cenu na 1-3 roky. Správna veľkosť a čistenie pri nečinnosti nevyžadujú žiadne záväzky a sú takmer bez rizika.

13. Aké je najdôležitejšie bezpečnostné opatrenie, ak má skript navrhnutý AI riadok 'rm -rf "$DIR"/'?

• A) Spustenie skriptu priamo v produkte bez jeho čítania sa urýchli
• B) Pridajte set -euo pipefail a vyprázdnite premennú kontrolu a vyskúšajte najskôr suchý chod ✔
• C) Postačí skrátenie názvu premennej
• D) Použitie rm -rf --force namiesto rm rieši problém

Vysvetlenie: Ak je $DIR prázdny, tento príkaz sa môže pokúsiť vymazať koreňový adresár. Zastavenie pri nedefinovanej premennej s 'set -u' a kontrola, či premenná nie je prázdna pred jej odstránením (napr. [ -n "$DIR" ] || exit 1) zabráni katastrofe. Okrem toho by sa deštruktívne operácie mali najskôr vyskúšať s chodom nasucho.

14. Čo treba urobiť ako prvé, ak prístupový kľúč cloudu omylom unikne do verejného úložiska?

• A) Okamžite zrušte a obnovte (otočte) kľúč; Samotné mazanie nestačí ✔
• B) Stačí odstrániť súbor z úložiska a kľúč je v bezpečí
• C) Nerobiť nič, pretože to nikto nevidel
• D) Nastavenie úložiska ako súkromného eliminuje potrebu otáčať kľúčom

Vysvetlenie: Uniknutý tajný kód musí byť okamžite zrušený a otočený. Len odstránenie súboru nestačí, pretože tajomstvo zostáva v histórii Git a verejné úložiská sú skenované robotmi v priebehu niekoľkých sekúnd. Po zrušení/vrátení sa dopad vyhodnotí a pridá sa tajný skener, aby sa zabránilo opakovaniu.

15. Ktorý z nasledujúcich prístupov minimalizuje riziko pri vydaní novej verzie Prod?

• A) Poskytnúť novú verziu všetkým používateľom súčasne (veľký tresk) a nepripravovať plán návratu
• B) Vzhľadom na to, že nasadenie je ukončené hneď, ako sa javí ako „zelené“, nevykonáva sa dodatočné overenie
• C) Použitie kontrolovanej stratégie, ako je kanáriková/modro-zelená/vlajka, pripravený plán návratu a dymový test + metrické monitorovanie po nasadení ✔
• D) Testovanie kritických obchodných ciest úplne ponechať na umelú inteligenciu a vôbec ich neurčovať.

Vysvetlenie: Stratégie riadeného uvoľnenia (začínajúc malým percentom s kanárikom, okamžitý návrat späť s modro-zelenou, oddeľujúce nasadenie od vydania príznakom funkcie) obmedzujú riziko. Okrem toho je nevyhnutný jasný plán návratu pred nasadením a monitorovanie zlatého signálu s testovaním dymu po nasadení; „vyzerať zeleno“ neznamená, že to funguje.