Freigeben über

Empfehlungen zum Entwerfen einer Notfallstrategie

  • Artikel

Gilt für diese Checklistenempfehlung für Azure Well-Architected Framework Operational Excellence:

OE:08 Entwickeln Sie eine effektive Notfalloperationspraxis. Stellen Sie sicher, dass Ihre Workload über Infrastruktur und Code hinweg aussagekräftige Integritätssignale ausgibt. Sammeln Sie die resultierenden Daten, und verwenden Sie sie, um verwertbare Warnungen zu generieren, die Notfallreaktionen über Dashboards und Abfragen auslösen. Definieren Sie klar menschliche Verantwortlichkeiten, z. B. Bereitschaftsdienstrotationen, Incidentverwaltung, Zugriff auf Notfallressourcen und Ausführen von Postmortems.

In diesem Leitfaden werden die Empfehlungen zum Entwerfen einer Notfallstrategie beschrieben. Einige Probleme, die im Laufe des Lebenszyklus einer Workload auftreten, sind kritisch genug, um die Deklarierung von Notfällen zu rechtfertigen. Sie können streng kontrollierte und fokussierte Prozesse und Verfahren implementieren, die Ihr Team befolgen kann, um sicherzustellen, dass ein Problem in einer ruhigen, geordneten Weise behandelt wird. Notfälle erhöhen natürlich das Stressniveau aller Menschen und können zu einer chaotischen Umgebung führen, wenn Ihr Team nicht gut vorbereitet ist. Um Stress und Verwirrung zu minimieren, entwerfen Sie eine Reaktionsstrategie, teilen Sie die Antwortstrategie mit Ihrem organization und führen Sie regelmäßige Notfallschulungen durch.

Wichtige Entwurfsstrategien

Eine Notfallstrategie sollte eine geordnete, klar definierte Gruppe von Prozessen und Verfahren sein. Jeder Prozess und jede Prozedur sollte über Skripts verfügen, um sicherzustellen, dass ihr Team in jedem Schritt schnell und sicher ein Problem lösen kann. Beachten Sie die folgende Übersicht, um eine Notfallstrategie zu entwickeln:

  • Voraussetzungen
    • Entwickeln einer Beobachtbarkeitsplattform
    • Erstellen eines Plans zur Reaktion auf Incidents
  • Incidentphasen
    • Erkennung
    • Containment
    • Eingrenzung
  • Post-Incident-Phasen
    • Fehlerursachenanalyse (Root Cause Analysis, RCA)
    • Postmortem
  • Laufende Aktivität
    • Drills zur Notfallreaktion

Die folgenden Abschnitte enthalten Empfehlungen für jede dieser Phasen.

Einblick

Um über eine robuste Notfallstrategie zu verfügen, müssen Sie über eine stabile Beobachtbarkeitsplattform verfügen. Ihre Beobachtbarkeitsplattform sollte die folgenden Merkmale aufweisen:

  • Ganzheitliche Überwachung: Stellen Sie sicher, dass Sie Ihre Workload aus Infrastruktur- und Anwendungssicht gründlich überwachen.

  • Ausführliche Protokollierung: Aktivieren Sie die ausführliche Protokollierung für Ihre Komponenten, um untersuchungen zu unterstützen, wenn Sie ein Problem trichieren. Strukturprotokolle, sodass sie einfach zu verwalten sind. Senden Sie Protokolle automatisch an Datensenken, um für die Analyse vorbereitet zu werden.

  • Nützliche Dashboards: Erstellen Sie integritätsmodellbasierte Dashboards, die auf jedes Team in Ihren organization zugeschnitten sind. Verschiedene Teams sind für unterschiedliche Aspekte der Workloadintegrität verantwortlich.

  • Umsetzbare Warnungen: Erstellen Sie Warnungen, die für Ihre Workloadteams nützlich sind. Vermeiden Sie Warnungen, die keine Aktionen von Ihren Teams erfordern. Zu viele Warnungen dieser Art können dazu führen, dass Personen Warnungsbenachrichtigungen ignorieren oder blockieren.

  • Automatische Benachrichtigungen: Stellen Sie sicher, dass die entsprechenden Teams automatisch Warnungen erhalten, die Aktionen von ihnen erfordern. Beispielsweise sollte Ihr Supportteam der Ebene 1 Benachrichtigungen für alle Warnungen erhalten, während Ihre Sicherheitstechniker nur Warnungen für Sicherheitsereignisse erhalten sollten.

