Tuotteiden vahvistus, julkaisustrategiat ja kokonaisvaltainen tekoälytyönkulku

Voitot:

• Riskejä vähentävien julkaisustrategioiden (sini-vihreä, kanarialintu, ominaisuuslippu) ja tuotteen varmistuskurin (terveystarkastus, savutesti, kultaisen signaalin seuranta) ymmärtäminen
• Kyky toteuttaa tapana laatia selkeä palautussuunnitelma ennen käyttöönottoa ja varmistaa kriittiset liiketoimintapolut käyttöönoton jälkeen
• Kyky yhdistää kaikki moduulin aikana opitut osat päästä päähän tekoälyn tukemaan työnkulkuun ja soveltaa periaatetta "AI tuottaa, ihmiset varmistavat ja takaavat" joka vaiheessa.

Tämä koko moduuli kulki kohti yhtä kohtaa: koodin ja infrastruktuurin turvallinen toimitus tuotantoon (oikeiden asiakkaiden käyttämä live-ympäristö). Nyt olemme ketjun kriittisimmässä ja stressaavimmassa lenkkeessä: saamme muutoksen livenä ja varmistamme, että se todella toimii siellä. Virhe ei ole abstrakti - se vaikuttaa suoraan asiakkaaseen, tuloihin ja maineeseen. Siksi kypsät tiimit eivät lähde tuotantoon "toivoamalla", vaan käyttämällä kontrolloituja julkaisustrategioita ja järjestelmällistä todentamista.

Tässä viimeisessä osiossa yhdistämme kaksi asiaa: (1) riskiä vähentävät julkaisumenetelmät (kanarian, sinivihreä, ominaisuuslippu) ja prod-todentamisen kurinalaisuuden; (2) kuinka jokainen moduulin aikana oppimamme osa – CI/CD, IaC, säiliö, valvonta, tapahtuma, kustannukset, komentosarja, tietoturva – yhdistyy yhdeksi tekoälyllä toimivaksi päästä päähän -työnkuluksi. Toistetaan alkuperäinen lainaus viimeisen kerran: AI luo ja nopeuttaa luonnoksia joka vaiheessa; Mutta sinä olet se, joka painaa "otan tämän livenä" -painiketta ja takaa tuloksen.

Vapauta strategioita, jotka vähentävät riskiä

Muutoksen työntäminen kaikille käyttäjille samanaikaisesti on riskialttein tapa. Aikuiset menetelmät:

• Sinivihreä käyttöönotto: Kaksi identtistä ympäristöä ylläpidetään - "sininen" (live) ja "vihreä" (uusi versio). Uusi versio valmistetaan ja testataan vihreänä, minkä jälkeen liikenne vaihtuu yhtäkkiä vihreäksi. Jos tulee ongelmia, liikenne palaa välittömästi siniseksi. Nopea palautus on sen suurin etu.
• Canary Deployment: Uusi versio julkaistaan ​​ensin pienelle prosenttiosuudelle käyttäjistä (esim. 5 %); Jos mittarit ovat hyvät, nosta asteittain 100 prosenttiin. Ongelma koskee vain pientä osaa käyttäjää, ei koko käyttäjää.
• Ominaisuuden lippu: Uusi ominaisuus syöttää koodin, mutta lippu estää sen; Se avataan tietyille käyttäjille pyydettäessä. Käyttöönoton ja "julkaisun" välillä on ero; Jos ongelma ilmenee, lippu sammutetaan ilman koodin peruuttamista.

Vinkki: Nopein turvaverkko on, että palautus on valmis ennen jokaista käyttöönottoa. "Jos jokin menee pieleen, kuinka voin palata vanhaan versioon 60 sekunnissa?" Jos kysymykseen ei ole selvää vastausta, et ole valmis toteuttamaan tätä käyttöönottoa.

Tuotantovarmennus: työ ei lopu, kun käyttöönotto päättyy

Se, että käyttöönotto näyttää "vihreältä", ei tarkoita, että se toimii. Systemaattinen tarkastus:

