Es war im Winter 2019, als wir ein System für die automatisierte Bestandsverwaltung eines mittelständischen Logistikers betreuten. Alles lief monatelang reibungslos, bis plötzlich jeden Dienstag um Punkt 03:15 Uhr morgens der Synchronisations-Algorithmus abbrach. Es gab keine Fehlermeldung, nur einen lautlosen Stopp. Mein Kollege meinte damals: „— Das muss ein Hardware-Problem im Rechenzentrum sein, die Logs zeigen absolut nichts Auffälliges.“
Doch ich war skeptisch. Wir verbrachten drei Nächte damit, den Code Zeile für Zeile zu prüfen. Schließlich fanden wir die Ursache in einer völlig unerwarteten Ecke: Ein externer API-Endpunkt lieferte zu dieser spezifischen Zeit einen Wartungs-Header zurück, den unser Parser fälschlicherweise als "Ende des Datenstroms" interpretierte. Es war kein technischer Defekt, sondern ein logischer Denkfehler in der Fehlerbehandlung.
"Ein Fehler im Algorithmus ist selten ein Zufall. Er ist fast immer das Ergebnis einer Annahme, die wir über die Daten getroffen haben, die sich in der Realität als falsch herausstellt."
Nachdem wir eine dedizierte Exception-Handling-Routine für HTTP-Statuscodes 503 implementiert hatten, verschwand der Fehler sofort. Diese Erfahrung lehrte uns, dass Debugging weniger mit "Suchen" und mehr mit "Ausschließen" zu tun hat. Man muss Hypothesen aufstellen und diese systematisch durch Tests widerlegen, bis nur noch die Wahrheit übrig bleibt.
Seitdem gehört es bei Brightmarketco zum Standard, dass jeder Algorithmus über einen sogenannten "Safe-Fail"-Modus verfügt. Wenn eine externe Komponente nicht antwortet, darf das Gesamtsystem nicht kollabieren. Diese Redundanz in der Logik ist es, die professionelle Automatisierung von Bastellösungen unterscheidet.