Die Automatisierung eines Vorgangs bedeutet nicht immer, dass er ohne menschliches Eingreifen ausgeführt wird. Wenn eine Aktion wichtige Daten verändern, eine geschäftliche Bedingung anwenden, Geld transferieren oder Dritte betreffen kann, muss sie möglicherweise warten, bis eine Person sie autorisiert. Ein menschlicher Freigabeprozess in PHP-Automatisierungen schafft diese Kontrolle, ohne den Prozess in eine informelle Kette aus Nachrichten und schwer nachvollziehbaren Entscheidungen zu verwandeln.
Entscheidend ist nicht, einfach eine Schaltfläche zum „Freigeben“ hinzuzufügen, sondern festzulegen, was vorgeschlagen wird, wer entscheiden darf, auf Grundlage welcher Informationen, für welchen Zeitraum und was anschließend geschieht. Das System muss jeden Status erklären können und verhindern, dass eine veraltete oder doppelte Freigabe eine andere Aktion ausführt als die geprüfte.
Entscheiden, wann ein Vorgang pausiert werden soll
Eine nachträgliche Prüfung hilft, Probleme zu erkennen, nachdem die Aktion erfolgt ist. Eine vorherige Freigabe hingegen hält die Ausführung an, bis eine Entscheidung vorliegt. Eine Autorisierung sollte erforderlich sein, wenn die potenziellen Auswirkungen, die Schwierigkeit, die Aktion rückgängig zu machen, oder die Unsicherheit das für die Automatisierung akzeptierte Maß übersteigen.
Bewerten Sie jeden Vorgang anhand konkreter Fragen: Kann sich ein schwer wiederherstellbarer Datenwert ändern? Betrifft der Vorgang Geld, Rechte, Zugriff oder Verpflichtungen gegenüber Kunden? Gibt es eine überprüfbare Regel, die eine autonome Ausführung erlaubt? Wie groß wäre der Schaden im Fehlerfall, und wie viel Zeit bleibt für eine Reaktion? Ein routinemäßiger, reversibler und begrenzter Vorgang könnte automatisch ausgeführt und zur späteren Prüfung protokolliert werden. Für eine außergewöhnliche oder folgenreiche Aktion kann eine Autorisierung vor der Ausführung erforderlich sein.
Verlangen Sie nicht standardmäßig für alles eine menschliche Freigabe. Eine überlastete Warteschlange verursacht Verzögerungen und fördert mechanische Freigaben. Definieren Sie Schwellenwerte und Ausnahmen und messen Sie offene Fälle, Wartezeiten, Ablehnungen und Ablaufereignisse, um Regeln zu erkennen, die angepasst werden sollten. Die Entscheidung sollte auf dem tatsächlichen Risiko beruhen und nicht allein darauf, dass ein Vorgang technisch möglich ist.
Festlegen, was vorgeschlagen wird und was autorisiert werden kann
Die prüfende Person muss die Auswirkungen des Vorgangs verstehen können, statt ein internes PHP-Objekt entschlüsseln zu müssen. Zeigen Sie den aktuellen und den vorgeschlagenen Wert, den Grund, die Herkunft der Daten, die relevanten Folgen und etwaige Einschränkungen an. Hängt die Entscheidung von einer Regel ab, stellen Sie die für ihre Anwendung nötige Erklärung bereit. Verbergen oder schützen Sie nicht erforderliche personenbezogene Daten.
Trennen Sie den Vorschlagsbefehl von der Autorisierung. Der Vorschlag beschreibt die Aktion und ihre Parameter; die Autorisierung erlaubt die Ausführung genau dieses Vorschlags. Sie darf keine allgemeinen Berechtigungen erteilen und es der freigebenden Person nicht ermöglichen, die Parameter unbemerkt zu ändern. Sind Änderungen erforderlich, kann die prüfende Person eine Anpassung anfordern; das System erstellt dann einen aktualisierten Vorschlag, der die entsprechenden Autorisierungsregeln erneut durchlaufen muss.
Setzen Sie das Prinzip der geringsten Berechtigung um: Beschränken Sie, wer Vorschläge erstellen, freigeben, ablehnen oder abbrechen darf, und prüfen Sie diese Berechtigungen serverseitig bei jedem Zustandsübergang. Wenn das Risiko es rechtfertigt, muss die vorschlagende Person daran gehindert werden, den eigenen Vorgang freizugeben. Diese Trennung muss in der Berechtigungslogik umgesetzt werden und darf nicht allein davon abhängen, Schaltflächen in der Benutzeroberfläche auszublenden.
Explizite Zustände und Übergänge modellieren
Modellieren Sie den Prozess als Zustandsmaschine. Eine sinnvolle anfängliche Menge von Zuständen kann pending, approved, executing, rejected, changes_requested, expired, cancelled und executed umfassen. Ein ausstehender Vorschlag kann freigegeben, abgelehnt, abgebrochen oder als abgelaufen markiert werden; ein freigegebener Vorschlag darf nur dann in die Ausführung übergehen, wenn er weiterhin gültig ist. Ein gerade ausgeführter Vorschlag kann als ausgeführt enden oder in einen wiederherstellbaren Zustand zurückkehren, wenn festgestellt wird, dass keine Wirkung eingetreten ist. Ein ausgeführter Vorschlag kann nicht erneut freigegeben werden.
Speichern Sie den aktuellen Zustand zusammen mit einem unveränderlichen Verlauf der Entscheidungen und Übergänge. Protokollieren Sie die Vorschlags-ID, den vorherigen und den neuen Zustand, den Akteur, Datum und Uhrzeit, den Grund sowie einen Verweis auf die geprüfte Datenversion. Ersetzen Sie den Verlauf nicht, wenn Sie den Datensatz aktualisieren: Er wird benötigt, um nachzuvollziehen, was geschehen ist, und Fehler zu diagnostizieren.
Zentralisieren Sie in PHP die Zustandsübergänge in einem Domänendienst oder einer gleichwertigen Komponente. Vermeiden Sie, dass verschiedene Controller den Zustand direkt mit allgemeinen Aktualisierungen ändern. Validieren Sie gegebenenfalls den Übergang und die Berechtigungen innerhalb einer Transaktion und weisen Sie Aktionen zurück, die mit dem aktuellen Zustand unvereinbar sind. Diese Struktur reduziert Nebenläufigkeitsfehler und erleichtert das Testen der Regeln unabhängig von der Benutzeroberfläche.
Veraltete Freigaben und doppelte Ausführungen verhindern
Daten können sich ändern, während ein Vorschlag auf eine Entscheidung wartet. Eine Person darf keine Bedingung freigeben, die nicht mehr mit dem auszuführenden Vorgang übereinstimmt. Speichern Sie beim Erstellen des Vorschlags eine Version, ein Aktualisierungsdatum oder einen Fingerabdruck der relevanten Felder. Prüfen Sie bei der Freigabe erneut, ob diese Angaben noch dem aktuellen Stand entsprechen.
Die Prüfung bei der Freigabe reicht nicht aus: Die Daten können sich noch ändern, bevor der Vorgang ausgeführt wird. Vergleichen Sie unmittelbar vor der Ausführung die aktuelle Version oder den aktuellen Fingerabdruck erneut mit dem freigegebenen Stand. Bei einer Abweichung muss der Prozess angehalten, die Autorisierung für diesen Vorschlag ungültig gemacht und eine neue Entscheidung auf Grundlage der aktualisierten Daten angefordert werden. Je nach Risiko können Sie die Unterschiede anzeigen und eine ausdrückliche Bestätigung verlangen, aber die vorherige Freigabe darf nicht automatisch wiederverwendet werden.
Eine Ablaufzeit begrenzt, wie lange die Entscheidung als gültig gilt. Markieren Sie den Vorschlag nach Ablauf als abgelaufen und verlangen Sie für die Fortsetzung eine neue Autorisierung. Bei jedem Wiederholungsversuch muss geprüft werden, ob die Autorisierung weiterhin gültig ist. Verwenden Sie niemals eine abgelaufene Autorisierung, um die Ausführung fortzusetzen oder zu wiederholen.
Die Freigabe muss sich auf einen eindeutig identifizierbaren Vorschlag beziehen und darf kein wiederverwendbares Signal sein. Um zu verhindern, dass zwei nebenläufige Worker denselben Vorschlag ausführen, beanspruchen oder sperren Sie seinen Übergang von approved zu executing atomar: Nur ein Worker darf ihn übernehmen, sofern der Vorschlag weiterhin freigegeben und gültig ist. Prüfen Sie in diesem lokalen Schutzmechanismus auch die Idempotenz und protokollieren Sie vor dem Fortfahren die eindeutige Vorgangs-ID. Das verhindert Duplikate innerhalb des Systems; eine Datenbanktransaktion allein garantiert jedoch nicht, dass eine externe API eine Wirkung nur einmal anwendet.
Findet die Aktion in einem anderen Dienst statt, verwenden Sie, sofern verfügbar, einen Idempotenzschlüssel, den dieser Dienst akzeptiert und idempotent verarbeitet. Protokollieren Sie die Korrelations-ID, den Versuch und die Antworten. Geht eine Antwort verloren oder ist das Ergebnis unbekannt, wiederholen Sie die Wirkung nicht blind: Fragen Sie den Remote-Status anhand dieser ID ab oder gleichen Sie das Ergebnis mit verlässlichen Daten ab. Lässt sich nicht bestätigen, ob die Wirkung eingetreten ist, stoppen Sie weitere automatische Versuche und übergeben Sie den Fall an eine operative Person. Ein bekannter Fehler vor dem Absenden der Anfrage kann einen erneuten Versuch erlauben, sofern Zustand und Autorisierung erneut geprüft werden.
Fällt ein Worker aus und lässt einen Vorschlag in executing zurück, markieren Sie ihn nicht automatisch als ausgeführt und senden Sie ihn nicht ohne Diagnose erneut. Ein Wiederherstellungsprozess muss anhand des lokalen Protokolls und gegebenenfalls durch Abfrage des Remote-Dienstes feststellen, ob die Wirkung eingetreten ist. Bestätigt er, dass dies nicht der Fall war, darf der Vorschlag erst dann in einen ausführbaren Zustand zurückversetzt werden, wenn Gültigkeit, Daten und Autorisierung erneut geprüft wurden. Ist das Ergebnis weiterhin unbekannt, muss der Vorschlag gesperrt bleiben und eskaliert werden.
Eine operative Warteschlange und einen manuellen Ersatzweg gestalten
Die Warteschlange sollte es ermöglichen, offene Fälle nach Alter, Auswirkung, Verantwortlichen und Ablaufdatum zu finden und zugleich den Kontext anzuzeigen, auf dem die Entscheidung beruht. Erklären Sie, warum ein Fall blockiert ist und welche Aktion angebracht ist: warten, Änderungen anfordern, abbrechen oder eskalieren. Die Benutzeroberfläche muss außerdem deutlich machen, was bei einer Freigabe geschieht, statt lediglich Entscheidungsschaltflächen anzubieten.
Legen Sie einen Ersatzweg für den Ausfall einer Abhängigkeit fest, etwa des Benachrichtigungsdienstes oder einer für die Ausführung erforderlichen Integration. Der Vorschlag kann ausstehend bleiben, während ein kontrolliertes Verfahren bereitgestellt wird, mit dem eine autorisierte Person den Fall in der verfügbaren Betriebsumgebung prüfen kann. Der manuelle Weg muss dieselben Prüfungen einhalten, Akteur und Grund protokollieren, eine parallele Ausführung verhindern und das Ergebnis nach Wiederherstellung der Integration abgleichen.
Verwandeln Sie einen technischen Ausfall nicht in eine implizite Freigabe. Können Identität, Berechtigungen oder erforderliche Informationen nicht überprüft werden, muss das System sicher fehlschlagen: pausieren, informieren und eskalieren. Legen Sie fest, wer den Prozess entsperren darf, wie dieser Eingriff dokumentiert wird und welche Aufgaben nach Wiederherstellung des Dienstes überprüft werden müssen.
Den Prozess testen und seinen Betrieb überwachen
Testen Sie die Domänenregeln und vollständigen Abläufe: Freigabe, Ablehnung, Änderungsanforderung, Ablauf, Abbruch und Wiederholungsversuche. Ergänzen Sie Berechtigungstests, um zu bestätigen, dass eine nicht autorisierte Person den Zustand nicht ändern kann, sowie Nebenläufigkeitstests, damit zwei gleichzeitige Entscheidungen nicht zu zwei Ausführungen führen.
Berücksichtigen Sie Fälle, in denen sich Daten während der Wartezeit oder unmittelbar vor der Ausführung ändern, die Remote-Ausführung nach Annahme der Anfrage fehlschlägt oder eine Antwort verloren geht, obwohl die Wirkung eingetreten ist. Prüfen Sie, dass die atomare Beanspruchung nur einem Worker die Ausführung des Vorschlags erlaubt, dass Wiederholungsversuche abgelaufene Autorisierungen zurückweisen und dass jeder manuelle Eingriff ausreichend protokolliert wird. Überwachen Sie in der Produktion das Volumen und Alter offener Fälle, Ablaufereignisse, Ausführungsfehler und Fälle, die einen Abgleich erfordern.
Ein gut gestalteter Prozess gewährleistet menschliche Aufsicht dort, wo sie Kontrolle schafft, statt die Sicherheit dem Gedächtnis der Teams zu überlassen. Explizite Zustände, getrennte Berechtigungen, aktuelle geprüfte Daten, idempotente Ausführung und ein klarer Fehlerpfad machen aus einer informellen Freigabe einen überprüfbaren Prozess.