1. Terveystarkastukset: Onko palvelu käytössä, vastaako /healthz?
2. Savustestit: Toimivatko muutamat kriittisimmät käyttäjäpolut (kirjautuminen, maksu, haku) todella? Automaattinen ja nopea.
3. Varo kultaisia ​​signaaleja: käyttöönoton jälkeinen virheprosentti, latenssi, onko liikenne normaalia? (Neljä signaalia laitteessa 6.)
4. Laajenna asteittain: Tarkastele mittareita jokaisessa vaiheessa, kun lisäät Kanarian prosenttiosuutta.
5. Tarkkailuikkuna: Tarkkaile tarkasti jonkin aikaa (esim. 30 minuuttia) käyttöönoton jälkeen; Salakavalat ongelmat eivät näy heti.

Varoitus: Tekoäly voi tuottaa luettelon savutesteistä tai -tarkistuksista, mutta sinun tehtäväsi on määrittää, mitkä käyttäjäpolut ovat "kriittisiä". AI antaa yleisen luettelon; Vain sinä tiedät, että maksuvirtasi, eniten tuloja tuottava polkusi, on testattava.

Julkaisustrategioiden vertailu

strategia

Tärkein etu

Kustannukset/monimutkaisuus

sopivin

Sinivihreä

Välitön palautus

Kaksi ympäristöä = 2x resurssit

Jos nopea haku on kriittinen

kanarialainen

Rajoittaa vaikutuksen pieneen siivuun

Liikenteenhallinta vaaditaan

Valtava käyttäjäkunta

Ominaisuuslippu

Erottaa käyttöönoton julkaisusta

Lippuhallinnan velka

Asteittainen/kohdennettu avaaminen

Rullaava päivitys

Yksinkertainen, resurssiystävällinen

hidas palautus

Yksinkertaiset palvelut

Päästä päähän tekoälyllä toimiva työnkulku

Yhdistetään nyt koko moduuli yhdeksi virtaukseksi. Oletetaan, että julkaiset uuden mikropalvelun. AI tuottaa luonnoksia jokaisessa vaiheessa; vahvistat jokaisessa vaiheessa:

1. Koodi ja kontti (yksikkö 4): AI tuottaa optimoidun, suojatun Docker-tiedoston; Vahvistat salaisuuden ja koon.
2. CI/CD (yksikkö 2): Kirjoittaa AI-testaa-build-deploy-putkilinjan; Rajoitat käyttöoikeuksia ja tarkistat salaiset viittaukset.
3. Infrastruktuuri (yksikkö 3): Määrittää tarvittavat resurssit AI Terraformilla; Luet suunnitelman tulosten etkä etsi odottamattomia poistoja.
4. Orkestrointi (yksikkö 5): AI tuottaa Kubernetes-luetteloita; vahvistat resurssirajan, mittauksen ja RBAC:n.
5. Turvallisuus (yksikkö 10): Priorisoi AI-skannauslähdöt; Tartu ensin hyödynnettävissä oleviin.
6. Valvonta (yksikkö 6): AI luo hälytyssäännöt ja kojelaudan; Testaat kynnysarvoja aiemmilla tiedoillasi.
7. Vapautus ja validointi (tämä yksikkö): Esittelee tekoälyn savutestin ja palautussuunnitelman; aloitat kanarian, katso mittareita, paina nappia.
8. Jos tapahtuma tapahtuu (yksikkö 7): AI luo hypoteesin ja post mortem -luonnoksen; Vahvistat ja opit opetukset.
9. Kustannukset (yksikkö 8): AI valvoo uusien resurssien tuhlausta; Teet oikeankokoiset päätökset.

Joka vaiheessa yleinen sääntö pysyy vakiona: tekoäly tuottaa ja kiihdyttää, ihminen varmentaa ja takaa. Tämä on moduulin ydin.

kolme minilaukkua

Tapaus 1 – Kanarian saarna rajoitti katastrofin 5 prosenttiin. Tiimi antoi uuden version 5 %:lle kanarialaiskäyttäjistä. Tekoälyn tuottama kojelauta osoitti välittömästi, että virheprosentti hyppäsi 8 prosenttiin tässä siivussa. Tiimi otti sen takaisin nostamatta sitä 100 %:iin; Ongelma vaikutti vain 5 %:iin käyttäjistä, ja se kesti muutaman minuutin. Jos käyttöönotto tapahtuisi räjähdysmäisesti, se vaikuttaisi kaikkiin asiakkaisiin.

Tapaus 2 – savutesti havaitsi puuttuvan polun. Tekoäly tarjosi savutestisarjan, mutta sillä ei ollut "maksuvirtaa". Insinööri lisäsi sen tietäen, että kriittisin tulonlähde oli maksu. Käyttöönoton jälkeinen testi katkesi heti maksuvaiheessa – kolmannen osapuolen avain oli vanhentunut. Vahvistus havaitsi hiljaisen tulonmenetyksen muutamassa minuutissa.

