Es ist Dienstagnacht, 2:37 Uhr, du schläfst – aber du hast Bereitschaftsdienst. Du erhältst einen Anruf von PagerDuty. Dein Partner versucht, dich mit einem Kissen zu wecken. Es hat funktioniert. Verschlafen nimmst du den Anruf entgegen und hörst deinen Lieblings-Roboter am anderen Ende der Leitung:

Robo-Guy:
„PagerDuty Alarm. Es wurde ein Alarm für den Dienst Datadog ausgelöst. Drücken Sie 2 zum Bestätigen. Drücken Sie 4 zum Eskalieren.“

„PagerDuty Alarm. Es wurde ein Alarm für den Dienst Datadog ausgelöst. Drücken Sie 2 zum Bestätigen. Drücken Sie 4 zum Eskalieren.“

„PagerDuty Alarm. Sie haben –“

Du drückst die 2 und stehst dann so leise wie möglich auf, damit das Kissen nicht zum Tritt wird.

Sie melden sich bei PagerDuty an und klicken auf den Ihnen zugewiesenen Vorfall. Da der Vorfall durch einen Dienst namens „ Datadog Sie gehen davon aus, dass das Problem mit etwas zusammenhängt, das Datadog erfasst hat. Aber, Sie fragen sich bei sich selbst: Ich habe seit Monaten an nichts gearbeitet, was mit Datadog zu tun hat, warum bin ich also überhaupt für diesen Dienst im Einsatz? Diese Datadog-Payload liefert nicht viele Informationen, daher loggen Sie sich bei Datadog ein, um sie genauer zu betrachten.

Welchen Stack überwacht Datadog? Rechenzentrum an der Westküste? Ostküste? Datenbank? API?

Tiefer Seufzer

Nach ein paar Minuten Klicken haben Sie den Fehler gefunden. Jetzt müssen Sie nur noch zu PagerDuty wechseln, den Vorfall dem richtigen Team zuweisen und können wieder schlafen gehen!

Sie gehen also zurück zu PagerDuty, klicken auf „Neu zuweisen“ und wählen die Option, die Aufgabe einem anderen Benutzer zuzuweisen. Eskalationsrichtlinie Es stellt sich heraus, dass Eskalationsrichtlinien (EP) nach Diensten oder Teams benannt werden sollten, was wahrscheinlich eine sichere Sache ist. Sie sehen sich die Liste der EPs an und finden Folgendes:

• Lisas Test EP
• Offshore rund um die Uhr
• Streusel und Einhörner
• Führungsteam
• Batman

Ein weiterer tiefer Seufzer

Kommt Ihnen das bekannt vor?

Als Digital Insights Consultant arbeite ich mit Unternehmen aller Größen und Branchen zusammen, die PagerDuty nutzen, und kenne dieses Szenario nur zu gut. Dank der Flexibilität der Plattform kann es vorkommen, dass ich mit zehn verschiedenen Unternehmen zusammenarbeite und zwölf verschiedene PagerDuty -Konfigurationen sehe. Ein wesentlicher Teil meiner Arbeit besteht darin, bestehende Nutzer zu beraten, wie sie ihren Incident-Management-Workflow mit PagerDuty optimieren können. Expertenleistungen Pakete oder unsere Betrieblicher Gesundheitsmanagementdienst Die

Für den Erfolg gerüstet

Als ich mit einem milliardenschweren Unterhaltungskonzern an der Optimierung ihres PagerDuty Erlebnisses arbeitete, stieß ich unter anderem auf das Problem, dass die realen Teams nicht mit ihren Mitarbeitern synchronisiert waren. Teams in PagerDuty Dieses Phänomen hat viele Gründe, beispielsweise den Wechsel von Mitarbeitern zwischen Teams oder die Bildung temporärer, projektbezogener Teams, die nicht aufgelöst werden, sobald sie nicht mehr benötigt werden. Werden die Teams in PagerDuty nicht aktuell gehalten, besteht für die Einsatzkräfte die Gefahr, mitten in der Nacht für etwas geweckt zu werden, das sie seit Wochen, Monaten oder sogar Jahren nicht mehr bearbeitet haben.

Ein weiteres Konfigurationsproblem, auf das ich stoße, sind PagerDuty -Dienste, die nach den Teams benannt sind, nicht nach den überwachten Geschäftsanwendungen. Dieser Ansatz ist in kleinen Unternehmen sinnvoll, in denen ein kleines Team für ein komplettes Produkt verantwortlich ist. Er ist auch dann sinnvoll, wenn das Team bisher nur an einem Produkt gearbeitet hat und statisch ist. Obwohl diese Option anfangs praktikabel sein mag, ist die Struktur „ein Team pro Produkt“ schlichtweg nicht skalierbar.

Gute Praxis

Bewährte Verfahren erfordern eine einheitliche Systematik für Ihre PagerDuty -Teams, Zeitpläne, Eskalationsrichtlinien und Dienste. Warum ist das wichtig? Richtig benannte Dienste können wertvolle Minuten einsparen. Reaktionszeit bei einem Vorfall Indem dem Helfer Kontextinformationen darüber gegeben werden, was defekt ist – was es einfacher macht, Vorfälle zu eskalieren, mehr Fachexperten (SMEs) hinzuzuziehen und, was am wichtigsten ist, die Auswirkungen von Vorfällen auf das Geschäft zu verringern.

