Verifikimi i produktit, Strategjitë e lëshimit dhe rrjedha e punës nga AI nga fundi në fund

Fitimet:

Kuptimi i strategjive të lëshimit të reduktimit të rrezikut (blu-jeshile, kanarina, flamuri tipar) dhe disiplina e verifikimit të produktit (kontrolli i shëndetit, testi i tymit, monitorimi i sinjalit të artë)
Aftësia për të zbatuar zakonin e përgatitjes së një plani të qartë rikthimi përpara vendosjes dhe verifikimit të shtigjeve kritike të biznesit pas vendosjes
Aftësia për të kombinuar të gjitha pjesët e mësuara përgjatë modulit në një rrjedhë pune të mbështetur nga AI dhe për të zbatuar parimin e 'AI prodhon, njerëzit verifikojnë dhe garantojnë' në çdo hap

I gjithë ky modul rrodhi drejt një pike: dërgimi i sigurt i kodit dhe infrastrukturës në prodhim (mjedisi i drejtpërdrejtë i përdorur nga klientët e vërtetë). Tani jemi në hallkën më kritike dhe stresuese të zinxhirit: marrja e një ndryshimi drejtpërdrejt dhe verifikimi se ai funksionon në të vërtetë atje. Një gabim këtu nuk është abstrakt - ai godet drejtpërdrejt klientin, të ardhurat dhe reputacionin. Kjo është arsyeja pse ekipet e pjekura shkojnë në prodhim jo duke "shpresuar", por me strategji të kontrolluara lëshimi dhe verifikim sistematik.

Në këtë njësi përfundimtare ne kombinojmë dy gjëra: (1) metodat e lëshimit që zvogëlojnë rrezikun (kanarina, blu-jeshile, flamuri tipar) dhe disiplina e verifikimit të prodhimit; (2) se si çdo pjesë që mësuam përgjatë modulit - CI/CD, IaC, kontejneri, monitorimi, incidenti, kostoja, skripti, siguria - bashkohet në një rrjedhë të vetme pune të fuqizuar nga AI. Le të përsërisim citatin fillestar për herë të fundit: AI gjeneron dhe përshpejton draftet në çdo hap; Por ju jeni ai që shtyp butonin "Unë po e marr këtë drejtpërdrejt" dhe garanton rezultatin.

Lëshoni strategji që zvogëlojnë rrezikun

Shtyrja e një ndryshimi për të gjithë përdoruesit në të njëjtën kohë është mënyra më e rrezikshme. Metodat e pjekura:

Vendosja blu-jeshile: Ruhen dy mjedise identike - "blu" (live) dhe "jeshile" (versioni i ri). Versioni i ri përgatitet dhe testohet me ngjyrë të gjelbër, më pas trafiku kalon papritur në jeshile. Nëse ka një problem, trafiku kthehet menjëherë në blu. Rikthimi i shpejtë është avantazhi i tij më i madh.
Vendosja e Canary: Versioni i ri lëshohet fillimisht për një përqindje të vogël përdoruesish (p.sh. 5%); Nëse matjet janë të mira, rriteni gradualisht në 100%. Një problem prek një pjesë të vogël të përdoruesit, jo të gjithë përdoruesin.
Flamuri i veçorive: Tipari i ri fut kodin por bllokohet nga një flamur; Ai hapet për përdorues të caktuar kur kërkohet. Ekziston një dallim midis vendosjes dhe "lëshimit"; Nëse ka një problem, flamuri fiket pa e rikthyer kodin.

Këshillë: Rrjeti më i shpejtë i sigurisë është të keni gati një rikthim përpara çdo vendosjeje. "Nëse diçka shkon keq, si mund të rikthehem në versionin e vjetër në 60 sekonda?" Nëse nuk ka përgjigje të qartë për pyetjen, nuk jeni gati ta bëni atë vendosje.

Verifikimi i produktit: puna nuk përfundon kur mbaron vendosja

