Dieser Beitrag ist der zweite in unserer Reihe über Wie Sie Daten zur Verbesserung Ihrer IT-Abläufe nutzen können. Unser erster Beitrag handelte von Alarmmüdigkeit Die

Vor einigen Wochen haben wir in unserem Blog über wichtige Leistungskennzahlen geschrieben, die Top-Operations-Teams verfolgen Im Gespräch mit unseren Betatestern für die erweiterte Berichtsfunktion haben wir viel darüber erfahren, wie Teams die Zeit bis zur Bestätigung (MTTA) und die Zeit bis zur Antwort (MTTR) messen. Die Art und Weise, wie Ihr Team PagerDuty nutzt, kann einen erheblichen Einfluss auf die Aussagekraft dieser Kennzahlen haben. Daher möchten wir Ihnen einige Best Practices vorstellen, um die Kennzahlen aussagekräftiger zu gestalten.

1. Richtlinien für die Erfassung von Vorfällen entwickeln

Die Reaktionszeit auf einen Vorfall ist eine wichtige Leistungskennzahl. Um Ihre Reaktionszeit in PagerDuty zu verstehen, empfehlen wir Ihnen, einen Vorfall zu bestätigen, sobald Sie mit der Bearbeitung beginnen. Bei einer Eskalationsrichtlinie für mehrere Benutzer ist dies besonders wichtig: Wir haben kürzlich ein Update veröffentlicht, das Ihre Teammitglieder benachrichtigt, sobald Sie einen Vorfall bestätigen und sie sich keine weiteren Sorgen mehr machen müssen.

Viele leistungsstarke Operationsteams setzen sich Ziele für die Bearbeitungszeit (TTA), da diese Kennzahl in der Regel gut beeinflussbar ist. Der Teambericht von PagerDuty zeigt Ihnen Trends in Ihrer TTA, sodass Sie sehen können, ob Sie Ihre Ziele erreichen und wie sich die TTA mit der Anzahl der Vorfälle verändert.

2. Festlegen, wann eine Lösung gefunden werden soll

Wir empfehlen, Vorfälle zu beheben, sobald sie vollständig abgeschlossen sind und der Dienst wieder voll funktionsfähig ist. Bei Verwendung einer API-Integration behebt PagerDuty Vorfälle automatisch, sobald wir vom Dienst die Meldung „Alles in Ordnung“ erhalten. Wenn Sie Vorfälle jedoch manuell beheben, stellen Sie sicher, dass Ihr Team weiß, dass Vorfälle in PagerDuty nach Behebung des Problems als abgeschlossen markiert werden müssen. Um die Behebung von Vorfällen weiter zu vereinfachen, veröffentlichen wir in Kürze ein Update für unsere E-Mail-basierten Integrationen, mit dem Vorfälle automatisch per E-Mail behoben werden können.

3. Timeouts sollten sorgfältig eingesetzt werden.

Beim Erstellen der Einstellungen für einen Dienst können Sie zwei Timeouts festlegen: das Timeout für die Bestätigung von Vorfällen und das Timeout für die automatische Problembehebung. Diese Timeouts können sich auf Ihre MTTA- und MTTR-Metriken auswirken. Daher ist es wichtig zu verstehen, wie sie konfiguriert werden.

Ein Timeout für die Ereignisbestätigung bietet Sicherheit, falls Sie mitten in der Nacht durch eine Benachrichtigung geweckt werden und nach der Bestätigung wieder einschlafen. Nach Ablauf des Timeouts wird das Ereignis erneut geöffnet und Sie werden erneut benachrichtigt. Wenn das Einschlafen nach der Ereignisbestätigung für Ihr Team ein großes Problem darstellt, sollten Sie das Timeout beibehalten – dies kann jedoch Ihre MTTA-Kennzahlen komplexer gestalten. Das Timeout für die Ereignisbestätigung kann für jeden Dienst individuell konfiguriert werden; die Standardeinstellung beträgt 30 Minuten.

Wenn Sie es nicht gewohnt sind, Vorfälle nach Abschluss der Arbeit zu bearbeiten, sorgt die automatische Schließungs-Timeout-Funktion dafür, dass vergessene Vorfälle automatisch geschlossen werden. Dieses Timeout ist in den Serviceeinstellungen konfigurierbar und standardmäßig auf 4 Stunden eingestellt. Wenn Sie dieses Timeout verwenden, sollten Sie sicherstellen, dass es länger ist als die Zeit, die Sie üblicherweise für die Bearbeitung Ihrer Vorfälle benötigen (Ihre Bearbeitungszeiten können Sie in unseren System- oder Teamberichten einsehen). Damit Sie keine offenen Vorfälle vergessen, sendet Ihnen PagerDuty außerdem alle 24 Stunden eine E-Mail, falls Vorfälle länger als einen Tag offen sind.

4. Behandeln Sie die Flatteralarm-Warnungen

Ein flatternder Alarm ist ein Alarm, der ausgelöst wird und sich anschließend schnell wieder löst. Dies tritt typischerweise auf, wenn der überwachte Messwert um einen Schwellenwert schwankt. Flappende Alarme können Ihre MTTR- und MTTA-Kennzahlen verfälschen – im Teambericht sehen Sie möglicherweise eine hohe Anzahl von Alarmen mit kurzer Lösungszeit oder einer Lösungszeit, die kürzer ist als die Bestätigungszeit (automatisch gelöste Vorfälle werden nie bestätigt). Es ist ratsam, flatternde Alarme zu untersuchen, da sie zu Alarmmüdigkeit beitragen (und zudem lästig sein können) – oft lassen sie sich durch Anpassen des Schwellenwerts beheben. Weitere Informationen zu flatternden Alarmen finden Sie hier. New Relic Und Nagios Artikel.