Produktüberprüfung, Release-Strategien und End-to-End-KI-Workflow

Gewinne:

Verständnis risikomindernder Release-Strategien (Blue-Green, Canary, Feature Flag) und der Produktverifizierungsdisziplin (Health Check, Smoke Test, Golden Signal Monitoring)
Fähigkeit, die Gewohnheit umzusetzen, vor der Bereitstellung einen klaren Rollback-Plan zu erstellen und kritische Geschäftspfade nach der Bereitstellung zu überprüfen
Fähigkeit, alle im Laufe des Moduls erlernten Teile in einem durchgängig KI-gestützten Arbeitsablauf zu kombinieren und bei jedem Schritt das Prinzip „KI produziert, Menschen überprüfen und bürgen“ anzuwenden

Dieses gesamte Modul zielte auf einen Punkt ab: die sichere Lieferung von Code und Infrastruktur an die Produktion (die Live-Umgebung, die von echten Kunden genutzt wird). Jetzt sind wir am kritischsten und stressigsten Glied in der Kette: eine Änderung live zu bringen und zu überprüfen, ob sie dort tatsächlich funktioniert. Ein Fehler ist hier nicht abstrakt – er wirkt sich direkt auf den Kunden, den Umsatz und den Ruf aus. Aus diesem Grund gehen ausgereifte Teams nicht durch „Hoffen“, sondern mit kontrollierten Release-Strategien und systematischer Überprüfung in die Produktion.

In dieser letzten Einheit kombinieren wir zwei Dinge: (1) Release-Methoden, die das Risiko reduzieren (Canary, Blue-Green, Feature Flag) und die Disziplin der Produktüberprüfung; (2) wie alle Teile, die wir im Laufe des Moduls gelernt haben – CI/CD, IaC, Container, Überwachung, Vorfall, Kosten, Skript, Sicherheit – in einem einzigen KI-gestützten End-to-End-Workflow zusammenkommen. Wiederholen wir noch einmal das Eingangszitat: KI generiert und beschleunigt Entwürfe bei jedem Schritt; Aber Sie sind derjenige, der den „Ich nehme das live“-Knopf drückt und für das Ergebnis bürgt.

Release-Strategien, die das Risiko reduzieren

Die gleichzeitige Übertragung einer Änderung an alle Benutzer ist der riskanteste Weg. Ausgereifte Methoden:

Blau-Grün-Bereitstellung: Es werden zwei identische Umgebungen beibehalten – „blau“ (live) und „grün“ (neue Version). Die neue Version wird auf Grün vorbereitet und getestet, dann wird der Verkehr plötzlich auf Grün umgestellt. Sollte es ein Problem geben, wird der Verkehr sofort wieder auf Blau umgestellt. Ein schneller Rollback ist sein größter Vorteil.
Canary-Bereitstellung: Die neue Version wird zunächst für einen kleinen Prozentsatz der Benutzer (z. B. 5 %) freigegeben; Wenn die Kennzahlen gut sind, steigern Sie sie schrittweise auf 100 %. Ein Problem betrifft einen kleinen Teil des Benutzers, nicht den gesamten Benutzer.
Feature-Flag: Die neue Funktion tritt in den Code ein, wird aber durch ein Flag blockiert; Es wird auf Anfrage für bestimmte Benutzer geöffnet. Es gibt einen Unterschied zwischen Bereitstellung und „Freigabe“; Wenn ein Problem auftritt, wird das Flag deaktiviert, ohne dass der Code zurückgesetzt wird.

Tipp: Das schnellste Sicherheitsnetz besteht darin, vor jeder Bereitstellung ein Rollback bereitzuhalten. „Wenn etwas schief geht, wie kann ich dann in 60 Sekunden zur alten Version zurückkehren?“ Wenn es keine klare Antwort auf die Frage gibt, sind Sie für die Bereitstellung nicht bereit.

Produktüberprüfung: Die Arbeit endet nicht, wenn die Bereitstellung endet

Nur weil eine Bereitstellung „grün“ aussieht, heißt das nicht, dass sie funktioniert. Systematische Überprüfung:

