Wenn der Fehler sich als Erfolg meldet

Vier Fälle in einer Woche

Eine Karte auf einer Einrichtungsseite. Jede Kachel lädt, der Server antwortet mit Status 200, das Fehlerprotokoll bleibt leer. Über jeder Kachel steht in grauer Schrift „API KEY REQUIRED“. Der Kartendienst hatte seine Bedingungen geändert und lieferte weiter, nur eben mit Wasserzeichen.

Ein Formular, das eine Alarmmail an das Team schickt. Die Testmail kommt an. Die Absenderadresse steht korrekt im Text. Wer im Postfach auf Antworten klickt, schreibt an die technische Versandadresse, und die liest niemand.

Ein Testlauf gegen die Zwischenumgebung. Alle Prüfungen grün. Das Abfrageprotokoll der Datenbank zeigt später: Der Test hatte mit den Tabellen der lokalen Umgebung gesprochen. Die Umgebungsvariable war gesetzt, der Datenbankzugriff aber vorher erzeugt worden und hatte seine Konfiguration behalten.

Ein Bauschritt, der lokal durchläuft und in der Pipeline scheitert. Eine neue Seite wollte beim Bauen Daten aus der Datenbank laden. Lokal gab es die Verbindung, im Bauschritt nicht. Dieser Fall ist der harmloseste, weil er wenigstens laut war.

Drei von vier Fällen waren still. Sie haben Erfolg gemeldet.

Zwei Kanäle

Alle vier haben denselben Aufbau. Es gibt einen Kanal, auf dem das System über Erfolg berichtet: ein Statuscode, ein Rückgabewert, ein grüner Testbericht, ein Text in einer Mail. Und es gibt einen Kanal, auf dem das Ergebnis tatsächlich ankommt. Das gelieferte Bild. Das Antwort-Feld im Kopf der Mail. Die Tabelle, aus der wirklich gelesen wurde.

Wenn beide Kanäle derselbe sind, ist alles in Ordnung. Ein Test, der den Ausgabewert selbst vergleicht, kann nicht Erfolg melden und falsch liegen. Sobald die Kanäle getrennt sind, wird die Meldung zu einer Aussage über den Meldekanal. Über das Ergebnis sagt sie nichts.

Monitoring schaut fast immer auf den Meldekanal. Statuscodes, Antwortzeiten, Fehlerprotokolle, Testberichte. Das ist kein Versäumnis, sondern die Natur der Sache: Der Meldekanal ist maschinenlesbar, der Ergebniskanal oft nicht. Ein Wasserzeichen in einem Bild erkennt keine Überwachung. Ob das Antwort-Feld einer Mail auf die richtige Adresse zeigt, prüft kein Zustellbericht.

Die Prüfung setzt am Ergebnis an

Der Nachweis kam in allen vier Fällen nicht aus einem Protokoll. Er kam vom Ansehen der ausgelieferten Seite. Vom Beantworten der Testmail statt vom Lesen ihres Inhalts. Vom Abfrageprotokoll der Datenbank, das die tatsächlich gelesenen Tabellen zeigt, statt vom Testbericht. Vom lokalen Bau auf demselben Weg wie die Pipeline, mit geleertem Zwischenspeicher, statt vom Entwicklungsserver.

Das ist aufwendiger als ein Blick auf ein Dashboard. Es ist aber die einzige Prüfung, die etwas über das Ergebnis aussagt. Alles andere ist eine Prüfung der Meldung.

Für einen Betrieb heißt das: Es gibt Stellen, an denen einmal im Quartal ein Mensch das tun muss, was der Kunde tut. Die Seite öffnen, nicht den Statusbericht. Auf die automatische Mail antworten, nicht nur nachsehen, ob sie angekommen ist. Eine Bestellung bis zum Ende durchspielen, nicht nur die Bestellbestätigung lesen.

Ein Fallback macht es schlimmer

In derselben Woche stand eine Entscheidung an. Die Alarmmail an das Team braucht eine Zieladresse. Was passiert, wenn sie fehlt, weil jemand die Konfiguration vergessen hat?

Die bequeme Antwort: eine Notadresse hinterlegen, an die im Zweifel gesendet wird. Dann läuft alles weiter. Genau das ist das Problem. Der Alarm sieht funktionierend aus und erreicht niemanden, der zuständig ist. Er hat den Meldekanal bedient und den Ergebniskanal verlassen.

Die Entscheidung fiel anders: Ohne Zieladresse wirft das System einen Fehler. Das ist unbequem, und es ist die einzige Rückmeldung, die man nicht übersehen kann.

Ein Fallback, der einen Fehler still auffängt, verwandelt einen lauten Fehler in einen stillen. Stille Fehler sind die, die neun Monate halten. Dazu nächste Woche.

Drei Fragen, die sich übertragen lassen

Welche Erfolgsmeldung prüft niemand gegen das Ergebnis? Jede Überwachung hat Stellen, an denen sie auf die Meldung vertraut. Die Liste dieser Stellen ist kurz und lohnt sich, weil dort die stillen Fehler wohnen.

Wer tut regelmäßig, was der Kunde tut? Nicht der Statusbericht, sondern die Seite. Nicht der Zustellbericht, sondern die Antwort auf die Mail. Ein Termin im Quartal, eine Person, eine Liste.

Wo fängt ein Fallback einen Fehler still auf? Jede Notadresse, jeder Standardwert, jede geschluckte Ausnahme ist so eine Stelle. Dort sieht das System funktionierend aus, während das Ergebnis fehlt.