Prod-verificatie, releasestrategieën en end-to-end AI-workflow

Winst:

• Inzicht in risicoverminderende releasestrategieën (blauwgroen, kanarie, feature flag) en productverificatiediscipline (gezondheidscontrole, rooktest, gouden signaalmonitoring)
• Mogelijkheid om de gewoonte te implementeren om vóór de implementatie een duidelijk rollback-plan op te stellen en kritieke bedrijfspaden na de implementatie te verifiëren
• Mogelijkheid om alle onderdelen die je tijdens de module hebt geleerd te combineren in een end-to-end AI-ondersteunde workflow en bij elke stap het principe van 'AI produceert, mensen verifiëren en garanderen' toe te passen

Deze hele module stroomde naar één punt toe: de veilige levering van code en infrastructuur aan de productie (de live-omgeving die door echte klanten wordt gebruikt). Nu zijn we bij de meest kritische en stressvolle schakel in de keten: een verandering live krijgen en verifiëren dat deze daar ook daadwerkelijk werkt. Een fout hier is niet abstract; het heeft rechtstreeks gevolgen voor de klant, de omzet en de reputatie. Dat is de reden waarom volwassen teams niet naar de productie gaan door te ‘hopen’, maar met gecontroleerde releasestrategieën en systematische verificatie.

In deze laatste unit combineren we twee dingen: (1) releasemethoden die het risico verminderen (kanarie, blauw-groen, feature flag) en de discipline van productverificatie; (2) hoe elk stukje dat we tijdens de module hebben geleerd (CI/CD, IaC, container, monitoring, incident, kosten, script, beveiliging) samenkomt in één door AI aangedreven end-to-end workflow. Laten we het oorspronkelijke citaat nog een laatste keer herhalen: AI genereert en versnelt concepten bij elke stap; Maar jij bent degene die op de knop 'Ik neem dit live' drukt en instaat voor de uitkomst.

Geef strategieën vrij die het risico verminderen

Een wijziging tegelijkertijd naar alle gebruikers pushen is de meest risicovolle manier. Volwassen methoden:

• Blauw-groene implementatie: Er worden twee identieke omgevingen onderhouden: ‘blauw’ (live) en ‘groen’ (nieuwe versie). De nieuwe versie wordt in het groen voorbereid en getest, waarna het verkeer ineens op groen schakelt. Als er een probleem is, gaat het verkeer onmiddellijk terug naar blauw. Snel terugdraaien is het grootste voordeel.
• Canary-implementatie: de nieuwe versie wordt eerst vrijgegeven aan een klein percentage gebruikers (bijvoorbeeld 5%); Als de statistieken goed zijn, kunt u dit geleidelijk verhogen tot 100%. Een probleem treft een klein deel van de gebruiker, niet de hele gebruiker.
• Feature Flag: De nieuwe feature voert de code in, maar wordt geblokkeerd door een vlag; Het wordt op verzoek voor bepaalde gebruikers geopend. Er is een onderscheid tussen inzet en "vrijgave"; Als er een probleem is, wordt de vlag uitgeschakeld zonder dat de code wordt teruggedraaid.

Tip: Het snelste vangnet is om vóór elke implementatie een rollback gereed te hebben. “Als er iets misgaat, hoe kan ik dan binnen 60 seconden terugkeren naar de oude versie?” Als er geen duidelijk antwoord op de vraag is, bent u niet klaar om die implementatie uit te voeren.

Prod-verificatie: het werk stopt niet wanneer de implementatie eindigt

Het feit dat een implementatie er 'groen' uitziet, betekent niet dat deze werkt. Systematische verificatie:

1. Gezondheidscontroles: is de service actief, reageert /healthz?
2. Rooktesten: werken de meest kritische gebruikerspaden (inloggen, betalen, zoeken) eigenlijk? Automatisch en snel.
3. Let op gouden signalen: foutenpercentage na implementatie, latentie, is verkeer normaal? (Vier signalen op unit 6.)
4. Geleidelijk uitbreiden: bekijk de statistieken bij elke stap terwijl u het Canarische percentage verhoogt.
5. Observatievenster: Houd nauwlettend toezicht gedurende een bepaalde periode (bijvoorbeeld 30 minuten) na de implementatie; Verraderlijke problemen zijn niet onmiddellijk zichtbaar.