Tapaus 3 – valmis palautus tallennettu 90 sekunnissa. Blue-greenin asentanut tiimi vei uuden version vihreäksi; 2 minuutin kuluttua viive tuplaantui. He muuttivat liikenteen siniseksi 90 sekunnissa etukäteen valmistelemillaan palautuksilla. He löysivät perimmäisen syyn (hidas kysely uudessa versiossa) ilman paineita, vaan rauhallisesti. Valmis paluupolku teki keskeytyksen lähes näkymättömäksi.

Neljä kopioitavaa mallia

1) Julkaisustrategian valinta:

Tuotan seuraavan palvelun: [PALVELU/KONTEKSTI: käyttäjien määrä, käyttökatkostoleranssi, infrastruktuuri]. Kumpaa suosittelet sinivihreän, kanarian ja erikoislippujen väliltä? Vertaa jokaisen etuja, kustannuksia ja palautusnopeutta tässä yhteydessä. Anna ehdotus, mutta sano, että minä teen lopullisen päätöksen.

2) Savustesti/vahvistuslista:

Luodaan [PALVELULLE] savutesti- ja vahvistusluetteloluonnos, jonka aion suorittaa käyttöönoton jälkeen: kuntotarkastus, kriittisimmät käyttäjäpolut, mitä mittareita minun pitäisi seurata kuinka monta minuuttia? Oletetaan, että merkitsen kriittisimmät liiketoimintapolut ja jätän kentän tyhjäksi.

3) Palautussuunnitelma:

Käytän [DEPLOY METHOD]. Kirjoita minulle selkeä palautussuunnitelma: millä komennolla/vaiheella palaan takaisin vanhaan versioon, kuinka kauan se kestää, mitkä ovat itse palautuksen riskit (esim. tietokannan siirtoa ei voi peruuttaa), mitä tulee tarkistaa ennen palautusta?

4) Päästä päähän -julkaisujen tarkistuslista:

Luo kattava valmistelun tarkistuslista uuteen [SERVICE]-projektiin julkaisemista varten: koodin/kuvan suojaus, putkisto, infrastruktuurisuunnitelma, valvonta ja hälytykset, suojausskannaus, julkaisustrategia, palautus ja vahvistus. Tarkista jokainen kohde kysymyksellä "Olenko valmis?" Muuta se kysymykseksi.

Heikko kehote / Vahva kehote

Heikko: "Kuinka saan tämän tuotantoon?"

Tulos: ei kontekstia; AI luettelee yleiset käyttöönottovaiheet, se ei ota huomioon riskinsietokykyäsi, käyttäjän laajuutta ja palautustarpeitasi.

Güçlü: "Tuotan maksupalvelun, jossa on 10 miljoonaa käyttäjää, seisokkien sietokykyni on erittäin alhainen. Suositteletko Canarya vai Blue-Greeniä, miksi? Mitä kriittisiä polkuja minun tulisi testata käyttöönoton jälkeen, mitä mittareita minun tulee seurata kuinka monta minuuttia ja millainen 60 sekunnin palautussuunnitelman pitäisi olla? Teen lopullisen päätöksen."

Ero: toinen kehote antaa mittakaavan, toleranssin ja palautusodotuksen; Se vaatii strategiaa + todentamista + kumoamista ja jättää päätöksen ihmisen tehtäväksi.

Yleisiä virheitä

• Käyttöönotto ilman palautussuunnitelmaa. Jos paluuta ei ole, jokainen käyttöönotto on uhkapeliä.
• Huikea käyttöönotto. Sen antaminen koko käyttäjälle kerralla maksimoi riskin.
• Olettaen "vihreä = toimiva". Terveystarkastuksen läpäissyt palvelu voi katketa ​​kriittisellä polulla.
• Ajattelet, että jätät kriittiset liiketoimintapolut tekoälylle. Sinun tulee merkitä maksutavat, kuten maksu.
• Ei valvontaa käyttöönoton jälkeen. Salakavalat ongelmat eivät ilmene ensimmäisessä minuutissa; tarkkailuikkuna vaaditaan.
• Ajatteleva tietokannan siirto on peruutettava. Joitakin muutoksia ei palauteta; suunnitellaan erikseen.

