Empfehlungen für das Entwerfen einer Notfallreaktionsstrategie

Gilt für diese Checkliste für azure Well-Architected Framework Operational Excellence:

OE:08

Entwickeln Sie eine effektive Praxis für Notfallvorgänge. Stellen Sie sicher, dass Ihre Workload aussagekräftige Gesundheitssignale über Infrastruktur und Code hinweg ausgibt. Sammeln Sie die resultierenden Daten, und verwenden Sie sie, um Aktionen erfordernde Warnungen zu generieren, die Notfallantworten über Dashboards und Abfragen erstellen. Definieren Sie die Verantwortlichkeiten der Menschen, z. B. Anrufdrehungen, Vorfallverwaltung, Zugriff auf Notfallressourcen und das Ausführen von Postmortems.

In diesem Leitfaden werden die Empfehlungen zum Entwerfen einer Notfallreaktionsstrategie beschrieben. Einige Probleme, die sich im Verlauf des Lebenszyklus einer Workload ergeben, sind kritisch genug, um die Deklaration 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 die Stressstufen aller 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 Reaktionsstrategie mit Ihrer Organisation, und führen Sie regelmäßige Notfallreaktionsschulungen durch.

Wichtige Entwurfsstrategien

Eine Notfallreaktionsstrategie sollte eine geordnete, gut definierte Gruppe von Prozessen und Verfahren sein. Jeder Prozess und jede Prozedur sollten Skripts haben, um sicherzustellen, dass jeder Schritt Ihr Team schnell und sicher in Richtung eines Problems voranschreitet. Berücksichtigen Sie die folgende Übersicht, um eine Notfallreaktionsstrategie zu entwickeln:

• Voraussetzungen
  • Entwickeln einer Observability-Plattform
  • Erstellen eines Plans zur Reaktion auf Incidents
• Vorfallphasen
  • Erkennung
  • Eindämmung
  • Eingrenzung
• Phasen nach dem Vorfall
  • Ursachenanalyse (Root Cause Analysis, RCA)
  • Postmortem
• Laufende Aktivität
  • Drilldowns für Notfallreaktionen

In den folgenden Abschnitten finden Sie Empfehlungen für jede dieser Phasen.

Um eine robuste Notfallreaktionsstrategie zu haben, müssen Sie über eine stabile Observability-Plattform verfügen. Ihre Observability-Plattform sollte die folgenden Merkmale aufweisen:

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

• Ausführliche Protokollierung: Aktivieren Sie ausführliche Protokollierung für Ihre Komponenten, um Untersuchungen zu unterstützen, wenn Sie ein Problem triagen. Strukturprotokolle, damit sie einfach verwaltet werden können. Senden Sie Protokolle automatisch an Datensenken, die für die Analyse vorbereitet werden sollen.

• Nützliche Dashboards: Erstellen Sie modellbasierte Dashboards, die auf jedes Team in Ihrer Organisation zugeschnitten sind. Verschiedene Teams sind für unterschiedliche Aspekte der Arbeitsauslastungsintegrität verantwortlich.

• Aktionen erfordernde Warnungen: Erstellen Sie Warnungen, die für Ihre Workloadteams nützlich sind. Vermeiden Sie Warnungen, die keine Aktion von Ihren Teams erfordern. Zu viele Warnungen dieser Art können dazu führen, dass Benachrichtigungen ignoriert oder blockiert werden.

• Automatische Benachrichtigungen: Stellen Sie sicher, dass geeignete Teams automatisch Benachrichtigungen erhalten, für die eine Aktion erforderlich ist. Ihr Supportteam der Stufe 1 sollte beispielsweise 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 Observability-Frameworks.

Erstellen eines Plans zur Reaktion auf Incidents

Die Grundlage einer Notfallreaktionsstrategie ist ein Plan zur Reaktion auf Vorfälle. Wie bei einem 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 die folgenden Komponenten in Ihrem Plan eindeutig.

Rollen