Let op: de AI kan een lijst met rooktests of verificaties produceren, maar het is jouw taak om te bepalen welke gebruikerspaden "kritiek" zijn. AI geeft een algemene lijst; Alleen u weet dat uw betalingsstroom, uw meest inkomstengenererende pad, moet worden getest.

Vergelijking van releasestrategieën

Strategie

Belangrijkste voordeel

Kosten/complexiteit

meest geschikt

Blauw-groen

Direct terugdraaien

Twee omgevingen = 2x bronnen

Als snel ophalen van cruciaal belang is

kanarie

Beperkt de impact tot een klein stukje

Verkeersmanagement vereist

Enorme gebruikersbasis

FeatureFlag

Scheidt de implementatie vanaf de release

Markeer schuldenbeheer

Geleidelijke/gerichte opening

Rollende update

Eenvoudig, hulpbronnenvriendelijk

langzaam terugdraaien

Eenvoudige diensten

End-to-end AI-aangedreven workflow

Laten we nu de hele module combineren in één enkele stroom. Stel dat u een nieuwe microservice publiceert. AI produceert bij elke stap concepten; u verifieert bij elke stap:

1. Code en container (eenheid 4): AI produceert een geoptimaliseerd, veilig Dockerbestand; Je verifieert het geen-geheim en de grootte.
2. CI/CD (Unit 2): Schrijft de AI test-build-deploy pipeline; Je beperkt de rechten en controleert de geheime referenties.
3. Infrastructuur (eenheid 3): definieert de benodigde bronnen met AI Terraform; U leest de planuitvoer en zoekt niet naar onverwachte verwijderingen.
4. Orkestratie (eenheid 5): AI produceert Kubernetes-manifesten; u verifieert de resourcelimiet, de test en de RBAC.
5. Beveiliging (eenheid 10): geeft prioriteit aan AI-scanuitvoer; Je pakt eerst de exploiteerbare.
6. Monitoring (Unit 6): AI genereert alarmregels en dashboard; U test de drempels met uw gegevens uit het verleden.
7. Release & validatie (deze unit): schetst het AI-rooktest- en rollback-plan; je start Canary, bekijkt de statistieken en drukt op de knop.
8. Als er een incident plaatsvindt (Unit 7): AI genereert hypothese en postmortale schets; Je verifieert en leert de lessen.
9. Kosten (eenheid 8): AI houdt toezicht op de verspilling van nieuwe hulpbronnen; Je neemt de juiste maatbeslissingen.

Bij elke stap blijft de gemeenschappelijke regel constant: AI produceert en versnelt, de mens verifieert en staat garant. Dit is de essentie van de module.

drie minikoffers

Geval 1: Kanarie beperkte de ramp tot 5%. Een team gaf de nieuwe versie aan 5% van de gebruikers met Canary. Uit het dashboard dat de AI produceerde, bleek meteen dat het foutenpercentage in dit segment naar 8% was gestegen. Het team heeft het teruggenomen zonder het naar 100% te verhogen; Het probleem trof slechts 5% van de gebruikers, en dat duurde een paar minuten. Als er een big-bang-implementatie zou plaatsvinden, zouden alle klanten hierdoor worden getroffen.

Geval 2: de rooktest trof het ontbrekende pad aan. AI bood een rooktestset aan, maar deze had geen "betalingsstroom". De ingenieur voegde het toe, wetende dat de meest kritische inkomstenstroom de betaling was. De test na de implementatie mislukte meteen bij het afrekenen: een sleutel van een derde partij was verlopen. Bij verificatie werd binnen enkele minuten een stille inkomstenderving geconstateerd.

