Ein Incident, den Schweigen nicht schließt

Jedes Monitoringsystem steht irgendwann vor derselben Frage in leicht anderem Gewand: Was tun Sie, wenn die Messungen ausbleiben?

Die verlockende Antwort ist, das als Erholung zu behandeln. Es fällt nichts mehr aus, die rote Zeile verschwindet, das Dashboard ist ruhig. Es ist zugleich die teuerste Lüge, die das System erzählen kann, denn der Moment, in dem Sie etwas nicht mehr ansehen können, ist genau der Moment, in dem Sie nicht behaupten dürfen, dass es in Ordnung ist.

Das ist der Entwurf, bei dem wir für Incidents gelandet sind, und der größte Teil davon dreht sich darum, „wir haben gemessen, dass es kaputt ist“, „wir haben gemessen, dass es behoben ist“ und „wir können es gerade nicht sehen“ als drei getrennte Aussagen zu halten, die nie still ineinander übergehen.

Warum der Incident ein Objekt ist

Vorher war ein Ausfall eine Reihe von Zeilen in einer Zustandsübergangstabelle. Das reicht, um einen Graphen zu zeichnen, und nicht, um irgendetwas zu sagen. Drei Dinge gibt es erst, sobald es ein Objekt gibt.

Eine Dauer. Die Wiederherstellungsmeldung trug früher überhaupt keine Dauer, weil es nichts gab, womit sich der Parameter füllen ließ. Ein Incident hat einen Anfang, also ist die Dauer eine Messung und keine Schätzung.

Eine menschliche Ebene. Quittieren, zuweisen und von Hand schließen sind Dinge, die Menschen tun, und sie dürfen den gemessenen Zustand nicht berühren. Eine Spalte acknowledged_at auf einer Messung würde genau die Linie verwischen, auf der diese ganze Funktion aufgebaut ist.

Deduplizierung über die Zeit. Eine Benachrichtigung beim Öffnen, Erinnerungen nach eigener Uhr, höchstens eine Eskalation. Ohne Objekt gibt es nichts, woran sich ein „das haben wir Ihnen schon gesagt“ hängen ließe, und dann ist jeder Takt eine weitere Gelegenheit, es Ihnen erneut zu sagen.

Die Deduplizierung ist ein Index

Die Eindeutigkeit, die verhindert, dass für eine Regel zwei Incidents bestehen, ist ein partieller eindeutiger Index auf der Regel, bei dem der Zeitstempel des Abschlusses null ist. Zwei Gateways, die denselben Übergang verarbeiten, erzeugen bauartbedingt einen Incident; das zweite bekommt eine Eindeutigkeitsverletzung und geht weiter.

Code, der prüft, ob schon einer existiert, und dann einfügt, sind zwei Anweisungen, und das sind zwei Gelegenheiten für etwas, das sich dazwischenschiebt. Das ist dieselbe Form wie der Slot-Index des Schedulers und der Index für die Rackbelegung anderswo in diesem Produkt, und aus demselben Grund.

Es gab hier außerdem einen ehrlich gesagt peinlichen Fehler, den aufzuschreiben sich lohnt, weil er im Review unsichtbar ist. Der Schlüssel für die Deduplizierung der Benachrichtigung wurde aus der Regel, dem neuen Zustand und dem aktuellen Zeitstempel gebildet. Ein Schlüssel, der den aktuellen Zeitstempel enthält, dedupliziert bauartbedingt nichts, und auf dem Bildschirm sieht er vollkommen vernünftig aus. Er ist jetzt die Kennung des Incidents. Danach gemessen: Drei aufeinanderfolgende Fehlschläge erzeugen einen Incident und eine Benachrichtigung, und drei weitere ändern daran nichts.

Drei Arten, wie ein Incident enden kann, und nur eine ist eine Messung

Die mittlere ist der Sinn dieser Liste. Eine Regel, die von einer neuen Vorlagenfassung abgelöst wird, muss ihre offenen Incidents schließen, und sie muss das ohne eine falsche Wiederherstellungsmessung tun. Gäbe es nur den Abschluss recovered, würde das Ersetzen einer Vorlage still „das ist wieder hochgekommen“ in die Historie jedes Dienstes schreiben, der zu dem Zeitpunkt unten war.

Es gibt bewusst keinen Abschluss stale. Dass Messungen ausgeblieben sind, sagt nichts über das Ziel.

Welche Übergänge einen Incident überhaupt berühren