Weitere Informationen finden Sie unter Empfehlungen zum Entwerfen und Erstellen eines Beobachtbarkeitsframeworks.

Plan zur Reaktion auf Vorfälle

Die Grundlage einer Notfallstrategie ist ein Plan zur Reaktion auf Vorfälle. Wie ein Notfallwiederherstellungsplan definieren Sie Rollen, Zuständigkeiten und Verfahren für einen Plan zur Reaktion auf Vorfälle klar und gründlich. Der Plan sollte ein versionsgesteuertes Dokument sein, das regelmäßig überprüft wird, um sicherzustellen, dass er auf dem neuesten Stand ist.

Definieren Sie eindeutig die folgenden Komponenten in Ihrem Plan.

Rollen

Identifizieren sie einen Incident Response Manager. Diese Person besitzt den Vorfall von der Initiierung über die Behebung bis hin zur Analyse der Grundursache. Ein Incident Response Manager stellt sicher, dass Prozesse befolgt werden und die entsprechenden Parteien informiert werden, während das Antwortteam ihre Arbeit ausführt.

Identifizieren Sie einen postmortalen Leiter. Diese Person stellt sicher, dass Postmortems bald nach der Lösung des Vorfalls durchgeführt werden. Sie erstellen einen Bericht, mit dem Sie die Ergebnisse des Vorfalls anwenden können.

Prozesse und Verfahren

Ihr Workloadteam sollte Notfallkriterien definieren und verstehen. Wenn Ihr Team feststellt, dass ein schwerwiegender Fall ist, können Sie einen Notfall deklarieren und den Notfallwiederherstellungsplan initiieren. In weniger schwerwiegenden Fällen erfüllt das Problem möglicherweise nicht die Kriterien einer Katastrophe. Sie sollten das Problem jedoch dennoch als Notfall betrachten, was die Einleitung des Notfallplans erfordert. Notfälle können interne Probleme ihrer Workload sein, oder sie können das Ergebnis eines Problems mit einer Abhängigkeit Ihrer Workload sein. Das Supportteam muss in der Lage sein zu ermitteln, ob ein von externen Benutzern gemeldetes Problem die Notfallkriterien erfüllt, auch wenn sie keinen Einblick in das zugrunde liegende Problem haben.

Definieren Sie präzise Kommunikations- und Eskalationspläne. Stellen Sie basierend auf der Art der Erhaltenen Warnungsbenachrichtigung sicher, dass Ihr Tier-1-Support problemlos die entsprechenden Teams kontaktieren kann, um Probleme zu eskalieren. Stellen Sie sicher, dass sie wissen, welche Art von Kommunikation für interne und externe Parteien geeignet ist. Fügen Sie in Kommunikations- und Eskalationsplänen eine Liste des Bereitschaftsdienstplans und der Mitarbeiter ein.

Schließen Sie im Gesamtplan Containment- und Triageskripts ein. Teams befolgen diese schrittweisen Verfahren, wenn sie ihre Containment- und Triagefunktionen ausführen. Fügen Sie eine Beschreibung der Definition eines Incident-Abschlusses hinzu.

Weitere Elemente, die enthalten sein sollen

Dokumentieren Sie alle Standardtools, die bei Incidents für die interne Kommunikation verwendet werden, z. B. Microsoft Teams, und zum Nachverfolgen der Aktivitäten im Verlauf des Incidents, z. B. Ticketingtools oder Backlogplanungstools.

Dokumentieren Sie Ihre Notfallanmeldeinformationen, die auch als Break-Glass-Konten bezeichnet werden. Fügen Sie eine schritt-für-Schritt-Anleitung hinzu, die beschreibt, wie sie verwendet werden sollten.

