Das Lösen von Vorfällen ist schwierig. Je nach Ihrer aktuellen Situation verlieren Sie möglicherweise auch viel Zeit damit, herauszufinden, welche Benachrichtigungen einen Vorfall darstellen. Dies führt zu immer mehr verlorener Zeit, da jede Benachrichtigung als potenzieller Vorfall eingestuft werden muss, bevor Sie mit der Lösung oder Ignorierung (als Nicht-Vorfall) fortfahren können. All dies mag sehr umständlich klingen, aber der schnellste Weg zur Verbesserung besteht darin, zu lernen und zu definieren, was Vorfälle sind. Und Sie haben Glück! Darum geht es in diesem Blogbeitrag. Wenn Sie fertig sind, sind Sie auf dem besten Weg, mit der Bereinigung Ihrer Prozesse zu beginnen, um die Identifizierung und Lösung von Vorfällen mit jeder Iteration zu vereinfachen.

Das Wichtigste zuerst: Was ist ein Vorfall? Bei PagerDuty definieren wir einen Vorfall als „jede ungeplante Störung oder Verschlechterung des Dienstes, die die Fähigkeit der Kunden, PagerDuty zu nutzen, aktiv beeinträchtigt“. Wir unterscheiden auch das, was wir einen schwerwiegenden Vorfall nennen, nämlich „jeden Vorfall, der eine koordinierte Reaktion mehrerer Teams erfordert“. Dies unterscheidet sich von einem „Ereignis“, das, nun ja, alles sein kann. Das Schreiben einer Protokollnachricht ist ein Beispiel für ein Ereignis, aber die Unfähigkeit, eine Protokollnachricht zu schreiben, könnte auf einen Vorfall (oder einen bevorstehenden) hinweisen. Das Verständnis der störenden Natur eines Vorfalls ist der Schlüssel zu seiner Identifizierung: Wenn Sie eine Nachricht (E-Mail, Chat, SMS, Anruf) und ihre Informationen erhalten, die nicht störend sind, handelt es sich nicht um einen Vorfall.

Es ist wichtig, sich Zeit zu nehmen, um gut konzipierte Warnmeldungen zu erstellen und zu pflegen. Warum? Weil nicht alle Warnmeldungen Vorfälle bedeuten, aber das Ziel ist, dass alle Vorfälle durch Warnmeldungen identifiziert werden können. Wenn Sie Ihre Warnmeldungen nicht planen, ist es wahrscheinlich, dass ein schwerwiegender Vorfall im allgemeinen Geplapper regulär betriebener Systeme übersehen wird. Dies besteht aus mehreren Teilen:

• Alle Warnungen sollten umsetzbar sein
• Warnmeldungen sollten so laut wie möglich sein (mehr dazu gleich)
• Warnmeldungen sollten mit Änderungen an Ihrem System und/oder Code synchronisiert werden (z. B. keine Warnmeldung bei migriertem Endpunkt).

Wenn wir uns den zweiten Punkt genauer ansehen: Was meine ich mit „so laut wie es sinnvoll ist“? Einiges davon ist durch das Bauchgefühl erkennbar. Sie möchten nicht in der Dämmerung geweckt werden, weil die Datenbank zu wenig Speicher verwendet (Was?). Auf der anderen Seite möchten Sie Tun Sie möchten geweckt werden, wenn es zu einer kundenseitigen Auswirkung kommt, die auf fehlgeschlagene Datenbankverbindungen zurückzuführen ist. Für die eher nebulösen Warnungen und sogar für einige der häufigeren müssen Sie einige klare Definitionen festlegen, damit Sie wissen, wie Sie jede einzelne kategorisieren: Priorität, Dringlichkeit und Schweregrad.

Einfach gesagt:

• Priorität. Wie schnell und in welcher Reihenfolge ein Alarm oder Vorfall bearbeitet werden soll. Ein Alarm mit hoher Priorität muss sofort bearbeitet werden, ein Alarm mit niedriger Priorität erfordert irgendwann Maßnahmen und ein informativer Alarm ist nur ein „FYI-Alarm“. Neben „hoch/niedrig“ sehen Sie für diese Kategorie normalerweise Aufschlüsselungen wie „P1, P2“ oder „SEV1, SEV2“.
• Dringlichkeit. Bei PagerDuty verwenden wir dies, um zu definieren, wie Sie benachrichtigt werden möchten. Im Allgemeinen ist dies im Gleichschritt mit der Priorität. Damit meine ich, dass eine Benachrichtigung mit hoher Dringlichkeit (normalerweise ein Anruf oder eine SMS) für einen Alarm mit hoher Priorität gilt, eine Benachrichtigung mit niedriger Dringlichkeit (E-Mail, Chat) für einen Alarm mit niedriger Priorität.
• Schwere . Dies drückt aus, wie schwerwiegend das Problem ist, normalerweise definiert als kritisch, Fehler, Warnung, Info usw.

