TL;DR
Runbooks für Edge Failover müssen mehr enthalten als eine Liste technischer Kommandos. Entscheidend sind eindeutige Symptome, Zuständigkeiten, Prüfreihenfolgen und Abbruchkriterien. Nur wenn Health Checks, Failover-Status, Backend-Zustand und Rückkehr zum Regelbetrieb gemeinsam bewertet werden, bleibt Incident Response auch unter Zeitdruck kontrollierbar.
Einleitung
Ein Failover an der Edge ist nicht automatisch ein erfolgreicher Betrieb. Ein ausgefallenes Backend kann zwar aus dem Traffic genommen werden, während gleichzeitig ein fehlerhaftes Zielsystem, ein falscher Health Check oder eine unvollständige Zustandsänderung den Incident verlängert. Genau deshalb müssen Runbooks für Edge Failover die gesamte Entscheidungskette abbilden: vom ersten Symptom über die technische Bewertung bis zur kontrollierten Rückkehr in den Regelbetrieb. Ein belastbares Runbook reduziert dabei nicht nur Reaktionszeit. Es verhindert auch, dass mehrere Teams parallel widersprüchliche Änderungen vornehmen oder ein noch instabiles Backend zu früh wieder Traffic erhält.
1. Symptome und Zuständigkeiten eindeutig beschreiben
Der erste Teil eines Runbooks muss klären, woran ein Edge-Incident erkannt wird. Relevante Symptome können erhöhte Fehlerquoten, Timeouts, fehlgeschlagene TLS-Verbindungen, DNS-Auffälligkeiten oder der Ausfall einzelner Backends sein. Entscheidend ist die Zuordnung: Ein HTTP-Fehlerbild weist auf andere Prüfungen hin als ein nicht erreichbarer Health-Check-Endpunkt oder ein Problem an einem einzelnen PoP.
Für jedes Symptom braucht das Runbook eine definierte Erstbewertung und eine Eskalationslogik. Wer übernimmt Incident Response? Wer darf Failover-Entscheidungen treffen? Wer bewertet die Anwendung im Backend? Wer informiert abhängige Teams und dokumentiert den Zeitverlauf? Diese Rollen müssen auch außerhalb der regulären Arbeitszeiten bekannt sein.
Sinnvoll sind außerdem feste Angaben zu Beginn des Incidents, betroffenen Services, Zeitstempeln, Kommunikationskanälen und Freigaben. Dadurch wird aus einer Sammlung technischer Hinweise ein Betriebsprozess. Gerade bei einer verteilten Aktiv-Aktiv-Architektur verhindert diese Struktur, dass ein lokales Symptom vorschnell als globaler Ausfall interpretiert wird.
2. Health Checks nicht mit Anwendungsgesundheit verwechseln
Health Checks liefern ein technisches Signal, aber keine vollständige Aussage über die Betriebsfähigkeit einer Anwendung. Ein Endpunkt kann erreichbar sein, obwohl Datenbankzugriffe fehlschlagen, Abhängigkeiten nicht verfügbar sind oder nur ein Teil der Requests verarbeitet werden kann. Umgekehrt kann ein zu streng konfigurierter Check ein funktionsfähiges Backend unnötig aus dem Traffic nehmen.
Das Runbook sollte deshalb festlegen, welche Health-Check-Ergebnisse welche Handlung auslösen. Dazu gehören Prüfungen von Status, Antwortzeit, Erreichbarkeit, betroffenen Backends und gegebenenfalls mehreren Regionen oder Infrastruktursegmenten. Wichtig ist auch die zeitliche Einordnung: Ein einzelner Fehlversuch erfordert eine andere Reaktion als ein über mehrere Prüfintervalle bestätigter Ausfall.
Vor einem Failover muss das Incident-Team prüfen, ob das Signal tatsächlich zum Fehlerbild passt. Nach einem Failover darf nicht nur der Status „healthy“ betrachtet werden. Entscheidend sind zusätzlich Traffic-Verteilung, Fehlerraten und die fachliche Funktionsfähigkeit der Anwendung. Die Edge Cloud kann mit Backend Health Checks und Failover-Mechanismen die öffentliche Erreichbarkeit steuern; die Bewertung der Anwendung bleibt jedoch eine gemeinsame Aufgabe von Edge- und Backend-Verantwortlichen.
3. Failover-Status und Backend-Bewertung dokumentieren
Ein Runbook braucht einen expliziten Status für jede Phase: Normalbetrieb, degradierter Betrieb, Failover eingeleitet, Failover aktiv, Backend unter Prüfung und Wiederanlauf. Ohne diese Zustände entstehen Mehrdeutigkeiten. Ein Team kann sonst annehmen, der Traffic sei bereits umgestellt, während ein anderes noch von einer vorbereitenden Maßnahme ausgeht.
Für jedes betroffene Backend sollten Zustand, Ursache, letzte erfolgreiche Prüfung und aktuelle Erreichbarkeit dokumentiert werden. Ebenso wichtig ist die Frage, ob ein Zielsystem nur nicht erreichbar oder tatsächlich nicht belastbar ist. Ein Backend, das Verbindungen annimmt, aber Requests nicht zuverlässig verarbeitet, darf nicht allein aufgrund eines erfolgreichen Netzwerk-Checks wieder aktiviert werden.
Das Runbook sollte außerdem festlegen, wann ein Failover als abgeschlossen gilt. Dazu gehören beispielsweise bestätigte Traffic-Umleitung, stabile Health Checks am Ziel und die Prüfung relevanter Anwendungssignale. Bei einer Anycast-basierten, verteilten Edge müssen diese Kriterien über die betroffenen Traffic-Pfade hinweg betrachtet werden. Ein lokaler Erfolg reicht nicht zwingend als Nachweis für einen stabilen Gesamtbetrieb.
4. Wiederanlauf und Rückkehr zum Regelbetrieb steuern
Der Wiederanlauf ist kein Rückgängigmachen des letzten Schritts, sondern ein eigener Betriebsprozess. Zuerst muss die Ursache des Ausfalls ausreichend verstanden oder zumindest eingegrenzt sein. Danach wird das Backend kontrolliert vorbereitet: Abhängigkeiten, Ressourcen, Konfiguration und Health-Check-Verhalten werden geprüft. Ein Dienst kann technisch erreichbar sein, aber unter realer Last weiterhin instabil reagieren.
Das Runbook sollte eine gestufte Rückführung vorsehen. Dazu gehören eine definierte Beobachtungsphase, klare Abbruchkriterien und eine verantwortliche Person für die Freigabe. Wird Traffic zu früh vollständig zurückgeführt, kann der Incident erneut auftreten oder sich auf weitere Komponenten ausweiten. Bleibt der Betrieb dauerhaft im Failover, entstehen dagegen Kapazitäts- und Betriebsrisiken am verbliebenen Ziel.
Nach der Rückkehr müssen Failover-Status, Monitoring, Routing und Kommunikation wieder auf Normalbetrieb gesetzt werden. Erst danach ist der Incident abgeschlossen. Eine kurze Nachbereitung sollte prüfen, ob Symptome, Zuständigkeiten und Prüfschritte im Runbook noch korrekt sind. Betriebsprozesse werden belastbarer, wenn reale Abweichungen systematisch in die nächste Version einfließen.
Praxis- und Betriebsszenario
Ein API-Backend reagiert in einem Infrastruktursegment zunehmend mit Timeouts. Die Edge erkennt über Health Checks eine Verschlechterung und nimmt das Ziel gemäß der Failover-Logik aus der Verteilung. Das Runbook verpflichtet das Team zunächst, die betroffenen Traffic-Pfade und den Failover-Status zu bestätigen. Parallel bewertet das Backend-Team Datenbankverbindungen und Ressourcenverbrauch.
Nach der Stabilisierung meldet der Health Check wieder Erfolg. Das Team aktiviert das Backend jedoch nicht sofort vollständig, sondern prüft zunächst fachliche Requests und beobachtet die Fehlerquote. Erst nach dokumentierter Freigabe wird der Regelbetrieb wiederhergestellt. So verhindert die Trennung von Edge-Entscheidung und Backend-Bewertung, dass ein formal erreichbares, aber praktisch instabiles System erneut Traffic erhält.
FAQ
Welche Informationen müssen im Runbook aktuell gehalten werden?
Zuständigkeiten, Eskalationswege, Health-Check-Kriterien, Failover-Zustände, Freigaben und Abbruchkriterien. Technische Details sollten regelmäßig gegen die tatsächlich betriebene Konfiguration geprüft werden.
Wer entscheidet über die Rückkehr zum Regelbetrieb?
Die Entscheidung sollte eine benannte Rolle treffen, nachdem Edge- und Backend-Signale gemeinsam bewertet wurden. Technische Erreichbarkeit allein ist kein ausreichendes Freigabekriterium.
Wie oft sollten Edge-Runbooks getestet werden?
Nicht nur nach einem Incident. Geplante Reviews, Tabletop-Übungen und kontrollierte Tests zeigen, ob Zuständigkeiten, Prüfschritte und Kommunikationswege unter Zeitdruck funktionieren.
Fazit
Ein gutes Runbook für Edge Failover beschreibt nicht nur, welche technische Aktion möglich ist. Es definiert, wann sie gerechtfertigt ist, wer sie ausführt und woran Erfolg oder Abbruch erkannt werden. Diese Trennung von Symptom, Entscheidung, Backend-Bewertung und Wiederanlauf reduziert Fehlsteuerung im Incident. Eine Edge-Plattform wie die ayedo Edge Cloud bietet dafür den technischen Rahmen aus verteiltem Betrieb, Health Checks und Failover. Die betriebliche Stabilität entsteht jedoch erst durch standardisierte Prozesse, klare Verantwortlichkeiten und überprüfbare Freigaben.