Vetëm për shkak se një vendosje duket "e gjelbër" nuk do të thotë se po funksionon. Verifikimi sistematik:

Kontrollet shëndetësore: A është shërbimi, a po përgjigjet /healthz?
Testet e tymit: A funksionojnë vërtet disa shtigje të përdoruesve më kritike (hyrja, pagesa, kërkimi)? Automatik dhe i shpejtë.
Shiko për sinjale të arta: Shkalla e gabimit pas vendosjes, vonesa, a është trafiku normal? (Katër sinjale në njësinë 6.)
Zgjerojeni gradualisht: Shikoni matjet në çdo hap ndërsa rritni përqindjen e Kanareve.
Dritarja e vëzhgimit: Monitoroni nga afër për një periudhë kohe (p.sh. 30 minuta) pas vendosjes; Problemet tinëzare nuk janë të dukshme menjëherë.

Kujdes: AI mund të prodhojë një listë të testeve ose verifikimeve të tymit, por është detyra juaj të përcaktoni se cilat shtigje përdoruesish janë "kritike". AI jep një listë të përgjithshme; Vetëm ju e dini se fluksi juaj i pagesave, rruga juaj më e gjenerimit të të ardhurave, duhet të testohet.

Krahasimi i strategjive të lëshimit

Strategjia

Avantazhi kryesor

Kostoja/kompleksiteti

më e përshtatshme

Blu-jeshile

Rikthim i menjëhershëm

Dy mjedise = 2x burime

Nëse marrja e shpejtë është kritike

kanarinë

Kufizon ndikimin në feta të vogla

Kërkohet menaxhimi i trafikut

Baza e madhe e përdoruesve

Flamuri i veçorive

Ndan vendosjen nga lëshimi

Borxhi i menaxhimit të flamurit

Hapje graduale/e synuar

Përditësim i vazhdueshëm

E thjeshtë, miqësore me burimet

kthim i ngadalshëm

Shërbime të thjeshta

Rrjedha e punës e fuqizuar nga AI nga fundi në fund

Tani le të kombinojmë të gjithë modulin në një rrjedhë të vetme. Le të themi se po publikoni një mikroshërbim të ri. AI prodhon drafte në çdo hap; ju verifikoni në çdo hap:

Kodi dhe kontejneri (Njësia 4): AI prodhon një Dockerfile të optimizuar dhe të sigurt; Ju verifikoni mos-sekretin dhe madhësinë.
CI/CD (Njësia 2): Shkruan tubacionin e testimit-ndërtimit-vendosjes së AI; Ju ngushtoni lejet dhe kontrolloni referencat sekrete.
Infrastruktura (Njësia 3): Përcakton burimet e kërkuara me AI Terraform; Ju lexoni daljen e planit dhe nuk kërkoni fshirje të papritura.
Orkestrimi (Njësia 5): AI prodhon manifeste Kubernetes; ju verifikoni kufirin e burimit, sondën dhe RBAC.
Siguria (Njësia 10): I jep përparësi daljeve të skanimit të AI; Së pari ju kapni ato të shfrytëzueshme.
Monitorimi (Njësia 6): AI gjeneron rregullat e alarmit dhe panelin e kontrollit; Ju testoni pragjet me të dhënat tuaja të kaluara.
Lëshimi dhe vlefshmëria (kjo njësi): Përvijon testin e tymit të AI dhe planin e rikthimit; filloni kanarinë, shikoni matjet, shtypni butonin.
Nëse ndodh incidenti (Njësia 7): AI gjeneron hipoteza dhe skicë pas vdekjes; Ju verifikoni dhe mësoni mësimet.
Kostoja (Njësia 8): AI monitoron humbjen e burimeve të reja; Ju merrni vendimet e duhura për madhësinë.

Në çdo hap, rregulli i përbashkët mbetet konstant: AI prodhon dhe përshpejton, njeriu verifikon dhe garanton. Ky është thelbi i modulit.

