Zum Hauptinhalt springen

Deployment-Alarme und automatischer Rollback

Prüfungsbezug: DOP-C02 Domain 1 zu Pipelines, Tests, Artefakten oder Deployment.

Lernziel

Technische und Business-Metriken mit sicheren Release-Entscheidungen verbinden.

Difficulty / SchwierigkeitsgradFortgeschritten
Study time / Lernzeit120 Minuten
Prerequisites / VoraussetzungenVorherige Lektionen dieses Bandes

Berufliches Szenario

Release besteht Instance Health, aber Zahlungsfehler steigen stark.

Kernkonzepte

  • Infrastruktur-Health ist nötig, aber nicht ausreichend.
  • Business-Metriken messen Kundenergebnis.
  • Alarme können unterstützte Deployments stoppen oder zurückrollen.
  • Rollback berücksichtigt Schema- und Konfigurationskompatibilität.

Architekturablauf

  1. Release-Input und unveränderliche Identität bestimmen.
  2. Managed AWS Control Plane und Least-Privilege-Rolle wählen.
  3. Build-, Test-, Artefakt- oder Deployment-Arbeit ausführen.
  4. Service Events, Logs, Reports und Runtime-Metriken sammeln.
  5. Nach klaren Regeln stoppen, wiederholen oder zurückrollen.

Entscheidungsmatrix

AnforderungBevorzugte WahlBegründung
Schneller schwerer FehlerKurzes robustes AlarmfensterSchnelle Begrenzung
Rauschende SignaleComposite AlarmWeniger Fehlrollback
Kritische TransaktionCustom Business MetricMisst Kundenergebnis

Fehlerbilder und Fehlersuche

  • Durchschnitt verdeckt Tail-Latenz.
  • Missing-Data-Verhalten ist falsch.
  • Code-Rollback kehrt Schema nicht um.

Sicherheit und Betrieb

  • Kurzlebige Service-Rollen und Least Privilege.
  • Artefakte verschlüsseln und Secrets aus Logs fernhalten.
  • Änderungen und Freigaben für Audit erfassen.

Praxislabor

Goal / Ziel: Einen technischen und einen Business-Rollback-Alarm erstellen.

Aufgaben

  1. Kleinste sichere Testarchitektur erstellen.
  2. Hauptworkflow umsetzen oder simulieren.
  3. Einen kontrollierten Fehler einführen.
  4. Anhand von Service-Nachweisen diagnostizieren.
  5. Cleanup und eine Verbesserung dokumentieren.

Validierung

  • Workflow nutzt unveränderliche Version.
  • Pflichtfehler blockiert Promotion.
  • Diagnose identifiziert ersten fehlerhaften Übergang.

Cost control / Kostenkontrolle: Ressourcen kurzlebig halten; Cleanup vorher lesen.

Aufräumen

  1. Pipeline-, Build- und Deployment-Ressourcen löschen.
  2. Temporäre Artefakte, Images, Logs und Rollen entfernen.

Prüfungsfallen

  • Nur CPU überwachen.
  • Nicht relevante Metrik verwenden.

Wichtigste Erkenntnisse

  • Infrastruktur-Health ist nötig, aber nicht ausreichend.
  • Rollback berücksichtigt Schema- und Konfigurationskompatibilität.
  • Entscheidungen werden mit Anforderungen und Fehlerverhalten begründet.

Wiederholungsfragen

  1. Was ist die unveränderliche Release-Identität?
  2. Welche Nachweise belegen Erfolg oder Fehler?
  3. Was ist die sicherste Recovery-Aktion?
Antworten
  1. Version, Digest oder eindeutig versioniertes Artefakt.
  2. Service Events, Logs, Reports, Health Checks und Runtime-Metriken.
  3. Bekannte gute Version über konfigurierten Rollback wiederherstellen.