Monitoring i status

Fast jede Statusseite, auf die Sie treffen, zeigt schöne Zahlen. 100 Prozent Uptime, alles auf grün, kein Kratzer. Das Problem ist, dass diese Zahlen meistens nicht "alles hat funktioniert" bedeuten, sondern "niemand hat hingeschaut". Fehlende Daten werden als Erfolg verbucht, und der Kunde bekommt ein hübsches Bild ohne Deckung in der Realität.

Wir haben ein Monitoring gebaut, das etwas Schwierigeres tut als ein hübsches Diagramm: es sagt die Wahrheit, auch wenn die Wahrheit unbequem ist. Wenn wir nicht wissen, wie ein Dienst lief, soll das Ergebnis "ich weiß nicht" lauten und nicht "alles gut". Dazu kommen eine öffentliche Statusseite mit einer ehrlichen Historie und eine Incident-Bearbeitung dort, wo das Team ohnehin sitzt. Diese Fallstudie handelt davon, wie man Verfügbarkeit berechnet, ohne sich selbst zu betrügen.

Der Mechanismus der typischen Statusseiten-Lüge ist banal. Wenn in einem bestimmten Zeitraum die Sonde keine Probe gesammelt hat und Sie diesen Zeitraum trotzdem als gesund verbuchen, wird Ihre Uptime immer großartig aussehen. Je seltener Sie hinschauen, desto besser stehen Sie da, was absurd ist: ein Werkzeug zum Überwachen der Verfügbarkeit belohnt Sie dafür, dass Sie nicht überwachen.

Der Effekt ist bequem und unwahr. Ein grünes Diagramm beruhigt das Team und den Kunden, obwohl darunter eine Stunde gelegen haben könnte, von der niemand etwas weiß. Wir wollten genau die entgegengesetzte Haltung: "ich weiß nicht" soll "ich weiß nicht" bedeuten und nicht still zu "alles funktioniert" aufgerundet werden.

Die ganze Ehrlichkeit dieses Monitorings kommt aus einer einzigen Entscheidung: eine Probe hat drei mögliche Zustände und nicht zwei. Nicht nur "up" und "down", sondern auch "unknown" für die Zeit, in der es einfach keine Beobachtung gab. Diese Unterscheidung ist das Herz von allem Übrigen.

In die Verfügbarkeit gehen ausschließlich tatsächlich gesammelte Proben ein, also die "up"- und "down"-Proben. Die "unknown"-Zustände werden beiseitegelegt, denn man darf sie in keine Richtung vortäuschen. Wenn es in einem Zeitraum keine Beobachtung gab, ist das Ergebnis nicht 100 Prozent und nicht null. Das Ergebnis ist leer, und genau so zeigt es die Statusseite.

Eine eigene Falle sind geplante Ausfälle. Es ist verlockend, ein Wartungsfenster als gesunde Zeit zu zählen, denn schließlich "war es eine geplante Pause, kein Ausfall". Nur lügt das Diagramm dann wieder, bloß subtiler: es tut so, als hätte der Dienst gelaufen, als er absichtlich weg war.

Wir sind einen Mittelweg gegangen, der in beide Richtungen ehrlich ist. Wartungsfenster sind separat gekennzeichnet und zählen nicht als Ausfall, denn es ist keiner. Aber sie tun auch nicht so, als wäre in dieser Zeit alles gelaufen. Im Diagramm sieht man eine als Wartung markierte Pause und keinen künstlichen grünen Hintergrund. Es ist dasselbe Prinzip, das das ganze Projekt bestimmt: wir runden nicht zu unseren Gunsten.

Monitoring, das nur zählt, ist die halbe Arbeit. Die andere Hälfte beginnt in dem Moment, in dem wirklich etwas ausfällt. Hier wird der klassische Fehler begangen: die Incident-Bearbeitung wird in ein separates Werkzeug gedrängt, in das sich mitten im Feuer niemand einloggen will. Wir sind dorthin gegangen, wo das Team ohnehin ist, also auf Discord.

Der Ablauf ist kurz und erfordert keinen Kontextwechsel. Eine Zustandsänderung eines Dienstes löst eine Benachrichtigung aus. Ein Incident wird direkt aus dem Kanal eröffnet und aktualisiert, ohne Anmeldung in einem weiteren Panel. Die öffentliche Statusseite zeigt den Kunden den Verlauf und den Abschluss, klar und ohne Beschönigung, genauso ehrlich wie die Uptime-Zahlen.

Die Zahl auf der Seite bedeutet genau das, was sie sagt. Wenn dort 99.5 Prozent steht, sind das 99.5 Prozent aus tatsächlichen Beobachtungen und kein Artefakt davon, dass die Sonde einen halben Tag geschlafen hat. Der Kunde schaut auf die Statusseite und sieht eine ehrliche Historie: Verfügbarkeit, Ausfälle und Wartungsfenster getrennt, und kein ewiges Grün, das nichts bedeutet.

Wenn etwas ausfällt, führt das Team den Incident von dem Ort aus, an dem es ohnehin ist, ohne sich im schlimmstmöglichen Moment in ein weiteres Werkzeug einzuloggen. Das Ganze hält sich an ein Prinzip, das bescheiden aussieht und selten ist: ein Monitoring, dem man glauben kann, weil es zugibt, was es nicht weiß, statt die Lücken grün zu übermalen.