Gesundheitschecks: Ist der Dienst aktiv, antwortet /healthz?
Rauchtests: Funktionieren die wenigen kritischsten Benutzerpfade (Anmeldung, Zahlung, Suche) tatsächlich? Automatisch und schnell.
Achten Sie auf goldene Signale: Fehlerrate nach der Bereitstellung, Latenz, ist der Datenverkehr normal? (Vier Signale auf Block 6.)
Erweitern Sie schrittweise: Sehen Sie sich bei jedem Schritt die Kennzahlen an, während Sie den Canary-Prozentsatz erhöhen.
Beobachtungsfenster: Nach dem Einsatz eine Zeit lang (z. B. 30 Minuten) genau beobachten; Heimtückische Probleme sind nicht sofort sichtbar.

Achtung: Die KI erstellt möglicherweise eine Liste von Rauchtests oder Verifizierungen, es ist jedoch Ihre Aufgabe, zu bestimmen, welche Benutzerpfade „kritisch“ sind. AI gibt eine allgemeine Liste; Nur Sie wissen, dass Ihr Zahlungsfluss, Ihr umsatzstärkster Weg, getestet werden muss.

Vergleich der Release-Strategien

Strategie

Hauptvorteil

Kosten/Komplexität

am besten geeignet

Blau-Grün

Sofortiger Rollback

Zwei Umgebungen = 2x Ressourcen

Wenn schnelles Abrufen entscheidend ist

Kanarienvogel

Begrenzt die Wirkung auf kleine Scheiben

Verkehrsmanagement erforderlich

Riesige Benutzerbasis

FeatureFlag

Trennt die Bereitstellung von der Veröffentlichung

Schulden des Flaggenmanagements

Schrittweise/gezielte Öffnung

Fortlaufendes Update

Einfach, ressourcenschonend

langsamer Rollback

Einfache Dienstleistungen

Durchgängiger KI-gestützter Workflow

Jetzt kombinieren wir das gesamte Modul zu einem einzigen Flow. Nehmen wir an, Sie veröffentlichen einen neuen Microservice. KI erstellt bei jedem Schritt Entwürfe; Sie überprüfen bei jedem Schritt:

Code & Container (Einheit 4): KI erstellt eine optimierte, sichere Docker-Datei; Sie überprüfen das No-Secret und die Größe.
CI/CD (Einheit 2): Schreibt die AI-Test-Build-Deploy-Pipeline; Sie schränken die Berechtigungen ein und überprüfen die geheimen Referenzen.
Infrastruktur (Einheit 3): Definiert die erforderlichen Ressourcen mit AI Terraform; Sie lesen die Planausgabe und suchen nicht nach unerwarteten Löschungen.
Orchestrierung (Einheit 5): KI erstellt Kubernetes-Manifeste; Sie überprüfen das Ressourcenlimit, die Probe und den RBAC.
Sicherheit (Einheit 10): Priorisiert AI-Scan-Ausgaben; Sie schnappen sich zuerst die ausnutzbaren.
Überwachung (Einheit 6): KI generiert Alarmregeln und Dashboard; Sie testen die Schwellenwerte mit Ihren vergangenen Daten.
Freigabe und Validierung (diese Einheit): Beschreibt den KI-Rauchtest und den Rollback-Plan. Sie starten Canary, sehen sich die Messwerte an und drücken den Knopf.
Wenn ein Vorfall eintritt (Einheit 7): KI erstellt Hypothese und Obduktionsskizze; Sie überprüfen und lernen die Lektionen.
Kosten (Einheit 8): KI überwacht die Verschwendung neuer Ressourcen; Sie treffen die richtigen Entscheidungen zur Dimensionierung.

Bei jedem Schritt bleibt die gemeinsame Regel bestehen: KI produziert und beschleunigt, der Mensch überprüft und bürgt. Dies ist die Essenz des Moduls.

drei Mini-Koffer