Yhteenvetona

Tuottoon siirtyminen on ketjun kriittisin lenkki, ja sitä ei tehdä "toivoamalla" vaan hallituilla strategioilla: sinivihreä tarjoaa välittömän palautuksen, rajoittaen kanariaefektin pieneen siivuun ja erottaen ominaisuuden lipun käyttöönoton julkaisusta. Työ ei ole ohi, kun käyttöönotto on valmis; Järjestelmällinen todentaminen terveystarkastuksilla, savutesteillä ja kultaisen signaalin seurannalla on välttämätöntä. Tekoäly luo ja nopeuttaa luonnoksia jokaisessa vaiheessa koko moduulissa – Dockerfile-tiedostosta putkiin, Terraformista hälytyssääntöön, kuolemanjälkeisestä kustannusanalyysiin. Mutta pätevä henkilö pysyy, joka tarkistaa jokaisen vaiheen, painaa live-painiketta ja takaa tuloksen. Tämä on kokonaisvaltaisten tekoälyllä varustettujen DevOps-laitteiden kultainen sääntö.

Sovellustehtävä

Valitse palvelu (todellinen tai kuvitteellinen), jossa haluat julkaista. (1) Valitse strategia, joka sopii kontekstisiisi Vapauta strategian valinta -mallin avulla ja kirjoita miksi. (2) Luo tarkistusluettelo "Savutesti/vahvistusluettelo" -mallilla ja lisää kriittisimmät liiketoimintapolut itse. (3) Valmistele 60 sekunnin palautussuunnitelma "Palautussuunnitelma"-mallilla ja tarkista, onko siinä peruuttamattomia vaiheita.

tarkistuslista

• [ ] Valitsin kontekstiini sopivan julkaisustrategian (kanarian/sinivihreä/lippu).
• [ ] Minulla on selkeä ja nopea palautussuunnitelma valmiina ennen käyttöönottoa.
• [ ] Lisäsin kriittisimmät liiketoimintapolut (esim. maksu) Smoke-testeihini itse.
• [ ] Käyttöönoton jälkeen seuraan kultaisia ​​signaaleja havaintoikkunan kautta.
• [ ] Suunnittelin myös peruuttamattomia vaiheita (tietokannan siirto jne.).
• [ ] Vahvistin tekoälysuunnitelman joka vaiheessa; Tein päätöksen lähteä live-lähetykseen.

Moduulin tentti

1. Mikä seuraavista on paras sijoitus DevOpsille ja tekoälylle pilvessä?

• A) Tekoäly on apu- ja päätöksenteon tukityökalu; Ihmiset ovat vastuussa tuotteeseen vaikuttavista kriittisistä päätöksistä ✔
• B) Tekoäly voi viimeistellä tuotannon käyttöönoton ja salaisen kierron ilman ihmisen hyväksyntää
• C) Tekoälystä on hyötyä vain dokumentaation kirjoittamiseen, sillä ei ole mitään tekemistä infrastruktuurin kanssa
• D) Auditointi on tarpeetonta, koska tekoäly tuottaa aina luotettavampia komentoja kuin insinööri

Kuvaus: Se on avustaja ja päätöksenteon tukityökalu, joka nopeuttaa tekstiintensiivisiä tehtäviä, kuten tekoälyn putkistoa, määrityksiä, komentosarjaa ja lokia. Vastuu seisokkiin, rahaan ja turvallisuuteen vaikuttavista päätöksistä, kuten tuotannon vapauttamisesta, salaisesta hallinnasta ja lopullisesta sovelluksesta, jää pätevälle insinöörille.

2. Mikä on tarkin ilmaus todentamisalalle ennen DevOps-komennon tai tekoälyn tuottaman konfiguraation toteuttamista?

• A) Jos tulos näyttää tasaiselta ja varmalta, sitä voidaan käyttää suoraan prod-tilassa
• B) Tulostus on turvallinen vain, jos siinä ei ole syntaksivirheitä, lisätarkastuksia ei tarvita
• C) Yhdistä lähtö lähteeseen, suunnittele/kuivakäynti ja suodata se järjestelmäkontekstin mukaan; hae sitten ✔
• D) Nopein varmistus on tehdä ensimmäinen yritys suoraan prodissa ja katsoa tulosta

