Termékellenőrzés, kiadási stratégiák és teljes körű mesterséges intelligencia munkafolyamat

Nyereség:

• A kockázatcsökkentő kibocsátási stratégiák (kék-zöld, kanári, funkciójelző) és a termékellenőrzési fegyelem (egészségügyi ellenőrzés, füstteszt, aranyjelzés figyelése) megértése
• Képes megvalósítani azt a szokást, hogy egyértelmű visszaállítási tervet készítenek a bevezetés előtt, és a kritikus üzleti utak ellenőrzését a telepítés után
• Képes kombinálni a modulban tanult összes részt egy teljes körű mesterségesintelligencia által támogatott munkafolyamatban, és minden lépésben alkalmazni tudja az „AI termel, az emberek ellenőrzik és kezeskedik” elvét.

Ez az egész modul egy pont felé áramlott: a kód és az infrastruktúra biztonságos szállítása a termelésbe (a valódi ügyfelek által használt élő környezet). Most a lánc legkritikusabb és legstresszesebb láncszeménél vagyunk: a változás élőben történő megvalósítása és annak ellenőrzése, hogy ott valóban működik. A hiba itt nem elvont – közvetlenül érinti az ügyfelet, a bevételt és a hírnevet. Éppen ezért a kiforrott csapatok nem „reménykedéssel”, hanem ellenőrzött kiadási stratégiákkal és szisztematikus ellenőrzéssel kezdik a gyártást.

Ebben az utolsó részben két dolgot kombinálunk: (1) a kockázatot csökkentő kiadási módszereket (kanári, kék-zöld, jellemző zászló) és a prod ellenőrzés fegyelmét; (2) hogyan áll össze minden darab, amelyet a modul során megtanultunk – CI/CD, IaC, konténer, megfigyelés, incidens, költség, szkript, biztonság – egyetlen, mesterséges intelligencia által vezérelt, végpontok közötti munkafolyamattá. Ismételjük meg még utoljára a kezdeti idézetet: az AI minden lépésben generálja és felgyorsítja a piszkozatokat; De te vagy az, aki megnyomja az "Én élek" gombot, és kezeskedsz az eredményért.

Engedje el azokat a stratégiákat, amelyek csökkentik a kockázatot

A legkockázatosabb módja annak, hogy a változtatásokat egyszerre minden felhasználóhoz hozzák át. Érett módszerek:

• Kék-zöld üzembe helyezés: Két azonos környezetet tartanak fenn – „kék” (élő) és „zöld” (új verzió). Az új verziót zöld színben készítik el és tesztelik, majd hirtelen zöldre kapcsolják a forgalmat. Ha probléma adódik, a forgalom azonnal visszaáll kékre. A gyors visszaállítás a legnagyobb előnye.
• Canary Deployment: Az új verzió először a felhasználók kis százalékának (pl. 5%) jelenik meg; Ha a mutatók jók, fokozatosan növelje 100%-ra. A probléma a felhasználó egy kis részét érinti, nem az egész felhasználót.
• Feature Flag: Az új funkció beírja a kódot, de egy jelző blokkolja; Kérésre megnyílik bizonyos felhasználók számára. Különbséget kell tenni a telepítés és a „kiadás” között; Ha probléma adódik, a jelzőt kikapcsolja a kód visszagörgetése nélkül.

Tipp: A leggyorsabb biztonsági háló, ha minden üzembe helyezés előtt készen kell állnia a visszaállításra. "Ha valami elromlik, hogyan tudok 60 másodpercen belül visszaállítani a régi verziót?" Ha nincs egyértelmű válasz a kérdésre, akkor nem áll készen a telepítésre.

Termékellenőrzés: a munka nem ér véget a telepítés végén

Csak azért, mert egy telepítés "zöldnek" tűnik, még nem jelenti azt, hogy működik. Szisztematikus ellenőrzés:

1. Egészségügyi ellenőrzések: A szolgáltatás működik, a /healthz válaszol?
2. Füstteszt: A néhány legkritikusabb felhasználói útvonal (bejelentkezés, fizetés, keresés) valóban működik? Automatikus és gyors.
3. Figyeljen az aranyjelzésekre: Telepítés utáni hibaarány, késleltetés, normális a forgalom? (Négy jel a 6-os egységen.)
4. Bővítse fokozatosan: Nézze meg a mutatókat az egyes lépéseknél, ahogy növeli a Kanári százalékos arányt.
5. Megfigyelési ablak: Figyeljen szorosan egy ideig (pl. 30 percig) a telepítés után; Az alattomos problémák nem azonnal láthatók.