Fall 1 – Canary begrenzte eine Katastrophe auf 5 %. Ein Team gab die neue Version an 5 % der Canary-Benutzer weiter. Das von der KI erstellte Dashboard zeigte sofort, dass die Fehlerquote in diesem Abschnitt auf 8 % anstieg. Das Team nahm es zurück, ohne es auf 100 % zu erhöhen; Das Problem betraf nur 5 % der Benutzer, und das nur für ein paar Minuten. Bei einem Big-Bang-Einsatz wären alle Kunden betroffen.

Fall 2 – Rauchtest hat den fehlenden Pfad erkannt. AI bot ein Rauchtestset an, es gab jedoch keinen Zahlungsablauf. Der Ingenieur fügte es hinzu, wohlwissend, dass die Bezahlung die wichtigste Einnahmequelle war. Der Post-Deploy-Test scheiterte direkt beim Auschecken – ein Schlüssel eines Drittanbieters war abgelaufen. Bei der Überprüfung wurde innerhalb von Minuten ein stiller Umsatzverlust festgestellt.

Fall 3 – Bereites Rollback, gespeichert in 90 Sekunden. Ein Team, das Blau-Grün installiert hat, hat die neue Version auf Grün umgestellt; Nach 2 Minuten verdoppelte sich die Verzögerung. Mit dem im Voraus vorbereiteten Rollback schalteten sie den Verkehr innerhalb von 90 Sekunden auf Blau um. Sie fanden die Grundursache (eine langsame Abfrage in der neuen Version) nicht unter Druck, sondern ruhig. Der bereitstehende Rollback-Pfad machte die Unterbrechung nahezu unsichtbar.

Vier kopierbare Vorlagen

1) Auswahl der Release-Strategie:

Ich werde den folgenden Dienst anbieten: [DIENST/KONTEXT: Anzahl der Benutzer, Ausfalltoleranz, Infrastruktur]. Welche empfehlen Sie zwischen Blaugrün-, Kanarien- und Feature-Flaggen? Vergleichen Sie in diesem Zusammenhang jeweils die Vorteile, Kosten und Rollback-Geschwindigkeit. Machen Sie einen Vorschlag, aber erklären Sie, dass ich die endgültige Entscheidung treffen werde.

2) Rauchtest / Verifizierungsliste:

Erstellen Sie einen Entwurf einer Rauchtest- und Verifizierungsliste für [SERVICE], die ich nach der Bereitstellung ausführen werde: Gesundheitsprüfung, die kritischsten Benutzerpfade, welche Metriken sollte ich wie viele Minuten lang überwachen? Gehen Sie davon aus, dass ich die kritischsten Geschäftspfade markiere und dieses Feld leer lasse.

3) Rollback-Plan:

Ich verwende [DEPLOY METHOD]. Schreiben Sie mir einen klaren Rollback-Plan: Mit welchem Befehl/Schritt führe ich ein Rollback auf die alte Version durch, wie lange dauert es, welche Risiken birgt das Rollback selbst (z. B. kann die Datenbankmigration nicht zurückgesetzt werden), was sollte ich vor dem Rollback überprüfen?

4) End-to-End-Release-Checkliste:

Erstellen Sie eine End-to-End-Vorbereitungscheckliste für die Veröffentlichung für ein neues [SERVICE]-Projekt: Code-/Image-Sicherheit, Pipeline, Infrastrukturplan, Überwachung und Alarmierung, Sicherheitsscans, Veröffentlichungsstrategie, Rollback und Überprüfung. Überprüfen Sie jeden Punkt mit der Frage „Bin ich bereit?“ Machen Sie daraus eine Frage.

Schwache Eingabeaufforderung / Starke Eingabeaufforderung

Schwach: „Wie bekomme ich das in das Produkt?“

Ergebnis: kein Kontext; AI listet allgemeine Bereitstellungsschritte auf, geht jedoch nicht auf Ihre Risikotoleranz, Benutzerskala und Rollback-Anforderungen ein.

