Deine primäre Region ist degradiert und das Business will einen Failover. Führ mich da durch.

Klär den Umfang der Störung und ob ein Failover wirklich schneller ist als Warten, denn ein Failover ist nicht umsonst und Teilausfälle erholen sich manchmal früher. Hol eine explizite Entscheidung von einem Verantwortlichen und folge dann dem Runbook: Replica promoten und den bekannten Datenverlust akzeptieren, Traffic auf DNS- oder Routing-Ebene umschalten, mit echten Requests verifizieren und kommunizieren. Plan den Failback später bewusst, sobald das Primary stabil ist.

Das Erste ist: ein Failover ist eine Entscheidung, kein Reflex. Ich will den Umfang wissen, ob es ein Service ist oder die ganze Region, und was der Provider sagt, denn wenn die Schätzung fünfzehn Minuten lautet, ist ein Failover, der dreißig dauert und Daten verliert, die schlechtere Option. Ich bringe diese Einschätzung also zum Incident Commander oder zum Business Owner und die treffen die Entscheidung explizit, denn niemand sollte um drei Uhr morgens im Alleingang Datenverlust akzeptieren. Sobald die Entscheidung steht, folge ich dem Runbook statt zu improvisieren. Replica in der Sekundärregion promoten, im Wissen, dass wir den Replication Lag akzeptieren, der im Moment des Ausfalls bestand, und ich schreibe diese Zahl für die spätere Abstimmung auf. Traffic auf der Routing-Ebene umschalten, und hier prüfe ich, ob Health Checks und Record-Lebensdauern kurz genug sind, um schnell umzuziehen, denn ein lang gecachter Record lässt das viel länger dauern als erwartet. Dann mit echten Requests verifizieren statt mit einem Dashboard. Und der Failback ist eine eigene geplante Änderung während der Geschäftszeiten, niemals ein hektischer zweiter Failover.