Figyelem: A mesterséges intelligencia elkészítheti a füsttesztek vagy ellenőrzések listáját, de az Ön feladata meghatározni, hogy mely felhasználói útvonalak „kritikusak”. Az AI általános listát ad; Csak Ön tudja, hogy a fizetési folyamatot, a legtöbb bevételt generáló útvonalat tesztelni kell.

Kiadási stratégiák összehasonlítása

Stratégia

Fő előnye

Költség/bonyolultság

legalkalmasabb

Kék-zöld

Azonnali visszaállítás

Két környezet = 2x erőforrás

Ha a gyors visszakeresés kritikus

kanári

A hatást kis szeletre korlátozza

Forgalomirányítás szükséges

Hatalmas felhasználói bázis

FeatureFlag

Elválasztja a telepítést a kiadástól

Zászlókezelés adóssága

Fokozatos/célzott nyitás

Gördülő frissítés

Egyszerű, erőforrás-barát

lassú visszatekerés

Egyszerű szolgáltatások

Végponttól végpontig mesterséges intelligencia alapú munkafolyamat

Most egyesítsük az egész modult egyetlen folyamatba. Tegyük fel, hogy egy új mikroszolgáltatást tesz közzé. Az AI minden lépésben piszkozatokat készít; minden lépésnél ellenőrizni kell:

1. Kód és konténer (4. egység): A mesterséges intelligencia optimalizált, biztonságos Dockerfile-t állít elő; Ellenőrized a nem titok és a méretet.
2. CI/CD (2. egység): Megírja az AI-teszt-felépítés-telepítés folyamatot; Leszűkíti a jogosultságokat és ellenőrzi a titkos hivatkozásokat.
3. Infrastruktúra (3. egység): Meghatározza a szükséges erőforrásokat az AI Terraform segítségével; Olvassa el a terv kimenetét, és nem keresi a váratlan törléseket.
4. Hangszerelés (5. egység): A mesterséges intelligencia Kubernetes manifeszteket készít; ellenőrzi az erőforráskorlátot, a vizsgálatot és az RBAC-t.
5. Biztonság (10. egység): Az AI-letapogatási kimenetek prioritása; Először a kihasználhatóakat ragadd meg.
6. Monitoring (6. egység): Az AI riasztási szabályokat és műszerfalat generál; A küszöbértékeket múltbeli adataival teszteli.
7. Kiadás és érvényesítés (ez az egység): felvázolja az AI-füstvizsgálatot és a visszaállítási tervet; elindítod a kanárit, nézd a mérőszámokat, nyomd meg a gombot.
8. Ha incidens történik (7. rész): az AI hipotézist és vágás utáni vázlatot generál; Ellenőrized és megtanulod a leckéket.
9. Költség (8. egység): A mesterséges intelligencia figyeli az új erőforrások pazarlását; Ön hozza meg a megfelelő méretezési döntéseket.

A közös szabály minden lépésnél változatlan marad: az MI termel és felgyorsít, az ember ellenőrzi és kezeskedik. Ez a modul lényege.

három mini tok

1. eset – Kanári 5%-ra korlátozta a katasztrófát. Egy csapat az új verziót a canary-t használók 5%-ának adta át. Az AI által készített műszerfal azonnal megmutatta, hogy a hibaarány 8%-ra ugrott ebben a szeletben. A csapat visszavette anélkül, hogy 100%-ra növelte volna; A probléma csak a felhasználók 5%-át érintette, és ez néhány percig tartott. Ha nagy robbanásszerű telepítés lenne, az minden ügyfelet érintené.

2. eset – füstteszt észlelte a hiányzó utat. Az AI felajánlott egy füstteszt-készletet, de nem volt „fizetési” folyamata. A mérnök hozzátette, tudva, hogy a legkritikusabb bevételi forrás a fizetés. A telepítés utáni teszt közvetlenül a fizetési lépésnél megszakadt – egy harmadik féltől származó kulcs lejárt. Az ellenőrzés perceken belül csendes bevételkiesést észlelt.

