Incident-Runbook

Dieses Runbook hilft der Vorfallleitung, den Kundendienst zu schützen, festzustellen, welches Teilsystem für den Fehler zuständig ist, und einen umkehrbaren Wiederherstellungsweg zu wählen. Die Vorfallleitung ist für Prioritäten und Kommunikation zuständig; der Plattform-Operator für die Belege zu Opfield und verwalteten Nodes; Anwendungs- und Datenbankverantwortliche prüfen ihre Dienste. Lassen Sie nicht die Person, die Befehle eintippt, zur einzigen Person werden, die über Risiken entscheidet.

Erfolg bedeutet, dass die Auswirkung auf Kunden verstanden ist, weitere Änderungen kontrolliert sind, der maßgebliche Laufzeitzustand abgeglichen ist und die Wiederherstellung über den benutzerseitigen Pfad geprüft wurde. Ein grünes Dashboard allein ist kein Wiederherstellungsnachweis.

Die ersten fünf Minuten

1. Halten Sie Startzeit, betroffenen Kundenpfad und jüngste Änderungen fest.
2. Prüfen Sie den Zustand von Opfield, PostgreSQL, Redis und Relay.
3. Ermitteln Sie, ob die Auswirkung die Control Plane, den Ingress, einen Node, einen Workload oder eine gemeinsame Abhängigkeit betrifft.
4. Frieren Sie unabhängige Änderungen ein.
5. Verwenden Sie den Wartungsmodus oder einen Vorfall auf der Statusseite, wenn eine Auswirkung auf Kunden bestätigt ist.

Relay nicht verfügbar

Prüfen Sie den Relay-Dienst, das Identitäts-Volume, die Erreichbarkeit der Datenbank, die Image-Version und den öffentlichen Port 9443/tcp. Prüfen Sie unter Settings > Relay für jedes Mitglied den Zustand des Richtlinienvertrauens und des Zertifikats: Opfield stellt das Vertrauen des lokalen Relays automatisch wieder her, und ein entferntes Mitglied, das zur erneuten Registrierung markiert ist oder ein abgelaufenes Zertifikat hat, kann mit Re-enroll oder Renew certificate wiederhergestellt werden; siehe Relay-Wiederherstellung in 2.11. Verschieben Sie den Port nicht zurück zur Anwendung und umgehen Sie die Autorisierung nicht mit einem neuen öffentlichen Listener.

Node offline

Bestehende Workloads laufen möglicherweise weiter. Availability-Richtlinien im Lease-Modus verschieben die Slots des Nodes selbstständig auf andere Kandidaten; prüfen Sie Lease mode und die Inhaber in der Availability-Zusammenfassung des Workloads, bevor Sie handeln. Prüfen Sie Stromversorgung und Netzwerk des Hosts, den Daemon-Dienst, die Zeit, die Zertifikatsidentität und die ausgehende Erreichbarkeit von Relay. Ändern Sie nichts auf Grundlage veralteten Inventars.

Fehlerhaftes Release

Setzen Sie Deployments auf den vorherigen fehlerfreien Slot zurück. Verschieben Sie bei Pages den Tag. Stellen Sie bei in Git gebauten Containern den letzten freigegebenen Digest erneut bereit. Meldet das Ziel BUILD_ROLLOUT_IN_PROGRESS, warten Sie, bis das laufende Rollout abgeschlossen ist oder fehlschlägt, bevor Sie erneut bereitstellen. Bewahren Sie Logs und Operationsverlauf.

Fehler eines Datenbank-Bindings

Prüfen Sie Relay, beide Nodes, den Zustand der Datenbank, den Sollzustand des Bindings, die Verbindung des Bindings auf dem Secure-Link-Connector des Ziel-Nodes und den Engine-Prinzipal. Wiederholen Sie den Abgleich, bevor Sie Identitäten manuell ändern; es gibt keinen Connector-Container pro Binding und keinen Host-Listener, der neu gestartet oder ersetzt werden müsste.

Verwenden Sie die Prüfungen Ebene für Ebene unter Anwendungs-Bindings für Datenbanken und bewahren Sie den fehlgeschlagenen Task, bevor Sie es erneut versuchen. Melden Clients unter Last Connection terminated unexpectedly oder ECONNRESET, insbesondere während eines Rollouts, lesen Sie zuerst die Laufzeit der Verbindung: Ein wachsendes throttledTotal, auf dem Node als managed link connection rejected mit reason=link_limit protokolliert, bedeutet, dass die Pools der Container die Kapazität der Verbindung überschreiten, die das eigene Verbindungslimit der Datenbank ist und von allen ihren Verbindungen geteilt wird; siehe Verbindungskapazität und Verbindungspools.