Güçlü: „Ich werde einen Zahlungsdienst mit 10 Millionen Benutzern entwickeln, meine Toleranz für Ausfallzeiten ist sehr gering. Empfehlen Sie Canary oder Blue-Green, warum? Welche kritischen Pfade sollte ich nach der Bereitstellung testen, welche Metriken sollte ich für wie viele Minuten überwachen und wie sollte ein 60-Sekunden-Rollback-Plan aussehen? Die endgültige Entscheidung werde ich treffen.“

Unterschied: Die zweite Eingabeaufforderung gibt den Maßstab, die Toleranz und die Rollback-Erwartung an. Es erfordert Strategie + Verifizierung + Rückgängigmachung und überlässt die Entscheidung dem Menschen.

Häufige Fehler

Bereitstellung ohne Rollback-Plan. Wenn es kein Zurück mehr gibt, ist jeder Einsatz ein Glücksspiel.
Big-Bang-Einsatz. Die gleichzeitige Weitergabe an den gesamten Benutzer maximiert das Risiko.
Vorausgesetzt „grün = funktioniert“. Der Dienst, der die Integritätsprüfung bestanden hat, ist möglicherweise auf dem kritischen Pfad fehlerhaft.
Denken Sie, dass Sie wichtige Geschäftspfade der KI überlassen. Sie müssen die Methoden wie Zahlung markieren.
Keine Überwachung nach der Bereitstellung. Heimtückische Probleme tauchen nicht in der ersten Minute auf; Beobachtungsfenster erforderlich.
Denken Sie, dass die Datenbankmigration umkehrbar ist. Einige Änderungen werden nicht rückgängig gemacht; sind gesondert geplant.

Zusammenfassend

Der Übergang zur Produktion ist das kritischste Glied in der Kette und erfolgt nicht durch „Hoffen“, sondern mit kontrollierten Strategien: Blau-Grün sorgt für sofortiges Rollback, begrenzt den Canary-Effekt auf einen kleinen Teil und trennt die Bereitstellung von Feature-Flags von der Veröffentlichung. Die Arbeit ist nicht beendet, wenn die Bereitstellung abgeschlossen ist; Eine systematische Überprüfung durch Gesundheitschecks, Rauchtests und Golden-Signal-Überwachung ist unerlässlich. KI generiert und beschleunigt Entwürfe bei jedem Schritt im gesamten Modul – von der Docker-Datei bis zur Pipeline, von Terraform bis zur Alarmregel, von der Post-Mortem-Analyse bis zur Kostenanalyse. Aber es bleibt die kompetente Person, die jeden Schritt überprüft, den Go-Live-Knopf drückt und für das Ergebnis bürgt. Dies ist die goldene Regel für durchgängig KI-gestütztes DevOps.

Anwendungsaufgabe

Wählen Sie einen Dienst (real oder fiktiv) zum Veröffentlichen aus. (1) Wählen Sie mit der Vorlage „Release-Strategieauswahl“ eine Strategie aus, die zu Ihrem Kontext passt, und schreiben Sie, warum. (2) Lassen Sie sich eine Prüfliste mit der Vorlage „Rauchtest / Prüfliste“ erstellen und ergänzen Sie selbst die kritischsten Geschäftspfade. (3) Bereiten Sie einen 60-Sekunden-Rollback-Plan mit der Vorlage „Rollback-Plan“ vor und prüfen Sie, ob darin irreversible Schritte enthalten sind.

Checkliste

[ ] Ich habe eine Veröffentlichungsstrategie (Kanarienvogel/Blaugrün/Flagge) gewählt, die zu meinem Kontext passt.
[ ] Ich habe vor der Bereitstellung einen klaren und schnellen Rollback-Plan bereit.
[ ] Die kritischsten Geschäftspfade (z. B. Zahlung) habe ich selbst zu meinen Smoke-Tests hinzugefügt.
[ ] Nach dem Einsatz überwache ich die goldenen Signale durch ein Beobachtungsfenster.
[ ] Ich habe auch irreversible Schritte geplant (Datenbankmigration usw.).
[ ] Ich habe den KI-Plan bei jedem Schritt überprüft; Ich habe die Entscheidung getroffen, live zu gehen.

