Ziele

Ein Monitor beantwortet die Frage "ist gerade etwas kaputt". Ein Ziel beantwortet eine andere: wie viel der Zeit war es in Ordnung, über einen Zeitraum, der Ihnen wichtig ist -- und wie viel Ihres Spielraums für Abweichungen ist noch übrig.

Diese zweite Frage ist die, in der Verträge geschrieben werden. "Die Linie läuft zu 99,5 % des Monats innerhalb der Grenzwerte" ist ein Versprechen, an dem man Sie messen kann; "das Kühlmittel hat gerade 78 °C" nicht. Ein Ziel ist der Ort, an dem Sie das Versprechen festhalten, damit Pulse Ihnen sagen kann, ob es eingehalten wird -- bevor es jemand anderes tut.

Pulse nennt das ein Ziel. Anderswo begegnet Ihnen dieselbe Idee als SLO -- ein Service Level Objective. Es ist dasselbe.

Worüber ein Ziel etwas aussagt

Ein Ziel ist ein Versprechen über eine Bedingung -- genauer: über einen Ziel-Knoten im Graphen dieser Bedingung.

Daraus folgt etwas, das man vorab verstanden haben sollte: die Bedingung legt fest, was "gut" bedeutet, das Ziel legt fest, wie viel gut genug ist. Beides wird bewusst an verschiedenen Stellen bearbeitet. Ein Zielwert von 99,5 % auf 99,9 % zu ändern ist keine Änderung an der Logik -- der Graph bleibt unberührt, seine Version steigt nicht, und nichts anderes, das denselben Graphen liest, ist davon betroffen.

Ein Ziel-Knoten ist wahr, wenn alles wie versprochen läuft -- die umgekehrte Polarität zu einem Alarm-Knoten, der wahr ist, wenn etwas nicht stimmt. Ein Graph mit beidem sieht üblicherweise so aus:

Kühlmittel avg₅ₘ > 80 ─┐
                       ├─ eines von ─┬─→ Alarm  "Kühlmittel- oder Spindelüberlast"
Spindel avg₅ₘ > 16 ────┘             └─ nicht ──→ Ziel  "Linie bleibt innerhalb der Grenzwerte"

Ein Gatter, zwei Abnehmer, ein nicht dazwischen. Genau diese Zeichnung verhindert, dass Alarm und Versprechen sich über die Grenzwerte uneinig werden: Sie ändern den Schwellwert einmal, und beide folgen.

Mehrere Ziele dürfen auf denselben Knoten zeigen. Das ist üblich und sinnvoll -- ein vertragliches Versprechen über einen Monat und ein betriebliches über eine Woche sind verschiedene Versprechen über denselben Indikator.

Ein Ziel anlegen

Über Ziele → Neues Ziel, das eine eigene Anlageseite öffnet. Füllen Sie die Versprechen-Felder aus und beschreiben Sie den Indikator inline:

Feld	Bedeutung
Name	Benennt sowohl das Ziel als auch die Bedingung, auf der es gemessen wird
Zielwert	Wie viel der gemessenen Zeit die Bedingung halten muss. Zwischen 0 und 100 %
Fenster	Wie weit das Versprechen zurückblickt, rollierend. Zwischen 1 Stunde und 365 Tagen
Abdeckungsuntergrenze	Wie viel des Fensters gemessen sein muss, bevor Pulse überhaupt eine Zahl nennt
Eskalationsrichtlinie	Wer alarmiert wird, wenn das Ziel sein Budget verbrennt — Pflicht, wie bei jedem Monitor
Tags	Optionale Kennzeichnungen, dieselben Tags, die jeder Monitor trägt

Der Abschnitt Indikator unterhalb der Versprechen-Felder ermöglicht es Ihnen, das Kriterium in Satzform zu beschreiben -- einen Messwert, der innerhalb eines Bereichs bleibt, oder einen beliebigen Schwellwert, den die Appliance auswerten kann. Für alles, was ein Satz nicht ausdrücken kann, öffnet Im Graph-Editor bearbeiten den vollständigen Bedingungseditor; nach dem Speichern der gezeichneten Bedingung bietet der Editor Ziel erstellen an, was mit dieser Bedingung als Auswahl auf diese Seite zurückführt. Die Auswahl Vorhandene Bedingung verwenden im selben Abschnitt erreicht denselben Zustand für eine bereits gespeicherte Bedingung -- auch für eine, die schon ein Versprechen trägt, denn eine Bedingung kann mehrere Ziele stützen (etwa 99,5 % über dreißig Tage für den Vertrag und 99,9 % über sieben für das Team). Auf beiden Wegen wird die Bedingung nur angezeigt und ausschließlich das Ziel angelegt; der Graph selbst wird weiterhin im Editor bearbeitet, wo auch alles andere sichtbar ist, das ihn verwendet. Nach dem Anlegen des Ziels verweist dessen Seite für Änderungen auf den Bedingungseditor.

