Jedes System hat Fehler, die keinen Alarm auslösen können

Victoria Shinder20 September 2026, 21:403 Min. Lesezeit

Überwachung ist um Fehler herum organisiert, weil Fehler leicht zu definieren sind: etwas wurde geworfen, etwas lieferte einen Status im falschen Bereich, etwas lief in eine Zeitüberschreitung. Jedes gebräuchliche Alarmsystem ist eine Funktion dieser Definition. Damit gibt es eine ganze Klasse von Defekten, die für es strukturell unsichtbar ist: die Operation, die gelingt und trotzdem falsch ist.

Cloudflare hat in diesem Monat ein gutes Beispiel veröffentlicht. TLS 1.3 verlangt vom Client, sich bereits im ersten Paket auf ein Schlüsselaustauschverfahren festzulegen. Rät er falsch, antwortet der Server mit einem HelloRetryRequest, und der Handshake braucht zwei Rundreisen statt einer. Die Messung ergab: Das geschah bei etwa der Hälfte der Verbindungen zu Ursprungsservern. Kein einziger dieser Handshakes schlug fehl. Nichts wurde geworfen, nichts lief ab, kein Statuscode lag außerhalb des Bereichs. Das Protokoll arbeitete exakt wie spezifiziert — und kostete jahrelang eine Rundreise auf der Hälfte der Verbindungen.

Die Gestalt dieser Klasse

Hat man die Gestalt einmal, sieht man sie überall, und sie ist immer dieselbe: ein korrektes Ergebnis, erreicht mit mehr Arbeit als nötig.

• Eine Seite, die für eine nicht existierende Adresse 200 und die Startseite liefert. Nutzer sehen eine Seite, Crawler sehen ein Duplikat, die Fehlerrate ist null.
• Ein Cache, der einen veralteten, aber gültigen Eintrag zurückgibt. Jede Anfrage gelingt. Die Daten sind einen Tag alt.
• Das N+1-Problem. Einhundertundeine erfolgreiche Abfrage, wo zwei gereicht hätten.
• Ein Wiederholungsversuch, der im zweiten Anlauf gelingt, während das Budget dafür eine Abhängigkeit abfedert, die leise halb kaputt ist.
• Ein Ersatzpfad, der ständig genommen wird, weil der Hauptpfad falsch konfiguriert ist. Der Ersatzpfad funktioniert. Genau das ist das Problem.

Jeder dieser Fälle ist nach der Definition Ihrer Überwachung ein Erfolg. Jeder ist ein echter Defekt. Und jeder überlebt genau so lange, wie niemand misst, was ihn unterscheidet — denn es gibt keinen Alarm, kein Ticket und keine Beschwerde, nur ein System, das mehr kostet, als es müsste, und langsamer wird, je größer es wird.

Warum Schwellenwerte sie nicht finden

Die naheliegende Antwort lautet „dann eben auf Latenz alarmieren". Das trägt nicht, und der Grund lohnt die Genauigkeit. Diese Defekte liegen meist innerhalb der normalen Latenzverteilung: Eine zusätzliche Rundreise sind 40 ms auf einer Strecke, deren p99 ohnehin um 200 schwankt. Sichtbar werden sie als Anzahl, nicht als Dauer — wie viele Handshakes wiederholt wurden, wie viele Anfragen den Ersatzpfad nahmen, wie viele Abfragen pro Anfrage liefen. Auf eine Zahl, die ungleich null sein soll, setzt niemand einen Schwellenwert — also hat niemand die Zahl überhaupt.

Der zweite Grund: Diese Verhältnisse driften, sie brechen nicht. An dem Tag, an dem die Annahme X25519 für ein Drittel des Internets falsch wurde, änderte sich nichts; die beschriebene Grundgesamtheit veränderte sich langsam, während die Voreinstellung weiterhin richtig aussah. Ein Schwellenwert erkennt eine Stufe. Eine Steigung erkennt er nie.

Was stattdessen zu tun ist

Zählen Sie die Pfade, nicht nur die Ergebnisse. Für jeden Zweig, über den Ihr System zur selben korrekten Antwort gelangt — Wiederholung, Ersatzpfad, Cache-Fehltreffer, langsamer Weg, zweiter Anlauf — geben Sie einen Zähler aus und stellen Sie ihn neben die Zahl der Anfragen. Das Verhältnis ist das Messinstrument. Sie erwarten nicht, dass es null ist; Sie wollen wissen, wie groß es ist, damit eine Veränderung überhaupt lesbar wird.

Dann sehen Sie sich diese Verhältnisse einmal bewusst an, wenn gerade nichts brennt. Nicht auf einem Dashboard, auf das Sie während eines Vorfalls schauen, sondern als Arbeit, an einem ruhigen Nachmittag, mit der Frage: „Hätte ich diese Zahl so geschätzt?" Die Hälfte ja. Die interessante Hälfte nicht — und jeder dieser Fälle ist ein Defekt, der sich nie von selbst gemeldet hätte.

Und schreiben Sie auf, welche Annahme jede Voreinstellung enthält. Jede Voreinstellung ist eine Behauptung über die Grundgesamtheit, der sie dient: dass die meisten Gegenstellen X25519 bevorzugen, dass die meisten Antworten in den Puffer passen, dass die meisten Wiederholungen vorübergehend sind. Eine Behauptung ist prüfbar. Eine Voreinstellung, die nie als Behauptung notiert wurde, wird zum Mobiliar — und Mobiliar misst niemand.

Die Fehler, die Sie wecken, werden Sie beheben. Die, die gelingen, werden Sie bezahlen.