Der Kanal, in den niemand mehr schaut: Alert-Fatigue in der Automatisierung

Vier Tage lang meldete ein Kanal einen echten Ausfall, und niemand sah ihn

Ein Onlinehändler, gut fünfzig Mitarbeiter, hatte für seine Automatisierungen einen eigenen Slack-Kanal eingerichtet. #automatisierung-alerts. Jeder Durchlauf schrieb hinein, dass er gestartet war, dass die Bestellung verarbeitet wurde, dass der Lagerabgleich erfolgreich lief. Ein paar hundert Nachrichten am Tag, alle grün, alle brav. Das fühlte sich nach Kontrolle an.

Dann brach der Lagerabgleich. Ein Artikel wurde weiterverkauft, obwohl er ausverkauft war, und die entsprechende Fehlermeldung landete pünktlich im Kanal, zwischen zweihundert Erfolgsmeldungen. Dort blieb sie liegen. Vier Tage, bis ein Kunde sich beschwerte, dass seine bezahlte Bestellung storniert wurde. Erst da suchte jemand im Kanal und fand die Meldung, die seit Dienstag da stand und auf niemanden gewartet hatte.

Der Kanal hatte funktioniert. Er hatte den Fehler gemeldet, sauber, mit Zeitstempel. Nur hatte längst niemand mehr hingeschaut, weil in diesem Kanal seit Monaten nichts stand, worauf man reagieren musste. Das ist Alert-Fatigue, und ich finde sie in fast jedem gewachsenen Setup, das ich mir ansehe.

Alert-Fatigue ist kein Aufmerksamkeitsproblem

Die erste Reaktion ist meistens, den Menschen die Schuld zu geben. Warum hat denn niemand hingeschaut. Die Frage geht am Kern vorbei. Niemand schaut in einen Kanal, in dem zu neunundneunzig Prozent Belanglosigkeiten stehen, weil das Gehirn nach zwei Wochen gelernt hat, dass sich das Hinschauen nicht lohnt. Das ist keine Faulheit, das ist eine völlig vernünftige Anpassung an ein kaputtes Signal.

Wer alles meldet, meldet am Ende nichts. Aufmerksamkeit ist eine begrenzte Ressource, und ein Monitoring, das sie mit Erfolgsmeldungen verbraucht, hat für den echten Fehler nichts mehr übrig. Der Kanal aus dem Beispiel war nicht zu leise, er war zu laut. Und in dem Lärm ging das eine Signal unter, das zählte.

Der Unterschied zwischen einem Log und einem Alert

Die Wurzel des Problems ist eine Verwechslung, die schon beim Bauen passiert. Ein Log und ein Alert sind zwei verschiedene Dinge, und die meisten Setups behandeln sie gleich.

Ein Log ist für später. Es hält fest, was passiert ist, damit Sie im Fehlerfall nachvollziehen können, was schiefging. Ein Log darf ausführlich sein, es darf jeden Schritt festhalten, denn es wartet geduldig, bis jemand es braucht. Niemand liest ein Log in Echtzeit.

Ein Alert ist für jetzt. Er unterbricht einen Menschen und fordert eine Handlung. Ein Alert sagt nicht "das ist passiert", er sagt "tu etwas". Und genau das ist der Test, der über jede Benachrichtigung entscheidet: Was soll der Mensch tun, wenn diese Nachricht bei ihm ankommt? Wenn die ehrliche Antwort "nichts" oder "zur Kenntnis nehmen" lautet, dann ist es kein Alert. Dann ist es ein Log am falschen Ort, und es verstopft den Kanal, in dem die echten Alerts stehen sollten.

Der Onlinehändler hatte zweihundert Logs pro Tag in seinen Alert-Kanal geschrieben. Kein Wunder, dass der eine echte Alert dazwischen keine Chance hatte.

Drei Regeln, die wir jedem Monitoring mitgeben

Wir bauen Benachrichtigungen nach drei Grundsätzen, und sie klingen banal, bis man sieht, wie selten sie eingehalten werden.

Erstens, nur Handlungsbedarf löst einen Alert aus. Erfolg wird geloggt, nicht gemeldet. Dass eine Bestellung sauber durchlief, ist die Norm, und die Norm gehört nicht in einen Kanal, der Aufmerksamkeit verlangt. Wenn Sie eine Bestätigung brauchen, dass ein nächtlicher Lauf überhaupt stattgefunden hat, dann bauen Sie ein Heartbeat-Signal, das genau einmal am Morgen meldet: gestern liefen alle Läufe. Eine Nachricht, nicht dreihundert.

Zweitens, trennen Sie die Schweregrade und schicken Sie sie an verschiedene Orte. Ein kritischer Fehler, der Geld, Kunden oder rechtliche Fristen berührt, gehört nicht in denselben Kanal wie eine harmlose Warnung. Kritisches darf laut sein und einen anderen Weg nehmen, eine SMS, einen Anruf, einen eigenen Kanal, der wirklich nur dann piept, wenn etwas brennt. Wenn in diesem Kanal einmal im Monat eine Nachricht steht, schaut jeder sofort. Das ist genau der Zustand, den Sie wollen.

Drittens, fassen Sie zusammen, statt einzeln zu schreien. Wenn eine Schnittstelle ausfällt und vierhundert Datensätze nacheinander scheitern, brauchen Sie eine Nachricht, nicht vierhundert. "Der Abgleich mit dem Lager schlägt seit 14:20 Uhr fehl, bisher 400 betroffene Vorgänge" sagt alles, was zählt. Vierhundert einzelne Fehlermeldungen sagen dasselbe und begraben dabei jeden anderen Alert, der in derselben Stunde eintrifft.