Das Fenster ist rollierend, nicht kalendarisch: Ein 30-Tage-Ziel bedeutet immer "die letzten 30 Tage", nie "seit dem Ersten des Monats".

Eine Rückrechnung erscheint, sobald Zielwert und Abdeckungsuntergrenze ausgefüllt sind. Sie zeigt, wie sich das Ziel anhand der bisherigen Verlaufsdaten der Bedingung verhalten hätte -- nützlich, um vor dem Speichern zu prüfen, ob Fenster und Zielwert auf echten Daten sinnvoll sind.

Nach dem Anlegen navigiert Pulse direkt zur Seite des neuen Ziels -- und rechnet das Fenster im Hintergrund aus gespeicherten Messwerten nach. Schon nach wenigen Augenblicken zeigt die Seite einen als näherungsweise gekennzeichneten Wert, statt bis zum Aufbau genügend laufender Messung bei "Zu wenig Daten" zu verharren. Der nachgerechnete Abschnitt wandert mit dem rollierenden Fenster hinaus, während echte Messung ihn ersetzt, und mit ihm verschwindet die Kennzeichnung.

Die Zahlen lesen

Die Seite eines Ziels führt mit dem erreichten Prozentwert und der Abdeckung daneben. Darunter:

Zahl	Bedeutung
Fehlerbudget	Wie viel Zeit außerhalb der Vorgabe der Zielwert über dieses Fenster erlaubt
Verbraucht	Wie viel davon aufgebraucht ist
Budget übrig	Was bleibt, in Prozent. Negativ, sobald Sie darüber hinaus sind
Verbrauchsrate	Wie schnell es geht. 1,0 ist genau im Plan; 2,0 verbraucht das Budget eines ganzen Fensters in einem halben
Nicht gemessen	Zeit im Fenster, die Pulse nicht auswerten konnte

Budget übrig ist meist die Zahl, nach der man handelt. "32 % übrig" sagt, was Sie sich noch leisten können; "99,66 %" sagt, wie es bisher gelaufen ist.

Ein Abzeichen näherungsweise neben dem Wert bedeutet: Ein Teil des Fensters ist nachgerechnete Historie -- beim Anlegen des Ziels aus gespeicherten Messwerten berechnet statt live gemessen. Die Seite sagt, wie viel des Fensters das betrifft, und die Budget-Kurve zeichnet diesen Abschnitt gestrichelt. Für nachgerechnete Zeit gilt derselbe Vorbehalt wie für eine Rückrechnung: verrauscht, nicht wohlwollend. Sie zählt für die Anzeige -- nie für Budget-Alarme.

Die Abdeckung wird immer gezeigt, und sie ist keine Zierde

Jede Erfüllungszahl in Pulse trägt im selben Atemzug den Anteil des Fensters, auf dem sie gemessen wurde. Das ist Absicht: der übliche Weg, auf dem eine Verfügbarkeitszahl lügt, ist das stille Weglassen der Zeit, in der niemand hingeschaut hat. Perfekte 100 %, gemessen an zwei Tagen eines dreißigtägigen Monats, sind kein guter Monat.

Zeit, die Pulse nicht auswerten konnte, wird aus der Rechnung herausgenommen und weder als gut noch als schlecht gezählt. Unbekannt ist kein Fehlschlag -- und auch kein Erfolg.

Unterhalb der Abdeckungsuntergrenze gibt es keine Zahl

Wurde weniger vom Fenster gemessen, als die Abdeckungsuntergrenze verlangt, meldet das Ziel Nicht genug Daten statt eines Prozentwerts -- die Zahlen dahinter bleiben sichtbar, die Überschrift ist dann aber der Vorbehalt.

Das ist die ehrliche Antwort, und sie ist einer Zahl vorzuziehen: Ein Versprechen, das auf einem Drittel seines Fensters gemessen wurde, wird weder eingehalten noch gebrochen -- es wird nicht gemessen.

Die Budget-Kurve