Selitys: Kolmivaiheinen vahvistus on olennainen: lähtö kytketään lähteeseen (onko komento/lippu todella virallisissa asiakirjoissa), ajetaan se kuivana (nähdään mitä tapahtuu suunnitelmalle/--dry-run) ja ohjataan se järjestelmäsuodattimen läpi (sopiuko se arkkitehtuuri- ja suojauskontekstiinsa). Sujuvuus ei tarkoita tarkkuutta.

3. Mikä on oikea tapa kysyä tekoälyltä todellisen tietokannan salasanan sisältävän .env-tiedoston virhe- tai käyttöönottoongelmista?

• A) Peitä todelliset salaisuudet <PLACEHOLDER>-komennolla; jaa vain peitetty virhe ja konteksti ✔
• B) Koko .env-tiedoston liittäminen sellaisenaan ratkaisee ongelman nopeammin
• C) Koska salaisuudet ovat jo base64, on turvallista liittää tavallisena
• D) Salasanan liittäminen on turvallista, koska tekoäly ei koskaan tallenna sitä

Kuvaus: Tekoälykehotteeseen ei ole liitetty todellisia salaisuuksia. Arvot, kuten salasanat ja tunnukset, on peitetty merkinnällä <PLACEHOLDER>; vain virheilmoitus ja tarvittava konteksti jaetaan. Jos Secret on jo vuotanut, se tulee peruuttaa ja kiertää välittömästi.

4. Mikä seuraavista on oikea salaisuuksien (salasana, tunnus) hallinta CI/CD-liukuhihnassa?

• A) Sitä säilytetään alustan salaisessa arkistossa ja sitä kutsutaan viittauksella (esim. ${{ secrets.X }}), ei kirjoitettu pelkällä tekstillä ✔
• B) Kirjoitettu selkeänä tekstinä liukuhihnaan YAML mukavuuden vuoksi
• C) Se varmistetaan painamalla kaiku ja loki jokaisen työn alussa.
• D) Jos määritetään laajimmalla luvalla (kirjoita kaikki), turvallisuus paranee

Selitys: Salaisuuksia ei kirjoiteta YAML:iin pelkkänä tekstinä; Sitä säilytetään alustan salaisessa arkistossa ja sitä kutsutaan viitteillä, kuten ${{ secrets.X }}. Lisäksi vähimmän auktoriteetin periaatteella token-käyttöoikeuksia rajoitetaan eikä salaista lokia tallenneta.

5. Mikä on kriittisin askel infrastruktuurin hallinnassa Terraformilla ennen muutoksen toteuttamista livenä?

• A) "Terraform apply" -toiminnon suorittaminen suoraan; suunnitelma on ajanhukkaa
• B) Osavaltiotiedoston varmuuskopiointi julkiseen arkistoon
• C) Suorita 'terraform plan' ja tarkista tulosteen tuhoa/korvaa rivit ja käytä sitten ✔
• D) Poista Provider-version asennus ja varmista, että uusin versio tulee automaattisesti

Selitys: 'terraform plan' on suoritettava ennen 'terraform apply'. Suunnitelma näyttää, mitä lisätä, mitä muuttaa ja erityisesti mitä poistaa (tuhota) tekemättä mitään. Jos huomaat odottamattoman tuhoavan tai korvaavan linjan, sovellusta ei tule käyttää.

6. Mitä se tarkoittaa ja mitä pitäisi tehdä, jos tuotantotietokannan rivi '-/+ korvaa' näkyy Terraform-suunnitelman tulosteessa?

• A) Lähde vain päivitetään paikan päällä, riskiä ei ole
• B) Resurssi poistetaan ja luodaan uudelleen; Tietojen katoamisen vaara on olemassa, hakemus tulee lopettaa, jos sitä ei odoteta ✔
• C) Uuden resurssin lisääminen ei vaikuta olemassa olevaan tietokantaan
• D) Tämä on vain varoitus, joka voidaan jättää huomiotta

Selitys: "-/+ korvaa" tarkoittaa, että resurssi poistetaan ja luodaan uudelleen; Tietokannan osalta tämä tarkoittaa tietojen menetystä. Jos sitä ei odoteta, sovellus tulee lopettaa, muutos tulee muuntaa turvalliseksi menetelmäksi tai muuttumaton kenttä tulee jättää koskematta.

7. Mikä seuraavista pitää paikkansa, kun Dockerfile on tuotantovalmis turvallisuuden ja koon suhteen?