Um tiefer in diese Themen einzutauchen, werfen Sie bitte einen Blick auf unseren Incident Response Ops Guide, insbesondere Alarmierungsgrundsätze Und Schweregrade .

Während Sie über Warnmeldungen nachdenken, kommen wir zu einem verwandten Thema: dem Vorfall selbst. Wenn eine Warnmeldung die Kriterien für einen Vorfall erfüllt, handelt es sich um einen aktiven Vorfall. Das ist großartig! 😅 Vorfälle werden normalerweise per Anruf gelöst. Dies kann ein Telefonanruf, eine Webkonferenz oder beides sein. Früher konnten sich die zuständigen Einsatzkräfte auch physisch in einem Konferenzraum treffen. Was auch immer der Fall sein mag, jetzt muss jeder in der Lage sein, zu kommunizieren. Einige grundlegende Regeln für das Engagement helfen dabei: Treffen Sie Maßnahmen, um sicherzustellen, dass die Leute nicht durcheinanderreden.

Einige grundlegende Regeln für die Zusammenarbeit helfen dabei, zu verhindern, dass die Leute durcheinanderreden. Zum Beispiel Reactjis in Zoom oder das Heben der Hand vor der Kamera. Stellen Sie sicher, dass Ihr Mikrofon stummgeschaltet ist, wenn Sie nicht der aktive Sprecher sind, und/oder verwenden Sie etwas wie Krisp, um Hintergrundgeräusche fernzuhalten. Unabhängig davon, ob Sie Sprache oder Text verwenden, vermeiden Sie Akronyme und Fachjargon so weit wie möglich. Der zusätzliche Aufwand, „Fachexperte“ statt „KMU“ zu tippen oder zu sagen, verhindert, dass Sie im Telefonat Zeit mit der Definition von Akronymen verbringen müssen. Dies ist äußerst relevant, da insbesondere im Falle eines größeren Vorfalls möglicherweise nicht alle Teilnehmer des Telefonats die gleiche Akronymverwendung und den gleichen Fachjargon haben. Es können Frontend-, Backend-, UI-, Rechts- und Personalvertreter am Telefon teilnehmen oder Updates erhalten. Tatsächlich ist es höchstwahrscheinlich, dass es Vertreter von Frontend, Backend, UI, Recht und Personal gibt. Wille Es dürfen keine Ingenieure am Gespräch teilnehmen.

Warum ist das so? Die Bearbeitung eines aktiven Vorfalls erfordert viel Arbeit und die Sichtung und Lösung ist nur ein Teil davon. Dies ist der Schwerpunkt für die Ingenieure (d. h. Fachexperten); wer kommuniziert jedoch mit den Teams, dem Unternehmen oder sogar extern über Statusaktualisierungen? Wer dokumentiert, was wann versucht wird? Im Idealfall sollte das Ingenieurteam, das an der Lösung des Vorfalls arbeitet, keine anderen Aufgaben übernehmen. Dies bedeutet, dass andere Gruppen auf Abruf bereitstehen können und sollten. Bei PagerDuty haben wir diese separaten Rollen als unseren Vorfallskommandoprozess definiert. Diese Rollen umfassen:

• Einsatzleiter
• Stellvertreter
• Schreiber
• Fachexperten
• Ansprechpartner für Kunden- und/oder interne Kommunikation

Kurz gesagt, der Einsatzleiter entscheidet endgültig, welche Schritte wann unternommen werden. Er verlässt sich bei der Entscheidungsfindung auf die Eingaben der entsprechenden Ingenieure und Fachexperten, aber ohne deren Zustimmung werden keine Maßnahmen ergriffen. Der Stellvertreter ist der zweite Befehlshaber, der den Einsatzleiter unterstützt und bei Bedarf die Verwaltung des Vorfalls übernimmt. Der Schreiber dokumentiert den Vorfall, während er passiert, z. B. „Kubernetes-Cluster um 8 Uhr neu gestartet, Cluster wieder online“. Die Fachexperten sind diejenigen, die die von dem Vorfall betroffenen Dienste und Systeme verstehen und aktiv an seiner Lösung arbeiten. Und schließlich sind die Verbindungspersonen für die Kommunikation von Statusaktualisierungen verantwortlich. Dies muss unbedingt als separate Rolle festgelegt werden, da interne Führungskräfte und Vertreter Updates benötigen, die sie auch an ihre eigenen Stakeholder, Kunden usw. kommunizieren können. Weitere Informationen zum Training dieser Rollen finden Sie in unserem Schulung zur Einsatzleitung Seite.

Puh! Ich weiß, das war viel, aber jetzt sind Sie auf dem besten Weg, Ihre Alarme und Vorfälle zu optimieren. Bitte kontaktieren Sie uns über unsere Community-Foren wenn Sie weitere Fragen haben oder einfach nur chatten möchten. Wir freuen uns, von Ihnen zu hören!

Dieser Artikel wurde zuvor am 17. Juli 2020 veröffentlicht auf Besser liefern.