Abschluss

Bestätigen Sie die Wiederherstellung von einem externen Client aus, heben Sie die Wartung bewusst auf, dokumentieren Sie die Ursache und die Erkennungslücke und erstellen Sie Folgearbeiten für jede vorübergehende Gegenmaßnahme.

Control Plane nicht verfügbar

Prüfen Sie den Opfield-Container bzw. -Prozess, PostgreSQL, Redis, persistente Volumes, Festplattendruck, Migrationen und Anwendungslogs. Solange die API noch antwortet, kann der Assistent oder ein MCP-Client mit diagnostics:view all dies mit manage_opfield_diagnostics lesen, und diagnostics:logs ergänzt die Container-Logs; siehe Opfield-Diagnose. Bewahren Sie die bestehenden Verschlüsselungsschlüssel und die Datenbank, bevor Sie eine Ersatzinstanz versuchen. Laufen Kunden-Workloads weiter, vermeiden Sie breite Änderungen am Host, während Sie die Control Plane wiederherstellen.

Stellen Sie zuerst fest, ob Relay noch erreichbar ist. Ist Relay fehlerfrei, können bereits angewendete nginx-Konfiguration, Container, Datenbanken und erlaubte bestehende private Datenströme weiterlaufen, während neue Verwaltungs- und Autorisierungsentscheidungen warten. Relays lassen neue Secure-Link- und Datenbankverbindungen anhand ihrer letzten signierten Richtlinie für die Dauer der Richtlinien-Lease weiter zu, Availability-Richtlinien im Lease-Modus führen weiter Failover durch, und die öffentliche Statusseite wird aus dem Cache des Ingress Nodes ausgeliefert. Ist das einzige Relay lokal auf dem ausgefallenen Opfield-Host, verlieren auch Secure Links und Sitzungen verwalteter Nodes ihren Transport; gewöhnliche hostlokale Workloads können weiterlaufen, aber bestehende, von Relay abhängige Datenströme sind nicht garantiert. Unabhängige externe Relay-Mitglieder verringern diesen gemeinsamen Ausfall nur, wenn Nodes sie tatsächlich erreichen und verwenden können.

Prüfen Sie nach der Rückkehr von Opfield Anmeldung, Entschlüsselung, Zustand von Relay, Hintergrundjobs, Update-Erkennung, Benachrichtigungen und frische Node-Momentaufnahmen. Nehmen Sie nicht an, dass sich Daemons abgeglichen haben, nur weil das Dashboard lädt.

Verwenden Sie Verfügbarkeit, Kompatibilität und Grenzen, um die betroffenen Pfade einzuordnen, und Updates und Backups, bevor Sie eine Ersatzinstanz wiederherstellen oder persistenten Zustand ändern.

Ingress-Ausfall

Folgen Sie der Fehlerbehebung beim Ingress von DNS über Netzwerk, TLS, Anwendung durch nginx und Health-Zustand der Route bis zum Upstream. Verwenden Sie den Wartungsmodus, wenn der virtuelle Host während der Reparatur stabil bleiben soll. Bewahren Sie Validierungsfehler der generierten Konfiguration und Belege externer Anfragen.

Workload-Operation hängt

Prüfen Sie den dauerhaften Task, die Verbindung des zuständigen Nodes, den Operationsverlauf des Daemons, die Laufzeitressource und die Request- bzw. Operations-ID. Eine Zeitüberschreitung im Browser beweist nicht, dass der Befehl fehlgeschlagen ist. Gleichen Sie die erste Operation ab, bevor Sie ein doppeltes Erstellen, Neuerstellen, eine doppelte Migration oder ein doppeltes Löschen starten.

Ist Force Cancel verfügbar, verstehen Sie, ob es nur die Verfolgung in Opfield abbricht oder auch einen Abbruch an den Zuständigen sendet. Aktualisieren Sie nach dem Abbruch den Laufzeitzustand und entfernen Sie eine Markierung einer unterbrochenen Operation nur über den unterstützten Abgleichsweg.

Verwenden Sie Tasks, Ereignisse und Audit, um angenommene, laufende, abgebrochene und abgeschlossene Arbeit zu unterscheiden, und fahren Sie dann mit der zuständigen Docker-Ressource fort.

Datenbank nicht verfügbar