Der Alert, der sich selbst zum Schweigen bringt

Die dritte Regel hat eine Fortsetzung, die viele übersehen. Ein einzelner Ausfall darf einen Kanal nicht stundenlang fluten. Wenn derselbe Fehler alle fünf Minuten erneut auftritt, weil ein Workflow im Takt wiederholt und immer wieder gegen dieselbe kaputte Schnittstelle läuft, dann melden Sie ihn einmal und danach nicht mehr, bis er behoben ist oder eine feste Zeit vergangen ist.

Deduplizierung heißt das im Fachjargon, und ohne sie passiert das Gegenteil von dem, was Sie wollen. Ein einziger Ausfall überschwemmt den Kanal mit hundert identischen Meldungen, und während alle genervt wegscrollen, kommt der zweite, unabhängige Fehler rein und verschwindet spurlos im Strom des ersten. Ein gutes Alerting meldet ein Problem einmal deutlich und hält dann still, statt im Minutentakt an dieselbe offene Wunde zu klopfen.

Was in einen brauchbaren Alert gehört

Ein Alert, der nur "Fehler in Workflow 3" sagt, ist fast so nutzlos wie gar keiner. Er löst keine Handlung aus, er löst eine Suche aus. Jemand muss sich einloggen, das Szenario finden, die Ausführung öffnen und rekonstruieren, was gemeint war. Bis dahin sind zehn Minuten vergangen, und das bei jeder einzelnen Meldung.

Ein brauchbarer Alert beantwortet vier Fragen, bevor der Mensch fragen muss. Was ist passiert, in verständlichen Worten. Wo, also welcher Prozess und welches System. Seit wann und wie oft. Und ein direkter Link zur betroffenen Ausführung, damit der Sprung vom Alarm zur Ursache ein Klick ist und keine Schnitzeljagd. "Rechnungsexport nach DATEV scheitert seit 09:15 Uhr, 12 Rechnungen betroffen, letzter Fehler: Zeitüberschreitung, hier ansehen." Diesen Alert kann jemand um sieben Uhr morgens auf dem Handy lesen und sofort einschätzen, ob er seinen Kaffee austrinken kann oder nicht.

Der einfachste Test, ob Ihr Monitoring krank ist

Es gibt ein Frühwarnzeichen, und es ist leicht zu prüfen. Schauen Sie nach, ob jemand den Alert-Kanal stummgeschaltet hat. Wenn Kollegen anfangen, die Benachrichtigungen wegzudrücken, ist das kein Disziplinproblem, das ist die Diagnose. Sie haben unbewusst entschieden, dass der Kanal mehr Lärm als Wert liefert, und sie haben damit recht.

Ein stummgeschalteter Alert-Kanal ist der gefährlichste Zustand von allen, gefährlicher als gar kein Monitoring. Denn er täuscht Sicherheit vor. Die Meldungen laufen weiter ein, alles sieht überwacht aus, das grüne Häkchen im Kopf ist gesetzt. Nur schaut niemand mehr hin. Sie haben ein Monitoring, das protokolliert, aber niemanden mehr warnt. Der Onlinehändler aus dem Beispiel war genau da, nur ohne die Stummschaltung. Seine Leute hatten den Kanal nicht offiziell gemutet, sie hatten ihn im Kopf gemutet, was aufs Gleiche hinausläuft.

Weniger melden, damit die Meldung wieder zählt

Als wir das Setup des Händlers umgebaut haben, fiel die Zahl der täglichen Nachrichten von mehreren hundert auf im Schnitt zwei. An den meisten Tagen null, plus eine Heartbeat-Meldung am Morgen. Kritische Fehler gehen seitdem als Push aufs Telefon des Betriebsleiters, alles andere sammelt sich in einem Log, in das man nur schaut, wenn man wirklich etwas sucht.

Der Effekt war nicht, dass weniger passierte. Es passierte genauso viel wie vorher. Der Unterschied ist, dass eine Meldung im Alert-Kanal jetzt wieder etwas bedeutet. Wenn das Telefon vibriert, schaut der Betriebsleiter, weil es in den letzten zwei Wochen kein einziges Mal grundlos vibriert hat. Genau dieses Vertrauen in das Signal ist das eigentliche Ziel von Monitoring, und man kann es nur haben, wenn man mit den Meldungen geizt.

Die Frage, die vor jeder Benachrichtigung steht, die Sie einbauen, ist deshalb nicht "könnte das jemand wissen wollen". Fast alles könnte jemand wissen wollen, das ist die Falle. Die Frage ist: Muss jemand sofort etwas tun, wenn diese Nachricht kommt? Wenn nicht, gehört sie ins Log. Ein Alert-Kanal, in den man ohne Sorge stundenlang nicht schaut, ist kein guter Alert-Kanal. Er ist ein Kanal, dem niemand mehr glaubt.

Wenn Sie den Verdacht haben, dass Ihre eigenen Alerts längst niemand mehr liest, oder wenn Sie nicht sicher sind, ob ein echter Ausfall bei Ihnen überhaupt jemanden erreichen würde, werfen wir gern gemeinsam einen Blick darauf. In unserem kostenlosen Automations-Check schauen wir uns an, wie Ihre Automatisierungen überwacht werden und ob die eine wichtige Meldung im Ernstfall wirklich ankommt.