Fehlerklassifikation
01Bestimmen Sie den Fehler, bevor Sie etwas wiederholen.
Zuverlässige Automation schickt nicht jeden Fehler in dieselbe Schleife. Flower trennt Transportbedingungen, Datenqualität und unklare Zielergebnisse.
Transient und wiederholbar
Timeouts, Drosselung und temporäre Nichtverfügbarkeit nutzen begrenzte Versuche, Backoff, Jitter und Budget. Erschöpfung wird sichtbarer Rückstand oder Alarm.
Dauerhaft und handlungsrelevant
Falsche Zugangsdaten, fehlende Rechte, inkompatibles Schema oder Fachregel werden durch Wiederholung nicht besser. Einheit stoppen, Kontext bewahren, isolieren und Eigentümer informieren.
Unklar und zuerst abzugleichen
Die Verbindung kann nach Ziel-Commit ausfallen. Flower prüft Zielidentität, Tracking, Mengen oder Prüfsummen vor Replay, damit Unklarheit kein Duplikat erzeugt.
Recovery-Regelkreis
02Erst nach sicherem, belegtem Abschluss fortschreiten.
Derselbe Regelkreis begleitet Daten von der Quelle bis zum Ziel. Routinemäßige transiente Recovery läuft automatisch; unsichere oder unklare Ergebnisse bewahren Kontext, folgen der Richtlinie und melden sich erst, wenn menschliches Urteil nötig ist.
Wiederaufnahmegrenze wählen
Nutzen Sie Objekt, Datei, deterministischen Batch oder kleinste sichere Einheit. Speichern Sie den Prüfpunkt außerhalb flüchtiger Ausführung und rücken Sie nach Zielbestätigung vor.
Fortschritt durch Validierung steuern
Transportabschluss ist nur ein Signal. Struktur, Schema, Mengen, Fachregeln, Integrität und Abgleich entscheiden über Freigabe, Prüfung oder Reject.
Recovery-Nachweis verbunden halten
Erfassen Sie Versuche, Klasse, Identitäten, Validierung, Quarantäne, Abgleich und finale Aktion in einem Lineage-Pfad. Warnungen tragen Handlungskontext.
Aus der Produktion geformt
03Zuverlässigkeit, bewährt unter realem Datendruck.
Zuverlässigkeit ist keine Eigenschaft einer Präsentation. Flower entwickelt sich seit 2019 im kontinuierlichen Produktionsbetrieb weiter, darunter sehr große Telekommunikationsvolumen und geschäftskritische Finanzdaten.
Fehler werden explizit
Unvollständige Transfers, ungültige Datensätze und Richtlinienverstöße werden zu sichtbaren Zuständen mit definierter Behandlung statt zu stillen Folgefehlern.
Recovery bleibt begrenzt
Retry-Budgets, Backoff, Wiederaufnahmegrenzen, Quarantäne, Zielabgleich und Lebenszyklusaktionen passen sich Endpunkt und Last an, statt im Vorfall improvisiert zu werden.
Nachweise bleiben verbunden
Lineage, Metadaten, Ereignisse, Metriken und Warnungen helfen nachzuvollziehen, was bewegt und verändert wurde und was Aufmerksamkeit braucht.
Recovery-Abnahme
04Legen Sie Wiederherstellbarkeit vor dem ersten Vorfall fest.
Ein Selbstheilungsversprechen wird erst operativ, wenn das Team festlegt, was wiederholt werden darf, welcher Nachweis eine Einheit schließt, wie Unklarheit abgeglichen wird und wann Automation stoppen muss. Machen Sie daraus Release-Tests und wiederholen Sie sie bei Endpunkt- oder Richtlinienänderungen.
Recovery-Vertrag festlegen
Legen Sie je Einheit zulässigen Verlust, Duplikate, Reihenfolgeänderung, maximale Verzögerung und erforderlichen Zielnachweis fest. Ein präziser Vertrag verhindert, dass ein neu gestarteter Prozess als Erfolg gilt, während das Datenergebnis unklar bleibt.
Unterschiedliche Fehlerklassen injizieren
Testen Sie getrennt Quellenausfall, Transportunterbrechung, Drosselung, falsche Zugangsdaten, Schema-Reject, beschädigte Nutzlast, vollen lokalen Speicher und Ziel-Timeout. Jeder Fall muss den vorgesehenen Retry-, Stopp-, Quarantäne- oder Abgleichpfad erreichen.
Unklaren Commit erzwingen
Trennen Sie die Verbindung, nachdem das Ziel möglicherweise committed hat, aber bevor die Bestätigung den Sender erreicht. Prüfen Sie Zielidentität, Mengen, Prüfsummen oder ein anderes dauerhaftes Signal vor jedem Replay.
Über die Zustandsgrenze neu starten
Starten Sie Worker, Host und abhängigen Zustandsdienst an verschiedenen Punkten neu. Bestätigen Sie, dass Checkpoints, offene Versuche, Quarantänekontext und Lineage zusammen überleben und Upgrade oder Rollback laufende Arbeit nicht neu interpretieren.
Druck und Aufholen messen
Lassen Sie einen Endpunkt lange genug ausfallen, um realistischen Rückstand aufzubauen, und stellen Sie ihn wieder her. Messen Sie Queue-Alter, Plattenwachstum, Retry-Rate, Nutzdurchsatz beim Aufholen, Sättigung und Schutz neuen Verkehrs.
Quarantäne und Replay nachweisen
Senden Sie ungültige oder richtlinienwidrige Einheiten neben gültiger Arbeit. Bestätigen Sie, dass unsichere Daten ohne Blockade anderer Arbeit stoppen, Diagnosekontext behalten und nach Korrektur ohne Umgehung der Validierung oder Duplikate wiederholt werden können.
Wiederherstellung des dauerhaften Zustands nachweisen
Entfernen oder beschädigen Sie den aktiven Zustandsspeicher und stellen Sie ihn aus der dokumentierten Sicherung oder Replik wieder her. Messen Sie die Recovery-Point-Lücke, gleichen Sie Quell- und Zielnachweise ab und bestätigen Sie, dass der rekonstruierte Checkpoint weder berechtigte Arbeit überspringt noch abgeschlossene Einheiten unbemerkt erneut veröffentlicht.
Übergabe an den Betrieb testen
Schöpfen Sie das Retry-Budget aus und lösen Sie einen dauerhaften Fehler aus. Die Warnung muss Einheit, Quelle und Ziel, letzte sichere Grenze, Versuche, Nachweise, Eigentümer und freigegebene nächste Schritte ohne Rekonstruktion über getrennte Werkzeuge nennen.
Releases durch Recovery-Übungen absichern
Bewahren Sie Fehlermatrix, erwartete Nachweise und Recovery-Zeiten als wiederholbare Suite. Führen Sie sie nach Runtime-, Connector-, Schema-, Richtlinien- oder Infrastrukturänderungen aus, damit Wiederherstellbarkeit getestete Release-Eigenschaft statt historische Zuversicht ist.