• A) Mukavuuden vuoksi upota salaisuus kuvaan ENV:llä ja käytä sitä pääkäyttäjänä
• B) Käytä aina ':latest' -tunnistetta ja pidä pohjakuva mahdollisimman suurena
• C) Yksivaiheinen rakennus ja jättää kaikki rakennustyökalut lopulliseen kuvaan
• D) Salaisuuden upottamatta jättäminen, työskentely luvattoman KÄYTTÄJÄN kanssa, pieni ja vakaa peruskuva ja monivaiheinen rakenne ✔

Kuvaus: Tuotantovalmis kuva: ei upota salaisuutta (lisää sen ajon aikana), toimii luvattoman KÄYTTÄJÄN kanssa rootin sijaan, käyttää pientä ja versioittua peruskuvaa (slim/alpine, ei :uusin) ja sitä pienennetään monivaiheisella koontiversiolla. Se myös tarkistetaan haavoittuvuuksien varalta ennen julkaisua.

8. Mikä on tärkein riski, jos Kubernetesin käyttöönotolle ei määritellä resurssirajoja?

• A) Pod ei käynnisty koskaan, koska raja on pakollinen kenttä
• B) Valvontataulussa näkyy vain varoitus, toiminta ei vaikuta
• C) Kubernetes pakottaa automaattisesti turvalliset oletusrajat ilman riskiä
• D) Pod voi kasvaa rajattomasti ja kuluttaa solmun resursseja, jolloin naapuripalvelut kaatuvat ✔

Selitys: Pod, jolla ei ole resurssirajoitusta, voi kasvaa rajattomasti, kuluttaa kaikki sen solmun resurssit, jossa se on käynnissä, ja kaataa viereiset palvelut esimerkiksi muistivuodon vuoksi. Siksi pyyntöjen/rajojen määrittäminen on kestävyyden perusta.

9. Kuinka välttää "hälytysväsymys" valvonnassa ja hälytyksen asetuksissa?

• A) Aseta hälytykset mahdollisimman monelle mittarille ja luo hälytyksiä jokaisesta vaihtelusta.
• B) Aseta kaikki hälytykset korkeimmalle vakavuustasolle
• C) Hälytysten laukaiseminen hetkellisillä arvoilla ilman aikaa (for)
• D) Hälytysten pitäminen toimintakeskeisinä ja oikealla kiireellisyydellä, kynnysten testaaminen historiallisilla tiedoilla, tarpeettomien yhdistäminen ✔

Kuvaus: Jokaisen hälytyksen on oltava toimintakelpoinen ja riittävän kiireellinen; Tietoa, joka ei vaadi toimia, näytetään taululla, se ei herätä ketään. Hälytyskynnykset testataan järjestelmän historiallisten tietojen perusteella ja tarpeettomat/toistuvat hälytykset yhdistetään. Näin todellinen hälytys ei katoa melussa.

10. Mikä on paras prioriteettijärjestys tuotantotapahtuman aikana?

• A) Etsi ensin tarkka perimmäinen syy ja vähennä sitä vasta, kun syy on selvä.
• B) Kirjoita ensin post mortem -raportti ja kosketa sitten palvelua
• C) Vähennä ensin (palautus/palautuspalvelu), jättäen perussyyanalyysin myöhemmäksi ✔
• D) Etsi ensin tapahtumasta vastuussa oleva henkilö ja ilmoita siitä

Selitys: Kultainen sääntö on "vähennä ensin, tutki myöhemmin". Tavoitteena on ensin palauttaa palvelu tai palauttaa se tunnettuun hyvään versioon (lieventää); Perussyyanalyysi tehdään rauhallisesti paineen laantuessa. Tarkan perimmäisen syyn löytämisen odottaminen lisää toipumisaikaa (MTTR).

11. Mikä on moitteettoman postmortem-kulttuurin päätarkoitus?

• A) Virheen tehneen henkilön tunnistaminen ja vastuun asettaminen hänelle
• B) Keskittyminen järjestelmiin ja prosesseihin ja kannustaminen oppimiseen; ✔ Oppitunnit, jotka estävät toiston syyttelyn sijaan
• C) Älä koskaan ilmoita tapauksesta ja varmista, että se unohdetaan
• D) Kirjoita vain teknisiä yksityiskohtia, älä lisää toimivia kohteita