Modulprüfung

1. Welche der folgenden ist die beste Positionierung für DevOps und KI in der Cloud?

A) Künstliche Intelligenz ist ein Hilfsmittel und Entscheidungsunterstützungstool; Menschen tragen die Verantwortung für kritische Entscheidungen, die das Produkt betreffen ✔
B) Künstliche Intelligenz kann Produktbereitstellungen und geheime Rotationen ohne menschliche Zustimmung abschließen
C) Künstliche Intelligenz ist nur zum Schreiben von Dokumentationen nützlich, sie hat nichts mit Infrastruktur zu tun
D) Eine Prüfung ist unnötig, da künstliche Intelligenz immer zuverlässigere Befehle liefert als der Ingenieur

Beschreibung: Es handelt sich um ein Assistenten- und Entscheidungsunterstützungstool, das textintensive Aufgaben wie Pipeline, Konfiguration, Skript und Protokoll für künstliche Intelligenz beschleunigt. Die Verantwortung für Entscheidungen, die sich auf Ausfallzeiten, Geld und Sicherheit auswirken, wie z. B. Produktionsfreigabe, Geheimverwaltung und endgültige Anwendung, liegt beim zuständigen Ingenieur.

2. Welches ist der genaueste Ausdruck für die Verifizierungsdisziplin vor der Implementierung eines DevOps-Befehls oder einer durch künstliche Intelligenz erstellten Konfiguration?

A) Wenn die Ausgabe reibungslos und zuverlässig aussieht, kann sie direkt in Prod ausgeführt werden
B) Die Ausgabe ist nur dann sicher, wenn keine Syntaxfehler vorliegen, es sind keine weiteren Prüfungen erforderlich
C) Verbinden Sie die Ausgabe mit der Quelle, führen Sie einen Plan/Probelauf durch und filtern Sie sie mit Ihrem Systemkontext. dann anwenden ✔
D) Den ersten Versuch direkt im Produkt zu machen und das Ergebnis zu beobachten ist die schnellste Überprüfung

Erläuterung: Eine Überprüfung in drei Schritten ist unerlässlich: Verbinden der Ausgabe mit der Quelle (ist der Befehl/Flag tatsächlich in den offiziellen Dokumenten), es trocken laufen lassen (sehen, was mit dem Plan/--dry-run passiert) und es durch den Systemfilter leiten (passt es in seinen Architektur- und Sicherheitskontext). Geläufigkeit bedeutet nicht Genauigkeit.

3. Was ist der richtige Ansatz, wenn man künstliche Intelligenz nach einem Fehler oder Bereitstellungsproblem mit einer .env-Datei fragt, die ein echtes Datenbankkennwort enthält?

A) Maskieren Sie echte Geheimnisse mit <PLACEHOLDER>; Teilen Sie nur maskierte Fehler und Kontext ✔
B) Das Einfügen der gesamten .env-Datei im Originalzustand löst das Problem schneller
C) Da die Geheimnisse bereits Base64 sind, ist es sicher, sie einfach einzufügen
D) Das Einfügen des Passworts ist sicher, da die künstliche Intelligenz es niemals speichert

Beschreibung: Es werden keine echten Geheimnisse in die KI-Eingabeaufforderung eingefügt. Werte wie Passwörter und Token werden mit <PLACEHOLDER> maskiert; Nur die Fehlermeldung und der erforderliche Kontext werden geteilt. Wenn das Geheimnis bereits durchgesickert ist, sollte es sofort gelöscht und rotiert werden.

4. Welche der folgenden Punkte ist die korrekte Verwaltung von Geheimnissen (Passwort, Token) in einer CI/CD-Pipeline?

A) Es wird im geheimen Repository der Plattform gespeichert und per Referenz aufgerufen (z. B. ${{ Secrets.X }}), nicht im Klartext geschrieben ✔
B) Der Einfachheit halber im Klartext geschrieben, um YAML weiterzuleiten
C) Die Überprüfung erfolgt durch Drücken von Echo und Log zu Beginn jedes Auftrags.
D) Bei Definition mit der umfassendsten Berechtigung (Alles schreiben) erhöht sich die Sicherheit