3. eset – a készenléti visszaállítás 90 másodperc alatt mentve. A kék-zöld színt telepítő csapat zöldre vitte az új verziót; 2 perc múlva a késés megduplázódott. 90 másodperc alatt kékessé változtatták a forgalmat az előre elkészített visszagurítással. Nem nyomás alatt találták meg a kiváltó okot (az új verzióban lassú lekérdezés), majd nyugodtan. A kész visszafutási útvonal szinte láthatatlanná tette a megszakítást.

Négy másolható sablon

1) Kiadási stratégia kiválasztása:

A következő szolgáltatást fogom nyújtani: [SZOLGÁLTATÁS/KONTEXT: felhasználók száma, kimaradástűrés, infrastruktúra]. Melyiket ajánlod a kék-zöld, a kanári és a különleges zászlók közül? Ebben az összefüggésben hasonlítsa össze mindegyik előnyeit, költségeit és visszaállítási sebességét. Adjon javaslatot, de jelezze, hogy a végső döntést én hozom meg.

2) Füstvizsgálat/ellenőrző lista:

Készítsen füstteszt- és ellenőrzőlista vázlatot a [SZOLGÁLTATÁS] számára, amelyet az üzembe helyezés után futtatok: állapotfelmérés, a legkritikusabb felhasználói útvonalak, mely mutatókat hány percig kell figyelnem? Tegyük fel, hogy megjelölöm a legkritikusabb üzleti utakat, és ezt a mezőt üresen hagyom.

3) Visszaállítási terv:

[DEPLOY METHOD]-t használok. Írj egy világos visszaállítási tervet: melyik paranccsal/lépéssel térjek vissza a régi verzióra, mennyi ideig tart, milyen kockázatai vannak magának a visszaállításnak (pl. az adatbázis-migrációt nem lehet visszaállítani), mit érdemes ellenőrizni a visszaállítás előtt?

4) Végpontok közötti kiadási ellenőrzőlista:

Készítsen egy teljes körű előkészítési ellenőrzőlistát az új [SERVICE] projekt kiadásához: kód-/képbiztonság, folyamat, infrastruktúraterv, figyelés és riasztás, biztonsági szkennelés, kiadási stratégia, visszaállítás és ellenőrzés. Jelölje be az egyes elemeket a „Készen állok?” kérdéssel. Változtasd kérdéssé.

Gyenge felszólítás / Erős felszólítás

Gyenge: "Hogyan tehetem ezt prod-ba?"

Eredmény: nincs kontextus; Az AI felsorolja az általános telepítési lépéseket, nem foglalkozik a kockázattűrő képességgel, a felhasználói méretekkel és a visszaállítási igényekkel.

Güçlü: "Egy 10 millió felhasználós fizetési szolgáltatást fogok gyártani, az állásidőtűrő képességem nagyon alacsony. A Canaryt vagy a Blue-Green-t ajánlod, miért? Mely kritikus útvonalakat teszteljem a telepítés után, mely mutatókat hány percig kell figyelnem, és milyen legyen a 60 másodperces visszaállítási terv? A végső döntést én hozom meg."

Különbség: a második prompt megadja a léptéket, a toleranciát és a visszaállítási elvárást; Stratégiát igényel + ellenőrzés + visszavonás, és a döntést az emberre bízza.

Gyakori hibák

• Üzembe helyezés visszaállítási terv nélkül. Ha nincs visszaút, minden bevetés szerencsejáték.
• Nagy robbanású bevetés. Ha az egész felhasználónak egyszerre adjuk át, az maximalizálja a kockázatot.
• Feltéve, hogy "zöld = működik". Az állapotfelmérésen átesett szolgáltatás megszakadhat a kritikus úton.
• Úgy gondolja, hogy a kritikus üzleti utakat az AI-ra hagyja. Meg kell jelölnie az olyan módokat, mint a fizetés.
• Nem figyel a telepítés után. Az alattomos problémák nem az első percben jelennek meg; megfigyelési ablak szükséges.
• Az adatbázis-migráció megfordítható. Egyes módosítások nem vonhatók vissza; külön tervezzük.

Összefoglalva