Geval 3 – klaar terugdraaien opgeslagen in 90 seconden. Een team dat blauwgroen installeerde, bracht de nieuwe versie naar groen; Na 2 minuten was de vertraging verdubbeld. Ze veranderden het verkeer in 90 seconden in blauw met de rollback die ze van tevoren hadden voorbereid. Ze vonden de oorzaak (een langzame zoekopdracht in de nieuwe versie) niet onder druk, maar kalm. Het kant-en-klare terugdraaipad maakte de onderbreking bijna onzichtbaar.

Vier kopieerbare sjablonen

1) Selectie van releasestrategie:

Ik zal de volgende service aanbieden: [SERVICE/CONTEXT: aantal gebruikers, uitvaltolerantie, infrastructuur]. Welke raad jij aan tussen blauwgroene, kanarie- en featurevlaggen? Vergelijk in deze context de voordelen, kosten en terugdraaisnelheid van elk. Geef een suggestie, maar zeg dat ik de uiteindelijke beslissing zal nemen.

2) Rooktest-/verificatielijst:

Maak een concept-rooktest en verificatielijst voor [SERVICE] die ik na de implementatie zal uitvoeren: statuscheck, de meest kritische gebruikerspaden, welke statistieken moet ik gedurende hoeveel minuten monitoren? Stel dat ik de meest kritieke bedrijfspaden markeer en dat veld leeg laat.

3) Terugdraaiplan:

Ik gebruik [Implementatiemethode]. Schrijf mij een duidelijk rollback-plan: met welk commando/stap rol ik terug naar de oude versie, hoe lang duurt het, wat zijn de risico's van het rollback zelf (databasemigratie kan bijvoorbeeld niet worden teruggedraaid), wat moet ik controleren voordat ik het terugdraai?

4) Controlelijst voor end-to-end release:

Maak een end-to-end voorbereidingscontrolelijst voor vrijgave voor een nieuw [SERVICE]-project: code-/imagebeveiliging, pijplijn, infrastructuurplan, monitoring en alarmering, beveiligingsscans, vrijgavestrategie, terugdraaien en verificatie. Controleer elk item met de vraag "Ben ik er klaar voor?" Maak er een vraag van.

Zwakke prompt/sterke prompt

Zwak: "Hoe krijg ik dit in de productie?"

Resultaat: geen context; AI somt algemene implementatiestappen op, maar houdt geen rekening met uw risicotolerantie, gebruikersschaal en terugdraaibehoefte.

Güçlü: "Ik ga een betalingsdienst aanbieden met 10 miljoen gebruikers, mijn tolerantie voor downtime is erg laag. Beveel je Canary of Blue-Green aan, waarom? Welke kritieke paden moet ik testen na de implementatie, welke statistieken moet ik controleren gedurende hoeveel minuten, en hoe zou een rollback-plan van 60 seconden eruit moeten zien? Ik zal de uiteindelijke beslissing nemen."

Verschil: de tweede prompt geeft de schaal, tolerantie en terugdraaiverwachting; Het vereist strategie + verificatie + ongedaan maken en laat de beslissing aan de mens over.

Veel voorkomende fouten

• Implementatie zonder rollbackplan. Als er geen weg meer terug is, is elke inzet een gok.
• Big-bang-implementatie. Door het in één keer aan de hele gebruiker te geven, maximaliseert u het risico.
• Ervan uitgaande dat "groen = werkt". De service die de statuscontrole heeft doorstaan, is mogelijk defect op het kritieke pad.
• Denkend dat u cruciale zakelijke paden aan AI overlaat. U moet de methoden zoals betaling markeren.
• Geen monitoring na implementatie. Verraderlijke problemen verschijnen niet in de eerste minuut; observatievenster is vereist.
• Denken dat databasemigratie omkeerbaar is. Sommige wijzigingen worden niet teruggedraaid; worden afzonderlijk gepland.

Samengevat