Darüber hinaus sollte die Anlagenklassifizierung serviceorientiert sein, denn dadurch wird deutlich, welche Komponente Ihres geschäftskritischen Dienstes die meisten Probleme verursacht.

Was genau macht einen gut benannten Dienst aus? Hier sind einige Beispiele für schlecht benannte Dienste:

• Datadog
• DevOps
• AWS
• E-Mail-Integration

Und hier sind einige serviceorientierte Beispiele für die Benennung Ihrer Dienste:

• Business-Service-Software-Service-Monitoring-Tool
• (Produktion/QA/Entwicklung/Stg) – Geschäftsdienst – Software-Service – Überwachungstool

Bessere Vorgehensweise

Eine Funktion, die PagerDuty bietet (und selten genutzt wird), ist die Benennung der Integrationen auf Ihrem Dienst. Standardmäßig ist der Name der Integration das Überwachungstool. Wenn aber jedes Team in Ihrem Unternehmen eine Datadog-Integration hat, wie wissen Sie dann, was die Datadog-Integration Ihres Teams überwacht? Um Verwirrung zu vermeiden, empfehle ich, eine Integration anhand dessen zu benennen, was sie überwacht. Beispielsweise können Datadog-Integrationen aussagekräftiger benannt werden:

• Datadog-Komponente
• Datadog-Anwendung

Eine weitere Integrationsnomenklatur könnte lauten:

• Überwachungstool-Anwendungskomponente

Da PagerDuty Benachrichtigungen von jedem beliebigen System versenden kann, das E-Mails versendet, ist die korrekte Benennung Ihrer E-Mail-Integration entscheidend. Ich schlage etwa Folgendes vor:

• Komponentenüberwachungstool-E-Mail

Bewährte Vorgehensweise

Die meisten Unternehmen haben Service-Level-Agreements (SLAs) für ihre Dienste, und die Eskalationsrichtlinien von PagerDuty helfen ihnen, diese SLAs durch schnellere Reaktionszeiten einzuhalten. In diesem Fall empfehlen wir, die Eskalationsrichtlinien so zu benennen, dass sie den Kontext des zugehörigen Dienstes und des Teams widerspiegeln. Zum Beispiel:

• Team-Anwendungssoftware-Service-SLA min
• Team-Anwendungssoftware-Service-Produktion/Stufe/Entwicklung

Mithilfe dieser Formate erhalten Sie auf einen Blick Kontextinformationen darüber, welcher Dienst eine Störung verursacht, zu welchem Team dieser Dienst gehört und wie schnell Sie mit einer Reaktion rechnen können! Dies bietet NOC-/Support-Teams, die Störungen manchmal manuell erfassen/eskalieren, die Möglichkeit, schnell das richtige Team für die Bearbeitung zu finden.

Zeitpläne setzen sich aus Benutzern zusammen, die in der Regel Teams angehören. Je nach Organisationsstruktur können Sie Zeitpläne entweder nach den Fachexperten für den jeweiligen Dienst oder nach den Teams benennen, die diesen Dienst unterstützen. Zum Beispiel:

• Teamname-Dienstname-Primär/Sekundär
• Dienstbezeichnung – Primär/Sekundär

Erfolg!

Zum Abschluss meines Engagements bei diesem milliardenschweren Unterhaltungsunternehmen haben wir Folgendes durchgeführt:

1. Wir haben zwei PagerDuty -Teams zu einem zusammengeführt, um ihre tatsächlichen Gegebenheiten besser abzubilden. Dadurch wurden unnötige Daten entfernt und eine zentrale Übersicht über das Team und die Benachrichtigungen geschaffen.
2. Die vielen Integrationen, die alle in einem einzigen Dienst zusammenflossen, wurden auseinandergenommen (keine Best Practice). Außerdem wurden die neuen Dienste nach der Geschäftsanwendung und dem Überwachungstool benannt. Da es nur eine Integration pro Dienst gibt, haben wir dann Folgendes angewendet: Ereignisintelligenz zu den an PagerDuty gesendeten Signalen. Mit Ereignisintelligenz, Funktion „Zeitbasierte Alarmgruppierung“ Das System gruppiert zuverlässig alle Warnmeldungen desselben Tools für dieselbe Anwendung innerhalb eines zweiminütigen Zeitfensters. Dadurch werden irrelevante Warnmeldungen in Warnfluten reduziert. Einsatzkräfte können so die Fehlerquelle schnell lokalisieren und entsprechende Maßnahmen ergreifen.

Um 2:37 Uhr nachts möchte man sicher nicht die Dokumentation des Unternehmens durchforsten. Erfahrene Betriebsteams verwenden eine standardisierte Taxonomie für ihre Hosts und Server – und das sollte auch für die Plattform gelten, die sie zur Koordination ihrer Reaktion auf schwerwiegende Vorfälle nutzen.