A prod-re váltás a lánc legkritikusabb láncszeme, és nem "reménykedéssel", hanem ellenőrzött stratégiákkal történik: a kék-zöld azonnali visszaállítást biztosít, egy kis szeletre korlátozva a kanári hatást, elválasztva a funkciójelző telepítését a kiadástól. A munka nem ért véget, amikor a telepítés befejeződött; Alapvető fontosságú a szisztematikus ellenőrzés az egészségügyi ellenőrzéseken, füstteszteken és aranyjelzéseken keresztül. A mesterséges intelligencia a teljes modul minden lépésében piszkozatokat generál és felgyorsít – a Dockerfile-tól a csővezetékig, a Terraformtól a riasztási szabályig, a postmortemtől a költségelemzésig. De az illetékes személy marad, aki minden egyes lépést ellenőriz, megnyomja a indítás gombot, és kezeskedik az eredményért. Ez a végpontok közötti AI-alapú DevOps aranyszabálya.

Pályázati feladat

Válasszon egy szolgáltatást (valódi vagy kitalált) a közzétételhez. (1) Válasszon ki egy stratégiát, amely illeszkedik az Ön környezetéhez a „Strategia kiválasztása” sablonnal, és írja meg, miért. (2) Készítsen ellenőrző listát a „Füstvizsgálat/ellenőrző lista” sablonnal, és adja hozzá a legkritikusabb üzleti utakat. (3) Készítsen egy 60 másodperces visszaállítási tervet a „Visszaállítási terv” sablonnal, és ellenőrizze, hogy vannak-e benne visszafordíthatatlan lépések.

ellenőrző lista

• [ ] A környezetemnek megfelelő kiadási stratégiát (kanári/kék-zöld/zászló) választottam.
• [ ] Világos és gyors visszaállítási tervem van készen a telepítés előtt.
• [ ] A legkritikusabb üzleti utakat (pl. fizetés) magam adtam hozzá a Smoke tesztekhez.
• [ ] Telepítés után megfigyelőablakon keresztül figyelem az aranyjeleket.
• [ ] Visszafordíthatatlan lépéseket is terveztem (adatbázis migráció stb.).
• [ ] Minden lépésnél ellenőriztem az AI tervrajzot; Úgy döntöttem, hogy élni fogok.

Modul vizsga

1. Az alábbiak közül melyik a legjobb elhelyezés a DevOps és a mesterséges intelligencia számára a felhőben?

• A) A mesterséges intelligencia egy asszisztens és döntéstámogató eszköz; Az emberek felelősek a terméket érintő kritikus döntésekért ✔
• B) A mesterséges intelligencia emberi jóváhagyás nélkül is véglegesítheti a prod telepítéseket és a titkos rotációt
• C) A mesterséges intelligencia csak dokumentáció írására hasznos, semmi köze az infrastruktúrához
• D) Az audit szükségtelen, mert a mesterséges intelligencia mindig megbízhatóbb parancsokat ad, mint a mérnök

Leírás: Ez egy asszisztens és döntéstámogató eszköz, amely felgyorsítja a szövegigényes feladatokat, például a mesterséges intelligencia folyamatát, a konfigurációt, a szkriptet és a naplót. Az állásidőt, pénzt és biztonságot érintő döntésekért – például a gyártás kiadásáért, a titkos kezelésért és a végső alkalmazásért – a felelősség továbbra is az illetékes mérnöké.

2. Melyik a legpontosabb kifejezés a DevOps parancs vagy mesterséges intelligencia által létrehozott konfiguráció végrehajtása előtti ellenőrzési fegyelemre?

• A) Ha a kimenet simának és magabiztosnak tűnik, akkor közvetlenül prod-ban futtatható
• B) A kimenet csak akkor biztonságos, ha nincsenek szintaktikai hibák, nincs szükség további ellenőrzésekre
• C) Csatlakoztassa a kimenetet a forráshoz, tervezze meg/száraz futást, és szűrje le a rendszer környezetének megfelelően; majd jelentkezz ✔
• D) A leggyorsabb ellenőrzés az első próbálkozás közvetlenül a prod-ban, és az eredmény figyelése