Prod gaan is de meest kritische schakel in de keten en gebeurt niet door te "hopen", maar met gecontroleerde strategieën: blauw-groen zorgt voor onmiddellijke terugdraaiing, waardoor het kanarie-effect tot een klein stukje wordt beperkt, waardoor de inzet van feature flags wordt gescheiden van de release. Het werk is nog niet voorbij als de inzet klaar is; Systematische verificatie door middel van gezondheidscontroles, rooktests en gouden signaalmonitoring is essentieel. AI genereert en versnelt concepten bij elke stap in de hele module: van Dockerfile tot pijplijn, van Terraform tot alarmregel, van postmortem tot kostenanalyse. Maar de competente persoon blijft die elke stap verifieert, op de go live-knop drukt en instaat voor de uitkomst. Dit is de gouden regel van end-to-end AI-aangedreven DevOps.

Applicatie taak

Kies een dienst (echt of fictief) waarop u wilt publiceren. (1) Kies een strategie die bij uw context past met het sjabloon ‘Release strategie selectie’ en schrijf op waarom. (2) Laat een verificatielijst genereren met het sjabloon "Rooktest / verificatielijst" en voeg zelf de meest kritische bedrijfspaden toe. (3) Maak een rollback-plan van 60 seconden op met de sjabloon "Rollback-plan" en controleer of er onomkeerbare stappen in zitten.

controlelijst

• [ ] Ik heb een releasestrategie gekozen (kanarie/blauw-groen/vlag) die bij mijn context past.
• [ ] Ik heb een duidelijk en snel rollback-plan klaar voordat ik het implementeer.
• [ ] Ik heb zelf de meest kritische zakelijke paden (bijvoorbeeld betaling) aan mijn Smoke-tests toegevoegd.
• [ ] Na de inzet volg ik de gouden signalen via een observatievenster.
• [ ] Ik heb ook onomkeerbare stappen gepland (databasemigratie, enz.).
• [ ] Ik heb bij elke stap de AI-blauwdruk geverifieerd; Ik heb de beslissing genomen om live te gaan.

Module-examen

1. Welke van de volgende is de beste positionering voor DevOps en AI in de cloud?

• A) Kunstmatige intelligentie is een hulp- en beslissingsondersteunend instrument; Mensen zijn verantwoordelijk voor cruciale beslissingen die van invloed zijn op het product ✔
• B) Kunstmatige intelligentie kan de implementatie van producten en geheime rotaties voltooien zonder menselijke goedkeuring
• C) Kunstmatige intelligentie is alleen nuttig voor het schrijven van documentatie, het heeft niets met infrastructuur te maken
• D) Audit is niet nodig omdat kunstmatige intelligentie altijd betrouwbaardere commando's produceert dan de ingenieur

Beschrijving: Het is een assistent- en beslissingsondersteunende tool die tekstintensieve taken versnelt, zoals de pijplijn voor kunstmatige intelligentie, configuratie, script en log. De verantwoordelijkheid voor beslissingen die van invloed zijn op downtime, geld en veiligheid, zoals productievrijgave, geheim beheer en definitieve toepassing, blijft bij de bevoegde ingenieur.

2. Wat is de meest nauwkeurige uitdrukking voor de verificatiediscipline voordat een door kunstmatige intelligentie geproduceerde DevOps-opdracht of -configuratie wordt geïmplementeerd?

• A) Als de uitvoer er soepel en zelfverzekerd uitziet, kan deze direct in productie worden uitgevoerd
• B) De uitvoer is alleen veilig als er geen syntaxisfouten zijn; er zijn geen verdere controles vereist
• C) Verbind de output met de bron, plan/dry-run en filter deze met uw systeemcontext; solliciteer dan ✔
• D) De eerste poging direct in het product doen en het resultaat bekijken is de snelste verificatie

Uitleg: Driestapsverificatie is essentieel: de uitvoer verbinden met de bron (staat het commando/de vlag daadwerkelijk in de officiële documenten), het droog laten lopen (zien wat er gebeurt met het plan/--droogdraaien), en het door het systeemfilter laten gaan (past het binnen de architecturale en beveiligingscontext). Vlotheid betekent niet nauwkeurigheid.

3. Wat is de juiste aanpak bij het vragen aan kunstmatige intelligentie over een fout of implementatieprobleem met een .env-bestand dat een echt databasewachtwoord bevat?

