Dieser Beitrag ist der zweite in unserer Reihe über wie Sie Daten nutzen können, um Ihren IT-Betrieb zu verbessern. Unser erster Beitrag war über Alarmmüdigkeit .

Vor ein paar Wochen haben wir in unserem Blog über wichtige Leistungskennzahlen berichtet, die Top-Operationsteams verfolgen . Im Gespräch mit unseren Betatestern für Advanced Reporting haben wir einiges darüber gelernt, wie Teams die Time to Acknowledge (MTTA) und Time to Respond (MTTR) messen. Die Art und Weise, wie Ihr Team PagerDuty verwendet, kann einen erheblichen Einfluss darauf haben, wie diese Metriken aussehen. Daher möchten wir einige Best Practices weitergeben, um die Metriken aussagekräftiger zu gestalten.

1. Richtlinien zur Bestätigung von Vorfällen entwickeln

Die Zeit, die zum Reagieren auf einen Vorfall benötigt wird, ist eine wichtige Leistungskennzahl. Um Ihre Reaktionszeit in PagerDuty zu verstehen, empfehlen wir Ihnen, einen Vorfall zu bestätigen, wenn Sie mit der Arbeit daran beginnen. Wenn Sie außerdem eine Eskalationsrichtlinie für mehrere Benutzer haben, ist diese Vorgehensweise noch wichtiger – wir haben gerade ein Update veröffentlicht, sodass Ihre Teamkollegen benachrichtigt werden, sobald Sie einen Vorfall bestätigen, dass sie sich nicht mehr um die Warnung kümmern müssen.

Viele leistungsstarke Operationsteams setzen Ziele für die Bestätigungszeit, da dies eine Kennzahl ist, über die Teams normalerweise viel Kontrolle haben. Der Teambericht von PagerDuty kann Ihnen Trends in Ihrer TTA anzeigen, sodass Sie sehen können, ob Sie Ihre Ziele erreichen und wie sich die TTA mit der Anzahl der Vorfälle ändert.

2. Definieren Sie, wann eine Lösung erfolgen soll

Wir empfehlen, Vorfälle zu lösen, wenn sie vollständig abgeschlossen sind und der Dienst wieder voll betriebsbereit ist. Wenn Sie eine API-Integration verwenden, löst PagerDuty Vorfälle automatisch, wenn wir vom Dienst die Meldung „Alles ist in Ordnung“ erhalten. Wenn Sie Vorfälle jedoch manuell lösen, stellen Sie sicher, dass Ihr Team weiß, dass Vorfälle in PagerDuty gelöst werden müssen, wenn das Problem behoben ist. Um die Lösung von Vorfällen noch einfacher zu machen, werden wir in Kürze ein Update für unsere E-Mail-basierten Integrationen veröffentlichen, um Vorfälle automatisch per E-Mail zu lösen.

3. Timeouts mit Bedacht nutzen

Wenn Sie die Einstellungen für einen Dienst erstellen, können Sie zwei Timeouts festlegen: das Timeout für die Bestätigung des Vorfalls und das Timeout für die automatische Lösung. 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 Bestätigung von Vorfällen bietet ein Sicherheitsnetz, wenn Sie mitten in der Nacht durch eine Warnung geweckt werden und nach der Bestätigung wieder einschlafen. Sobald das Timeout erreicht ist, wird der Vorfall erneut geöffnet und Sie werden erneut benachrichtigt. Wenn das Einschlafen nach der Bestätigung eines Vorfalls ein großes Problem für Ihr Team darstellt, sollten Sie das Timeout für die Bestätigung von Vorfällen beibehalten – dies kann jedoch Ihre MTTA-Metriken komplexer machen. Das Timeout für die Bestätigung von Vorfällen kann für jeden Dienst unabhängig konfiguriert werden und die Standardeinstellung beträgt 30 Minuten.

Wenn Sie es nicht gewohnt sind, Vorfälle nach Abschluss der Arbeit zu lösen, können Sie vergessene Vorfälle mit automatischen Lösungs-Timeouts schließen. Dieses Timeout ist auch in den Serviceeinstellungen konfigurierbar und der Standardwert beträgt 4 Stunden. Wenn Sie dieses Timeout verwenden, sollten Sie sicherstellen, dass es länger ist als die Zeit, die zum Lösen der meisten Ihrer Vorfälle benötigt wird (Sie können unsere System- oder Teamberichte verwenden, um Ihre Zeit für die Lösung von Vorfällen anzuzeigen). Um sicherzustellen, dass Sie offene Vorfälle nicht vergessen, sendet Ihnen PagerDuty auch alle 24 Stunden eine E-Mail, wenn Sie Vorfälle haben, die länger als einen Tag offen sind.

4. Behandeln Sie Flatteralarme

Ein Flatteralarm ist ein Alarm, der ausgelöst wird und sich danach schnell auflöst. Flatteralarme werden normalerweise dadurch verursacht, dass die überwachte Metrik um einen Schwellenwert schwankt. Flatteralarme können Ihre MTTR- und MTTA-Metriken durcheinanderbringen – im Teambericht sehen Sie möglicherweise eine hohe Anzahl von Alarmen mit einer niedrigen Lösungszeit oder einer Lösungszeit, die kürzer als die Bestätigungszeit ist (automatisch gelöste Vorfälle werden nie bestätigt). Es ist eine gute Idee, Flatteralarme zu untersuchen, da sie zu Alarmmüdigkeit beitragen können (ganz zu schweigen davon, dass sie Ärger verursachen) – oft können sie durch Anpassen des Schwellenwerts behoben werden. Weitere Ressourcen zu Flatteralarmen finden Sie hier Neues Relikt Und Nagios Artikel.