Magyarázat: A háromlépéses ellenőrzés elengedhetetlen: a kimenet csatlakoztatása a forráshoz (a parancs/jelző valóban benne van-e a hivatalos dokumentumokban), szárazon lefuttatva (megnézve, mi történik a tervvel/--dry-run), és átengedni a rendszerszűrőn (belefér-e az építészeti és biztonsági környezetbe). A folyékonyság nem jelent pontosságot.

3. Mi a helyes megközelítés, amikor egy valódi adatbázisjelszót tartalmazó .env fájl hibájáról vagy telepítési problémájáról kérdezzük meg a mesterséges intelligenciát?

• A) Takarja el a valódi titkokat a <PLACEHOLDER> segítségével; csak maszkolt hibát és kontextust ossza meg ✔
• B) A teljes .env fájl beillesztése gyorsabban megoldja a problémát
• C) Mivel a titkok már base64-esek, nyugodtan lehet simán beilleszteni
• D) A jelszó beillesztése biztonságos, mert a mesterséges intelligencia soha nem tárolja

Leírás: Az AI promptba nem illesztenek be valódi titkokat. Az olyan értékeket, mint a jelszavak és a tokenek, a <PLACEHOLDER> maszkolja; csak a hibaüzenet és a szükséges kontextus van megosztva. Ha a Titok már kiszivárgott, azonnal törölni kell és meg kell forgatni.

4. Az alábbiak közül melyik a helyes titkok (jelszó, token) kezelése egy CI/CD folyamatban?

• A) A platform titkos tárában tárolják, és hivatkozással hívják meg (pl. ${{ secrets.X }}), nem egyszerű szöveggel írva ✔
• B) Egyszerű szöveggel írva a YAML-be a kényelem kedvéért
• C) Ezt az echo és a log gomb megnyomásával ellenőrzi minden egyes feladat elején.
• D) Ha a legszélesebb körű engedéllyel (minden írása) van megadva, a biztonság megnő

Magyarázat: A titkok nem íródnak egyszerű szövegként a YAML-be; A platform titkos tárában tárolják, és olyan hivatkozásokkal hívják meg, mint például ${{ secrets.X }}. Ezenkívül a legkisebb jogosultság elve szerint a jogkivonat-engedélyek szűkítve vannak, és a titkos napló nem kerül rögzítésre.

5. A Terraform infrastruktúra-kezelésben mi a legkritikusabb lépés a változás éles végrehajtása előtt?

• A) A „terraform apply” közvetlen futtatása; a terv időpocsékolás
• B) Az állami fájl biztonsági mentése nyilvános adattárba
• C) Futtassa a 'terraform tervet' és ellenőrizze a megsemmisítés/csere sorokat a kimenetben, majd alkalmazza ✔
• D) Távolítsa el a Szolgáltató verzióját, és győződjön meg arról, hogy a legújabb verzió automatikusan érkezik

Magyarázat: a „terraform plan”-et a „terraform apply” előtt kell futtatni. A terv megmutatja, hogy mit kell hozzáadni, mit kell megváltoztatni, és főleg mit kell törölni (megsemmisíteni), anélkül, hogy bármit is tenne. Ha váratlan megsemmisítési vagy cserevonalat lát, az alkalmazást nem szabad alkalmazni.

6. Mit jelent és mit kell tenni, ha a termelési adatbázis '-/+ csere' sora megjelenik egy Terraform terv kimenetében?

• A) A forrást csak a helyszínen frissítik, nincs kockázat
• B) Az erőforrás törlődik és újra létrejön; Fennáll az adatvesztés veszélye, az alkalmazást le kell állítani, ha nem várható ✔
• C) Új erőforrás hozzáadása a meglévő adatbázist nem érinti
• D) Ez csak figyelmeztetés, nyugodtan figyelmen kívül hagyható

Magyarázat: „-/+ csere” azt jelenti, hogy az erőforrás törlésre és újra létrehozásra kerül; Egy adatbázis esetében ez adatvesztést jelent. Ha nem várható, az alkalmazást le kell állítani, a változtatást át kell alakítani biztonságos módszerré, vagy érintetlenül kell hagyni a megváltoztathatatlan mezőt.

7. Az alábbiak közül melyik igaz arra, hogy egy Dockerfile a biztonságát és méretét tekintve készen áll a gyártásra?