Erläuterung: Geheimnisse werden nicht im Klartext in YAML geschrieben; Es wird im geheimen Repository der Plattform gespeichert und mit Referenzen wie ${{ Secrets.X }} aufgerufen. Darüber hinaus werden durch das Prinzip der geringsten Autorität die Token-Berechtigungen eingeschränkt und das geheime Protokoll wird nicht aufgezeichnet.

5. Was ist beim Infrastrukturmanagement mit Terraform der wichtigste Schritt, bevor eine Änderung live umgesetzt wird?

A) „Terraform Apply“ direkt ausführen; Der Plan ist Zeitverschwendung
B) Sichern der Statusdatei in einem öffentlichen Repository
C) Führen Sie „Terraform Plan“ aus und überprüfen Sie die Zeilen zum Zerstören/Ersetzen in der Ausgabe. Wenden Sie dann ✔ an
D) Deinstallieren Sie die Provider-Version und stellen Sie sicher, dass die neueste Version automatisch bereitgestellt wird

Erläuterung: „Terraform Plan“ muss vor „Terraform Apply“ ausgeführt werden. Der Plan zeigt, was hinzugefügt, was geändert und insbesondere gelöscht (zerstört) werden soll, ohne etwas zu tun. Wenn eine unerwartete Zerstörungs- oder Ersetzungszeile angezeigt wird, sollte „Apply“ nicht angewendet werden.

6. Was bedeutet es und was ist zu tun, wenn die Zeile „-/+ replace“ für die Produktionsdatenbank in einer Terraform-Planausgabe erscheint?

A) Die Quelle wird lediglich vor Ort aktualisiert, es besteht kein Risiko
B) Die Ressource wird gelöscht und neu erstellt; Es besteht die Gefahr eines Datenverlusts, die Anwendung sollte gestoppt werden, wenn dies nicht erwartet wird ✔
C) Beim Hinzufügen einer neuen Ressource ist die vorhandene Datenbank nicht betroffen
D) Dies ist nur eine Warnung, die getrost ignoriert werden kann

Erläuterung: „-/+ ersetzen“ bedeutet, dass die Ressource gelöscht und neu erstellt wird; Für eine Datenbank bedeutet das Datenverlust. Wenn dies nicht erwartet wird, sollte die Anwendung gestoppt, die Änderung in eine sichere Methode umgewandelt oder das unveränderliche Feld unberührt gelassen werden.

7. Welche der folgenden Aussagen trifft zu, damit eine Docker-Datei im Hinblick auf ihre Sicherheit und Größe produktionsbereit ist?

A) Der Einfachheit halber können Sie das Geheimnis mit ENV in das Image einbetten und es als Root ausführen
B) Verwenden Sie immer das Tag „:latest“ und halten Sie das Basisbild so groß wie möglich
C) Einstufiger Build und Belassen aller Build-Tools im endgültigen Image
D) Das Geheimnis nicht einbetten, mit nicht autorisierten Benutzern arbeiten, ein kleines und stabiles Basis-Image und einen mehrstufigen Build verwenden ✔

Beschreibung: Ein produktionsbereites Image: Bettet das Geheimnis nicht ein (fügt es zur Laufzeit ein), läuft mit einem nicht autorisierten BENUTZER statt mit Root, verwendet ein kleines und versioniertes Basisimage (slim/alpine, nicht :latest) und wird mit einem mehrstufigen Build verkleinert. Außerdem wird es vor der Veröffentlichung auf Schwachstellen überprüft.

8. Was ist das größte Risiko, wenn keine Ressourcengrenzen für eine Bereitstellung in Kubernetes definiert werden?

A) Der Pod startet nie, da „Limit“ ein Pflichtfeld ist
B) Auf der Überwachungsplatine erscheint nur eine Warnung, der Betrieb wird nicht beeinträchtigt
C) Kubernetes erzwingt automatisch sichere Standardlimits, kein Risiko
D) Der Pod kann unbegrenzt wachsen und die Ressourcen des Knotens verbrauchen, wodurch benachbarte Dienste abstürzen ✔