Identifizieren eines Vorfallreaktions-Managers. Diese Person besitzt den Vorfall von der Initiierung bis zur Behebung der Ursachenanalyse. Ein Vorfallreaktionsmanager stellt sicher, dass Prozesse befolgt werden, und die entsprechenden Parteien werden informiert, wenn das Reaktionsteam ihre Arbeit ausführt.

Identifizieren sie einen Postmortemführer. Diese Person stellt sicher, dass Postmorteme bald nach der Lösung des Vorfalls durchgeführt werden. Sie erstellen einen Bericht, mit dem Sie die Ergebnisse anwenden können, die aus dem Vorfall kommen.

Prozesse und Verfahren

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

Definieren Sie genau Kommunikations- und Eskalationspläne. Stellen Sie basierend auf der Art der empfangenen Benachrichtigung sicher, dass Sich Ihr Support der Stufe 1 problemlos an die entsprechenden Teams wenden 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 der Anrufpläne und Mitarbeiter hinzu.

Schließen Sie im Gesamtplan Eindämmungs- und Triageskripts ein. Teams befolgen diese schrittweisen Verfahren, wenn sie ihre Eindämmungs- und Triagefunktionen ausführen. Geben Sie eine Beschreibung an, was eine Vorfallschließung definiert.

Weitere einzuschließde Elemente

Dokumentieren Sie alle Standardtools, die während Vorfällen für die interne Kommunikation wie Microsoft Teams verwendet werden, und zum Nachverfolgen der Aktivitäten im Verlauf des Vorfalls, z. B. Ticketing-Tools oder Backlog-Planungstools.

Dokumentieren Sie Ihre Notfallanmeldeinformationen, andernfalls als Break-Glass-Konten bezeichnet. Fügen Sie eine schrittweise Anleitung hinzu, die beschreibt, wie sie verwendet werden sollen.

Erstellen Sie Drillanweisungen für Notfallreaktionen, und notieren Sie sich, wann Drills ausgeführt wurden.

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

Reagieren auf Observability-Trigger

Wenn Sie über eine gut gestaltete Observability-Plattform verfügen, die auf Anomalien überwacht und diese automatisch benachrichtigt, können Sie Probleme schnell erkennen und deren Schweregrad ermitteln. Wenn das Problem als Notfall gilt, kann der Plan eingeleitet werden. In einigen Fällen wird das Supportteam nicht über die Observability-Plattform benachrichtigt. Kunden können Probleme bei der Unterstützung melden, indem Sie supportteamkommunikationswege 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 dieselben Schritte ausführen, um das Problem zu überprüfen und den Schweregrad zu bestimmen. Die Abweichung vom Antwortplan kann Stress und Verwirrung hinzufügen.

Definieren von Eindämmungsverfahren

Der erste Schritt bei der Problembehebung besteht darin, das Problem zu enthalten, um den Rest Ihrer Workload zu schützen. Eine Eindämmungsstrategie hängt von der Art des Problems ab, umfasst jedoch in der Regel das Entfernen der betroffenen Komponente aus den Arbeitsauslastungsflusspfaden. Sie können beispielsweise eine Ressource herunterfahren oder aus Netzwerkroutingpfaden entfernen. Systemadministratoren, Ingenieure und Senior-Entwickler sollten zusammenarbeiten, um Eindämmungsstrategien zu entwerfen. Die Eindämmung sollte den Strahlradius von Problemen einschränken und die Workloadfunktionalität in einem beeinträchtigten Zustand beibehalten, bis das Problem behoben ist. Wenn eine betroffene Komponente für die Durchführung einer Triage zugänglich sein muss, ist es wichtig, dass der Zugriff auf den Rest der Workload blockiert wird. So weit wie möglich sollten Sie nur über einen Pfad, der von der Workload und den restlichen Systemen getrennt ist, auf die Komponente zugreifen.

Definieren von Triageprozeduren

