Auto-Scaling-Policies, Kapazität und Failure Recovery

Prüfungsbezug: DOP-C02 Domain 3 — highly available, scalable, and automatically recoverable solutions.

Lernziel

Target Tracking, Step Scaling, Scheduled Scaling, Headroom und Quotas aus messbaren Availability-, Scaling- und Recovery-Anforderungen entwerfen, implementieren und untersuchen.

Berufliches Szenario

CPU bleibt niedrig, während Request Worker erschöpft sind und Benutzer Timeouts sehen.

Kernkonzepte

• Diese Lektion fokussiert Target Tracking, Step Scaling, Scheduled Scaling, Headroom und Quotas.
• Mit Business Impact sowie messbaren Availability-, RTO- und RPO-Zielen beginnen.
• Infrastruktur-, Daten-, Identity-, Quota-, Netzwerk-, Deployment- und menschliche Dependencies abbilden.
• Unbeabsichtigte SPOFs entfernen und Blast Radius begrenzen.
• Health Signals, Detection, Failover, Rollback und Failback definieren.
• Kapazität, Replication Lag und Recovery Duration messen.
• Tests und Operational Readiness als Teil der Architektur behandeln.

Architektur-Schrittfolge

1. Business-Anforderung in Availability, RTO, RPO, Kapazität und Failure Domains übersetzen.
2. Alle Dependencies und gemeinsamen Control Paths zeichnen.
3. Multi-AZ-, Cross-Region-, Decoupling-, Replication- oder Backup-Muster wählen.
4. Technische und Business-Health-Signale definieren.
5. Recovery mit begrenzten Rollen und bekannten Quotas automatisieren.
6. Tabletop, Restore-Test oder kontrolliertes Fault Experiment durchführen.
7. Ergebnisse mit Zielen vergleichen und System verbessern.

Entscheidungshilfe

Anforderung	Bevorzugte Richtung	Warum
Einen AZ-Ausfall überstehen	Multi-AZ Targets und überlebende Kapazität	AZ ist kein SPOF
Regionskatastrophe	Definierte Cross-Region-Strategie	Passt zu RTO, RPO und Kosten
Burst oder Dependency-Ausfall	Asynchrone Entkopplung und Backpressure	Verhindert kaskadierende synchrone Fehler
Logische Datenkorruption	Geschütztes Backup und PITR	Replikation kann Fehler kopieren
Produktionsvertrauen	Game Days und kontrollierte Fault Injection	Diagramme sind kein Nachweis

Fehlerbilder und Fehlersuche

• Standby besitzt keine aktuellen Daten, Secrets, Zertifikate, Quotas oder Kapazität.
• Traffic wird bewegt, bevor Recovery bereit ist.
• Retries verstärken Overload oder duplizieren nicht-idempotente Arbeit.
• Health Check ist zu flach und repräsentiert Business-Funktion nicht.
• Replikation ist aktiv, aber Lag und Fehler werden nicht überwacht.

Sicherheits- und Betriebsaspekte

• Recovery-Zugriff unabhängig von gestörter oder kompromittierter Umgebung halten.
• Backup Vaults, KMS Keys, DNS Changes, Replication Roles und Experiment Controls schützen.
• Least-Privilege-Automation-Rollen und Audit von Failover-Aktionen.
• Keine Kundendaten in Experimenten, Metriken, Logs oder Game-Day-Nachweisen.

Praxislabor

Ziel: Ein kontrolliertes Resilienzszenario entwerfen und validieren.

Aufgaben

1. Messbare Availability-, RTO- und RPO-Ziele notieren.
2. Dependencies und Failure Domains zeichnen.
3. Architektur und verworfene Alternativen wählen.
4. Health, Failover, Rollback und Failback definieren.
5. Einen kontrollierten Fault oder Tabletop Inject einführen.
6. Recovery messen und Verbesserungen erfassen.

Validierung

• Die Architektur erfüllt das definierte Ziel.
• Recovery hängt nicht von nicht verfügbaren Zugriffspfaden ab.
• Ergebnisse werden mit Zielen verglichen.

Kostenkontrolle: Für teure Multi-Region-Designs Tabletop-Simulation nutzen und alle Live-Testressourcen löschen.

Aufräumen

1. Experimente und synthetischen Traffic stoppen.
2. Temporäre Compute-, Replica-, Alarm-, Backup- und DNS-Testressourcen löschen.
3. Bestätigen, dass Produktions-Recovery-Ressourcen erhalten bleiben.

Prüfungsfallen

• Backup, Replikation, Durability und Availability gleichsetzen.
• Active/Active ohne Kosten, Konflikte und Betriebskomplexität wählen.
• Annehmen, ein Feature erfülle automatisch RTO oder RPO.
• Traffic bewegen, bevor Daten und Kapazität bereit sind.
• Ungetestetes Runbook als zuverlässige Recovery behandeln.

Wichtigste Erkenntnisse

• Target Tracking, Step Scaling, Scheduled Scaling, Headroom und Quotas beherrschen.
• Resilienzziele müssen messbar sein.
• Recovery benötigt bereite Daten, Kapazität, Routing, Berechtigungen und Betrieb.
• Tests liefern den Nachweis, dass das Design funktioniert.

Wiederholungsfragen

1. Welche Business-Anforderung treibt das Design?
2. Was ist die wichtigste Failure Domain?
3. Welche versteckte Dependency kann noch ausfallen?
4. Welches Health-Signal startet Recovery?
5. Welche RTO und RPO gelten?
6. Was muss vor Traffic Movement bereit sein?
7. Wie erfolgt Failback?
8. Wie wird das Design getestet?

Antworten

1. Das ausdrückliche Availability- und Recovery-Ziel.
2. Die kleinste Grenze, deren Ausfall den Service betrifft.
3. Eine gemeinsame Ressource, Credential, Quota, Control Path oder menschlicher Prozess.
4. Ein getesteter technischer oder Business-Indikator.
5. Sie stammen aus der Business-Impact-Analyse.
6. Daten, Kapazität, Version, Konfiguration, Credentials, Routing und Observability.
7. Über einen separaten kontrollierten und getesteten Workflow.
8. Mit Restore-Tests, Failover-Übungen, Game Days und Fault Injection.