Der Bericht, der Stille als Wohlbefinden meldet
Jeden Morgen gegen sieben kommt bei uns ein Ticket an. Absender: die Veeam-Installation eines Kunden. Betreff: „Last 24 hours: 0 Errors, 0 Warnings, 23 Successes". Fast immer ist alles in Ordnung, und jemand schließt das Ticket.
Wir wollten das automatisieren. Drei Zahlen im Betreff, eine Entscheidung, ein Klick. Was kann da schon schiefgehen.
Beim Bau kamen drei Fallen ans Licht — zwei stecken im Bericht, eine steckte in uns.
Der Betreff zählt Aufträge, nicht Rechner
„23 Successes" klingt nach 23 gesicherten Maschinen. Dahinter stehen gut 200. Ein einzelner Auftrag deckt bis zu 66 Rechner ab. Wer die Zahl als Rechnerzahl liest, verrechnet sich um eine Größenordnung.
Das gilt auch in die andere Richtung. An einem Tag stand im Betreff „1 Warnings". Im Bericht selbst: zwei betroffene Rechner, beide mit Warnung, beide im selben Auftrag. Der Zähler bezieht sich auf Aufträge oder Sitzungen, nicht auf Maschinen. Wer beim Nachsehen die Betreffzahl als Vorgabe nimmt, hört nach dem ersten Fund auf — und übersieht den zweiten.
Die Auswertung muss den Bericht durchgehen, nicht den Betreff hochrechnen.
Wir haben eine Schwankung erfunden
Bevor das Skript entscheiden durfte, was „normal" ist, haben wir 35 Tage Berichte angesehen. Die Erfolgszahl schwankte zwischen 21 und 33. Schluss daraus: Die Zahl ist für sich genommen kein Maß, zu unruhig.
Der Schluss war falsch, und der Fehler ist lehrreich.
Mitten im Beobachtungszeitraum hatte der Kunde seine Jobstruktur umgebaut: Fünf Einzelaufträge, einer je Rechner, wurden ein Sammelauftrag; vier weitere ein zweiter. Weil der Betreff Aufträge zählt, fiel die Zahl von rund 30 auf rund 23 — ohne dass ein einziger Rechner weniger gesichert wurde. Unsere Auswertung hatte über den Umbau hinweg gemittelt und daraus eine Streuung gemacht, die zum größten Teil nur der Umbau war. Was übrig blieb, erklärt der Nachtrag unten.
Bevor man aus einer Zeitreihe eine Spanne ableitet, muss man prüfen, ob sich in ihr die Definition geändert hat.
Das Unangenehme daran: Die Regel, die wir fälschlich abgeleitet hatten — „die Zahl sagt nichts" — hätte uns genau für das blind gemacht, was die Zahl zeigen soll. Auf den Umbau hingewiesen hat uns der Kunde, nicht die Auswertung.
Seit dem Umbau ist das Bild bis auf einzelne Ausreißer nach oben stabil: werktags 23, am Wochenende 22. Und damit ist die Zahl sehr wohl ein Maß. Sie muss nur zum Wochentag passen.
Was gar nicht läuft, taucht nirgends auf
Das ist die wichtigste der drei Fallen, und sie hat nichts mit unserer Auswertung zu tun. Sie steckt im Bericht selbst.
Ein Auftrag, der nicht startet, erzeugt keinen Fehler. Er erzeugt auch keinen Erfolg. Er fehlt einfach. Das folgt aus dem Aufbau des Berichts: Er listet Sitzungen der letzten 24 Stunden. Wo keine Sitzung war, gibt es keine Zeile, und nichts zählt nach, ob eine hätte da sein müssen. „0 Errors, 0 Warnings" kann deshalb auch bedeuten, dass ein Rechner seit Tagen nicht gesichert wird — weil sein Auftrag deaktiviert ist, weil der Zeitplan verstellt wurde, weil ein Dienst hängt. Der Bericht meldet Stille als Wohlbefinden.
Deshalb reichen null Fehler und null Warnungen nicht. Die dritte Bedingung ist die entscheidende: die für den Wochentag erwartete Zahl an Aufträgen. Sie fängt ab, was die ersten beiden nicht sehen können. Ein Tag mit 0/0/21 ist kein guter Tag, wenn 23 erwartet werden. Er ist ein Tag, an dem zwei Aufträge nicht gelaufen sind, und niemand hat es gemeldet.
Dieselbe Regel steckt bei uns auch im Überwachungsskript für die Fernwartung: Ein Auftrag ohne jede Sitzung im Zeitfenster gilt dort bewusst als Fehler. Beide Quellen produzieren dasselbe Schweigen, also brauchen beide dieselbe Gegenregel. Wie sich das im Einzelfall anfühlt, steht in Der Job, der nicht mehr anlief und nichts meldete .
Nachtrag: Die Sollzahl darf nie das Maximum sein
Am ersten Werktag nach der Inbetriebnahme hielt das Skript ein völlig unauffälliges Ticket offen. Das Soll hatten wir aus der Vorwoche übernommen, Tag für Tag. Für Dienstag stand 24, weil der Bericht am Dienstag davor 24 gemeldet hatte. Jetzt kamen 23.
Der Grund: An jenem Dienstag war zusätzlich die Montagssicherung im Bericht. Sie war spät genug gelaufen, um noch in das 24-Stunden-Fenster des Dienstagsberichts zu fallen. Der Bericht bildet ein gleitendes Fenster ab, keinen Kalendertag — ein Auftrag kann in zwei aufeinanderfolgenden Berichten stehen und einen einzelnen Tag aufblähen. Daher auch die Ausreißer nach oben in der Zeitreihe.
Eine Sollzahl, gegen die automatisch geprüft wird, muss deshalb das Minimum sein, das an diesem Wochentag erwartet wird. Nicht der Durchschnitt, nicht das Maximum. Alles darüber ist ein Auftrag, der zufällig noch ins Fenster gerutscht ist. Alles darunter ist ein Auftrag, der fehlt — oder so spät lief, dass er erst morgen auftaucht. Beides muss sich jemand ansehen.
Warum hier kein Sprachmodell entscheidet
Man könnte den Bericht einem Modell vorlegen und fragen, ob alles in Ordnung ist. Wir haben es nicht getan.
Der Aufbau ist fest, die Entscheidung hängt an drei Zahlen, und die Aktion am Ende ist das Schließen eines Backup-Tickets. Ein Modell könnte das nicht besser, wohl aber gelegentlich anders. Und ein fälschlich geschlossenes Backup-Ticket fällt niemandem auf — das ist der Unterschied zu einer überflüssigen Notiz, die man wegklickt. Wo eine Aktion etwas aus dem Blickfeld nimmt, soll sie vorhersagbar sein.
Was der Blick in die alten Tickets zeigte
Vor dem Bau haben wir die Verläufe der bisherigen Berichtstickets angesehen. Auf keines wurde je geantwortet — auch nicht an den Tagen mit drei Fehlern. Eine Sicherung, die fast drei Tage hing, lief drei Berichte lang mit, ohne dass etwas geschah.
Das ist der eigentliche Grund für die Automatisierung. Nicht die Minute, die das Schließen kostet, sondern die Fälle, die im täglichen Einerlei untergehen. Wo jeden Morgen dieselbe Mail kommt und fast immer alles in Ordnung ist, gewöhnt sich der Blick daran, dass alles in Ordnung ist.