Gemeinsamen Prozess für Vorfallmanagement aufbauen

Last reviewed 2023-08-08 UTC

Dieses Dokument im Google Cloud-Architektur-Framework enthält Best Practices zum Verwalten von Diensten und zum Definieren von Prozessen, um auf Vorfälle zu reagieren. Vorfälle treten in allen Diensten auf. Daher ist ein gut dokumentierter Prozess erforderlich, um diese Probleme effizient zu beheben und zu minimieren.

Übersicht über das Vorfallmanagement

Es ist unvermeidlich, dass Ihr gut konzipiertes System irgendwann seine SLOs nicht mehr erfüllt. Ohne eines SLOs definieren Ihre Kunden das akzeptable Serviceniveau aufgrund ihrer bisherigen Erfahrungen selbst. Die Kunden wenden sich an Ihren technischen Support oder eine ähnliche Gruppe, unabhängig davon, was in Ihrem SLA steht.

Um Ihren Kunden einen angemessenen Service zu bieten, sollten Sie einen Plan für das Vorfallmanagement erstellen und regelmäßig testen. Der Plan kann so kurz sein wie eine einseitige Checkliste mit zehn Punkten. Dieser Prozess hilft Ihrem Team, die Zieldiagnosezeit (TTD) und die Zeit zur Problem-Reduzierung (TTM) zu reduzieren.

TTM wird im Gegensatz zu TTR bevorzugt, wobei mit dem R für Repair (Reparatur) oder Recovery (Wiederherstellung) häufig eine vollständige Korrektur im Vergleich zu Problemminderung gemeint ist. TTM legt den Schwerpunkt auf eine schnelle Schadensbegrenzung, um die Auswirkungen eines Ausfalls auf die Kunden schnell zu beenden, und beginnt dann mit dem oft viel längeren Prozess zur vollständigen Behebung des Problems.

Ein gut konzipiertes System, bei dem Vorgänge hervorragend sind, erhöht die Zeit zwischen Fehlern (TBF). Mit anderen Worten, die Betriebsgrundsätze für Zuverlässigkeit, einschließlich eines guten Vorfallmanagements, versuchen, Fehler weniger häufig zu vermeiden.

Um zuverlässige Services auszuführen, wenden Sie die folgenden Best Practices für Ihren Vorfallmanagement-Prozess an.

Klare Dienstinhaberschaft zuweisen

Alle Services und ihre kritischen Abhängigkeiten müssen klare Inhaber haben, die für die Einhaltung ihrer SLOs verantwortlich sind. Bei Reorganisationen oder Abzügen durch das Team muss die Leitenden Mitarbeiter der Entwicklung darauf achten, dass die Inhaberschaft zusammen mit der Dokumentation und der Schulung explizit an ein neues Team übergeben wird. Die Inhaber eines Service müssen für andere Teams leicht auffindbar sein.

Zeit zur Erkennung (Time to detect, TTD) mit gut abgestimmten Benachrichtigungen reduzieren

Bevor Sie die TTD reduzieren können, sollten Sie die Empfehlungen in den Abschnitten Für mehr Beobachtbarkeit in Ihrer Infrastruktur und Ihren Anwendungen sorgen und Zuverlässigkeitsziele definieren der Zuverlässigkeitskategorie des Architektur-Frameworks überprüfen und umsetzen. Unterscheiden Sie beispielsweise zwischen Anwendungsproblemen und zugrunde liegenden Cloud-Problemen.

Mit gut abgestimmten SLIs wird Ihr Team zur richtigen Zeit benachrichtigt, ohne dass es zu einer Überlastung mit Benachrichtigungen kommt. Weitere Informationen finden Sie im Abschnitt Effiziente Benachrichtigungen erstellen in der Zuverlässigkeitskategorie des Architektur-Frameworks oder unter SLI-Messwerte optimieren: CRE Life Lessons.

Zeit zur Problemminderung (Time to Mitigate, TTM) durch Vorfallmanagementpläne und -schulungen verkürzen

Um die TTM zu reduzieren, sollten Sie einen dokumentierten und gut geübten Plan für das Vorfallmanagement erstellen. Sie sollten leicht zugängliche Daten darüber haben, was sich in der Umgebung geändert hat. Sorgen Sie dafür, dass Teams allgemeine Schadensbegrenzungen kennen, die sie schnell anwenden können, um die TTM zu minimieren. Diese Maßnahmen umfassen Draining, Rollback von Änderungen, Ressourcen erweitern und Verschlechtern der Dienstqualität.

Wie in einer anderen Kategoriedokument zur Architektur-Frameworks-Zuverlässigkeit erörtert, sollten Sie zuverlässige betriebliche Prozesse und Tools entwickeln, um ein sicheres und schnelles Rollback von Änderungen zu ermöglichen.

Dashboard-Layouts und Inhalte gestalten, um die TTM zu minimieren

Organisieren Sie das Layout und die Navigation Ihres Dienst-Dashboards so, dass ein Operator innerhalb von ein oder zwei Minuten feststellen kann, ob der Dienst sowie alle seine kritischen Abhängigkeiten laufen. Um mögliche Problemursachen schnell ausfindig zu machen, müssen die Operatoren auf alle Diagramme auf dem Dashboard zugreifen können, um schnell nach Diagrammen zu suchen, die sich zum Zeitpunkt der Benachrichtigung signifikant verändern.