tre mini kuti

Rasti 1 - kanarinë e kufizoi një fatkeqësi në 5%. Një ekip u dha versionin e ri 5% përdoruesve me kanarinë. Paneli i prodhuar nga AI tregoi menjëherë se shkalla e gabimit u hodh në 8% në këtë pjesë. Ekipi e mori përsëri pa e rritur në 100%; Problemi preku vetëm 5% të përdoruesve, dhe kjo ishte për disa minuta. Nëse do të kishte një dislokim të madh, të gjithë klientët do të prekeshin.

Rasti 2 - testi i tymit kapi rrugën që mungonte. AI ofroi një grup testimi të tymit, por nuk kishte një fluks "pagese". Inxhinieri e shtoi atë, duke ditur se fluksi më kritik i të ardhurave ishte pagesa. Testi pas vendosjes u prish pikërisht në hapin e arkës - një çelës i palës së tretë kishte skaduar. Verifikimi zbuloi një humbje të heshtur të të ardhurave brenda pak minutash.

Rasti 3 - rikthim i gatshëm i ruajtur në 90 sekonda. Një ekip që instaloi blu-jeshile e mori versionin e ri në jeshile; Pas 2 minutash vonesa u dyfishua. Ata e kthyen në blu trafikun në 90 sekonda me rikthimin që përgatitën paraprakisht. Ata gjetën shkakun rrënjësor (një pyetje e ngadaltë në versionin e ri) jo nën presion, pastaj me qetësi. Rruga e gatshme e rikthimit e bëri ndërprerjen pothuajse të padukshme.

Katër shabllone të kopjueshëm

1) Zgjedhja e strategjisë së lëshimit:

Unë do të prodhoj shërbimin e mëposhtëm: [SHËRBIMI/KONTEKSTI: numri i përdoruesve, toleranca ndaj ndërprerjeve, infrastruktura]. Cilin rekomandoni midis flamujve blu-jeshile, kanarinë dhe flamuj me tipare? Krahasoni avantazhet, kostot dhe shpejtësinë e rikthimit të secilit në këtë kontekst. Jepni një sugjerim, por deklaroni se unë do të marr vendimin përfundimtar.

2) Lista e testit / verifikimit të tymit:

Krijo një draft test tymi dhe listë verifikimi për [SERVICE] që do të ekzekutoj pas vendosjes: kontrolli shëndetësor, shtigjet më kritike të përdoruesit, cilat metrika duhet të monitoroj për sa minuta? Supozoni se unë do të shënoj shtigjet më kritike të biznesit dhe do ta lë atë fushë bosh.

3) Plani i rikthimit:

Unë përdor [METODA E SHPËRNDARJES]. Më shkruaj një plan të qartë rikthimi: me cilën komandë/hap mund të rikthehem në versionin e vjetër, sa kohë zgjat, cilat janë rreziqet e vetë rikthimit (p.sh. migrimi i bazës së të dhënave nuk mund të kthehet prapa), çfarë duhet të kontrolloj përpara rikthimit?

4) Lista kontrolluese e lëshimit nga fundi në fund:

Krijoni një listë kontrolli përgatitore nga fundi në fund për lëshimin në një projekt të ri [SHËRBIMI]: siguria e kodit/imazhit, tubacionit, plani i infrastrukturës, monitorimi dhe alarmi, skanimi i sigurisë, strategjia e lëshimit, rikthimi dhe verifikimi. Kontrolloni çdo artikull me pyetjen "A jam gati?" Kthejeni atë në një pyetje.

Prompt i dobët / Prompt i fortë

I dobët: "Si mund ta bëj këtë në prod?"

Rezultati: pa kontekst; AI rendit hapat e përgjithshëm të vendosjes, ajo nuk adreson tolerancën tuaj ndaj rrezikut, shkallën e përdoruesit dhe nevojën për rikthim.