Erstellen Sie Anweisungen zur Notfallreaktion, und notieren Sie sich, wann Drillvorgänge ausgeführt wurden.

Dokumentieren Sie alle erforderlichen rechtlichen oder behördlichen Maßnahmen, z. B. die Kommunikation von Datenverletzungen.

Incidenterkennung

Wenn Sie über eine gut konzipierte Beobachtbarkeitsplattform verfügen, die auf Anomalien und automatische Warnungen überwacht, können Sie Probleme schnell erkennen und deren Schweregrad bestimmen. Wenn das Problem als Notfall angesehen wird, kann der Plan initiiert werden. In einigen Fällen wird das Supportteam nicht über die Beobachtungsplattform benachrichtigt. Kunden können Probleme an den Support melden, indem sie Die Kommunikationsmöglichkeiten des Supportteams verwenden. Oder sie können sich an Personen wenden, mit denen sie regelmäßig zusammenarbeiten, z. B. Kontoleiter oder VPs. Unabhängig davon, wie das Supportteam benachrichtigt wird, sollten sie immer die gleichen Schritte ausführen, um das Problem zu überprüfen und den Schweregrad zu bestimmen. Abweichungen vom Antwortplan können zu Stress und Verwirrung führen.

Containment

Der erste Schritt bei der Problembehebung besteht darin, das Problem zu enthalten, um den Rest Ihrer Workload zu schützen. Eine Containmentstrategie hängt vom Typ des Problems ab, aber normalerweise wird die betroffene Komponente aus den Workloadflusspfaden entfernt. Beispielsweise können Sie eine Ressource herunterfahren oder aus Netzwerkroutingpfaden entfernen. Systemadministratoren, Ingenieure und leitende Entwickler sollten zusammenarbeiten, um Eindämmungsstrategien zu entwerfen. Das Containment sollte den Explosionsradius von Problemen begrenzen und die Workloadfunktionalität in einem eingeschränkten Zustand beibehalten, bis das Problem behoben ist. Wenn auf eine betroffene Komponente zugegriffen werden muss, um eine Triage durchzuführen, ist es von entscheidender Bedeutung, dass ihr Zugriff auf den Rest der Workload blockiert wird. So weit wie möglich sollten Sie nur über einen Pfad auf die Komponente zugreifen, der von der Workload und dem Rest der Systeme getrennt ist.

Eingrenzung

Nachdem Sie das Problem erfolgreich enthalten haben, können Sie mit der Einstufung beginnen. Die Schritte, die Sie während der Triage ausführen, hängen vom Typ des Problems ab. Das Team für einen bestimmten Bereich der Workloadunterstützung sollte Verfahren für Vorfälle erstellen, die mit ihrem Team zusammenhängen. Beispielsweise sollten Sicherheitsteams Sicherheitsprobleme ausgrenzen und die von ihnen entwickelten Skripts befolgen. Es ist wichtig, dass Teams gut definierte Skripts befolgen, während sie ihre Triagebemühungen durcharbeiten. Diese Skripts sollten schrittweise Prozesse sein, die Rollbackprozesse enthalten, um Änderungen rückgängig zu machen, die ineffektiv sind oder andere Probleme verursachen können. Verwenden Sie Standard-Protokollaggregations- und Analysetools, um Probleme, die eine umfassende Analyse erfordern, effizient zu untersuchen. Nachdem das Problem behoben wurde, befolgen Sie klar definierte Prozesse, um die betroffene Komponente sicher wieder in die Workloadflusspfade zu bringen.

RCA-Berichterstellung

