Durchführen einer fortlaufenden Optimierung zum Verringern bedeutungsloser Warnungen
In dieser Lerneinheit erfahren Sie mehr über Prozesse, die Sie zur Überwachung der Standortzuverlässigkeit implementieren können. Außerdem erfahren Sie mehr über die fortlaufende Optimierung Ihrer Warnungen, um die Anzahl bedeutungsloser Warnungen zu reduzieren.
Überwachung und Warnung
Die Überwachung und Benachrichtigung ermöglicht es einem System, Personen mitzuteilen, wenn es defekt ist oder was eventuell demnächst defekt sein wird. Wenn jemand das Problem untersuchen muss, sollte die Warnung relevante Informationen enthalten, damit die Person weiß, wo sie ansetzen muss.
Wenn Sie bestehende Warnungen überprüfen oder neue Warnungsregeln schreiben, berücksichtigen Sie diese Richtlinien, damit Ihre Warnungen relevant bleiben und Ihr Bereitschaftsdienst glücklicher wird:
- Warnungen, die die Aufmerksamkeit einer Person erregen, sollten dringend, wichtig, handlungsorientiert und real sein.
- Warnungen sollten entweder laufende oder bevorstehende Probleme mit Ihrem Dienst darstellen.
- Entfernen Sie ungenaue Warnungen. Eine übermäßige Überwachung ist ein schwieriger zu lösendes Problem als eine nicht ausreichende Überwachung.
- Ordnen Sie das Problem in eine dieser Kategorien ein:
- Verfügbarkeit und grundlegende Funktionalität.
- Latency.
- Richtigkeit.
- Funktionsspezifische Probleme.
- Symptome sind eine bessere Möglichkeit, um Probleme mit weniger Aufwand umfassend und ordentlich zu erfassen.
- Beziehen Sie ursachenbasierte Informationen auf symptombasierten Seiten oder auf Dashboards ein, aber vermeiden Sie es, direkt auf Ursachen hinzuweisen.
- Je weiter oben Sie sich im Bereitstellungsstapel befinden, desto mehr unterschiedliche Probleme können Sie mit einer einzelnen Regel abfangen. Gehen Sie aber nicht so weit, dass Sie nicht mehr unterscheiden können, was vor sich geht.
- Wenn Sie einen ruhigen Bereitschaftsdienst wünschen, sollten Sie über ein System für den Umgang mit Problemen verfügen, die eine zeitnahe Reaktion erfordern, aber nicht unmittelbar kritisch sind.
Überwachen für Benutzer
Die Überwachung für Ihre Benutzer wird auch symptombasierte Überwachung genannt. Dies steht im Gegensatz zur ursachenbasierten Überwachung. Ihre Benutzer interessiert es nicht, ob bei Ihrem Datenpush ein Fehler auftritt. Sie interessieren sich dafür, ob ihre Ergebnisse aktuell sind.
Im Allgemeinen ist Folgendes für Benutzer wichtig:
- Grundlegende Verfügbarkeit und Richtigkeit: Alles, was den Kerndienst in irgendeiner Weise unterbricht, sollte als „Nichtverfügbarkeit“ kategorisiert werden.
- Latenz: Seiten sollten schnell geladen werden.
- Vollständigkeit, Aktualität und Dauerhaftigkeit: Die Daten Ihrer Benutzer sollten sicher sein, zeitnah zurückgesendet werden und über aktuelle Suchindizes verfügen.
- Uptime: Auch wenn der Dienst vorübergehend nicht verfügbar ist, sollten die Benutzer darauf vertrauen, dass der Dienst bald wieder zur Verfügung steht.
- Features: Ihre Benutzer achten darauf, dass alle Features des Diensts funktionieren. Überwachen Sie sämtliche wichtigen Aspekte Ihres Diensts, auch wenn sie nicht zur Kernfunktionalität gehören.
Es gibt einen feinen, aber wichtigen Unterschied dahingehend, ob Datenbankserver oder Benutzerdaten nicht verfügbar sind. Ersteres ist eine unmittelbare Ursache, letzteres ist ein Symptom.
Ursachenbezogene Warnungen haben ihre Berechtigung
Manchmal gibt es kein Symptom, bei dem ein Warnung ausgelöst werden muss, aber Sie müssen trotzdem auf eine Situation aufmerksam gemacht werden. Ein Beispiel dafür ist, wenn der Arbeitsspeicher knapp wird. Sie möchten, dass die Regeln Sie über Aspekte informieren, die zu einem Problem werden könnten, bevor sie ein Symptom verursachen. In diesem Fall können Sie eine Regel schreiben, die auf diese Bedingung hinweist.
Schreiben Sie jedoch keine ursachenbasierten Regeln, die bei Aufruf Warnungen für Symptome auslösen, die Sie anderweitig abfangen können.
Tickets, Berichte und E-Mails
Warnungen, die bald (aber nicht sofort) Aufmerksamkeit erfordern, sind unterkritische Warnungen. Hier folgen einige Vorschläge für die Protokollierung von unterkritischen Warnungen zur späteren Weiterverfolgung:
- Fehler- oder Ticketverfolgungssysteme können für diese Art von Warnung nützlich sein: Eine Warnung kann einen Fehler öffnen, solange dieselbe Warnung ordnungsgemäß in einem einzelnen Ticket oder Fehler platziert wird. Diese Fehler können dann einen Selektierungsprozess durchlaufen, um einer Person zur Nachverfolgung zugewiesen zu werden. Es ist wichtig, dass diese Art von Problemen behoben wird, bevor diese Probleme kritisch werden. Berücksichtigen Sie, wie viel von der Zeit Ihrer Teammitglieder für die Fehlerbehebung aufgewendet werden kann.
- Ein täglicher (oder häufigerer) Bericht kann nützlich sein: Schreiben Sie unterkritische langlebige Warnungen, z. B. „die Datenbank ist zu über 90 % gefüllt“, in einen Bericht, in dem alle aktiven Warnungen anzeigt werden. Beauftragen Sie eine Person mit der täglichen Selektierung dieses Berichts.
- Jede Warnung sollte durch ein Workflowsystem nachverfolgt werden: Dadurch wird sichergestellt, dass sie erkannt und behandelt wird.
Im Allgemeinen sollte ein System geschaffen werden, das die Verantwortlichkeit für die Reaktionsfähigkeit fördert, aber nicht die hohen Kosten eines sofortigen menschlichen Eingriffs verursacht.
Playbooks
Playbooks, manchmal auch als Runbooks bezeichnet, sind ein wichtiger Bestandteil eines Benachrichtigungssystems. Verwenden Sie einen Eintrag im Playbook, der erläutert, was für jede Warnung oder jede Gruppe von Warnungen zu erledigen ist, die ein Symptom erfasst.
Nachverfolgung und Verantwortlichkeit
Wenn jemand eine Warnung erhält und feststellt, dass kein Problem vorliegt, ist das ein Zeichen dafür, dass Sie die Regel entfernen, sie zurückstufen oder auf andere Weise Daten sammeln müssen. Warnungen, die weniger als 50 % genau sind, gelten als fehlerhaft. Selbst diejenigen Warnungen, die in 10 % der Fälle entsprechende False Positive-Ergebnisse auslösen, sollten neu bewertet werden.
Eine wöchentliche Überprüfung aller ausgelösten Bereitschaftswarnungen und die Analyse der vierteljährlichen Warnungstatistiken kann Ihnen helfen, Muster zu erkennen, die beim Konzentrieren auf einzelne Warnungen verloren gehen.
Wann ist die Ausnahme von der Regel zu suchen?
Hier sind einige Gründe, warum Sie gegen die oben genannten Richtlinien verstoßen könnten:
Es gibt eine bekannte Ursache, die tatsächlich unter dem Rauschen Ihrer Symptome liegt:Wenn Ihr Dienst z. B. eine Verfügbarkeit von 99,99 % aufweist, aber ein häufig auftretendes Ereignis dafür sorgt, dass 0,001 % der Anforderungen fehlschlagen, können Sie nicht auf dieses Symptom hinweisen, da es innerhalb der Störungen liegt, aber Sie können das verursachende Ereignis abfangen.
Sie können keine Überwachung am Einstiegspunkt ausführen, weil Datenauflösung verloren geht: Beispielsweise tolerieren Sie, dass einige Endpunkte langsam sind, z. B. die Überprüfung von Kreditkarten. Bei Ihren Lastenausgleichsmodulen kann dieser Unterschied verloren gehen. Sie müssen sich auf dem Stapel nach unten bewegen und die Warnung von der höchsten Stelle aus auslösen, die diesen Unterschied aufweist.
Ihre Symptome treten erst auf, wenn es zu spät ist: Beispielsweise verfügen Sie über kein weiteres Kontingent. Sie müssen jemanden benachrichtigen, bevor es zu spät ist, und das bedeutet manchmal, eine Ursache für die Warnung zu finden. Beispiel: Ihr Verbrauch ist größer als 80 % und wird bei der Wachstumsrate der letzten Stunde in weniger als vier Stunden aufgebraucht sein.
Sie sollten aber auch in der Lage sein, eine ähnliche Ursache zu finden, die weniger dringend ist. Beispiel: Ihr Kontingent ist größer als 90 % und wird bei der Wachstumsrate des letzten Tags in weniger als vier Tagen aufgebraucht sein. Dieser Satz von Umständen wird die meisten Fälle auffangen. Sie können das Problem dann in Form eines Tickets, einer E-Mail-Warnung oder eines täglichen Problemberichts behandeln, anstatt es in letzter Minute zu eskalieren, wie es durch eine Warnung dargestellt wird.
Ihre Warnungseinrichtung ist komplexer als die Probleme, die erkannt werden sollen: Das Ziel sollte darin bestehen, einfache, robuste und sich selbst schützende Systemen zu verwenden.