Güçlü: "Unë do të krijoj një shërbim pagese me 10 milionë përdorues, toleranca ime për kohën e ndërprerjes është shumë e ulët. A rekomandoni Canary apo Blue-Green, pse? Cilat shtigje kritike duhet të testoj pas vendosjes, cilat metrikë duhet të monitoroj për sa minuta dhe si duhet të jetë një plan rikthimi 60 sekonda? Unë do të marr vendimin përfundimtar."

Diferenca: prompti i dytë jep shkallën, tolerancën dhe pritshmërinë e rikthimit; Kërkon strategji + verifikim + zhbërje dhe ia lë vendimin njeriut.

Gabimet e zakonshme

Vendosja pa një plan rikthimi. Nëse nuk ka rrugë kthimi, çdo vendosje është një kumar.
Shpërthimi i shpërthimit të madh. Dhënia e tij për të gjithë përdoruesit në të njëjtën kohë maksimizon rrezikun.
Duke supozuar "gjelbër = duke punuar". Shërbimi që ka kaluar kontrollin shëndetësor mund të prishet në rrugën kritike.
Duke menduar se po i lini shtigjet kritike të biznesit tek AI. Ju duhet të shënoni mënyra të tilla si pagesa.
Mos monitorimi pas vendosjes. Problemet tinëzare nuk shfaqen në minutën e parë; kërkohet dritarja e vëzhgimit.
Të menduarit migrimi i bazës së të dhënave është i kthyeshëm. Disa ndryshime nuk kthehen prapa; janë planifikuar veçmas.

Në përmbledhje

Shkuarja në nxitje është lidhja më kritike e zinxhirit dhe nuk bëhet duke "shpresuar", por me strategji të kontrolluara: blu-jeshile siguron rikthim të menjëhershëm, duke kufizuar efektin e kanarinës në një pjesë të vogël, duke ndarë vendosjen e flamurit të veçorive nga lëshimi. Puna nuk ka mbaruar kur të përfundojë vendosja; Verifikimi sistematik përmes kontrolleve shëndetësore, testeve të tymit dhe monitorimit të sinjalit të artë është thelbësor. AI gjeneron dhe përshpejton draftet në çdo hap në të gjithë modulin - nga Dockerfile te pipeline, nga Terraform te rregulli i alarmit, nga postmortem deri te analiza e kostos. Por mbetet personi kompetent që verifikon çdo hap, shtyp butonin e transmetimit live dhe garanton rezultatin. Ky është rregulli i artë i DevOps të fuqizuar nga AI nga fundi në fund.

Detyra e aplikimit

Zgjidhni një shërbim (real ose imagjinar) për të publikuar. (1) Zgjidhni një strategji që i përshtatet kontekstit tuaj me shabllonin "Përzgjedhja e strategjisë së lëshimit" dhe shkruani pse. (2) Keni një listë verifikimi të krijuar me shabllonin "Testi i tymit / lista e verifikimit" dhe shtoni vetë shtigjet më kritike të biznesit. (3) Përgatitni një plan rikthimi prej 60 sekondash me shabllonin "Plani i rikthimit" dhe kontrolloni nëse ka ndonjë hap të pakthyeshëm në të.

listë kontrolli

[ ] Zgjodha një strategji lëshimi (kanari/blu-jeshile/flamur) që i përshtatet kontekstit tim.
[ ] Unë kam një plan të qartë dhe të shpejtë rikthimi gati përpara vendosjes.
[ ] I shtova vetë shtigjet më kritike të biznesit (p.sh. pagesa) në testet e mia të tymit.
[ ] Pas vendosjes, unë monitoroj sinjalet e arta përmes një dritareje vëzhgimi.
[ ] Kam planifikuar gjithashtu hapa të pakthyeshëm (migrim i bazës së të dhënave, etj.).
[ ] Kam verifikuar planin e AI në çdo hap; Mora vendimin të shkoja live.

Provimi i Modulit

1. Cili nga sa vijon është pozicionimi më i mirë për DevOps dhe AI në cloud?