Ein Incident hängt an einer Aussage über das Ziel. Ein Übergang nach „Quelle nicht verfügbar“, also unser eigener Agent ist weggefallen, öffnet daher nichts und, wichtiger noch, schließt nichts. Könnte ein abreisender Agent einen Incident schließen, würde ein laufender Ausfall genau in dem Moment aus dem Blick verschwinden, in dem wir die Fähigkeit verlieren, hinzusehen.

Ein Übergang nach „Konfigurationsfehler“ verhält sich genauso: Die Regel beschreibt nichts Messbares mehr, und das ist eine Aussage über uns, nicht über den Dienst.

„Beeinträchtigt“ schließt einen Incident sehr wohl. Der Dienst antwortet, die Bedingung gilt als gesund, nur die Latenz ist hoch. Ihn offen zu lassen würde einen langsamen Dienst zu einem dauerhaft offenen Ausfall machen, Erinnerungen inklusive.

Darunter liegt, aus einer früheren Runde, eine harte Unterscheidung zwischen einer nicht erreichbaren Quelle und einem Ziel, das unten ist. Eine Prüfung, deren Agent nicht verbunden ist, erzeugt „Quelle nicht verfügbar“ und nie „unten“. Alles darüber ist dieselbe Regel, eine Ebene höher.

Wartung schweigt die Benachrichtigungen und misst weiter

Ein Wartungsfenster unterdrückt Benachrichtigungen. Es unterdrückt keine Messung. Der Incident öffnet trotzdem, die Zeitleiste läuft trotzdem, und nur die Meldung bleibt in der Schublade.

Das ist kein Detail. Die Frage, die Menschen nach einem Wartungsfenster stellen, lautet „war es rechtzeitig zurück“, und diese Frage ist unbeantwortbar, wenn Sie aufgehört haben zu messen, während es darauf ankam. Es gibt ein getrenntes, ausdrückliches Kontrollkästchen, das die Prüfungen tatsächlich pausiert, und es ist standardmäßig aus; damit überspringt der Scheduler das Belegen des Slots, sodass nichts fällig wird und nichts versäumt wird. Was danach bleibt, ist eine einzelne Lückenmarkierung, wie bei jeder anderen Lücke auch. Es gibt kein Nachholen.

Das Fenster selbst wird als absolutes Intervall mit einer IANA-Zeitzone daneben gespeichert. Der Kunde gibt Ortszeit ein und will sie als dieselbe Ortszeit zurücklesen, obwohl das Panel in einer festen Zone rendert. Stattdessen Ortszeit plus Zone zu speichern würde jeden Leser, Scheduler, Einlesevorgang und Bildschirm gleichermaßen zwingen, die Umrechnung erneut zu machen, und dann ist eine Zeitumstellung eine Stunde Uneinigkeit zwischen zwei von ihnen.

Wo sich zwei Fenster überschneiden, gewinnt dasjenige, das die Prüfungen pausiert. Wenn ein Kunde irgendwo ausdrücklich die strengere Wahl getroffen hat, ist das die Wahl, die zu achten ist.

Erinnerungen, Eskalation und die Reihenfolge zweier Anweisungen

Sowohl das Erinnerungsintervall als auch die Eskalationsverzögerung liegen auf der Regelfassung und nicht auf dem Incident, denn sie sind Konfiguration, und Konfiguration gehört zu der Fassung, die sie festgehalten hat. Ändern Sie die Richtlinie während eines Ausfalls, bleibt der laufende Incident unter der Richtlinie, unter der er geöffnet wurde.

Beide sind standardmäßig aus. Eine Voreinstellung, die Menschen nachts weckt, ist eine Entscheidung, die der Kunde nicht getroffen hat.

Quittieren schweigt die Erinnerungen, und das ist die gesamte Funktion des Quittierens. Wer sagt „ich sehe es mir an“, sollte nicht alle paar Minuten unterbrochen werden. Die Wiederherstellungsmeldung kommt trotzdem an, denn sie ist die Antwort auf die Frage, die er sich angesehen hat. Die Erinnerungsuhr läuft außerdem ab der letzten Erinnerung und nicht ab dem Beginn, sodass ein Worker, der nach einer Stunde aufholt, nicht zwölf Erinnerungen auf einmal zustellt.

Der Worker schreibt zuerst den Zeitstempel und sendet danach die Meldung, und die Aktualisierung verlangt, dass der Zustand noch der ist, den sie gelesen hat. Verliert sie dieses Rennen, geschieht hier nichts. In der anderen Reihenfolge erzeugt ein verlorenes Rennen eine Meldung ohne Aufzeichnung darüber, und dann kommt die Meldung in der nächsten Runde erneut an.

