Es ist 2:37 Uhr an einem Dienstag, Sie schlafen – aber Sie sind auch an der Reihe, Bereitschaftsdienst zu leisten. Sie erhalten einen Anruf von PagerDuty. Ihr Partner schlägt Sie mit einem Kissen, um Sie aufzuwecken. Es hat funktioniert. Sie nehmen benommen den Anruf entgegen und hören Ihren Lieblings-Roboter am anderen Ende der Leitung:

Robo-Typ:
„PagerDuty Alarm. Sie haben 1 ausgelösten Alarm für Service: Datadog. Drücken Sie 2 zum Bestätigen. Drücken Sie 4 zum Eskalieren.“

„PagerDuty Alarm. Sie haben 1 ausgelösten Alarm für Service: Datadog. Drücken Sie 2 zum Bestätigen. Drücken Sie 4 zum Eskalieren.“

„PagerDuty Alarm. Sie haben –“

Du drückst die 2 und steigst dann so leise wie möglich aus dem Bett, damit das Kissen nicht zu einem Tritt wird.

Sie melden sich bei PagerDuty an und klicken auf den Vorfall, der Ihnen zugewiesen ist. Da der Vorfall bei einem Dienst namens „ Datenhund „, gehen Sie davon aus, dass das Problem mit etwas zusammenhängt, das Datadog entdeckt hat. Aber, fragst du dich, Ich habe seit Monaten an nichts Datadog-bezogenem gearbeitet, warum stehe ich also überhaupt für diesen Dienst zur Verfügung? Diese Datadog-Nutzlast gibt Ihnen nicht viele Informationen, also melden Sie sich bei Datadog an, um einen Blick darauf zu werfen.

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

Tiefer Seufzer

Nach ein paar Minuten Klicken finden Sie, was kaputt ist. Jetzt müssen Sie nur noch zu PagerDuty wechseln und den Vorfall dem richtigen Team zuweisen. Dann können Sie wieder schlafen gehen!

Gehen Sie also zurück zu PagerDuty, klicken Sie auf „Neu zuweisen“ und die Option zur Neuzuweisung an einen Benutzer oder Eskalationsrichtlinie erscheint. Eskalationsrichtlinien (EP) sollten nach Services oder Teams benannt werden, also ist das wahrscheinlich eine sichere Sache. Sie sehen sich die Liste der EPs an und finden:

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

Noch ein tiefer Seufzer

Klingt bekannt?

Als Digital Insights Consultant arbeite ich mit Unternehmen aller Größen und Branchen zusammen, die PagerDuty verwenden, und habe immer wieder von diesem Szenario gehört. Aufgrund der Flexibilität der Plattform kann ich mit 10 verschiedenen Unternehmen zusammenarbeiten und 12 verschiedene PagerDuty Konfigurationen sehen. Ein großer Teil meiner Rolle besteht darin, aktuelle Benutzer zu beraten, wie sie ihren Incident-Management-Workflow mit PagerDuty optimieren können, was ich über Experten-Services Pakete oder unsere Betrieblicher Gesundheitsmanagement-Dienst .

Auf Erfolg eingestellt

Als ich mit einem Multimilliarden-Dollar-Entertainment-Unternehmen daran arbeitete, ihr PagerDuty Erlebnis zu maximieren, stieß ich bei diesem Engagement unter anderem auf das Problem, dass ihre realen Teams nicht mit ihren Teams in PagerDuty . Es gibt viele Gründe für dieses Phänomen, zum Beispiel Mitarbeiter, die zwischen Teams wechseln, oder die Bildung temporärer projektbasierter Teams, die nicht aufgelöst werden, wenn sie nicht mehr relevant sind. Wenn Teams in PagerDuty nicht auf dem neuesten Stand gehalten werden, besteht das Risiko, dass die Einsatzkräfte mitten in der Nacht wegen etwas geweckt werden, das sie seit Wochen, Monaten oder sogar Jahren nicht mehr angefasst haben.

Ein weiteres Konfigurationsproblem, auf das ich stoße, sind PagerDuty Dienste, die nach den Teams benannt sind, und nicht nach den überwachten Geschäftsanwendungsdiensten. Dieser Ansatz ist in einem kleinen Unternehmen sinnvoll, in dem ein kleines Team für ein ganzes Produkt verantwortlich ist. Er ist auch sinnvoll, wenn das Team nur an einem Produkt gearbeitet hat und statisch ist. Diese Option mag zwar am Anfang praktikabel sein, aber die Ein-Team-für-ein-Produkt-Struktur ist einfach nicht skalierbar.