A) Inteligjenca artificiale është një asistent dhe mjet mbështetës vendimesh; Njerëzit janë përgjegjës për vendimet kritike që ndikojnë në produktin ✔
B) Inteligjenca artificiale mund të finalizojë dislokimet e nxitjeve dhe rrotullimin sekret pa miratimin e njeriut
C) Inteligjenca artificiale është e dobishme vetëm për shkrimin e dokumentacionit, nuk ka lidhje me infrastrukturën
D) Auditimi është i panevojshëm sepse inteligjenca artificiale prodhon gjithmonë komanda më të besueshme se inxhinieri

Përshkrimi: Është një asistent dhe mjet për mbështetjen e vendimeve që përshpejton detyrat me tekst intensiv si tubacioni i inteligjencës artificiale, konfigurimi, skripti dhe regjistri. Përgjegjësia për vendimet që ndikojnë në kohëzgjatjen e ndërprerjes, paratë dhe sigurinë, si lëshimi i prodhimit, menaxhimi sekret dhe aplikimi përfundimtar, i mbetet inxhinierit kompetent.

2. Cila është shprehja më e saktë për disiplinën e verifikimit përpara zbatimit të një komande ose konfigurimi DevOps të prodhuar nga inteligjenca artificiale?

A) Nëse prodhimi duket i qetë dhe i sigurt, ai mund të ekzekutohet drejtpërdrejt në prod
B) Prodhimi është i sigurt vetëm nëse nuk ka gabime sintaksore, nuk kërkohen kontrolle të mëtejshme
C) Lidhni daljen me burimin, planifikoni/drejtoni dhe filtrojeni atë me kontekstin e sistemit tuaj; pastaj aplikoni ✔
D) Të bësh provën e parë direkt në prod dhe të shikosh rezultatin është verifikimi më i shpejtë

Shpjegim: Verifikimi me tre hapa është thelbësor: lidhja e daljes me burimin (është komanda/flamuri në të vërtetë në dokumentet zyrtare), ekzekutimi i tij i thatë (duke parë se çfarë ndodh me planin/--dry-run) dhe kalimi i tij përmes filtrit të sistemit (a përshtatet në kontekstin e tij arkitektonik dhe të sigurisë). Rrjedhshmëria nuk do të thotë saktësi.

3. Cila është qasja e saktë kur pyet inteligjencën artificiale për një gabim ose problem të vendosjes me një skedar .env që përmban një fjalëkalim të vërtetë të bazës së të dhënave?

A) maskoni sekretet e vërteta me <PLACEHOLDER>; Ndani vetëm gabimin dhe kontekstin e maskuar ✔
B) Ngjitja e të gjithë skedarit .env siç është e zgjidh problemin më shpejt
C) Meqenëse sekretet janë tashmë bazë64, është e sigurt që të ngjisni thjeshtë
D) Ngjitja e fjalëkalimit është e sigurt sepse inteligjenca artificiale nuk e ruan kurrë atë

Përshkrimi: Asnjë sekret i vërtetë nuk është ngjitur në kërkesën e AI. Vlerat të tilla si fjalëkalimet dhe shenjat maskohen me <PLACEHOLDER>; ndahen vetëm mesazhi i gabimit dhe konteksti i nevojshëm. Nëse Sekreti tashmë është zbuluar, ai duhet të anulohet dhe të ndërrohet menjëherë.

4. Cila nga sa vijon është menaxhimi i saktë i sekreteve (fjalëkalimi, token) në një tubacion CI/CD?

A) Ruhet në depon e fshehtë të platformës dhe thirret me referencë (p.sh. ${{ sekretet.X }}), jo i shkruar në tekst të thjeshtë ✔
B) Shkruar në tekst të thjeshtë në tubacionin YAML për lehtësi
C) Verifikohet duke shtypur echo dhe log në fillim të çdo pune.
D) Nëse përcaktohet me lejen më të gjerë (shkruani të gjitha), siguria rritet