Das Diagramm zeigt, wie das Fehlerbudget über das Fenster abschmilzt -- flach, solange die Bedingung hält, mit einer Stufe nach unten, wo sie es nicht tat. Der genaue abgedeckte Zeitraum wird unterhalb des Diagramms angezeigt.

Die Kurve sagt etwas, das der Prozentwert nicht sagen kann: wann das Budget verbraucht wurde. Eine einzelne Kante an einem Dienstag ist ein Vorfall, den man untersucht. Ein gleichmäßiges Gefälle ist ein Prozess, der nicht ganz stimmt und dabei nie etwas auslöst.

Benachrichtigt werden

Ein Ziel ist unter der Haube ein Monitor: Es trägt eine eigene Eskalationsrichtlinie, eigene Tags und einen eigenen Stummschalter, und seine Alarme erzeugen Vorfälle in derselben Liste wie alles andere. Eine Alarmierung wegen eines Fehlerbudgets funktioniert also genau wie eine wegen einer toten SPS -- nichts Neues musste lernen, wie es Sie erreicht.

Worüber es alarmiert, entscheiden seine Budget-Alarme -- die Staffel im gleichnamigen Bereich auf der Seite des Ziels. Ein Ziel ohne Stufen misst und berichtet und weckt niemanden, was völlig in Ordnung ist.

Budget-Alarme lesen ausschließlich laufende Messung -- nachgerechnete, näherungsweise Historie alarmiert niemanden. Ein frisch angelegtes Ziel zeigt deshalb sofort einen näherungsweisen Wert, hält seine Alarme aber zurück, bis genügend echte Abdeckung vorliegt -- genau wie es das ohne die Nachrechnung getan hätte.

Warum nicht einfach alarmieren, wenn das Ziel gerissen ist?

Weil es dann zu spät ist, noch etwas zu tun.

Ein 30-Tage-Ziel bei 99,5 % hat rund dreieinhalb Stunden Spielraum. Ein Alarm, der bei aufgebrauchtem Spielraum auslöst, meldet Ihnen einen Monat, den Sie bereits verloren haben. Wissen wollen Sie, dass Sie ihn zu schnell verbrauchen, um über den Monat zu kommen -- solange noch Budget da ist, das sich schützen lässt.

Genau darauf schaut ein Budget-Alarm: nicht auf den Stand, sondern auf die Rate.

Die Staffel einrichten

Im Bereich Budget-Alarme auf der Seite des Ziels:

1. Prüfen Sie, wer alarmiert wird -- die Eskalationsrichtlinie wurde beim Anlegen des Ziels gewählt und lässt sich hier ändern
2. Fügen Sie einen oder mehrere Budget-Alarme hinzu -- oder übernehmen Sie die empfohlene Staffel
3. Speichern

Die zwei Arten von Budget-Alarm

Art	Liest sich als
Budget wird zu schnell verbraucht	"Mindestens X % des Budgets sind in den letzten W verbraucht worden"
Zeit, bis das Budget aufgebraucht ist	"Beim aktuellen Tempo ist das Budget innerhalb von N leer"

Budget wird zu schnell verbraucht ist die Art, mit der man anfängt. Sie braucht keine Hochrechnung, und Sie können sie gegen die Budget-Kurve auf derselben Seite prüfen -- was viel wert ist, wenn zu entscheiden ist, ob ein ausgelöster Alarm berechtigt war.

Zeit, bis das Budget aufgebraucht ist lässt sich angenehmer formulieren und läuft unruhiger. Das aktuelle Tempo wird über ein Viertel des angefragten Horizonts gemessen, sodass eine kurze Abweichung auf eine Verletzung hochrechnen kann, die ein längerer Blick nicht vorhergesagt hätte.

Der Prozentwert bezieht sich auf das gesamte Budget, nicht auf das Fenster

"8,5 % innerhalb von 1 Stunde" bedeutet achteinhalb Prozent des Spielraums des ganzen Monats, verbraucht innerhalb einer Stunde.

Das macht die Stufen untereinander und gegenüber der Budget-Kurve vergleichbar. Würde jede Stufe gegen den Budgetanteil ihres eigenen Fensters messen, bedeutete jeder Schwellwert etwas anderes, und die Staffel wäre nicht lesbar.

Die empfohlene Staffel

Zwei Stufen, die der Bereich für Sie ausfüllt:

Stufe	Bedeutet typischerweise
8,5 % in 1 Stunde	Gerade läuft etwas ernsthaft schief -- jemanden alarmieren
43,2 % in 3 Tagen	Ein schleichender Verlust, der den Monat kostet -- Ticket

