Wenn ein mehrstufiger Prozess fehlschlägt, kann eine vollständige erneute Ausführung bereits eingetretene Auswirkungen wiederholen: zwei Bestellungen anlegen, zwei Benachrichtigungen versenden oder denselben Datensatz zweimal importieren. Bei der teilweisen Wiederherstellung fehlgeschlagener PHP-Prozesse wird ermittelt, welche Schritte bestätigt sind, welche gefahrlos wiederholt werden können und welche eine Kompensation oder menschliche Prüfung erfordern.
Die Entscheidung hängt von der Semantik der jeweiligen Operation ab, nicht nur davon, wo eine Exception aufgetreten ist. Eine ausgebliebene Antwort einer API beweist beispielsweise nicht, dass das externe System die Anfrage abgelehnt hat. Der Prozess könnte abgeschlossen worden sein, während die Verbindung ausfiel, bevor PHP das Ergebnis erhielt. Wer diesen Fall einplant, verwechselt eine unterbrochene Ausführung nicht mit einer nie erfolgten Ausführung.
Zwischen erneutem Versuch, Fortsetzen und Kompensieren wählen
Ein vollständiger erneuter Versuch führt alle Schritte erneut aus. Das ist angemessen, wenn der gesamte Ablauf idempotent ist – eine Wiederholung also denselben Endzustand hinterlässt – oder wenn noch keine externen Auswirkungen eingetreten sind. Lässt sich keine dieser Bedingungen garantieren, ist eine Wiederholung ohne vorherige Prüfung riskant.
Fortsetzen bedeutet, beim ersten nicht bestätigten Schritt weiterzumachen. Dazu müssen der Status der Schritte und ihre Ergebnisse protokolliert werden. Außerdem muss sich die Auswirkung eines Aufrufs wiederherstellen oder überprüfen lassen, wenn dessen Ergebnis unklar ist. Es bedeutet nicht, alles zu überspringen, was abgeschlossen zu sein scheint: Dafür sind persistierte Nachweise erforderlich.
Kompensieren bedeutet, eine Aktion auszuführen, die eine frühere Auswirkung ausgleicht, zum Beispiel eine Reservierung zu stornieren. Dadurch wird der ursprüngliche Zustand nicht immer exakt wiederhergestellt: Eine bereits versendete Benachrichtigung lässt sich nicht zurücknehmen, und für eine eingezogene Zahlung kann eine Erstattung mit eigener Frist und Protokollierung erforderlich sein. Eine Kompensation ist daher eine explizite Geschäftsoperation und kein automatischer Datenbank-Rollback.
Schritte mit Status und persistierten Ergebnissen modellieren
Stelle den Ablauf als Sequenz oder Zustandsmaschine dar, deren Schritte stabile Namen, eindeutig identifizierbare Eingaben und persistierte Ergebnisse haben. Ein erstes Modell könnte Status wie pending, running, succeeded, retryable, failed und manual_review enthalten. Definiere die zulässigen Übergänge und verhindere, dass ein Prozess in einen Endstatus wechselt, ohne die erforderlichen Nachweise zu speichern.
Ein Datensatz pro Prozess kann eine stabile ID, den Ablaufstyp, den Gesamtstatus, die Version der Prozessdefinition, Start- und Aktualisierungszeitpunkte, den Versuch und den Grund für den letzten Übergang enthalten. Für jeden Schritt sollten Status, Operations-ID, Zeitstempel und eine Referenz auf das relevante Ergebnis gespeichert werden. Persistiere nur die Informationen, die zum Fortsetzen oder Erklären des Ergebnisses erforderlich sind; kopiere nicht wahllos vollständige API-Antworten oder Geheimnisse.
In PHP kann der Koordinator den Statusübergang von der Ausführung des Schritts trennen. Wenn mehrere Worker dieselbe Arbeit übernehmen können, muss die Aktualisierung atomar sein: Verwende eine Transaktion oder einen geeigneten Sperrmechanismus und protokolliere, wer den Prozess beansprucht hat und bis wann. Eine Sperre mit Ablaufzeit muss es ermöglichen, verlassene Aufgaben wieder aufzunehmen, ohne einen nur teilweise ausgeführten Schritt als abgeschlossen zu behandeln.
Kontrollpunkte festlegen, ohne „Exactly once“ vorauszusetzen
Speichere nach jedem Ergebnis, das das System zuverlässig bestätigen kann, einen Kontrollpunkt. Bei lokalen Operationen kann dies eine Transaktion sein, die die Geschäftsänderung und den Status des Schritts gemeinsam speichert. Bei einem externen Aufruf gibt es keine gemeinsame Transaktion zwischen der Datenbank und dem Anbieter: Der Prozess kann angehalten werden, nachdem der Anbieter gehandelt hat, aber bevor PHP die Antwort protokolliert.
Verwende an dieser Grenze einen Idempotenzschlüssel, sofern der Anbieter dies unterstützt. Leite ihn aus einer stabilen ID des Prozesses und des Schritts ab. Falls die Unterstützung fehlt, frage den Remote-Status anhand einer Operations-ID ab, bevor du die Anfrage wiederholst. Gibt es weder Idempotenz noch eine zuverlässige Abfragemöglichkeit, behandle das Ergebnis als unklar und leite den Fall zur Prüfung weiter. Ein Timeout reicht nicht aus, um zu schließen, dass die Operation nicht stattgefunden hat.
Bei asynchronen Aufgaben ermöglicht das transaktionale Outbox-Muster, die lokale Änderung und die ausstehende Nachricht innerhalb derselben Transaktion zu speichern. Ein Worker stellt die Nachricht anschließend zu; auch der Verbraucher muss Duplikate tolerieren, beispielsweise indem er die IDs bereits verarbeiteter Nachrichten speichert. Diese Mechanismen verringern Inkonsistenzen, machen aber nicht automatisch eine gesamte verteilte Integration zu einer atomaren Operation.
Grenzen für erneute Ausführungen und Kompensationen festlegen
Lege für jeden Schritt fest, welche Fehler vorübergehend, welche endgültig und welche mit einem unbekannten Ergebnis verbunden sind. Vorübergehende Fehler können erneute Versuche mit zunehmender Wartezeit und zufälliger Streuung erlauben; lege eine maximale Zahl von Versuchen und eine Gesamtfrist fest. Validierungs- oder Berechtigungsfehler lassen sich durch Wiederholungen in der Regel nicht beheben: Es ist sinnvoll, den Ablauf anzuhalten, die Ursache zu korrigieren und zu entscheiden, ob eine neue Ausführung angebracht ist.
Dokumentiere für jede externe Auswirkung, ob sie wiederholt, abgefragt, kompensiert oder nicht rückgängig gemacht werden kann. Behalte das Ergebnis bei, wenn die Operation gültig ist und eine Wiederholung schädlicher wäre als der Teilzustand; kompensiere nur, wenn eine sichere und autorisierte Geschäftsaktion verfügbar ist. Halte an und eskaliere den Fall, wenn anhand der Daten nicht festgestellt werden kann, was geschehen ist, auch die Kompensation fehlschlägt oder die Aktion finanzielle, rechtliche oder kundenbezogene Auswirkungen hat, die eine Genehmigung erfordern.
Eine Kompensationsrichtlinie muss Reihenfolge, Bedingungen, Verantwortliche und erwartetes Ergebnis festlegen. Protokolliere die Kompensation als neuen, mit der ursprünglichen Auswirkung verknüpften Schritt, statt deren Verlauf zu löschen. So kann der Betrieb unterscheiden, ob eine Aktion nie ausgeführt oder ausgeführt und anschließend kompensiert wurde.
Dem Betrieb die nötigen Kontrollen und den Handlungskontext geben
Die Konsole oder das Betriebsverfahren sollte den Gesamtstatus und die Status der einzelnen Schritte, den zuletzt klassifizierten Fehler, die Zahl der Versuche, externe Referenzen und die zulässige Aktion anzeigen. Vermeide eine allgemeine Schaltfläche „Alles erneut versuchen“. Biete klar begrenzte Optionen an: einen idempotenten Schritt erneut ausführen, den Remote-Status abfragen, eine Kompensation ausführen oder den Fall eskalieren.
Sichere diese Aktionen durch rollenbasierte Autorisierung ab; verlange für sensible Auswirkungen eine zusätzliche Bestätigung und protokolliere, wer wann gehandelt, was ausgewählt und warum entschieden hat. Wenn eine erneute Ausführung Eingabedaten verändert, muss eine neue Ausführung oder eine explizite Überarbeitung angelegt werden, statt die Eingabe eines historischen Prozesses stillschweigend zu ändern.
Um Fehler zu diagnostizieren, ohne sensible Informationen offenzulegen, bewahre Korrelations-IDs, Fehlercodes, die Prozessversion und die erforderlichen Referenzen zum Abfragen der Quellsysteme auf. Schwärze Tokens, personenbezogene Daten und vollständige Payloads. Lege außerdem fest, wie lange Protokolle aufbewahrt werden und wer sie einsehen darf. Eine nützliche Ablaufverfolgung erklärt, was geschehen ist, ohne zu einer unnötigen Kopie der Geschäftsdaten zu werden.
Fehler testen und die Wiederherstellung schrittweise bereitstellen
Teste Unterbrechungen an konkreten Punkten: vor der Ausführung eines Schritts, nachdem der Anbieter gehandelt hat, aber bevor die Antwort gespeichert wurde, während einer Kompensation und wenn zwei Worker gleichzeitig versuchen, denselben Prozess zu beanspruchen. Prüfe für jeden Fall, ob der Status konsistent ist, Auswirkungen nicht dupliziert werden und manuelle Aktionen protokolliert sind.
Beziehe Tests für unklare Antworten, wiederholte Idempotenzschlüssel, ungültige Daten, Wiederholungsgrenzen und Änderungen der Ablaufversion ein. Integrationstests mit simulierten Abhängigkeiten können kontrollierte Fehler nachstellen. Wenn sich der reale Anbieter anders verhält, überprüfe den Vertrag und die Abfragemöglichkeiten zusätzlich in einer geeigneten Umgebung.
Beginne bei einem bestehenden Ablauf damit, seine Schritte nach Umkehrbarkeit und Idempotenz zu klassifizieren. Persistiere anschließend den Status einer begrenzten Etappe, implementiere die Wiederherstellung für die risikoreichsten Fehler und beobachte ausstehende Fälle, bevor du den Umfang erweiterst. Lösche oder setze keine historischen Datensätze zurück, um die Bereitstellung zu erleichtern: Bewahre die Nachvollziehbarkeit und lege fest, wie Prozesse zu interpretieren sind, die mit früheren Versionen erstellt wurden.
Checkliste für die Implementierung der Wiederherstellung
- Hat jeder Schritt eindeutig identifizierbare Eingaben, einen persistierten Status und ein überprüfbares Ergebnis?
- Ist bekannt, welche Aufrufe idempotent sind und was bei einem unklaren Ergebnis zu tun ist?
- Gibt es Grenzen für die Zahl der Versuche, Fristen und eine Klassifizierung der Fehler?
- Sind Kompensationen als Geschäftsaktionen mit Audit-Protokollierung und Verantwortlichen definiert?
- Kann der Betrieb mit geeigneten Berechtigungen Abfragen durchführen und handeln, ohne auf unnötige Daten zuzugreifen?
- Wurden Fehler zwischen Schritten, Parallelität, erneute Ausführungen und fehlgeschlagene Kompensationen getestet?
- Gibt es ein Eskalationsverfahren für Fälle, in denen eine automatische Fortsetzung nicht sicher ist?
Als praktischer Maßstab gilt: Bewahre genügend Nachweise auf, um über den nächsten Schritt zu entscheiden, und halte die Automatisierung an, wenn diese Nachweise nicht ausreichen. Eine sichere Wiederherstellung versucht nicht zu verbergen, dass ein Fehler aufgetreten ist: Sie macht transparent, was abgeschlossen wurde, was noch aussteht und wer den Fall lösen kann.