Shpjegim: Sekretet nuk i shkruhen YAML në tekst të thjeshtë; Ai mbahet në depon e fshehtë të platformës dhe thirret me referenca të tilla si ${{ secrets.X }}. Për më tepër, me parimin e autoritetit më të vogël, lejet e shenjave ngushtohen dhe regjistri sekret nuk regjistrohet.

5. Në menaxhimin e infrastrukturës me Terraform, cili është hapi më kritik që duhet ndërmarrë përpara se të zbatohet një ndryshim drejtpërdrejt?

A) Drejtimi i drejtpërdrejtë i 'terraform application'; plani është humbje kohe
B) Rezervimi i skedarit shtetëror në një depo publike
C) Ekzekutoni 'terraform plan' dhe kontrolloni linjat e shkatërrimit/zëvendësimit në dalje, më pas aplikoni ✔
D) Çinstaloni versionin Provider dhe sigurohuni që versioni më i ri të vijë automatikisht

Shpjegim: 'terraform plan' duhet të ekzekutohet përpara 'terraform application'. Plani tregon se çfarë të shtoni, çfarë të ndryshoni, dhe veçanërisht çfarë të fshini (shkatërroni), pa bërë asgjë. Nëse shihet një linjë e papritur e shkatërrimit ose zëvendësimit, aplikimi nuk duhet të zbatohet.

6. Çfarë do të thotë dhe çfarë duhet bërë nëse linja '-/+ zëvendëso' për bazën e të dhënave të prodhimit shfaqet në një dalje të planit Terraform?

A) Burimi thjesht do të përditësohet në vend, nuk ka asnjë rrezik
B) Burimi do të fshihet dhe rikrijohet; Ekziston rreziku i humbjes së të dhënave, aplikimi duhet të ndërpritet nëse nuk pritet ✔
C) Shtimi i një burimi të ri, baza e të dhënave ekzistuese nuk ndikohet
D) Ky është vetëm një paralajmërim, mund të injorohet me siguri

Shpjegim: '-/+ zëvendëso' do të thotë se burimi do të fshihet dhe rikrijohet; Për një bazë të dhënash, kjo do të thotë humbje e të dhënave. Nëse nuk pritet, aplikimi duhet të ndërpritet, ndryshimi duhet të konvertohet në një metodë të sigurt ose fusha e pandryshueshme duhet të lihet e paprekur.

7. Cila nga sa vijon është e vërtetë që një Dockerfile të jetë gati për prodhim për sa i përket sigurisë dhe madhësisë së tij?

A) Për lehtësi, futni sekretin në imazh me ENV dhe ekzekutoni atë si rrënjë
B) Përdorni gjithmonë etiketën ':më e fundit' dhe mbajeni imazhin bazë sa më të madh që të jetë e mundur
C) Ndërtimi me një fazë dhe lënia e të gjitha mjeteve të ndërtimit në imazhin përfundimtar
D) Mos përfshirja e sekretit, puna me USER të paautorizuar, duke përdorur imazhin bazë të vogël dhe të qëndrueshëm dhe ndërtimin me shumë faza ✔

Përshkrimi: Një imazh i gatshëm për prodhim: nuk e fut sekretin (e injekton atë në kohën e ekzekutimit), funksionon me një USER të paautorizuar në vend të rrënjës, përdor një imazh bazë të vogël dhe të versionuar (i hollë/alpin, jo më i fundit) dhe zvogëlohet me një ndërtim me shumë faza. Gjithashtu skanohet për dobësi përpara publikimit.

8. Cili është rreziku më i rëndësishëm i mospërcaktimit të kufijve të burimeve për një vendosje në Kubernetes?

A) Pod nuk fillon kurrë sepse kufiri është një fushë e detyrueshme
B) Vetëm një paralajmërim shfaqet në tabelën e monitorimit, funksionimi nuk ndikohet
C) Kubernetes zbaton automatikisht kufijtë e sigurt të paracaktimit, pa rrezik
D) pod mund të rritet pa kufi dhe të konsumojë burimet e nyjës, duke prishur kështu shërbimet fqinje ✔