Erläuterung: Ein Pod ohne Ressourcenlimit kann unbegrenzt wachsen, alle Ressourcen des Knotens verbrauchen, auf dem er ausgeführt wird, und benachbarte Dienste zum Absturz bringen, beispielsweise durch einen Speicherverlust. Deshalb ist die Definition von Anforderungen/Limits die Grundlage für Robustheit.

9. Wie kann „Alarmmüdigkeit“ bei der Überwachung und Alarmeinrichtung vermieden werden?

A) Stellen Sie Alarme für so viele Metriken wie möglich ein und generieren Sie bei jeder Schwankung Warnungen.
B) Stellen Sie alle Alarme auf den höchsten Schweregrad ein
C) Auslösen von Alarmen mit Momentanwerten ohne Zeitvorgabe (für)
D) Alarme handlungsorientiert und mit der richtigen Dringlichkeit halten, Schwellenwerte mit historischen Daten testen und unnötige zusammenführen ✔

Beschreibung: Jeder Alarm muss umsetzbar sein und die richtige Dringlichkeit aufweisen. Informationen, die keiner Aktion bedürfen, werden auf der Tafel angezeigt, sie wecken niemanden. Alarmschwellenwerte werden anhand der historischen Daten des Systems getestet und unnötige/wiederholte Alarme werden konsolidiert. So geht der eigentliche Alarm nicht im Lärm unter.

10. Was ist die höchste Prioritätsreihenfolge bei einem Produktionsvorfall?

A) Finden Sie zunächst die genaue Grundursache und reduzieren Sie sie erst, wenn die Ursache klar ist.
B) Schreiben Sie zuerst den Obduktionsbericht und berühren Sie dann den Dienst
C) Zuerst reduzieren (Wiederherstellung/Wiederherstellungsdienst) und die Ursachenanalyse für später aufheben ✔
D) Suchen Sie zunächst die für den Vorfall verantwortliche Person und melden Sie ihn

Erläuterung: Die goldene Regel lautet „Zuerst reduzieren, später untersuchen“. Das Ziel besteht darin, den Dienst zunächst wiederherzustellen oder auf eine bekanntermaßen funktionierende Version zurückzusetzen (Mitigate); Die Ursachenanalyse erfolgt in aller Ruhe, nachdem der Druck nachgelassen hat. Das Warten darauf, die genaue Ursache zu finden, erhöht die Wiederherstellungszeit (MTTR).

11. Was ist der Hauptzweck einer tadellosen Postmortem-Kultur?

A) Identifizieren Sie die Person, die den Fehler gemacht hat, und übertragen Sie ihr die Verantwortung
B) Konzentration auf Systeme und Prozesse und Förderung des Lernens; ✔ Lektionen lernen, die Wiederholungen verhindern, statt Schuldzuweisungen
C) Melden Sie den Vorfall niemals und sorgen Sie dafür, dass er vergessen wird
D) Nur technische Details schreiben und keine umsetzbaren Elemente hinzufügen

Erläuterung: Die tadellose Obduktion konzentriert sich auf die Frage, „welches System und welcher Prozess diesen Fehler zugelassen hat“, nicht auf die Frage, „wer ihn begangen hat“. Menschen teilen den Fehler offen, wenn sie wissen, dass sie nicht bestraft werden; Der versteckte Fehler wird wiederholt. Der Bericht ist kein Anklagebericht, sondern ein Lerndokument voller handlungsorientierter Punkte.

12. Was ist bei der Cloud-Kostenoptimierung (FinOps) der logischste Schritt, bevor man zu festen Rabatten (Reserviert/Sparplan) übergeht?

A) Nehmen Sie sich zunächst eine möglichst lange Bindung vor und denken Sie später über die Verschwendung nach
B) Bereinigen Sie zunächst den Abfall (Leerlaufverschluss, richtige Dimensionierung) und verpflichten Sie sich dann zur zweckgebundenen Nutzung ✔
C) Verschieben Sie alle Ressourcen sofort auf die Spot-Kapazität
D) Löschen des teuersten Artikels ohne Prüfung der Rechnungsdaten