Eine Eskalation geschieht höchstens einmal je Incident, und die Prüfung darauf liegt in der gemeinsamen Regel und nicht im Worker. Ohne sie würde jeder Durchlauf ein weiteres Eskalationsereignis schreiben, solange der Ausfall dauert: dreißig pro Stunde bei einem Zwei-Minuten-Takt.

Flapping ist die Ausnahme, und es wird beim Öffnen des Incidents entschieden: drei Incidents auf derselben Regel innerhalb einer Stunde. Eine flappende Prüfung hat definitionsgemäß nie einen Incident, der lange offen bleibt, also verpasst jede zeitbasierte Eskalation sie für immer. Drei und nicht zwei, denn zweimal ist Pech, und eine Schwelle von zwei würde jeden gewöhnlichen Dienstneustart einen Flap nennen. Eine Stunde und nicht ein Tag, denn drei Ausfälle über einen Arbeitstag verteilt sind drei Ausfälle.

Die Dauer ist eine Zahl und eine Einheit

Die Wiederherstellungsmeldung trägt, wie lange es gedauert hat, als Wert und als Einheit, nie als Satz. Würde der Worker „1 hour 12 minutes“ selbst zusammensetzen, säße dieses englische Bruchstück mitten in einem übersetzten Satz in acht anderen Sprachen. Was stattdessen reist, ist eine Einheit, auf die die Übersetzung auswählt, mit einem Plural innerhalb jedes Zweiges.

Eine Einheit, keine zusammengesetzten Angaben: Eine Zusammensetzung braucht ein Trennzeichen und eine Reihenfolge, und die sind je Sprache verschieden. Sekunden unterhalb einer Minute, Minuten bis zu zwei Stunden, Stunden bis zu zwei Tagen, danach Tage. Neunzig Minuten liest sich schärfer als zwei Stunden, und Aufrunden würde einen Ausfall von 89 Minuten zwei Stunden dauern lassen.

Zwei ehrliche Folgen, die wir nicht behoben haben

Ausfall, Wiederherstellung und Erinnerung teilen sich einen Gruppenschlüssel für Benachrichtigungen, denn eine Erinnerung ist buchstäblich dasselbe Thema noch einmal und sollte die bestehende Zeile aktualisieren, statt jedes Mal, wenn die Uhr auslöst, eine weitere hinzuzufügen. Der Preis dafür ist, dass eine Erinnerung eine Zeile aktualisiert, die jemand bereits gelesen hat, und für ihn damit unsichtbar ist. Die Eskalation bekommt genau deswegen eine eigene Gruppe: Die Meldung, die am härtesten ankommen muss, darf nicht diejenige sein, die zuerst überschrieben wird. Monitoring-Benachrichtigungen gehen heute nicht per Mail hinaus.

Was wir aufschreiben würden

1. 01Lassen Sie fehlende Daten nie etwas schließen. Geben Sie „wir können es nicht sehen“ einen eigenen Zustand und stellen Sie sicher, dass er weder einen Incident öffnet noch einen schließt.
2. 02Geben Sie dem Incident ein Objekt, sobald Sie eine Dauer, eine Quittierung oder eine zweite Meldung über dieselbe Sache wollen.
3. 03Legen Sie die Deduplizierung in einen eindeutigen Index und prüfen Sie, dass Ihr Benachrichtigungsschlüssel nicht die aktuelle Zeit enthält.
4. 04Zählen Sie auf, wie ein Incident enden kann, und verlangen Sie einen Beleg nur dort, wo ein Beleg behauptet wird.
5. 05Unterdrücken Sie während der Wartung Benachrichtigungen, keine Messungen, und machen Sie das Pausieren der Prüfungen zu einer getrennten, ausdrücklichen, standardmäßig ausgeschalteten Wahl.
6. 06Aktualisieren Sie den Zustand, dann senden Sie die Meldung. Die andere Reihenfolge verliert Meldungen still.

Diese Arbeit sitzt hinter einer Rollout-Schaltung, die standardmäßig aus ist, also ist nichts davon etwas, das Sie heute kaufen können. Es ist als Methode aufgeschrieben und nicht als Ankündigung. Die Messebene darunter, einschließlich der Frage, warum ein nicht erreichbarer Agent kein ausfallender Dienst ist, ist eine eigene Geschichte, und die eng verwandte Frage, wann eine Plattform überhaupt eine Zeit nennen darf, steht in ein Fortschrittsbalken, der nicht rät.

Aus der Plattformarbeit bei Provibr.