Shpjegim: Një Pod që nuk ka kufi burimesh mund të rritet pa kufi, të konsumojë të gjitha burimet e nyjes ku po funksionon dhe të prishë shërbimet fqinje, për shembull, me një rrjedhje memorie. Kjo është arsyeja pse përcaktimi i kërkesave/kufizimeve është baza e qëndrueshmërisë.

9. Si të shmangni 'lodhjen e alarmit' në monitorimin dhe vendosjen e alarmit?

A) Vendosni alarmet në sa më shumë metrikë të jetë e mundur dhe gjeneroni alarme me çdo luhatje.
B) Vendosni të gjithë alarmet në nivelin më të lartë të ashpërsisë
C) Aktivizimi i alarmeve me vlera të menjëhershme pa vendosur një kohë (për)
D) Mbajtja e alarmeve të orientuara drejt veprimeve dhe me urgjencën e duhur, testimi i pragjeve me të dhëna historike, bashkimi i atyre të panevojshme ✔

Përshkrimi: Çdo alarm duhet të jetë veprues dhe i urgjencës së duhur; Informacioni që nuk kërkon veprim shfaqet në tabelë, nuk zgjon askënd. Pragjet e alarmit testohen kundrejt të dhënave historike të sistemit dhe alarmet e panevojshme/përsëritëse janë konsoliduar. Në këtë mënyrë alarmi i vërtetë nuk do të humbasë në zhurmë.

10. Cili është urdhri më i mirë i prioritetit gjatë një incidenti prodhimi?

A) Së pari gjeni shkakun e saktë rrënjësor dhe zvogëlojeni atë vetëm kur shkaku është i qartë.
B) Fillimisht shkruani raportin pas vdekjes, më pas prekni shërbimin
C) Redukto fillimisht (shërbimin e restaurimit/rivendosjes), duke e lënë analizën e shkakut rrënjësor për më vonë ✔
D) Së pari gjeni personin përgjegjës për incidentin dhe raportoni atë

Shpjegim: Rregulli i artë është 'zvogëlo fillimisht, heto më vonë'. Qëllimi është që fillimisht të rivendosni shërbimin ose ta ktheni atë në një version të mirë të njohur (zbutur); Analiza e shkakut rrënjësor bëhet me qetësi pasi presioni ulet. Pritja për të gjetur shkakun e saktë rrënjësor rrit kohën e rikuperimit (MTTR).

11. Cili është qëllimi kryesor i kulturës së pafajshme pas vdekjes?

A) Identifikimi i personit që ka bërë gabimin dhe ngarkimi i përgjegjësisë mbi të
B) Përqendrimi në sisteme dhe procese dhe inkurajimi i të nxënit; ✔ Mësoni mësime që parandalojnë përsëritjen dhe jo fajësimin
C) Asnjëherë mos e raportoni incidentin dhe sigurohuni që ai të harrohet
D) Shkrimi i vetëm detajeve teknike dhe jo shtimi i artikujve të veprimit

Shpjegim: Pas vdekjes së pafajshme fokusohet në pyetjen 'cili sistem dhe proces e lejoi këtë gabim', jo 'kush e bëri atë'. Njerëzit e ndajnë gabimin hapur nëse e dinë se nuk do të ndëshkohen; Gabimi i fshehur përsëritet. Raporti nuk është një raport akuze, por një dokument mësimor plot me artikuj të orientuar drejt veprimit.

12. Në optimizimin e kostos së cloud (FinOps), cili është hapi më logjik që duhet ndërmarrë përpara se të kaloni në zbritjet e kryera (Plani i Rezervuar/Kursimeve)?