Selitys: Syytön postmortem keskittyy kysymykseen "mikä järjestelmä ja prosessi salli tämän virheen", ei "kuka sen teki". Ihmiset jakavat virheen avoimesti, jos he tietävät, ettei heitä rangaista; Piilotettu virhe toistuu. Raportti ei ole syytösraportti, vaan oppimisasiakirja täynnä toimintaan suuntautuneita asioita.

12. Mikä on loogisin askel pilvikustannusoptimoinnissa (FinOps), ennen kuin siirrytään sitoutuneisiin alennuksiin (Reserved/Savings Plan)?

• A) Ota ensin mahdollisimman pitkä sitoumus, mieti hukkaa myöhemmin
• B) Ensin siivoa jätteet (joutokäynti, oikea mitoitus), sitten sitoutuu sitoutuneeseen käyttöön ✔
• C) Siirrä kaikki resurssit Spot-kapasiteettiin välittömästi
• D) Kalleimman tuotteen poistaminen tarkistamatta laskun tietoja

Selitys: Jätteet on siivottava ensin (sulkemalla käyttämättömät resurssit, vähentämällä ylimitoitettuja resursseja). Muuten lukitset hukkaan käytön alennettuun hintaan 1-3 vuodeksi. Oikean kokoinen ja tyhjäkäyntisiivous ei vaadi sitoutumista ja ovat lähes riskittömiä.

13. Mikä on tärkein turvatoimenpide, jos tekoälyn ehdottamassa komentosarjassa on rivi 'rm -rf "$DIR"/'?

• A) Skriptin suorittaminen suoraan prod-tilassa lukematta sitä nopeuttaa
• B) Lisää set -euo pipefail ja tyhjä muuttujaohjaus ja kokeile ensin kuivaajolla ✔
• C) Muuttujan nimen lyhentäminen riittää
• D) Komento rm -rf --force rm:n sijaan ratkaisee ongelman

Selitys: Jos $DIR on tyhjä, tämä käsky saattaa yrittää poistaa juurihakemiston. Pysähtyminen määrittelemättömään muuttujaan komennolla "set -u" ja tarkistaminen, että muuttuja ei ole tyhjä ennen sen poistamista (esim. [ -n "$DIR" ] || exit 1) välttää katastrofin. Lisäksi tuhoavia operaatioita tulisi kokeilla ensin kuivakäynnillä.

14. Mikä on ensimmäinen asia, joka on tehtävä, jos pilvikäyttöavain vuotaa vahingossa julkiseen tietovarastoon?

• A) Peruuta ja uusi (käännä) avain välittömästi; Pelkkä poistaminen ei riitä ✔
• B) Poista vain tiedosto tallennustilasta ja avain on turvassa
• C) Älä tee mitään, koska kukaan ei nähnyt sitä
• D) Tallennustilan yksityistäminen poistaa avaimen kiertämisen tarpeen

Selitys: Vuotanut salaisuus on peruutettava ja käännettävä välittömästi. Pelkkä tiedoston poistaminen ei riitä, koska salaisuus säilyy Git-historiassa ja botit tarkistavat julkiset tietovarastot muutamassa sekunnissa. Peruutuksen/palautuksen jälkeen vaikutus arvioidaan ja salainen skanneri lisätään estämään toistumisen.

15. Mikä seuraavista keinoista minimoi riskin, kun julkaistaan ​​uusi Prod-versio?

• A) Uuden version antaminen kaikille käyttäjille samanaikaisesti (big-bang) eikä palautussuunnitelman laatiminen
• B) Katsotaan, että käyttöönotto on päättynyt heti, kun se näyttää "vihreältä", lisätarkistusta ei suoriteta
• C) Hallitun strategian, kuten kanarian / sinivihreän / ominaisuuslipun, valmiin palautussuunnitelman ja savutestin + metrisen tarkkailun käyttö käyttöönoton jälkeen ✔
• D) Kriittisten liiketoimintapolkujen testaaminen jätetään kokonaan tekoälylle, eikä niitä määritetä ollenkaan.

Selitys: Hallitut julkaisustrategiat (alkaen pienestä prosenttiosuudesta canarysta, välitön palautus sinivihreällä, käyttöönoton erottaminen julkaisusta ominaisuuden lipulla) rajoittavat riskiä. Lisäksi selkeä palautussuunnitelma ennen käyttöönottoa ja kultaisen signaalin seuranta savutestauksella käyttöönoton jälkeen ovat tärkeitä; 'vihreän näköinen' ei tarkoita, että se toimii.