Wenn der Wächter stirbt: warum Schweigen keine gute Nachricht ist

Sie haben die Warnungen eingerichtet. Wochen sind vergangen und nicht eine einzige Mail ist gekommen.

Es gibt zwei Erklärungen. Entweder ist wirklich nichts passiert, oder das Warnsystem hat aufgehört zu arbeiten und Sie wissen es nicht. Von außen sehen die beiden gleich aus.

Und der menschliche Verstand neigt dazu, Schweigen als gute Nachricht zu lesen. Genau deshalb lebt diese Art von Störung monatelang unbemerkt.

Das ist ein anderes Problem als ein verstummter Prüfpunkt

An anderer Stelle in diesem Wiki haben wir geschrieben: kann ein Prüfpunkt seine Daten nicht lesen, darf er nicht verstummen, er muss sagen, dass er nicht lesen konnte.

Was wir hier beschreiben, liegt eine Ebene darüber. Dort verstummte ein Prüfpunkt innerhalb eines arbeitenden Wächters. Hier ist der Wächter selbst weg. Es ist niemand mehr da, der spricht, also auch niemand, der "ich konnte es nicht lesen" sagt.

Wie ein Wächter leise stirbt

Der Dienst hält an. Ein Update, ein Absturz, zu wenig Speicher. Das, was es Ihnen sagen würde, ist genau das, was angehalten hat.

Der Postweg reißt. Ein Passwort ändert sich, ein Anbieter blockiert, die Adresse kommt zurück. Der Wächter arbeitet weiter, schreibt seine Nachrichten, und keine davon erreicht Sie. Das ist die trügerischste Variante, denn auf der Serverseite sieht alles gesund aus.

Jemand schaltet ab und vergisst es. Benachrichtigungen werden bei einer Untersuchung vorübergehend abgeschaltet. Das Problem wird gelöst. Die Benachrichtigungen bleiben aus.

Die Maschine fährt herunter. Der Extremfall: nichts ist kaputt, es ist einfach alles still.

Allen vieren ist eines gemeinsam: keiner erzeugt eine Nachricht. Und wenn Ihre Art, eine Störung zu bemerken, das Empfangen einer Nachricht ist, dann sind Störungen ohne Nachricht für Sie unsichtbar.

Die Lösung hat eine andere Form: kein Alarm, ein Herzschlag

Die Richtung muss umgedreht werden.

Ein Alarm sagt: sprich, wenn etwas nicht stimmt. Ein Herzschlag sagt: sag in regelmäßigen Abständen "ich lebe", auch wenn nichts ist. Und dann soll jemand bemerken, wenn das Sagen aufhört.

Der Unterschied zählt. Ein Alarm ist eine Nachricht über ein Problem; ein Herzschlag ist eine Nachricht über den Boten selbst. Sie beantworten verschiedene Fragen, und keiner ersetzt den anderen.

Sobald es einen Herzschlag gibt, ändert sich die Bedeutung des Schweigens. Schweigen trägt jetzt Information: etwas, das sprechen sollte, spricht nicht.

Wer es bemerkt, muss außerhalb der überwachten Maschine sein

Das ist der Teil, bei dem man verweilen sollte. Eine Maschine kann ihren eigenen Tod nicht melden.

Die Stelle, die den Herzschlag beurteilt, muss außerhalb des überwachten Servers liegen: eine andere Maschine, ein Telefon, ein äußerer Punkt. Eine Prüfung, die im Server läuft, geht mit dem Server aus und sagt niemandem etwas.

Selbst die einfachste selbstgebaute Fassung genügt: der Server soll jede Stunde irgendwo eine Markierung hinterlassen, und Sie schauen auf das Alter dieser Markierung. Es braucht keinen aufwendigen Aufbau; das Einzige, was es braucht, ist, dass die Beurteilung woanders geschieht.

Der Herzschlag hat seine eigene Falle

Hier steckt ein feiner Entwurfsfehler, und die meisten Aufbauten tappen hinein: den Herzschlag an den Zeitplan von etwas zu hängen, das der Benutzer abschalten kann.

Nehmen wir an, er teilt sich die Zeitsteuerung mit der täglichen Zusammenfassung. Der Benutzer schaltet die Zusammenfassung ab, weil sie ihm zu viel war. Der Herzschlag hört mit auf. Die Gegenseite sieht das Signal aussetzen und schlägt Alarm mit "keine Nachricht von Ihrem Server", während überhaupt nichts los ist.

Das Ergebnis können Sie sich denken: der Benutzer erschrickt einmal umsonst und schaltet beim zweiten Mal den Alarm ab. Ein Fehlalarm, den Ihr eigener Schutzmechanismus erzeugt, zerstört das Vertrauen in diesen Mechanismus schneller, als gar keiner zu haben.

Die Regel: der Herzschlag muss seinen eigenen Zeitplan haben und auf nichts aufsitzen, das abschaltbar ist.

Dieselbe Form, an anderer Stelle

Im Artikel über Sicherungsaufträge in diesem Wiki haben wir geschrieben: schauen Sie nicht auf den Status des Auftrags, schauen Sie auf das Alter der neuesten Sicherung.

Dieselbe Form taucht hier auf: fragen Sie das Warnsystem nicht, ob es funktioniert, schauen Sie auf das Alter des letzten Signals. Ein Status ist eine Behauptung, ein Alter ist eine Messung.

Und zuletzt das Einzige, was am Einrichtungstag zu tun ist: erzeugen Sie absichtlich eine Störung und sehen Sie zu, wie die Mail ankommt. Ein ungetesteter Alarm ist kein Mechanismus, sondern eine Hoffnung.

Was Atlas macht

Atlas Watch schickt eine tägliche Zusammenfassung, meldet kritische Lagen sofort ohne auf die Zusammenfassung zu warten, und erzeugt daneben stündlich ein Signal "ich lebe".

Erzählenswert ist, woran dieses Signal nicht hängt.

Das Signal sitzt weder auf dem Zeitplan der täglichen Zusammenfassung noch auf dem des Alarms. Beide haben eigene Einstellungen und der Benutzer kann beide abschalten. Hinge das Signal an ihnen, würde es in dem Moment, in dem der Benutzer die Zusammenfassung abschaltet, mit aufhören, und die Gegenseite würde "keine Nachricht von diesem Server" sagen, obwohl nichts ist. Deshalb hat das Signal seinen eigenen Zeitplan.

Das zweite Detail folgt demselben Gedanken: solange die Benachrichtigung abgeschaltet ist, wird die Zeitplandatei des Signals gar nicht geschrieben. Es bleibt also kein Zwischenzustand "eingeschaltet, aber funktioniert nicht"; entweder gibt es das Signal oder nicht.

Der Benachrichtigungsweg selbst gehört Ihnen: Sie tragen Ihren eigenen Mailserver ein, und die Mail geht von Ihrem Server hinaus. Ein Signal an einen äußeren Punkt zu senden ist eine wahlweise Ergänzung; das Produkt braucht sie nicht, um zu arbeiten.

Die allgemeine Lehre: ein Schutzmechanismus darf sich nicht auf die abschaltbaren Teile dessen stützen, was er schützt. Tut er es, stirbt er still mit ihm.