• A) Masker echte geheimen met <PLACEHOLDER>; deel alleen gemaskeerde fouten en context ✔
• B) Door het volledige .env-bestand te plakken zoals het is, wordt het probleem sneller opgelost
• C) Omdat de geheimen al base64 zijn, is het veilig om ze gewoon te plakken
• D) Het plakken van het wachtwoord is veilig omdat kunstmatige intelligentie het nooit opslaat

Beschrijving: Er worden geen echte geheimen in de AI-prompt geplakt. Waarden zoals wachtwoorden en tokens worden gemaskeerd met <PLACEHOLDER>; alleen de foutmelding en de noodzakelijke context worden gedeeld. Als het geheim al is gelekt, moet het onmiddellijk worden geannuleerd en gerouleerd.

4. Wat is het juiste beheer van geheimen (wachtwoord, token) in een CI/CD-pijplijn?

• A) Het wordt bewaard in de geheime repository van het platform en wordt aangeroepen door middel van referentie (bijvoorbeeld ${{ secrets.X }}), niet geschreven in platte tekst ✔
• B) Geschreven in leesbare tekst om YAML te pijplijnen voor het gemak
• C) Dit wordt geverifieerd door aan het begin van elke taak op echo en log te drukken.
• D) Indien gedefinieerd met de breedste machtiging (alles schrijven), neemt de beveiliging toe

Uitleg: Geheimen worden niet in platte tekst naar YAML geschreven; Het wordt bewaard in de geheime repository van het platform en aangeroepen met referenties zoals ${{ secrets.X }}. Bovendien worden, dankzij het principe van de minste autoriteit, de tokenmachtigingen beperkt en wordt het geheime logboek niet geregistreerd.

5. Wat is bij infrastructuurbeheer met Terraform de meest kritische stap die moet worden gezet voordat een verandering live wordt geïmplementeerd?

• A) Direct uitvoeren van 'terraform apply'; het plan is tijdverspilling
• B) Een back-up maken van het staatsbestand naar een openbare opslagplaats
• C) Voer 'terraform plan' uit en controleer de regels voor vernietigen/vervangen in de uitvoer, en pas vervolgens ✔ toe
• D) Verwijder de Provider-versie en zorg ervoor dat de nieuwste versie automatisch verschijnt

Toelichting: 'terraform plan' moet worden uitgevoerd vóór 'terraform toepassen'. Het plan laat zien wat je moet toevoegen, wat je moet veranderen en vooral wat je moet verwijderen (vernietigen), zonder iets te doen. Als er een onverwachte vernietigings- of vervangingslijn wordt gezien, mag de toepassing niet worden toegepast.

6. Wat betekent het en wat moet er gebeuren als de regel '-/+ vervangen' voor de productiedatabase verschijnt in een Terraform-planuitvoer?

• A) De bron wordt gewoon ter plaatse bijgewerkt, er is geen risico
• B) De bron wordt verwijderd en opnieuw gemaakt; Er bestaat een risico op gegevensverlies. De toepassing moet worden stopgezet als dit niet wordt verwacht ✔
• C) Als u een nieuwe bron toevoegt, wordt de bestaande database niet beïnvloed
• D) Dit is slechts een waarschuwing en kan veilig worden genegeerd

Uitleg: '-/+ vervangen' betekent dat de bron wordt verwijderd en opnieuw wordt aangemaakt; Voor een database betekent dit gegevensverlies. Als dit niet wordt verwacht, moet de toepassing worden stopgezet, moet de wijziging worden omgezet naar een veilige methode, of moet het onveranderlijke veld onaangeroerd blijven.

7. Welke van de volgende beweringen is waar voor een Dockerfile die klaar is voor productie in termen van beveiliging en omvang?

• A) Voor het gemak: het geheim in de afbeelding insluiten met ENV en het als root uitvoeren
• B) Gebruik altijd de tag ':latest' en houd de basisafbeelding zo groot mogelijk
• C) Bouw in één fase en laat alle bouwtools in de uiteindelijke afbeelding staan
• D) Het geheim niet inbedden, werken met ongeautoriseerde GEBRUIKERs, gebruik maken van een kleine en stabiele basisimage en een opbouw in meerdere fasen ✔

