Automatisierung im echten Leben sieht ganz anders aus als die Demo
Jede Automatisierungsdemo ist sauber. Die Daten kommen korrekt formatiert an. Die API antwortet beim ersten Aufruf. Die Randfälle existieren nicht. Die Fehlerzustände werden nie ausgelöst. Das Ergebnis ist elegant, schnell und schön anzusehen.
Die Produktion ist anders. In der Produktion sendet der Barcode-Scanner ein Duplikat. Die API gibt um 2 Uhr morgens einen 429-Fehler zurück. Der Datensatz, der eine Schallplatte sein sollte, entpuppt sich als Werbeartikel ohne Katalognummer und drei widersprüchlichen Kennungen in drei verschiedenen Datenbanken. Die Automatisierung, die Sie für eine saubere Welt gebaut haben, muss jetzt eine unsaubere überstehen.
Das ist die Lücke, in die die meisten Automatisierungsprojekte fallen. Nicht weil der Entwickler unvorsichtig war, sondern weil Demo und Deployment unterschiedliche Probleme lösen.
Die eigentliche Arbeit liegt in den Randfällen
Als ich das Lagerautomatisierungssystem für Schallplatten baute, dauerte es etwa zwei Wochen, den Happy Path zu entwerfen und zu implementieren. Die nächsten drei Monate wurden mit allem anderen verbracht. Was passiert, wenn eine Platte keinen Barcode hat? Was passiert, wenn Discogs drei Pressungsvarianten zurückgibt und wir die richtige auswählen müssen? Was passiert, wenn die Bilderfassung fehlschlägt? Was passiert, wenn eBay ein Listing ablehnt, weil der Titel ein Zeichen zu lang ist?
Keiner dieser Randfälle ist interessant zu demonstrieren. Alle sind entscheidend für den Betrieb. Ein System, das 80 % der Fälle automatisch handhabt und bei den restlichen 20 % scheitert, hat die Arbeit nicht reduziert — es hat sie auf die schlimmsten möglichen Fälle umverteilt.
Fehlerbehandlung ist eine Designentscheidung, kein Nachgedanke
Die Frage ist nicht, ob Ihre Automatisierung auf Fehler stoßen wird. Sie wird es. Die Frage ist, was das System tut, wenn es passiert. Scheitert es still? Wiederholt es unbegrenzt? Leitet es das fehlgeschlagene Element mit genug Kontext an eine menschliche Überprüfungswarteschlange weiter, um es schnell zu lösen? Benachrichtigt es jemanden — und wenn ja, wen und über welchen Kanal?
Gutes Fehlerbehandlungsdesign bedeutet, diese Fragen vor dem ersten Produktionsausfall zu entscheiden, nicht danach. Es bedeutet, die Wiederholungslogik, die Fallback-Pfade und das Benachrichtigungssystem als erstklassige Teile der Pipeline zu bauen — nicht als Patches, die nach einem Produktionsausfall aufgetragen werden.
Datenqualität ist ein stromaufwärts liegendes Problem
Die meisten Automatisierungsausfälle sind Datenqualitätsprobleme, die Automatisierungskleidung tragen. Die Pipeline hat nicht versagt — die Daten, die sie erhalten hat, entsprachen nicht den Annahmen, auf denen die Pipeline aufgebaut war. Ein Feld, das eine Zahl sein sollte, ist eine Zeichenkette. Ein Pflichtfeld fehlt. Ein Datum ist in einem Format, das nicht erwartet wurde.
Die Lösung ist nicht, die Automatisierung toleranter gegenüber schlechten Daten zu machen. Es geht darum, die Datenqualität an der Quelle zu beheben — Validierung bei der Erfassung, Normalisierung als erster Schritt und explizite Behandlung für Datensätze, die den Mindeststandard für automatisierte Verarbeitung nicht erfüllen.
Die Demo ist eine Hypothese. Das System ist der Beweis.
Ich habe aufgehört, Demos zu zeigen, die keine Fehlerzustände beinhalten. Nicht weil ich die Dinge schwieriger erscheinen lassen will, als sie sind, sondern weil die Fehlerzustände dort sind, wo die echten Designentscheidungen liegen. Jeder kann einen Happy Path bauen. Die Frage ist, ob das System den Kontakt mit der Realität überstehen kann.
Das ist der Unterschied zwischen Automatisierung, die in einer Präsentation funktioniert, und Automatisierung, die um 2 Uhr morgens funktioniert, wenn niemand zuschaut.