Die folgende Liste mit Beispieldiagrammen kann sich auf Ihrem Dashboard befinden, um Probleme zu beheben. Das Vorfallmanagementteam sollte sie in einer einzigen Ansicht parat haben und ansehen können:

  • Service Level Indicators, z. B. erfolgreiche Anfragen geteilt durch die Gesamtzahl der gültigen Anfragen
  • Konfiguration und binäre Rollouts
  • Anfragen pro Sekunde an das System
  • Fehlerantworten pro Sekunde vom System
  • Anfragen pro Sekunde vom System an seine Abhängigkeiten
  • Fehlerantworten pro Sekunde an das System von seinen Abhängigkeiten

Weitere gängige Diagramme, die bei der Fehlersuche helfen, sind für Latenz, Sättigung, Anfragegröße, Antwortgröße, Abfragekosten, Thread-Pool-Auslastung und Java Virtual Machine (JVM)-Messwerten (falls zutreffend). Sättigung bezieht sich auf die Auslastung durch einen Grenzwert wie die Quote oder die Größe des Systemspeichers. Bei der Thread-Pool-Auslastung wird nach Rückschritten aufgrund einer Erschöpfung des Pools gesucht.

Testen Sie die Platzierung dieser Diagramme anhand einiger Ausfallszenarien, damit die wichtigsten Diagramme ganz oben stehen und damit die Reihenfolge der Diagramme Ihrem Standard-Diagnose-Workflow entspricht. Sie können auch maschinelles Lernen und die statistische Erkennung von Anomalien einsetzen, um die richtige Teilmenge dieser Diagramme zu ermitteln.

Verfahren zur Dokumentdiagnose und Abhilfe für bekannte Ausfallszenarien

Schreiben Sie Playbooks und verknüpfen Sie sie mit den Benachrichtigungen. Wenn diese Dokumente von den Benachrichtigungen aus zugänglich sind, können die Operatoren schnell die Informationen abrufen, die sie für die Fehlerbehebung von Problemen benötigen.

Nachbesprechung ohne Schuldzuweisung nutzen, um von Ausfällen zu lernen und Wiederholungen zu verhindern

Etablieren Sie eine Nachbesprechungskultur ohne Schuldzuweisung und einen Prozess zur Überprüfung von Vorfällen. Ohne Schuldzuweisung bedeutet, dass Ihr Team objektiv bewertet und dokumentiert, was schief gelaufen ist, ohne Schuldzuweisungen vorzunehmen.

Fehler sind eine Gelegenheit zum Lernen und kein Grund zur Kritik. Versuchen Sie immer, das System stabiler zu machen, damit es sich schnell von menschlichen Fehlern erholen kann, oder noch besser, damit es menschliche Fehler erkennen und verhindern kann. Extrahieren Sie aus jedem Postmortem so viel Erkenntnisse wie möglich und nachbearbeiten Sie sorgfältig jedes Postmortem-Aufgabe, um Ausfälle weniger häufig zu machen und dadurch die TBF zu erhöhen.

Beispiel für einen Vorfallmanagementplan

Produktionsprobleme wurden erkannt, z. B. durch eine Benachrichtigung oder eine Seite, oder sie wurden an mich weitergeleitet:

  • Sollte ich an eine andere Person delegieren?
    • Ja, wenn Sie und Ihr Team das Problem nicht lösen können.
  • Handelt es sich um einen Datenschutz- oder Sicherheitsverstoß?
    • Wenn ja, delegieren Sie diesen an das Datenschutz- oder Sicherheitsteam.
  • Ist es ein Notfall oder sind SLOs gefährdet?
    • Im Zweifelsfall sollten Sie den Vorfall als Notfall behandeln.
  • Sollte ich weitere Personen einbeziehen?
    • Ja, wenn mehr als X % der Kunden betroffen sind oder die Behebung mehr als Y Minuten dauert. Im Zweifelsfall sollten Sie immer mehr Personen einbeziehen, insbesondere während der Geschäftszeiten.
  • Definieren Sie einen primären Kommunikationskanal wie IRC, Hangouts Chat oder Slack.
  • Delegieren Sie zuvor definierte Rollen wie die folgenden:
    • Incident Commander, der für die Gesamtkoordinierung verantwortlich ist.
    • Communications Lead, der für die interne und externe Kommunikation verantwortlich ist
    • Operations Lead, der dafür verantwortlich ist, das Problem zu minimieren.
  • Definieren Sie, wann der Vorfall als beendet gilt. Dafür ist möglicherweise eine Bestätigung durch einen Supportmitarbeiter oder ein ähnliches Team erforderlich.
  • Zusammenarbeit in der Nachbesprechung ohne Schuldzuweisung
  • Nehmen Sie an einer Nachbesprechung zur Überprüfung von Vorfällen teil, um Aufgaben zu besprechen und an Mitarbeiter zu verteilen.

Empfehlungen

Befolgen Sie diese Empfehlungen, um die Anleitung im Architektur-Framework auf Ihre eigene Umgebung anzuwenden:

Nächste Schritte

Weitere Informationen zum Erstellen eines kollaborativen Vorfallmanagementprozesses finden Sie in den folgenden Ressourcen:

Weitere Kategorien im Architektur-Framework kennenlernen, z. B. Systemdesign, operative Exzellenz sowie Sicherheit, Datenschutz und Compliance