Beschrijving: Een productieklare image: sluit het geheim niet in (injecteert het tijdens runtime), draait met een ongeautoriseerde GEBRUIKER in plaats van root, gebruikt een kleine basisimage met versiebeheer (slim/alpine, niet:latest) en wordt verkleind met een build in meerdere fasen. Ook wordt het vóór publicatie gescand op kwetsbaarheden.

8. Wat is het belangrijkste risico als er geen resourcelimieten worden gedefinieerd voor een implementatie in Kubernetes?

• A) Pod start nooit omdat limiet een verplicht veld is
• B) Er verschijnt alleen een waarschuwing op de bewakingskaart, de werking wordt niet beïnvloed
• C) Kubernetes handhaaft automatisch veilige standaardlimieten, zonder risico
• D) De pod kan onbeperkt groeien en de bronnen van het knooppunt verbruiken, waardoor aangrenzende services crashen ✔

Uitleg: Een Pod die geen resourcelimiet heeft, kan onbeperkt groeien, alle bronnen verbruiken van het knooppunt waarop hij draait, en aangrenzende services laten crashen, bijvoorbeeld als gevolg van een geheugenlek. Daarom is het definiëren van verzoeken/limieten de basis van robuustheid.

9. Hoe kan 'alertmoeheid' worden voorkomen bij het monitoren en instellen van alarmen?

• A) Stel alarmen in op zoveel mogelijk statistieken en genereer waarschuwingen bij elke fluctuatie.
• B) Stel alle alarmen in op het hoogste ernstniveau
• C) Alarmen activeren met momentane waarden zonder een tijd in te stellen (voor)
• D) Alarmen actiegericht en met de juiste urgentie houden, drempels testen met historische gegevens, onnodige samenvoegen ✔

Beschrijving: Elk alarm moet actiegericht zijn en de juiste urgentie hebben; Informatie die geen actie vereist, wordt op het bord weergegeven en maakt niemand wakker. Alarmdrempels worden getest aan de hand van de historische gegevens van het systeem en onnodige/herhaalde alarmen worden geconsolideerd. Zo gaat het echte alarm niet verloren in het lawaai.

10. Wat is de beste prioriteitsvolgorde tijdens een productie-incident?

• A) Zoek eerst de exacte oorzaak en verminder deze pas als de oorzaak duidelijk is.
• B) Schrijf eerst het postmortemrapport en raak vervolgens de dienst aan
• C) Eerst verminderen (herstel/herstelservice), waarbij de analyse van de hoofdoorzaak voor later wordt bewaard ✔
• D) Zoek eerst de persoon die verantwoordelijk is voor het incident en meld dit

Uitleg: De gouden regel is 'eerst verminderen, later onderzoeken'. Het doel is om eerst de service te herstellen of terug te zetten naar een versie waarvan bekend is dat deze goed is (mitigeren); De analyse van de hoofdoorzaak wordt rustig uitgevoerd nadat de druk is afgenomen. Wachten op het vinden van de exacte oorzaak verhoogt de hersteltijd (MTTR).

11. Wat is het voornaamste doel van een onberispelijke postmortale cultuur?

• A) Identificeren van de persoon die de fout heeft gemaakt en de verantwoordelijkheid bij hem/haar leggen
• B) Focussen op systemen en processen en het aanmoedigen van leren; ✔ Lessen leren die herhaling voorkomen in plaats van verwijten te maken
• C) Meld het incident nooit en zorg ervoor dat het wordt vergeten
• D) Schrijf alleen technische details en voeg geen bruikbare items toe

Uitleg: Onschuldig postmortem richt zich op de vraag 'welk systeem en proces deze fout hebben toegestaan', niet 'wie het heeft gedaan'. Mensen delen deze fout openlijk als ze weten dat ze niet gestraft zullen worden; De verborgen fout wordt herhaald. Het rapport is geen beschuldigingsrapport, maar een leerdocument vol actiegerichte items.