Nachdem Sie das Problem erfolgreich enthalten haben, können Sie mit der Triage beginnen. Die Schritte, die Sie während der Triage ausführen, hängen von der Art 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 triagen und skripts folgen, die sie entwickeln. Es ist wichtig, dass Teams gut definierte Skripts befolgen, während sie ihre Triage-Bemühungen durcharbeiten. Diese Skripts sollten schrittweise Prozesse sein, die Rollbackprozesse enthalten, um Änderungen rückgängig zu machen, die unwirksam sind oder andere Probleme verursachen können. Verwenden Sie off-the-shelf Log Aggregation and Analysis Tools, um Probleme, die eine umfassende Analyse erfordern, effizient zu untersuchen. Nachdem das Problem behoben wurde, folgen Sie klar definierten Prozessen, um die betroffene Komponente sicher wieder in die Arbeitsauslastungsflusspfade zu bringen.

Generieren von RCA-Vorfallberichten

Die Vereinbarungen auf Serviceebene für Ihre Kunden können festlegen, dass Sie RCA-Berichte innerhalb eines bestimmten Zeitraums ausstellen müssen, nachdem der Vorfall behoben wurde. Der Eigentümer des Vorfalls sollte die RCA-Berichte erstellen. Wenn das nicht möglich ist, kann eine andere Person, die eng mit dem Eigentümer des Vorfalls zusammengearbeitet hat, die RCA-Berichte erstellen. Diese Strategie gewährleistet eine genaue Protokollierung des Vorfalls. In der Regel verfügen Organisationen über eine definierte RCA-Vorlage mit Richtlinien dazu, 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 Beteiligten überprüft und genehmigt werden.

Haltevorfall postmortems

Eine unparteiische Person sollte schuldlose Postmortems führen. In Postmortemsitzungen teilt jeder seine Ergebnisse aus einem Vorfall. Jedes Team, das an der Reaktion auf den Vorfall beteiligt war, sollte von Personen dargestellt werden, die an dem Vorfall gearbeitet haben. Diese Personen sollten in die Sitzung kommen, vorbereitet mit Beispielen für die Bereiche, die erfolgreich waren, und Bereiche, die verbessert werden können. Die Sitzung ist kein Forum für die Zuweisung von Schuld für den Vorfall oder Probleme, die während der Antwort möglicherweise aufgetreten sind. Der Leiter des Postmortem sollte die Sitzung mit einer klaren Liste von Aktionselementen verlassen, die sich auf Verbesserung konzentrieren, z. B.:

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

• Verbesserungen an der Observability-Plattform. Schwellenwerte müssen möglicherweise neu ausgewertet werden, um den spezifischen Vorfalltyp früher abzufangen, oder es muss eine neue Überwachung implementiert werden, um verhaltensweisen zu erfassen, die nicht berücksichtigt wurden.

• Verbesserungen an der Arbeitsauslastung. Der Vorfall kann eine Sicherheitsanfälligkeit in der Workload offenlegen, die als dauerhafte Behebung behandelt werden muss.

Überlegungen

Eine übermäßig aggressive Reaktionsstrategie kann zu falschen Alarmen oder unnötigen Eskalationen führen.

Ebenso kann die aggressive Implementierung der automatischen Skalierung oder anderer Selbstheilungsmaßnahmen zur Reaktion auf Schwellenwertverletzungen 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, um die richtigen Schwellenwerte für Ihre Anforderungen zu ermitteln.

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 Warnplattform, die Sie für automatische Benachrichtigungen und andere Aktionen konfigurieren können, z. B. automatische Skalierung und andere Selbstheilungsmechanismen.

Verwenden Sie Monitor, um maschinelles Lernen zu integrieren. Automatisieren und Optimieren von Vorfallstriagen und proaktiven 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 Einblicke zu Ihrer Workload zu erhalten.

Microsoft bietet Azure-bezogene Schulungen zur Vorfallbereitschaft. Weitere Informationen finden Sie in der Einführung in die Azure-Vorfallbereitschaft und die Vorfallbereitschaft.

Verwandte Links

• Empfehlungen für das Entwerfen und Erstellen eines Observability-Frameworks
• Empfehlungen für das Entwerfen einer zuverlässigen Überwachungs- und Warnstrategie
• Empfehlungen für Selbstheilung und Selbsterhaltung

Checkliste für operative Exzellenz

Lesen Sie den vollständigen Satz von Empfehlungen.

Checkliste für operative Exzellenz