Trennen Sie Fehler bei Engine-Zustand, Speicher, direkter Veröffentlichung, verwaltetem Binding und Anwendungsabfragen. Prüfen Sie den Storage Node, den Engine-Container, Speicher-Image bzw. -Mount, die Monitoring-Momentaufnahme, den Relay-Pfad, den Ziel-Docker-Node, den Secure-Link-Connector des Nodes, die Binding-Identität und die Anwendungskonfiguration.

Löschen Sie die Datenbank oder den Engine-Prinzipal nicht als Diagnoseschritt. Bewahren Sie Speicher und Operationsverlauf und wiederholen Sie dann den eng umrissenen fehlgeschlagenen Abgleich.

Fahren Sie mit Datenbankbetrieb für Prüfungen zu Engine, Speicher, Backup und Wiederherstellung fort oder mit Anwendungs-Bindings für Datenbanken, wenn nur der private Anwendungspfad betroffen ist.

Kommunikation und Belege

Führen Sie eine Vorfall-Zeitleiste mit UTC-Zeitstempeln, betroffenen Ressourcen, für Benutzer sichtbaren Auswirkungen, Änderungen, Task-IDs, Request-IDs, Entscheidungen und Prüfungen. Öffentliche Updates beschreiben Auswirkung und Fortschritt, ohne Topologie oder Sicherheitsdetails offenzulegen.

Schwelle für die Wiederherstellung

Die Wiederherstellung erfordert:

• dass der kundenseitige Pfad von außerhalb des verwalteten Netzwerks funktioniert;
• dass der Sollzustand in Opfield dem aktuellen Zustand des Zuständigen entspricht;
• dass Alarme sich aus dem richtigen Grund erholen;
• dass eingereihte Operationen und Zustellungen verstanden sind;
• dass vorübergehende Offenlegungen oder Umgehungen entfernt sind;
• dass für jedes verbleibende Risiko ein Verantwortlicher und eine Frist existieren.

Entscheidungsrahmen für die Vorfallleitung

Bevorzugen Sie Maßnahmen, die Belege bewahren und den Wirkungsradius verringern. Pausieren Sie unabhängige Automatisierung, bevor Sie gemeinsam genutzte Dienste neu starten. Ist die Control Plane nicht verfügbar, liefern Workloads aber weiterhin Datenverkehr aus, stellen Sie die Verwaltung wieder her, ohne fehlerfreie Ressourcen neu zu erstellen. Ist der Ingress fehlerhaft, halten Sie den Hostnamen mit dem Wartungsmodus oder einem getesteten Rollback stabil, statt DNS wiederholt zu ändern. Ist die Datenintegrität unsicher, stoppen Sie Schreibvorgänge, bevor Sie die Verfügbarkeit optimieren.

Eskalieren Sie sofort, wenn der Vorfall eine mögliche Offenlegung von Zugangsdaten, beschädigten Speicher, einen unbekannten Zustand einer Schemamigration, den Verlust der Relay-Identität, eine inkonsistente Zuständigkeit für Datenbank-Bindings oder ein Release-Artefakt umfasst, das nicht geprüft werden kann. Diese Bedingungen können aus einem routinemäßigen Neustart einen dauerhaften Verlust oder unbefugten Zugriff machen.

Belegtabelle für Operatoren

Beleg	Warum er wichtig ist
Externes DNS, TLS und Anwendungsantwort	Bestätigt die tatsächliche Auswirkung auf Kunden
Zustand von Opfield, PostgreSQL, Redis und Relay	Trennt Ausfälle der Control Plane von denen der Datenebene
Letzte Meldung, Fähigkeitszustand und Daemon-Logs des Nodes	Ermittelt den zuständigen Laufzeit-Eigentümer und veraltetes Inventar
Task-, Operations- und Request-IDs	Verhindert doppelte oder mehrdeutige Änderungen
Letzte freigegebene Version und Artefakt-Digest	Liefert ein bekanntes Rollback-Ziel
Backup-Status von Datenbanken und Volumes	Legt sichere Wiederherstellungsoptionen fest

Führen Sie nach der Wiederherstellung eine kurze Nachbetrachtung durch, solange die Belege noch verfügbar sind. Halten Sie die auslösende Änderung fest, warum die Erkennung funktioniert hat oder nicht, welche manuellen Schritte nötig waren und welche Prüfung das Problem früher erkannt hätte. Wandeln Sie vorübergehende Anweisungen in eine getestete Runbook-Änderung um, statt einen undokumentierten Shell-Verlauf aufzubewahren.