• A) A kényelem kedvéért ágyazza be a titkot a képbe az ENV segítségével, és futtassa rootként
• B) Mindig használja a ':latest' címkét, és tartsa az alapképet a lehető legnagyobb méretben
• C) Egylépcsős összeállítás, és az összes összeállítási eszközt a végső képen hagyja
• D) A Secret beágyazása, illetéktelen FELHASZNÁLÓVAL való munkavégzés, kisméretű és stabil alapkép és többlépcsős összeállítás használata ✔

Leírás: Gyártásra kész kép: nem ágyazza be a titkot (futás közben beilleszti), jogosulatlan USER-vel fut a root helyett, kicsi és verziószámmal ellátott alapképet használ (slim/alpine, nem :legújabb), és többlépcsős összeállítással kicsinyítik. A közzététel előtt a biztonsági réseket is megvizsgálja.

8. Mi a legfontosabb kockázata annak, ha nem határoz meg erőforrás-korlátokat a Kubernetes-bevezetéshez?

• A) A pod soha nem indul el, mert a limit kötelező mező
• B) Csak figyelmeztetés jelenik meg a felügyelő táblán, a működést ez nem érinti
• C) A Kubernetes automatikusan érvényesíti a biztonságos alapértelmezett korlátokat, kockázat nélkül
• D) A pod korlátlanul növekedhet és fogyaszthatja a csomópont erőforrásait, így összeomlik a szomszédos szolgáltatások ✔

Magyarázat: Az erőforrás-korlátozás nélküli Pod korlátlanul növekedhet, felhasználhatja a rajta futó csomópont összes erőforrását, és összeomolhat a szomszédos szolgáltatásokban, például memóriaszivárgás miatt. Éppen ezért a kérések/korlátok meghatározása a robusztusság alapja.

9. Hogyan lehet elkerülni a „riasztási fáradtságot” a felügyelet és a riasztás beállítása során?

• A) Állítsa be a riasztásokat a lehető legtöbb mérőszámra, és állítson elő riasztásokat minden ingadozás esetén.
• B) Állítsa az összes riasztást a legmagasabb súlyossági szintre
• C) Riasztások kiváltása pillanatnyi értékekkel idő beállítása nélkül (for)
• D) A riasztások cselekvésorientált és megfelelő sürgős tartása, küszöbértékek tesztelése előzményadatokkal, feleslegesek összevonása ✔

Leírás: Minden riasztásnak működőképesnek és megfelelő sürgősnek kell lennie; A cselekvést nem igénylő információk megjelennek a táblán, nem ébreszt fel senkit. A riasztási küszöbértékeket a rendszer a rendszer előzményadatai alapján tesztelik, és a szükségtelen/ismétlődő riasztásokat összevonják. Így az igazi riasztó nem vész el a zajban.

10. Mi a legjobb elsőbbségi sorrend egy gyártási esemény során?

• A) Először keresse meg a pontos kiváltó okot, és csak akkor csökkentse azt, ha az ok egyértelmű.
• B) Először írja meg a halotti jelentést, majd érintse meg a szolgáltatást
• C) Először csökkentse (visszaállítás/visszaállítás szolgáltatás), a kiváltó ok elemzését későbbre hagyva ✔
• D) Először keresse meg az esemény felelősét, és jelentse

Magyarázat: Az aranyszabály: „először csökkentsd, később vizsgáld meg”. A cél a szolgáltatás visszaállítása vagy visszaállítása egy ismert jó verzióra (enyhítése); A kiváltó ok elemzését a nyomás enyhülése után nyugodtan végezzük. A pontos kiváltó ok megtalálása megnöveli a felépülési időt (MTTR).

11. Mi a feddhetetlen postmortem kultúra fő célja?

• A) A hibát elkövető személy azonosítása és a felelősség hárítása
• B) A rendszerekre és folyamatokra való összpontosítás és a tanulás ösztönzése; ✔ Olyan leckék elsajátítása, amelyek megakadályozzák az ismétlést, nem pedig a hibáztatást
• C) Soha ne jelentse az esetet, és gondoskodjon arról, hogy elfelejtse
• D) Csak technikai részleteket írjon be, és ne adjon hozzá kereshető elemeket

Magyarázat: A Blameless postmortem arra a kérdésre összpontosít, hogy „melyik rendszer és folyamat engedte meg ezt a hibát”, nem pedig „ki követte el”. Az emberek nyíltan megosztják a hibát, ha tudják, hogy nem fogják megbüntetni; A rejtett hiba megismétlődik. A jelentés nem vádjelentés, hanem cselekvésorientált tételekkel teli tanulási dokumentum.