12. Wat is bij cloudkostenoptimalisatie (FinOps) de meest logische stap voordat u overstapt op vastgelegde kortingen (gereserveerd/spaarplan)?

• A) Neem eerst de langst mogelijke verbintenis, denk later aan verspilling
• B) Ruim eerst het afval op (inactieve sluiting, juiste maatvoering) en zet u vervolgens in voor toegewijd gebruik ✔
• C) Verplaats alle grondstoffen onmiddellijk naar Spot-capaciteit
• D) Het duurste artikel verwijderen zonder de factuurgegevens te controleren

Toelichting: Afval moet eerst worden opgeruimd (ongebruikte hulpbronnen sluiten, overmaatse hulpbronnen verminderen). Anders vergrendelt u het verspilde gebruik tegen een gereduceerde prijs gedurende 1-3 jaar. De juiste maatvoering en inactieve schoonmaak vereisen geen enkele verplichting en zijn vrijwel risicoloos.

13. Wat is de belangrijkste beveiligingsmaatregel als een door AI voorgesteld script de regel 'rm -rf "$DIR"/' heeft?

• A) Het uitvoeren van het script rechtstreeks in Prod zonder het te lezen, zal versnellen
• B) Voeg set -euo pipefail en lege variabele regeling toe en probeer eerst met drooglopen ✔
• C) Het inkorten van de variabelenaam is voldoende
• D) Het gebruik van rm -rf --force in plaats van rm lost het probleem op

Uitleg: Als $DIR leeg is, kan deze instructie proberen de hoofdmap te verwijderen. Stoppen bij de ongedefinieerde variabele met 'set -u' en controleren of de variabele niet leeg is voordat deze wordt verwijderd (bijvoorbeeld [ -n "$DIR" ] || exit 1) voorkomt een ramp. Bovendien moeten destructieve operaties eerst worden geprobeerd met een droogloop.

14. Wat is het eerste dat u moet doen als een cloudtoegangssleutel per ongeluk in een openbare opslagplaats lekt?

• A) Onmiddellijk de sleutel annuleren en verlengen (roteren); Alleen verwijderen is niet voldoende ✔
• B) Verwijder gewoon het bestand uit de opslag en de sleutel is veilig
• C) Niets doen omdat niemand het zag
• D) Door de opslag privé te maken, hoeft u de sleutel niet meer te draaien

Uitleg: Het gelekte geheim moet onmiddellijk worden geannuleerd en gerouleerd. Het alleen verwijderen van het bestand is niet voldoende, omdat het geheim in de Git-geschiedenis blijft staan ​​en openbare opslagplaatsen binnen enkele seconden door bots worden gescand. Na annulering/retourneren wordt de impact geëvalueerd en wordt er een geheime scanner toegevoegd om herhaling te voorkomen.

15. Welke van de volgende benaderingen minimaliseert het risico bij het uitbrengen van een nieuwe versie van Prod?

• A) De nieuwe versie tegelijkertijd aan alle gebruikers geven (big-bang) en geen rollback-plan opstellen
• B) De implementatie als voltooid beschouwen zodra deze 'groen' verschijnt, en geen aanvullende verificatie uitvoeren
• C) Gebruik van een gecontroleerde strategie zoals kanarie/blauw-groen/kenmerkvlag, kant-en-klaar rollback-plan en rooktest + metrische monitoring na inzet ✔
• D) Het testen van kritieke bedrijfspaden volledig overlaten aan kunstmatige intelligentie en deze helemaal niet bepalen.

Uitleg: Gecontroleerde releasestrategieën (beginnend met een klein percentage met canary, onmiddellijke rollback met blauw-groen, scheiding van implementatie en release met feature flag) beperken het risico. Daarnaast zijn een duidelijk terugdraaiplan vóór inzet en gouden signaalmonitoring met rooktesten na inzet essentieel; 'er groen uitzien' betekent niet dat het werkt.