Ding Ding Ding! Es ist 3 Uhr morgens, Sie träumen einen wunderbaren Traum, und plötzlich — das Telefon klingelt. Diese Woche haben Sie den Dienst, und anscheinend ist etwas passiert. Das automatisierte System fordert Sie auf, herauszufinden, was los ist. Dies ist ein entscheidender Moment im Management moderner Computersysteme, aber lassen Sie uns sehen, wie wir Benachrichtigungen für die Menschen komfortabler gestalten können.
Lernen Sie die Philosophie des Monitorings kennen, die aus meinen jahrzehntelangen Diensten in verschiedenen Monitoring-Teams hervorgegangen ist. Sie wurde maßgeblich von der wahren Bibel von Rob Evasiuk beeinflusst. (My Philosophy on Alerting), die in das Buch über aufgenommen wurde, und das Buch von John Allspaw (Considerations for Alert Design).
, und — danke für die Unterstützung beim Editieren des Beitrags.
Was ist CASE?
Ich wollte eine ansprechende Abkürzung finden, ähnlich wie bei oder Ich nenne es DAS METHOD. Es beschreibt vier Punkte, auf die man beim automatisierten Monitoring achten sollte:
- (context-heavy)
- (actionable)
- (symptom-based)
- (evaluated)
Wenn Sie CASE verwenden, gehen Sie mit Benachrichtigungen entspannt um und wecken keine Leute nachts auf. Es ist wichtig, die Überwachung regelmäßig auf Nützlichkeit und Effektivität zu überprüfen. Wenn jemand eine Benachrichtigung erhält, hat er ein besseres mentales Modell und mehr Vertrauen.
Um es sich leichter zu merken, stellen Sie sich vor, dass Sie für jede Benachrichtigung einen CASE [also einen Grund — Translator's note] benötigen, um sie zu rechtfertigen. :sunglasses:
Und warum das alles?
. Aus vielen Gründen. Und CASE wird nicht alle beseitigen. Aber damit wachen Sie nachts von qualitativ besseren Benachrichtigungen auf. Diese Methode umfasst verschiedene organisatorische Prozesse, die ebenfalls hilfreich sind.
Das Schöne an den Methoden RED und USE ist, dass wir nicht nur wissen, wie wir arbeiten, sondern auch in einer gemeinsamen Sprache miteinander sprechen. Ich hoffe, dass es mit der Methode CASE einfacher sein wird, Benachrichtigungen zu diskutieren, die unsere Systeme schützen, aber unsere Kollegen nicht zur Ruhe kommen lassen.
Es geht darum, eine Kultur in der Organisation zu schaffen, in der Benachrichtigungen mit einer gesunden Gelassenheit behandelt werden. Benachrichtigungen können manchmal notwendig sein, aber es ist nicht sicher, dass sie später noch relevant sind. Warum haben wir diese Benachrichtigung eingerichtet? Wurden die Kriterien dafür kürzlich überprüft? Mit CASE können Antworten auf diese Fragen gefunden werden.
Kontextbelastet — Kontextbezug
3 Uhr morgens ist nicht die beste Zeit, um Nachrichten zu lesen, die viele komplizierte Begriffe enthalten. Um effektiv zu reagieren, braucht man Informationen. Idealerweise sollte es sich um Informationen zu einem konkreten Problem handeln, bei dem der Kontext sofort klar ist. Die Benachrichtigungen sollten so eingestellt werden, dass dies möglich ist. Das sind das "Beobachten" und "Orientieren" aus . Für diese Anpassung sollte man gerne Zeit investieren, denn jemanden ständig abzulenken, kostet noch mehr. Lassen Sie uns gegenseitig respektieren.
Probleme haben viele Ursachen. Besonders die unsichtbaren.
Wie kann man dem Bereitschaftsdienst helfen? Zunächst sieht der Bereitschaftsdienst die Benachrichtigung, also basiert er alle Hypothesen darauf. Dann schaut er sich die Anleitungen und Dashboards an, aber sind dort immer Daten zu der spezifischen Benachrichtigung enthalten oder nur allgemeine Informationen? Olspo empfiehlt, "darüber nachzudenken, wie man die Benachrichtigung interpretieren oder darauf reagieren kann" (Folie 29).Eine gute Benachrichtigung ist auf den Bereitschaftsdienst ausgerichtet und nicht nur nach einem Schwellenwert eingestellt.
Deshalb hier einige Ideen zur Verbesserung des Kontexts von Benachrichtigungen:
- Zeigen Sie dem Benutzer etwas Nützliches und Spezielles, und nicht einfach allgemeine Anleitungen oder ein Dashboard. Früher haben wir mit den Kollegen Dashboards zur Untersuchung genutzt, die auf spezifische Benachrichtigungen eingestellt waren. Das war hilfreich, wenn das Problem bekannt war, und hat in anderen Fällen nur verwirrt. Hier muss ein Gleichgewicht gefunden werden.
- Erzählen Sie die Geschichte der Benachrichtigung: Ist sie neu? Tritt sie häufig auf? Ist sie saisonal?
- Zeigen Sie kürzliche Änderungen im Systemzustand an. Hat sich kürzlich etwas geändert? (Zum Beispiel ein Deployment oder das Aktivieren/Deaktivieren von Funktionen.)
- Zeigen Sie die Beziehungen auf und geben Sie Informationen für ein mentales Modell: Die Abhängigkeiten des Systems sollten klar ersichtlich sein, idealerweise mit Angaben zur Funktionsfähigkeit.
- Verbinden Sie den Benutzer zügig mit dem Team: Sie sehen die aktuellen Vorfälle oder können herausfinden, wer in der Firma ebenfalls informiert wurde? Ist das Programm akt aktiviert?
Idealerweise gibt das Vorfallmanagement-Programm Hinweise zur Verbesserung des Kontextes der Benachrichtigung im Rahmen der Untersuchung von Vorfällen. Hier gibt es immer Verbesserungspotential!
Handlungsorientiert — praktische Relevanz
Sollte der Bereitschaftsdienst auf die Benachrichtigung reagieren? Wenn nichts zu tun ist oder unklar bleibt, was zu tun ist, warum wurde dann geweckt? Es sollten keine Benachrichtigungen vermieden werden, die den Bereitschaftsdienst belästigen und keine Handlungen erfordern.
Was ist zu tun? Was wird benötigt?
Früher, als Systeme einfach waren und die Teams klein, richteten wir das Monitoring ein, um einfach auf dem Laufenden zu bleiben. Eine Benachrichtigung über einen Anstieg der Last auf einem Cluster gibt uns Kontext, falls der Dienst später Störungen aufweist. In großem Maßstab führen solche Benachrichtigungen jedoch nur zu Verwirrung, da unsere Systeme immer in einem Zustand unterschiedlicher degradierten Leistung arbeiten. Das führt schnell zu und natürlich zu einem Verlust der Sensibilität. Daher ignoriert der Diensthabende solche Benachrichtigungen oder filtert sie sogar und reagiert nicht immer wie erforderlich. Lassen Sie sich nicht in diese Falle treiben! Richten Sie nicht alle Benachrichtigungen ein, um sie später an eine längst vergessene E-Mail-Ordner zu senden.
So sieht eine Benachrichtigung mit praktischem Nutzen aus:
- Die Benachrichtigung erfordert eine Handlung und informiert nicht nur über Neuigkeiten.
- Diese Handlung ist schwer oder riskant zu automatisieren. Wenn es machbar ist, automatisieren Sie es einfach, hören Sie auf, die Leute zu belästigen!
- Die Benachrichtigung enthält dringende Empfehlungen in Form von (SLA) oder (RTO). Dann kann der Diensthabende das Incident Management-Programm der Organisation aktivieren.
Ich möchte klarstellen: Ich sage nicht, dass Benachrichtigungen nur für die wichtigsten SLOs (Service Level Objectives, Ziele der Serviceleistung) des API kommen sollten. Das Monitoring von SLOs wird kontinuierlich unterteilt und erfordert einen einheitlichen Ansatz für alle Dienste. Es ist selbstverständlich, dass Sie die wichtigsten SLOs für zahlende Kunden überwachen werden. Aber auch die SLOs der Infrastruktur, wie z.B. von Datenbanken, müssen beachtet werden. Bald werden Sie sich auch um interne Kunden kümmern müssen. Und das geht ewig so weiter.
Symptomorientiert — Fokus auf Symptome
Ob es Ihnen gefällt oder nicht, Sie arbeiten in einem verteilten System (Kawaj).. Infolgedessen verwenden Sie verschiedene Taktiken, um Dienste zu isolieren und sie vor Ausfällen zu schützen (Treynor et al.). Und obwohl eine langwierige Müllabfuhr oder eine hängende Datenbankabfrage auf Probleme hindeuten, sollten Sie nicht nach ihrer Beseitigung streben, wenn die Benutzer in naher Zukunft keine Probleme haben werden.
Diese sind wichtige Signale und können praktischen Wert haben. Wenn sie jedoch die Benutzer nicht stören, sind sie nicht so dringend, dass sie den Dienst habenden ablenken sollten. Benachrichtigungen, die auf Ursachen basieren, sind Momentaufnahmen unserer mentalen Modelle eines Systemausfalls. Es ist besser, wichtige Symptome zu verfolgen, als zu versuchen, alle möglichen Ursachen eines Ausfalls aufzulisten.
Damit Benachrichtigungen praktischen Wert haben, konzentrieren Sie sich auf , die für die Benutzer wichtig sind. Jewaschuk bezeichnet dies als "Monitoring für die Benutzer". Denken Sie daran, dass diese Philosophie in der gesamten Organisation angewendet werden sollte. Sollten irgendwo in der Infrastruktur dringende Probleme auftreten, kümmert sich das entsprechende Team darum. Den Schutz der Systeme vor solchen Ausfällen zu gewährleisten, ist ein völlig anderes Thema (Trainer et al., Abschnitt über Strategien zur Minimierung kritischer Abhängigkeiten)..
Symptome sind nicht so variabel
Richard Cook erinnert daran, dass komplexe Systeme viele Mängel, Defekte und Probleme aufweisen.. Es ist Sisyphusarbeit, alle möglichen Ursachen aufzulisten. Sie versuchen, Probleme zu beschreiben, während sich diese ständig ändern. Sindhu Sreedharan ist der Meinung, dass „Systeme nicht jederzeit in einem perfekten Zustand sein müssen“ und dass es besser ist, einen menschenzentrierten Ansatz zu verfolgen. („Beobachtung verteilter Systeme“), 7).
Vermeiden Sie Benachrichtigungen über den Vorfall
Normalerweise werden Benachrichtigungen zu Ursachen eingerichtet, um Vorfälle zu beheben. Diese begrenzten Benachrichtigungen über den Vorfall selbst erzeugen jedoch ein falsches Gefühl der Sicherheit, da das System immer wieder neue Wege findet, um zu versagen.
Täuschen Sie sich nicht mit Ursachenbenachrichtigungen. Denken Sie besser nach:
- Warum hat die symptomatische Benachrichtigung das Problem nicht erkannt?
- Wäre es hilfreich, den Kontext für den Benutzer zu verbessern?
- Wie können wir die Überwachungstools verbessern, um schneller Diagnosen zu stellen, anstatt Benachrichtigungen über Vorfälle anzusammeln?
Überwachungswerkzeuge zur Diagnose helfen nur, wenn Sie sie als Mittel verstehen, um von einem Symptom zur Lösung zu gelangen. Ohne dieses Feedback werden Sie mit verspäteten Benachrichtigungen und Diagrammen über vergangene Ausfälle überflutet – ohne Hinweis auf zukünftige Probleme. Dies ist eine hervorragende Gelegenheit für das Unternehmen, von einer defensiven auf eine offensive Strategie umzusteigen. So haben Entwickler und Produktmanager die gleichen Erwartungen und klaren Ziele. Der Fall – CASE (:wink:) – ist für jede Benachrichtigung klar.
Ursachenbasierte Benachrichtigungen sind in moderatem Umfang akzeptabel.
Manchmal lässt unser System uns kaum eine Wahl hinsichtlich der ursachenbasierten Benachrichtigungen. Und manchmal verstehen die Diensthabenden gut, dass ein Symptom zwangsläufig zu einem Ausfall führen wird, was es von praktischer Bedeutung macht. Vielleicht sind Sie sich einfach nicht sicher, was vor sich geht, und stellen Benachrichtigungen zur Sicherheit ein. Hoffen wir, dass diese Maßnahme nur vorübergehend erforderlich ist, bis wir das System ändern, um das Problem der Leistungsabfälle zu lösen.
Denken Sie an andere Komponenten des CASE, wenn Sie mit solchen Situationen umgehen. Nur weil es vorübergehend ist, heißt das nicht, dass man nicht nachdenken sollte.
Bewertet — Bewertung
Änderungen im System (neuer Code, neue Infrastruktur, was auch immer neu ist) erhöhen das Risiko von Störungen (Cook, 3). Funktioniert diese Benachrichtigung immer noch wie erwartet? Klare und aktuelle mentale Modelle der Systeme sowie Erfahrungen im Umgang mit bestimmten Benachrichtigungen zur Unterstützung sind zentrale Merkmale . Fehler in den Systemen entwickeln sich ständig weiter, und wir müssen Schritt halten.
Es ist notwendig, die Qualität jeder Benachrichtigung kontinuierlich zu bewerten, damit sie wie erwartet funktionieren. Geschätzte Führungskräfte! Es wird Ihrem Team viel leichter fallen, wenn Sie ihnen helfen, diesen Prozess einzurichten! Hier sind einige Ideen zur Bewertung:
- Nutzen Sie , oder andere Methoden zur Prüfung der Benachrichtigungen. Das Team kann dies selbstständig durchführen, ohne ein schwerfälliges Incident-Management-System zu nutzen!
- Integrieren Sie die Erfassung von Daten zu allen benachrichtigen Vorfällen in das Incident-Management-Programm. Dokumentieren Sie nützliche, schädliche, irrelevante, unverständliche usw. Nutzen Sie diese als Feedback.
- Die richtigen Benachrichtigungen treten nicht oft auf und sind sorgfältig geprüft. Stellen Sie sicher, dass alle Links funktionieren, den richtigen Kontext angeben usw.
- Wenn die Benachrichtigung niemals auslöst oder zu oft auftritt, stimmt etwas nicht. Beheben Sie das Problem oder entfernen Sie sie. Seien Sie vorsichtig mit übermäßiger Passivität oder Aktivität!
- Richten Sie für die Benachrichtigungen Zeitstempel mit Ablaufdatum ein. Wenn das Ablaufdatum erreicht ist, bewerten Sie die Benachrichtigung nach der CASE-Methode und aktualisieren Sie den Zeitstempel. Überprüfen Sie regelmäßig das Ablaufdatum, wie bei Lebensmitteln.
- Vereinfachen Sie den Prozess zur Verbesserung der Benachrichtigungen. Verwenden Sie Monitoring als Code und speichern Sie Benachrichtigungen in einem Git-Repository. Pull-Requests helfen, das Team einzubinden, und Sie haben eine Historie früherer Benachrichtigungen. Sie werden weniger Angst haben, Benachrichtigungen zu ändern oder um Erlaubnis bei den Verantwortlichen zu fragen.
- Stellen Sie Feedback zu den Benachrichtigungen sicher, auch wenn es einfach ist , damit die Ansprechpersonen die Benachrichtigungen als nutzlos oder aufdringlich kennzeichnen können. Bauen Sie einen Link oder einen Aufruf zum Handeln direkt in die Benachrichtigung ein und überprüfen Sie regelmäßig das Feedback.
- Legen Sie in Ihrem Team eine Regel fest – lassen Sie die Bereitschaftsdienste an der Vereinfachung der Dienste arbeiten, wenn wenig zu tun ist. Lassen Sie alles nach Ihnen ein wenig besser werden, als es zuvor war.
Fazit
Ich denke, dass die CASE-Methode Entwicklern und Organisationen hilft, die Konfiguration und den Versand automatisierter Benachrichtigungen zu diskutieren. Ein Entwickler kann beginnen, die Benachrichtigungen mithilfe der CASE-Methode zu bewerten, und bald schließt sich die gesamte Organisation mit anderen Entwicklern, der Geschäftsführung und Incident-Management-Programmen an, um die Benachrichtigungen in gutem Zustand zu halten. Dafür sind keine besonderen Werkzeuge oder komplizierten Prozesse erforderlich.
Die gesamte Branche sollte den menschlichen Faktor im Bereitschaftsdienst in Betracht ziehen, ohne die erstklassige Kundenbetreuung zu beeinträchtigen. All diese Werkzeuge und Praktiken können und sollten verbessert werden. Ich hoffe, dass die CASE-Methode hierbei hilfreich ist.
Genießen Sie verbesserte Benachrichtigungen!
Quelle: habr.com