Wichtiger als die genauen Zahlen ist die Form: eine schnelle Stufe für die Krise, eine langsame für das Schleichende. Eine einzige Stufe schreit entweder bei jeder Kleinigkeit oder übersieht den schleichenden Verlust vollständig.

Ein Ziel hat eine Eskalationsrichtlinie. Sollen Stufen verschiedene Personen erreichen, zeichnen Sie zwei Ziele über denselben Knoten -- ein schnelles Versprechen an eine Richtlinie, die anruft, ein langsames an eine, die eine E-Mail schreibt.

Was ein Vorfall aussagt

Vorfälle entstehen je Stufe: Zwei ausgelöste Stufen sind zwei Vorfälle, und das Schließen des einen schließt den anderen nicht.

Linie 1 bleibt innerhalb der Grenzwerte verbraucht ihr Fehlerbudget 13,26 % des Fehlerbudgets wurden innerhalb von 1 h verbraucht; 32,3 % des Budgets sind noch übrig.

Benannt ist er nach dem Ziel, nicht nach der Stufe -- das ist der Satz, der für die lesende Person etwas bedeutet. Welche Stufe es war, steht in den Zahlen. Der Vorfall verweist direkt zurück auf die Seite des Ziels.

Vorfälle eskalieren, werden bestätigt und geschlossen wie alle anderen. Wird die Stufe wieder ruhig, schließt sich der Vorfall von selbst.

Ein nicht messbares Ziel hält seine Alarme offen

Fällt das Ziel unter seine Abdeckungsuntergrenze, melden seine Budget-Alarme Nicht bestimmbar statt ruhig.

Ein bereits offener Vorfall bleibt dann offen und eskaliert nicht weiter -- Pulse weckt niemanden zusätzlich für etwas, das es nicht mehr bestätigen kann, und gibt ebenso wenig stillschweigend Entwarnung. Die Eskalation läuft von selbst weiter, sobald die Daten zurück sind.

Bedingungs-Monitore werden genauso behandelt, aus demselben Grund: Ein sterbender Datenpunkt darf nie wie ein behobenes Problem aussehen.

Die Staffel lesen

Jede Stufe zeigt, was sie gerade sagt, mitsamt der Zahl dahinter:

Kennzeichnung	Bedeutung
Verbrennt · 13,26 %	Ausgelöst. So viel des Budgets ging innerhalb des Fensters dieser Stufe
13,26 %	Ruhig -- und so nah dran
Nicht bestimmbar	Das Ziel liegt unter seiner Abdeckungsuntergrenze -- siehe oben

Auch ruhige Stufen zeigen ihre Zahl, und zwar bewusst: Der nützliche Blick auf eine Staffel gilt der Frage, wie nah die ruhigen Stufen sind -- nicht nur, dass sie ruhig sind.

Die Staffel bearbeiten

Stufen werden gemeinsam bearbeitet und gemeinsam gespeichert. Das Fenster einer Stufe muss mindestens eine Stunde betragen und darf nicht länger als das Fenster des Ziels sein -- eine Stufe kann nicht nach Zeit fragen, die das Versprechen nicht misst.

Wird eine Stufe entfernt und gespeichert, wird sie stillgelegt. Ein von ihr erzeugter Vorfall wird geschlossen, und ihre Kennung wird nicht wiederverwendet -- eine spätere Stufe kann also keinen alten Vorfall erben.

Stummschalten

Stummschalten im Aktionsmenü des Ziels (oder im Zeilenmenü der Liste) bringt es zum Schweigen: Budget-Alarme erzeugen keine Vorfälle, bis die Stummschaltung aufgehoben wird. Die Messung läuft die ganze Zeit weiter -- die Zahlen aktualisieren sich weiterhin, und die Seite sagt deutlich, dass das Ziel stummgeschaltet ist.

Es ist dieselbe Stummschaltung, die jeder Monitor hat -- denn das Ziel ist einer.

Aktionen in der Zielliste

Jedes Ziel in der Liste verfügt über ein Zeilenmenü mit Schnellaktionen:

• Öffnen — navigiert zur Detailseite des Ziels.
• Bedingung öffnen — öffnet den Bedingungseditor für die Bedingung, auf der dieses Ziel gemessen wird.
• Stummschalten / Stummschaltung aufheben — der oben beschriebene Schalter. Ein stummgeschaltetes Ziel ist in der Liste gekennzeichnet.
• Löschen — entfernt das Ziel.

