Was ist passiert?

Das Telefon hat nicht geklingelt - Gott bewahre, eigentlich ist das ein gutes Zeichen - aber drei Tage lang nicht: das war der Fehler.

Freitagvormittag steht ein Arzt in der Tür der IT. Nicht hektisch, eher irritiert - die kafkaeske Variante. Er sucht einen Befund von Dienstag. Der Patient sitzt seit zwanzig Minuten vor ihm. Im KIS steht nichts. Im Subsystem, in dem der Befund erzeugt wurde, steht er sauber und vollständig seit Dienstag, 14:12 Uhr.

Er ist nur nie angekommen.

Ich öffne die Oberfläche des Kommunikationsservers. Alles grün. Keine Fehlermeldung, keine hängende Queue, keine roten Zähler. Das Log ist ruhig wie ein Wartezimmer um vier Uhr morgens. Und das ist die eigentliche Diagnose: Es steht nichts drin. Nicht “Fehler”. Nicht “Verbindung abgebrochen”. Nichts.

Irgendwann in der Nacht auf Dienstag hat eine Schnittstelle aufgehört zu senden. Kein Absturz, kein Crash-Dump, kein Knall. Sie hat einfach die Klappe gehalten, und alle haben ihr geglaubt.

Drei Tage. Der erste, der es gemerkt hat, war ein Arzt mit einem Patienten im Zimmer.

Die Anatomie des banalen Grauens

Wer schon mal HL7 gesehen hat, kennt den Mechanismus. Ein System schickt eine Nachricht, das empfangende System schickt eine Quittung zurück. ACK heißt angekommen und verarbeitet. NACK heißt angekommen und abgelehnt. Ein sauberes, ehrliches Protokoll. Sender und Empfänger reden miteinander.

Nur: Beide Antworten setzen voraus, dass überhaupt jemand etwas geschickt hat.

Da liegt die Asymmetrie, und sie ist brutal. Eine kaputte Nachricht schreit. Sie erzeugt ein NACK, eine Fehlerzeile, einen roten Balken, vielleicht sogar eine Mail an einen Verteiler, den irgendwann mal jemand angelegt hat. Eine ausbleibende Nachricht erzeugt nichts. Sie ist von einem ruhigen Dienstag nicht zu unterscheiden.

Silent Fail - kommt mir bekannt vor. Vor ein paar Wochen habe ich hier über fünf Labordrucker geschrieben, die gleichzeitig den Dienst verweigert haben, ohne eine einzige Fehlermeldung. Ich habe das damals für ein Druckerproblem gehalten. War es nicht. Es war dasselbe Problem, nur billiger.

Warum das eigentlich das falsche Problem ist

Drei Strukturen sind kaputt. Die Schnittstelle ist keine davon.

Erstens: Wir überwachen Ereignisse, nicht Erwartungen. Ein Fehler ist ein Ereignis, das man abfangen kann. Eine Erwartung ist eine Aussage über die Zukunft: An einem normalen Dienstag laufen zwischen 7 und 18 Uhr rund 400 Befundnachrichten über diese Strecke. Solange diesen Satz niemand aufschreibt, gibt es keine Abweichung, die man messen könnte. Es gibt nur Stille. Und Stille ist nie ein Alarm.

Zweitens: Die Erwartung gehört niemandem. Frag in einem beliebigen Haus, wie viele Nachrichten eines Typs pro Tag über eine Strecke laufen sollten. Die Antwort ist nicht die Zahl. Die Antwort ist ein Schulterzucken und der Verweis auf den Dienstleister, der die Strecke betreibt. Der überwacht seine Infrastruktur: CPU, Speicher, Prozess läuft ja. Ob fachlich noch irgendetwas fließt, steht in keinem Vertrag. Zwischen “der Prozess läuft” und “die Befunde kommen an” liegt eine Lücke, in die das ganze Haus fällt.

Drittens: Die eigentliche Kennzahl misst niemand. Nicht die Anzahl der Fehler ist die interessante Zahl. Interessant ist die Zeit zwischen Ausfall und Entdeckung. Hier waren es drei Tage. In keinem Reporting der Welt taucht diese Zahl auf, weil kein Ticket sie erzeugt hat. Der Vorfall wird abgehakt als “Befund fehlte, wurde nachgetragen”. Einzelfall. Erledigt.

Und darunter, wie immer, dasselbe Muster: Der Mensch ist der Sensor. Nicht das Monitoring hat den Ausfall gemeldet, sondern ein Arzt mit einem wartenden Patienten. Das ist die teuerste Überwachung, die man kaufen kann, und bezahlt wird sie in einer Währung, über die im Lenkungskreis niemand spricht.

Was stattdessen passieren müsste

Nichts davon kostet ein Modul, eine Lizenz oder einen Berater.

Erwartungswerte definieren, pro Strecke und Nachrichtentyp. Nicht auf die Nachricht genau. Eine Größenordnung und ein Zeitfenster reichen: werktags zwischen 7 und 18 Uhr mindestens X Nachrichten pro Stunde. Das ist eine Tabellenzeile. Sie zu füllen dauert eine Stunde, wenn man einmal in die Historie schaut.

Alarm bei Unterschreitung, nicht nur bei Fehler. Wenn eine Strecke, die stündlich liefert, zwei Stunden nichts liefert, ist das ein Alarm. Auch und gerade dann, wenn kein Fehler vorliegt. Technisch ist das trivial. Es ist nur niemandem eingefallen, weil wir Monitoring immer vom Fehler her denken.

Die Fehlerqueue sichtbar machen. Abgelehnte Nachrichten müssen dort landen, wo ein Mensch sie sieht. Eine Dead-Letter-Queue, die niemand aufmacht, ist ein Mülleimer mit besserem Namen.

Und jemandem die Erwartung geben. Das ist der unbequeme Teil und der einzige, der wirklich schwerfällt. Eine Rolle muss den Satz besitzen dürfen: Diese Strecke liefert so viel, und wenn nicht, entscheide ich, was passiert. Ohne Mandat wird daraus wieder das, was daraus immer wird: eine Bürde, die jeder weiterreicht, bis sie bei dem landet, der zufällig als Erster den Hörer abnimmt.

Fazit

Der Befund von Dienstag ist inzwischen im KIS. Nachgetragen, händisch, von jemandem, der dafür nicht zuständig war.

Die Strecke läuft wieder. Ich weiß nicht, seit wann. Ich weiß nur, dass sie jetzt Nachrichten schickt, weil ich nachgeschaut habe.

Nächste Woche schaue ich vielleicht nicht nach.