Die Vereinbarungen zum Servicelevel (SLAs) mit Ihren Kunden können vorschreiben, dass Sie innerhalb eines bestimmten Zeitraums nach der Behebung des Incidents RCA-Berichte ausstellen müssen. Der Incidentbesitzer sollte die RCA-Berichte erstellen. Wenn dies nicht möglich ist, kann eine andere Person, die eng mit dem Incidentbesitzer zusammengearbeitet hat, die RCA-Berichte erstellen. Diese Strategie gewährleistet eine genaue Abrechnung des Vorfalls. In der Regel verfügen Organisationen über eine definierte RCA-Vorlage mit Richtlinien darüber, wie Informationen präsentiert werden und welche Arten von Informationen freigegeben werden können oder nicht. Wenn Sie Ihre eigene Vorlage und Richtlinien erstellen müssen, stellen Sie sicher, dass sie von den Projektbeteiligten überprüft und genehmigt werden.

Vorfallspostmortems

Eine unparteiische Person sollte unschuldige Postmortale führen. In postmortem-Sitzungen teilt jeder seine Ergebnisse aus einem Vorfall. Jedes Team, das an der Reaktion auf Vorfälle beteiligt war, sollte durch Personen repräsentiert werden, die an dem Vorfall gearbeitet haben. Diese Personen sollten zu der Sitzung kommen, die mit Beispielen für die Bereiche, die erfolgreich waren, und Bereiche, die verbessert werden können, vorbereitet werden. Die Sitzung ist kein Forum zum Zuweisen Blame für den Vorfall oder Probleme, die während der Antwort aufgetreten sein könnten. Der Leiter des Postmortems sollte die Sitzung mit einer klaren Liste von Aktionselementen verlassen, die sich auf Verbesserungen konzentrieren, z. B.:

  • Verbesserungen am Antwortplan. Prozesse oder Prozeduren müssen möglicherweise neu ausgewertet und neu geschrieben werden, um geeignete Aktionen besser zu erfassen.

  • Verbesserungen an der Beobachtbarkeitsplattform. Schwellenwerte müssen möglicherweise neu ausgewertet werden, um den bestimmten Incidenttyp früher abzufangen, oder es muss eine neue Überwachung implementiert werden, um das Verhalten abzufangen, das nicht berücksichtigt wurde.

  • Verbesserungen an der Workload. Der Vorfall kann eine Sicherheitslücke in der Workload offenlegen, die als dauerhafte Korrektur behoben werden muss.

Überlegungen

Eine zu aggressive Reaktionsstrategie kann zu Fehlalarmen oder unnötigen Eskalationen führen.

Ebenso kann die aggressive Implementierung der automatischen Skalierung oder anderer Selbstreparaturmaßnahmen zur Reaktion auf Schwellenverletzungen zu unnötigen Ausgaben und Verwaltungsaufwand führen. Möglicherweise kennen Sie nicht die genauen Schwellenwerte, die für Warnungen und automatische Aktionen wie Skalierung festgelegt werden sollen. Führen Sie Tests in niedrigeren Umgebungen und in der Produktion durch, damit Sie die richtigen Schwellenwerte für Ihre Anforderungen ermitteln können.

Azure-Erleichterung

Azure Monitor ist eine umfassende Lösung zum Sammeln, Analysieren und Reagieren auf Überwachungsdaten aus Cloud- und lokalen Umgebungen. Es enthält eine robuste Warnungsplattform, die Sie für automatische Benachrichtigungen und andere Aktionen konfigurieren können, z. B. automatische Skalierung und andere Mechanismen zur Selbstreparatur.

Verwenden Sie Monitor, um Maschinelles Lernen zu integrieren. Automatisieren und optimieren Sie die Incidenttriage und proaktive Maßnahmen. Weitere Informationen finden Sie unter AIOps und maschinelles Lernen in Monitor.

Log Analytics ist ein robustes Analysetool, das in Monitor integriert ist. Sie können Log Analytics verwenden, um Abfragen für aggregierte Protokolle auszuführen und Erkenntnisse über Ihre Workload zu erhalten.

Microsoft bietet Azure-bezogene Schulungen zur Bereitschaft von Vorfällen an. Weitere Informationen finden Sie unter Einführung in die Azure-Incidentbereitschaft und Incidentbereitschaft.

Checkliste "Operational Excellence"

Sehen Sie sich den vollständigen Satz von Empfehlungen an.

Checkliste "Operational Excellence"