A) Merr fillimisht angazhimin më të gjatë të mundshëm, mendo për mbeturinat më vonë
B) Së pari, pastroni mbeturinat (mbyllja në punë, madhësia e duhur), më pas angazhohuni për përdorim të përkushtuar ✔
C) Zhvendosni menjëherë të gjitha burimet në kapacitetin Spot
D) Fshirja e artikullit më të shtrenjtë pa rishikuar të dhënat e faturës

Shpjegim: Mbetjet duhet të pastrohen së pari (mbyllja e burimeve të papuna, reduktimi i burimeve të mëdha). Përndryshe, ju do të bllokoni përdorimin e humbur me një çmim të zbritur për 1-3 vjet. Pastrimi me përmasa të drejta dhe në boshe nuk kërkon angazhim dhe është afër pa rrezik.

13. Cila është masa më e rëndësishme e sigurisë nëse një skript i sugjeruar nga AI ka linjën 'rm -rf "$DIR"/'?

A) Ekzekutimi i skenarit direkt në prod pa e lexuar do të përshpejtohet
B) Shto set -euo pipefail dhe kontrollin e variablës boshe dhe provo me fillimin e funksionimit të thatë ✔
C) Mjafton shkurtimi i emrit të ndryshores
D) Përdorimi i rm -rf --force në vend të rm zgjidh problemin

Shpjegim: Nëse $DIR është bosh, kjo deklaratë mund të përpiqet të fshijë direktorinë rrënjë. Ndalimi te ndryshorja e papërcaktuar me 'set -u' dhe kontrollimi që ndryshorja nuk është bosh përpara se ta fshish atë (p.sh. [ -n "$DIR" ] || dalja 1) shmang katastrofën. Për më tepër, operacionet shkatërruese duhet të provohen fillimisht me drejtim të thatë.

14. Cila është gjëja e parë që duhet bërë nëse një çelës aksesi në renë kompjuterike rrjedh aksidentalisht në një depo publike?

A) Anuloni dhe rinovoni (rrotulloni) çelësin menjëherë; Nuk mjafton vetëm fshirja ✔
B) Thjesht fshini skedarin nga ruajtja dhe çelësi është i sigurt
C) Të mos bësh asgjë sepse askush nuk e pa
D) Bërja private e ruajtjes eliminon nevojën për të rrotulluar çelësin

Shpjegim: Sekreti i zbuluar duhet të anulohet dhe të rrotullohet menjëherë. Thjesht fshirja e skedarit nuk mjafton sepse sekreti mbetet në historinë e Git dhe depot publike skanohen nga bots brenda sekondave. Pas anulimit/kthimit, ndikimi vlerësohet dhe shtohet një skaner sekret për të parandaluar përsëritjen.

15. Cila nga qasjet e mëposhtme minimizon rrezikun kur lëshohet një version i ri i Prod?

A) Dhënia e versionit të ri për të gjithë përdoruesit në të njëjtën kohë (big-bang) dhe mos përgatitja e një plani rikthimi
B) Duke e konsideruar vendosjen e përfunduar sapo të shfaqet 'e gjelbër', duke mos kryer verifikime shtesë
C) Përdorimi i një strategjie të kontrolluar si p.sh. flamuri kanarin/blu-jeshile/flamuri me tipare, plani i gatshëm i rikthimit dhe testi i tymit + monitorimi metrik pas vendosjes ✔
D) Lënia e testimit të rrugëve kritike të biznesit tek inteligjenca artificiale dhe mos përcaktimi fare i tyre.

Shpjegim: Strategjitë e lëshimit të kontrolluar (duke filluar me një përqindje të vogël me kanarinë, rikthimi i menjëhershëm me blu-jeshile, duke ndarë vendosjen nga lëshimi me flamurin tipar) kufizojnë rrezikun. Përveç kësaj, një plan i qartë rikthimi përpara vendosjes dhe monitorimi i sinjalit të artë me testimin e tymit pas vendosjes janë thelbësore; 'dukja e gjelbër' nuk do të thotë se funksionon.