12. Felhőköltség-optimalizálás (FinOps) esetén mi a leglogikusabb lépés, mielőtt lekötendő kedvezményekre (Fenntartott/Megtakarítási terv) térne át?

• A) Először vállalja a lehető leghosszabb elkötelezettséget, később gondoljon a pazarlásra
• B) Először takarítsa el a hulladékot (üresjárati zárás, megfelelő méretezés), majd vállaljon kötelezettséget ✔
• C) Azonnal helyezzen át minden erőforrást a Spot kapacitásba
• D) A legdrágább tétel törlése a számlaadatok áttekintése nélkül

Magyarázat: A hulladékot először fel kell takarítani (a tétlen erőforrások bezárása, a túlméretezett erőforrások csökkentése). Ellenkező esetben 1-3 évre kedvezményes áron zároljátok az elpazarolt használatot. A megfelelő méretezés és az üresjárati tisztítás nem igényel elkötelezettséget, és szinte kockázatmentes.

13. Mi a legfontosabb biztonsági intézkedés, ha egy mesterséges intelligencia által javasolt szkriptben az 'rm -rf "$DIR"/' sor van?

• A) Ha a szkriptet közvetlenül prod-ban futtatja anélkül, hogy elolvasná, az felgyorsul
• B) Adja hozzá a set -euo pipefail és üres változó vezérlést, és először próbálja szárazon futtatni ✔
• C) Elegendő a változó nevének rövidítése
• D) Az rm -rf --force használata az rm helyett megoldja a problémát

Magyarázat: Ha a $DIR üres, ez az utasítás megpróbálhatja törölni a gyökérkönyvtárat. Ha megállunk a definiálatlan változónál a 'set -u' paranccsal, és ellenőrizzük, hogy a változó nem üres-e a törlés előtt (pl. [ -n "$DIR" ] || exit 1), elkerülhető a katasztrófa. Ezenkívül a pusztító műveleteket először szárazonfutással kell kipróbálni.

14. Mi a teendő először, ha egy felhőalapú hozzáférési kulcs véletlenül egy nyilvános adattárba szivárog?

• A) Azonnal törölje és újítsa meg (forgassa el) a kulcsot; A törlés önmagában nem elég ✔
• B) Csak törölje a fájlt a tárolóból, és a kulcs biztonságban van
• C) Nem csinál semmit, mert senki sem látta
• D) A tár priváttá tétele szükségtelenné teszi a kulcs elforgatását

Magyarázat: A kiszivárgott titkot azonnal törölni kell és el kell forgatni. A fájl törlése nem elég, mert a titok a Git előzményeiben marad, és a nyilvános adattárakat a botok másodperceken belül átvizsgálják. A törlés/visszaküldés után a rendszer kiértékeli a hatást, és egy titkos szkennert ad hozzá az ismétlődés megelőzése érdekében.

15. Az alábbi megközelítések közül melyik minimalizálja a kockázatot a Prod új verziójának kiadásakor?

• A) Az új verziót egyszerre adjuk át minden felhasználónak (nagy durranás), és nem készítünk visszaállítási tervet
• B) Ha úgy tekintjük, hogy a telepítés befejeződött, amint „zöldnek” tűnik, nem hajt végre további ellenőrzést
• C) Ellenőrzött stratégia alkalmazása, például kanári/kék-zöld/jellemző zászló, kész visszaállítási terv és füstteszt + metrikus megfigyelés a telepítés után ✔
• D) A kritikus üzleti utak tesztelését teljesen a mesterséges intelligenciára bízzuk, és egyáltalán nem határozzuk meg.

Magyarázat: Az ellenőrzött kiadási stratégiák (kezdve a Canary kis százalékával, az azonnali visszaállítás kék-zölddel, a telepítés és a kiadás elválasztása funkciójelzővel) korlátozzák a kockázatot. Ezen túlmenően elengedhetetlen egy világos visszaállítási terv a bevetés előtt, és a bevetés utáni füstteszttel végzett aranyjel-figyelés; A „zöldnek látszó” nem jelenti azt, hogy működik.