Erläuterung: Zunächst muss der Abfall beseitigt werden (Stilllegung ungenutzter Ressourcen, Reduzierung übergroßer Ressourcen). Andernfalls sperren Sie die verschwendete Nutzung zu einem vergünstigten Preis für 1–3 Jahre. Die richtige Dimensionierung und die Reinigung im Leerlauf erfordern keine Verpflichtung und sind nahezu risikofrei.

13. Was ist die wichtigste Sicherheitsmaßnahme, wenn ein von der KI vorgeschlagenes Skript die Zeile „rm -rf „$DIR“/“ enthält?

A) Wenn Sie das Skript direkt in prod ausführen, ohne es zu lesen, wird die Geschwindigkeit erhöht
B) Fügen Sie set -euo pipefail und empty variable control hinzu und versuchen Sie es zunächst mit einem Trockenlauf ✔
C) Es reicht aus, den Variablennamen zu kürzen
D) Die Verwendung von rm -rf --force anstelle von rm löst das Problem

Erläuterung: Wenn $DIR leer ist, versucht diese Anweisung möglicherweise, das Stammverzeichnis zu löschen. Wenn Sie mit „set -u“ bei der undefinierten Variablen anhalten und prüfen, ob die Variable nicht leer ist, bevor Sie sie löschen (z. B. [ -n „$DIR“ ] || Exit 1), können Sie eine Katastrophe vermeiden. Darüber hinaus sollten destruktive Vorgänge zunächst mit einem Trockenlauf versucht werden.

14. Was ist als Erstes zu tun, wenn ein Cloud-Zugriffsschlüssel versehentlich in ein öffentliches Repository gelangt?

A) Den Schlüssel sofort kündigen und erneuern (drehen); Löschen allein reicht nicht aus ✔
B) Löschen Sie einfach die Datei aus dem Speicher und der Schlüssel ist sicher
C) Nichts tun, weil es niemand gesehen hat
D) Wenn Sie den Speicher privat machen, entfällt die Notwendigkeit, den Schlüssel zu wechseln

Erläuterung: Das durchgesickerte Geheimnis muss sofort gelöscht und rotiert werden. Das bloße Löschen der Datei reicht nicht aus, da das Geheimnis im Git-Verlauf verbleibt und öffentliche Repositorys innerhalb von Sekunden von Bots gescannt werden. Nach der Stornierung/Rückgabe werden die Auswirkungen bewertet und ein geheimer Scanner hinzugefügt, um ein erneutes Auftreten zu verhindern.

15. Welcher der folgenden Ansätze minimiert das Risiko bei der Veröffentlichung einer neuen Produktversion?

A) Die neue Version allen Benutzern gleichzeitig zur Verfügung stellen (Big-Bang) und keinen Rollback-Plan vorbereiten
B) Es wird davon ausgegangen, dass die Bereitstellung abgeschlossen ist, sobald sie „grün“ erscheint, ohne dass eine zusätzliche Überprüfung durchgeführt wird
C) Verwendung einer kontrollierten Strategie wie Canary/Blue-Green/Feature-Flag, vorgefertigtem Rollback-Plan und Smoke-Test + Metriküberwachung nach der Bereitstellung ✔
D) Die Prüfung kritischer Geschäftspfade vollständig der künstlichen Intelligenz zu überlassen und sie überhaupt nicht zu bestimmen.

Erläuterung: Kontrollierte Release-Strategien (beginnend mit einem kleinen Prozentsatz mit Canary, sofortiges Rollback mit Blue-Green, Trennung von Bereitstellung und Release mit Feature Flag) begrenzen das Risiko. Darüber hinaus sind ein klarer Rollback-Plan vor dem Einsatz und eine Golden-Signal-Überwachung mit Rauchtests nach dem Einsatz unerlässlich; „Grün aussehen“ bedeutet nicht, dass es funktioniert.