Gute Übung

Best Practices erfordern eine konsistente Taxonomie für Ihre PagerDuty Teams, Zeitpläne, Eskalationsrichtlinien und Dienste. Warum ist das wichtig? Richtig benannte Dienste können entscheidende Minuten einsparen Reaktionszeit bei Vorfällen Indem dem Reaktionspersonal Kontextinformationen zu den Defekten gegeben werden, können Vorfälle leichter eskaliert werden, es können mehr Fachexperten hinzugezogen werden und, was am wichtigsten ist, die geschäftlichen Auswirkungen von Vorfällen werden verringert.

Darüber hinaus sollte die Asset-Taxonomie serviceorientiert sein. Auf diese Weise können Sie deutlich erkennen, welche Komponente Ihres geschäftskritischen Dienstes die meisten Probleme verursacht.

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

• Datenhund
• 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) – Business Service – Software Service-Monitoring-Tool

Bessere Vorgehensweise

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

• Datadog-Komponente
• Datadog-Anwendung

Eine andere Integrationsnomenklatur könnte sein:

• Monitoring-Tool-Anwendungskomponente

Da PagerDuty außerdem Warnmeldungen von jedem System aus versenden kann, das E-Mails sendet, ist es wichtig, dass Sie Ihre E-Mail-Integration richtig benennen. Ich schlage etwas in der Art vor:

• Komponenten-Überwachungstool-E-Mail

Beste Übung

Die meisten Unternehmen haben für ihre Dienste ein Service-Level-Agreement (SLA) und die Eskalationsrichtlinien von PagerDuty helfen ihnen, diese SLAs einzuhalten, indem sie die Reaktionszeit verkürzen. In diesem Fall empfehlen wir, Ihre Eskalationsrichtlinien im Kontext des zugehörigen Dienstes und des Teams zu benennen. Beispiel:

• Team-Anwendungssoftware Service-SLA min
• Team-Anwendung-Software-Service-Prod/Stg/Dev

Mithilfe dieser Formate erhalten Sie auf einen Blick einen Kontext darüber, welcher Service einen Vorfall verursacht, zu welchem Team dieser Service gehört und wie schnell Sie mit einer Reaktion rechnen können! Dies bietet Kontext für NOC-/Support-Teams, die Vorfälle manchmal manuell melden/eskalieren, um schnell das richtige Team zur Triage zu finden.

Zeitpläne bestehen aus Benutzern, die normalerweise zu Teams gehören. Je nachdem, wie Ihre Organisation eingerichtet ist, können Sie Zeitpläne entweder nach den SMEs für diesen Dienst oder nach Teams benennen, die diesen Dienst unterstützen. Beispiel:

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

Erfolg!

Zum Abschluss meiner Zusammenarbeit mit diesem Multimilliarden-Dollar-Unterhaltungsunternehmen haben wir Folgendes umgesetzt:

1. Zwei PagerDuty -Teams wurden zu einem einzigen zusammengeführt, um ihre Realität besser widerzuspiegeln. Dadurch wurde Ballast entfernt und eine einheitliche Ansicht ihres Teams und ihrer Benachrichtigungen bereitgestellt.
2. Die Zusammenführung der Integrationen, die alle in einen Service flossen, wurde aufgelöst (KEINE Best Practice). Außerdem wurden die neuen Services nach der Business-Anwendung und dem Monitoring-Tool benannt. Da es nur eine Integration pro Service gibt, haben wir dann Ereignisintelligenz auf die Signale, die an PagerDuty gesendet werden. Mit Event Intelligence können die Funktion zur zeitbasierten Alarmgruppierung gruppiert zuverlässig alle Warnungen, die vom gleichen Tool für die gleiche Anwendung eingehen, innerhalb eines zweiminütigen Zeitfensters. Dies trägt dazu bei, nicht umsetzbare Störungen durch Alarmstürme zu reduzieren. Die Einsatzkräfte können dann schnell die Fehlerquelle lokalisieren und auf den Vorfall reagieren.

Um 2:37 Uhr morgens ist das Letzte, was Sie tun möchten, die Organisationsdokumentation zu durchforsten. Erfahrene Betriebsteams haben eine Standardtaxonomie für ihre Hosts und Server – und das sollte auch für die Plattform gelten, die sie zur Orchestrierung ihrer Reaktion auf größere Vorfälle verwenden.