Was beim Löschen eines Ziels mit der Bedingung geschieht, hängt davon ab, ob noch etwas anderes auf sie verweist. Verwendet ein Monitor oder ein anderes Ziel dieselbe Bedingung, bleiben die Bedingung und ihre Historie unverändert. Ist dieses Ziel der einzige Verwender, wird die Bedingung mit dem Ziel gelöscht. Der Löschdialog zeigt an, welcher Fall zutrifft, bevor Sie bestätigen.

Rückrechnung

Niemand kann einen Zielwert wählen, den er nie gemessen gesehen hat. Die Rückrechnung ermittelt aus gespeicherten Messwerten, was ein Versprechen über einen vergangenen Zeitraum gesagt hätte -- damit Sie einen Zielwert mit Belegen wählen statt zu raten. Sie lebt auf der Anlegen-Seite: Sobald das Ziel existiert, ist dieselbe Nachrechnung bereits automatisch gelaufen, und ihr Ergebnis steht als näherungsweise Nachrechnung auf der Seite des Ziels -- eine zweite Karte gibt es dort nicht mehr.

Sie beantwortet außerdem, wofür das Budget verbraucht wurde: welcher Zweig der Bedingung falsch war, während das Budget abfloss, als Anteil am Verbrauch. Da mehrere Zweige gleichzeitig falsch sein können, ergeben diese Anteile zusammen nicht 100 %; jeder liest sich als "dieser Teil war während N % des Verbrauchs falsch".

Eine Rückrechnung ist näherungsweise, und die Seite sagt das

Die Neuberechnung tastet auf einem groben Raster ab -- der Schritt steht neben der Zahl. Eine Abweichung, die kürzer als der Schritt ist, wird entweder ganz übersehen oder als ganzer Block gezählt.

Damit ist das Ergebnis verrauscht, nicht geschönt: Es über- und unterschätzt gleich wahrscheinlich, und der Fehler sinkt mit der Zahl der Abweichungen, nicht mit der Länge des Zeitraums. Ein Monat mit drei zweiminütigen Verletzungen kann als null oder als dreizehn Minuten zurückkommen.

Nutzen Sie sie, um einen Zielwert zu wählen. Zitieren Sie sie nie als Messung -- die aufgezeichnete Zahl darüber ist die Messung.

Die Rückrechnung reicht so weit zurück, wie Messwerte vorgehalten werden; deshalb sind die angebotenen Zeiträume begrenzt.

In Berichten

Vorfallberichte enthalten einen Abschnitt zu Zielen: was jedes Versprechen über den Zeitraum des Berichts gemeldet hat, nicht über sein eigenes rollierendes Fenster.

Genau darauf kommt es an. "Wurde das im Juni eingehalten" ist die Frage an einen Monatsbericht, und eine rollierende 30-Tage-Zahl vom Tag der Erstellung würde stillschweigend den Juli einschließen und den größten Teil des Juni auslassen.

Was Pulse hier noch nicht kann

Wissenswert, bevor Sie jemandem etwas versprechen:

• Geplante Stillstände werden nicht erkannt. Pulse kennt genau eine Ausnahme -- fehlende Daten -- und kann einen geplanten Stillstand nicht von einem toten Netzwerk unterscheiden. Eine Anlage, die jedes Wochenende steht, liegt unter ihrer Abdeckungsuntergrenze und meldet Nicht genug Daten statt einer Zahl. Wenn Ihre Anlage nicht durchgehend läuft, lesen Sie das, bevor Sie eine Abdeckungsuntergrenze setzen.
• Budget-Alarme werden einmal pro Minute ausgewertet, nicht in der Fünf-Sekunden-Schleife der Monitore. Das kürzeste zulässige Stufenfenster ist eine Stunde -- eine Minute liegt also deutlich innerhalb der Auflösung, die die Frage hat.
• Fenster sind ausschließlich rollierend. Ein vertraglicher "Kalendermonat" lässt sich noch nicht ausdrücken.
• Eine Bedingung je Ziel. Versprechen über mehrere Dinge gleichzeitig zeichnet man als eine Bedingung mit einem alle von-Gatter, nicht als mehrere Ziele.
• Die Bedingung kann sich innerhalb eines Fensters ändern. Passiert das, meldet die Seite Die Bedingung wurde in diesem Zeitraum geändert -- die Zahl umfasst dann zwei verschiedene Definitionen von "gut". Das ist nicht falsch, sollte aber bekannt sein, bevor man sie zitiert.