Erstellen eines effektiven Vorfallverwaltungsplans zur Verwaltung von Unterbrechungen

Ein Vorfall ist ein ungeplantes Ereignis, das den normalen Betrieb eines Systems stört, beeinträchtigt oder gefährdet. Vorfälle wirken sich häufig negativ auf Kunden oder ein Unternehmen aus. Sie existieren auf einem Spektrum, von vorübergehenden oder lokalisierten Störungen bis hin zu weit verbreiteten Ereignissen oder Katastrophen. Beispiele für Sicherheitsvorfälle sind Datenschutzverletzungen, behördliche Verstöße, Schadsoftware oder Identitätskompromittierungen. Ursachen sind Hardware- oder Infrastrukturfehler, Ressourcenbeschränkungen, menschliche Fehler wie fehlerhafte Bereitstellungen oder Fehlkonfigurationen oder externe Faktoren wie Sicherheitsangriffe.

Die Vorfallverwaltung (Incident Management, IcM) bietet einen systematischen Ansatz zur Wiederherstellung des Diensts während Unterbrechungen. Es koordiniert Erkennung, Untersuchung, Entschärfung und Lösung, während klare Kommunikation und Dokumentation von Erkenntnissen zur kontinuierlichen Verbesserung beibehalten werden. Die Reaktion auf Vorfälle folgt unabhängig vom Vorfalltyp demselben Playbook.

Wenn Sie Ihren IcM-Plan erstellen, konzentrieren Sie sich nicht nur auf Dashboards und Runbooks. Als Architekt arbeiten Mitarbeiter, Prozesse und Werkzeuge unter Druck zusammen, um Systeme effizient und ohne Chaos wiederherzustellen. Ihre IcM-Strategie sollte basierend auf dem Schweregrad skaliert werden, von der schnellen Entschärfung für kleinere Vorfälle bis hin zu koordinierten teamübergreifenden Bemühungen um wichtige Ereignisse. Die Antwort kann auch je nach Ursache variieren.

Dieser Artikel konzentriert sich auf die Phasen von IcM, einschließlich Vorbereitung, aktiver Reaktion auf Vorfälle, Überprüfung nach dem Vorfall und fortlaufender Verbesserung. Diese Anleitung enthält auch ein Beispiel zur Veranschaulichung der Entwurfspraktiken. Bevor Sie beginnen, überprüfen Sie die wichtigsten Strategien, und wählen Sie die Strategien aus, die für Ihr Unternehmen sinnvoll sind. Weitere Informationen finden Sie unter OE:08 Architekturstrategien für das Entwerfen eines IcM-Prozesses.

In diesem Artikel werden keine Katastrophen behandelt, die spezielle Wiederherstellungsbemühungen erfordern. Weitere Informationen zur Behandlung solcher Szenarien finden Sie unter Entwickeln eines Notfallwiederherstellungsplans für Bereitstellungen mit mehreren Regionen.

Terminologie

Bevor Sie mit der Entwicklung Ihres Vorfallverwaltungsplans beginnen, machen Sie sich mit diesen wichtigen Begriffen vertraut.

Begriff Definition
Strahlradius Der Umfang der Auswirkungen oder des betroffenen Bereichs, wenn ein Vorfall auftritt, den Eindämmungsstrategien darauf abzielen, zu begrenzen.
Bruchglaskonten Notfallanmeldeinformationen mit erhöhten Berechtigungen, die bei kritischen Vorfällen verwendet und streng nach klaren Verwendungsrichtlinien gesteuert werden.
Brückenteam Das Triageteam, das sich versammelt, um einen Vorfall zu untersuchen, auch als Ingenieurbrücke bezeichnet. Sie besteht aus relevanten technischen Experten und Entscheidungsträgern.
Eindämmung Der erste Schritt bei der Problembehebung, die betroffene Komponenten isoliert, um zu verhindern, dass sich das Problem auf andere Teile der Workload ausbreitet.
Vorfallverwaltung (IcM) Der strukturierte Prozess zum Erkennen, Triagieren, Verringern und Beheben von Vorfällen bei gleichzeitiger Koordination der Kommunikation und Erfassung der gelernten Erkenntnisse.
Last-known-good Der letzte fehlerfreie Zustand der Workload vor Beginn eines Vorfalls, der als Referenzpunkt für Rollbackvorgänge verwendet wird.
Ausgleich Aktionen zum Reduzieren oder Entfernen der Auswirkungen eines Vorfalls, einschließlich Rollback, Fallback, Bypass oder Notfallbehebungen.
Rückblickend Ein schuldfreier Prozess zur Überprüfung nach einem Vorfall konzentriert sich auf die Ermittlung von Erkenntnissen und umsetzbaren Verbesserungen und nicht auf die Zuweisung von Schuld.
Ursachenanalyse (Root Cause Analysis, RCA) Ein systematischer Prozess der Untersuchung eines Vorfalls, um die zugrunde liegenden Faktoren zu identifizieren, die für das Problem verantwortlich sind, und eine Wiederholung zu verhindern.
Schweregrad Ein Klassifizierungssystem, z. B. kritisch, hoch, mittel und niedrig, das die geeignete Reaktionsebene basierend auf den geschäftlichen Auswirkungen und betroffenen Benutzern bestimmt.
Triage Der Prozess der Analyse und Priorisierung von Vorfällen zur Ermittlung von Schweregrad, Effekten und geeigneten Reaktionsaktionen.

Vorbereitung

Bevor ein Vorfall auftritt, richten Sie die Grundlage für eine effektive Reaktion ein, indem Sie die Observability entwerfen, klare Rollen und Prozesse definieren und die Tools und Ressourcen vorbereiten, die Ihre Teams benötigen. Dokumentieren Sie den Plan zur Reaktion auf Vorfälle, und aktualisieren Sie ihn regelmäßig, und überprüfen Sie ihn regelmäßig.

  1. Verwalten Sie genaue, aktuelle Architekturdiagramme, die alle Komponenten und deren Interaktionen anzeigen, um Teams dabei zu helfen, Engpässe oder einzelne Fehlerstellen schnell zu erkennen. Dieser Ansatz ermöglicht eine schnellere Problembehandlung bei Hochdrucksituationen.

  2. Definieren Sie die Vorfalldaten, die Ihr Überwachungsstapel für die gesamte Workload bereitstellen muss:

    • Sammeln Sie End-to-End-Telemetrie, einschließlich Infrastruktur und Anwendungen.

    • Ermöglichen Sie die strukturierte Protokollierung für alle Komponenten, um die Triage und Untersuchung zu unterstützen, und senden Sie Protokolle an Datensenken zur Analyse. Leiten Sie bei Bedarf auch Protokolle an zentral verwaltete Sinks weiter. Stellen Sie sicher, dass Teammitglieder während Vorfällen zeitlich begrenzten Zugriff auf die geringsten Rechte haben.

    • Erstellen Sie Dashboards basierend auf dem Workload-Gesundheitsmodell. Die Dashboards zeigen Metriken und Signale an, die Ihr Team überwacht.

    • Konfigurieren Sie Aktionen erfordernde Warnungen, die Benachrichtigungen nur auslösen, wenn Schwellenwerte überschritten werden und ein potenzieller Vorfall erkannt wird. Optimieren Sie Warnungen, um zu viele Warnungen (Rauschen) oder zu wenige Warnungen zu vermeiden. Beispielsweise sollten Warnungen für Live-Site-Vorfälle kritische Metriken wie zentrale Verarbeitungseinheit (CPU), Arbeitsspeicher, Reaktionszeiten und Datenbankleistung überwachen, um umsetzbare Probleme zu erkennen, die mit Leistungszielen übereinstimmen.

      Leiten Sie Benachrichtigungen automatisch an die richtigen Teams weiter. Beispielsweise erhält der Tier-1-Support alle Warnungen, während Sicherheitstechniker nur sicherheitsbezogene Warnungen erhalten.

    Weitere Informationen finden Sie unter Empfehlungen zum Entwerfen und Erstellen eines Observability-Frameworks.

  3. Definieren Sie Schlüsselrollen, um Verantwortlichkeit, Entscheidungsfindung und effektive Nachverfolgung während und nach Vorfällen sicherzustellen. Erstellen Sie geeignete Genehmigungsprozesse, und codieren Sie sie in einem klaren Entscheidungsbaum. Definieren Sie Autorisierungsstufen für verschiedene Schweregrade, Entschärfungsentscheidungen, Eskalationspfade und andere Bereiche.

    Verwenden Sie die folgenden Beispiele als Ausgangspunkt und passen Sie sie an Ihre Teamstruktur an.

    Rolle Verantwortlichkeiten
    Vorfallreaktions-Manager Verantwortet den Vorfall von der Erkennung über die Auflösung bis zur Ursachenanalyse (RCA). Stellt sicher, dass Prozesse befolgt werden, Entscheidungen getroffen werden und die richtigen Personen informiert werden.
    Retrospektive Führungskraft Führt Überprüfungen nach Vorfällen durch, erfasst gelernte Erkenntnisse, erzeugt umsetzbare Berichte und stellt sicher, dass Ergebnisse angewendet werden.
    On-Call Engineer Entschärft und löst Vorfälle aktiv. Folgt den Verantwortlichkeiten für verschiedene Vorfalltypen und arbeitet bei Bedarf mit spezialisierten Teams zusammen, um eine zeitnahe Lösung des Vorfalls sicherzustellen.

  4. Definieren von Verfahren für die Untersuchung:

    • Definieren Sie Kategorien für Arten von Vorfällen , z. B. Betriebs-, Sicherheits-, Leistungs- und Bereitstellungsvorfälle – und Schweregrade ( z. B. kritisch, hoch, mittel und niedrig ), die für Ihre Workload gelten.

    • Dokumentieren Sie, wie Der Schweregrad, die Auswirkungen und die Dringlichkeit des Vorfalls ausgewertet werden. Berücksichtigen Sie die Auswirkungen der Benutzer, betroffenen Systeme und geschäftskritische Funktionen. Basierend auf dem Schweregrad aktiviert das Team den Katastrophenwiederherstellungsplan für Fälle, die Schwellenwerte auf Katastrophenebene erfüllen. Oder sie folgen dem Standardreaktionsplan für weniger schwere Vorfälle.

    • Definieren Sie Strategien, die die betroffene Komponente aus Arbeitsauslastungsflusspfaden isolieren oder entfernen, z. B. das Herunterfahren einer Ressource oder das Umleiten von Datenverkehr. Identifizieren Sie, welche Rollen über die Berechtigung verfügen, eine Eindämmungsaktion auszuführen.

      Legen Sie Überwachungssysteme fest, um die Eindämmung für definierte Vorfälle automatisch zu initiieren. Dieser Ansatz hält den Menschen in der Schleife für kritische Entscheidungen. Systemadministratoren, Ingenieure und leitende Entwickler sollten zusammenarbeiten, um den Strahlradius zu begrenzen und gleichzeitig beeinträchtigte Funktionen aufrechtzuerhalten. Wenn eine Komponente für die Triage verfügbar bleiben muss, isolieren Sie den Zugriff streng vom Rest der Workload.

    • Erstellen Sie Richtlinien für die Auswahl von Minderungsstrategien je nach Schweregrad des Vorfalls, wie zum Beispiel Isolation, Rollback, Konfigurationsänderungen und Problemumgehungen.

    • Geben Sie an, welche Teams oder Einzelpersonen den Vorfall basierend auf Typ und Schweregrad behandeln. Fügen Sie Eskalationspfade ein, wenn die anfänglichen Antwortenden das Problem nicht beheben können.

    • Beschreiben Sie, welche Daten während der Triage gesammelt werden sollen, z. B. Protokolle, Metriken, Benutzerberichte und Warnungen, um Die Untersuchung und Entscheidungsfindung zu unterstützen. Geben Sie auch an, wer Zugriff auf diese Daten haben soll.

    Von Bedeutung

    Schützen Sie Ihre Notfallanmeldeinformationen oder Break-Glass-Konten, indem Sie klare Regeln festlegen. Bestimmen Sie, wer sie verwenden kann, wann und wie genau. Koppeln Sie diese Regeln mit Notfallübungen und verfolgen Sie jeden Durchlauf. Definieren Sie, wie häufig das Team Übungen durchführen soll. Während eines Vorfalls gibt es keine Zeit, es im Moment herauszufinden. Drills bieten angemessene Trainings- und Verfeinerungsmöglichkeiten.

  5. Richten Sie Ihre Infrastruktur ein, um die Lösung zu unterstützen:

    • Parametrisieren Sie Pipelines. Aktivieren Sie Bereitstellungs- und Wiederherstellungspipelines, um bestimmte Versionen für eine schnelle Zurücksetzung zu akzeptieren oder die Bereitstellung zu korrigieren.

    • Sicherstellen der Datenebenenkonsistenz. Halten Sie Schlüssel, Geheimnisse, Konfigurationen und Zustandsdaten während der Wiederherstellungsvorgänge in Einklang.

    • Automatisieren Sie die Infrastrukturskalierung. Passen Sie Ressourcen automatisch an, um Verkehrsverschiebungen oder erhöhte Belastung zu verarbeiten.

    • Implementieren Sie die Selbstheilung. Sicheres Automatisieren von Antworten auf häufige Vorfallmuster, wobei eine ordnungsgemäße Überwachung und Optionen für die manuelle Übersteuerung enthalten sind.

  6. Definieren Sie Kommunikationsprozesse. Dokumentieren Sie klare Kommunikations- und Eskalationspläne, damit der Support der Stufe 1 schnell die richtigen Teams erreichen kann. Geben Sie geeignete Kommunikationskanäle für interne und externe Projektbeteiligte an, und fügen Sie Anrufpläne und Kontaktdetails ein.

  7. Definieren Sie die Verwendung eines IcM-Tools und die Standardbetriebsverfahren, die in einem einfachen Workflow erfasst werden sollen. Der Workflow umfasst vier Schritte: Erstellen, Bestätigen, Verringern und Auflösen. Das Tool bietet Teams Sichtbarkeit, verfolgt den Fortschritt, verwaltet die Verantwortlichkeit und stellt jederzeit eine konsistente Behandlung von Vorfällen sicher. Es zentralisiert alle Aktivitäten zur Unterstützung der Verwaltung von Live-Sites und Rufbereitschaftsrotationen.

  8. Definieren Sie die Kriterien, die einen Vorfall offiziell als geschlossen kennzeichnen:

    • Schließen Sie klare Auflösungsfaktoren ein. In der Regel bedeutet die Lösung, dass das System und die Dienste innerhalb der Vereinbarungen auf Serviceebene (Service Level Agreements, SLAs) betrieben werden, die Leistung und Zuverlässigkeit auf akzeptable Ebenen zurückkehren und sofortige Abhilfemaßnahmen erfolgreich abgeschlossen werden.

    • Schließen Sie Überprüfungen ein, um die vollständige Auflösung zu bestätigen. Verwenden Sie Überwachungstools, um zu überprüfen, ob sich der Vorfall nicht mehr auf das System auswirkt und betroffene Benutzer keine Unterbrechungen mehr erleben.

    • Berücksichtigen Sie bei der Schließung eines Vorfalls die Kommunikationsanforderungen. Benachrichtigen Sie relevante Projektbeteiligte, einschließlich interner Teams, Supportmitarbeiter und betroffener Benutzer, und stellen Sie eine Zusammenfassung der durchgeführten Maßnahmen zusammen mit der laufenden Arbeit bereit.

    • Fügen Sie umfassende Dokumentation hinzu, wenn Sie einen Vorfall schließen. Notieren Sie alle Details im IcM-System. Schließen Sie den Auslöser, die Eindämmungsschritte, die Triageentscheidungen und die endgültige Lösung ein. Behandeln Sie diese Dokumentation als Übergabe für RCA und die Retrospektive, um gelernte Erkenntnisse zu erfassen.

    Von Bedeutung

    Entwerfen Sie Ihre Vorgänge so, dass nur die benannte Behörde, z. B. der Incident Response Manager, einen Vorfall schließen kann. Erzwingen Sie strenge Checklisten, um vorzeitige Schließungen zu blockieren. Das Überspringen von Schritten kann ausgeblendete Probleme ungelöst lassen, wodurch ein geschlossener Vorfall zu einer Wiederholungskatastrophe wird.

Erkennen, Untersuchen und Reagieren

Phase 2 konzentriert sich auf die schnelle und effektive Erkennung und Reaktion auf Vorfälle. In dieser Phase werden Probleme frühzeitig identifiziert, ihre Auswirkungen bewertet und die richtigen Entschärfungsstrategien implementiert, während Unterbrechungen minimiert werden. In dieser Phase wird auch sichergestellt, dass Triage, Auflösung und Kommunikation in allen Teams koordiniert, konsistent und rechenschaftsfähig sind.

Von Bedeutung

Klare, konsistente Kommunikation sorgt für Kontrolle und Klarheit in Stresssituationen. Definieren Sie genau, wer spricht, was freigegeben wird und wie oft. Standardisieren Sie die Update-Kadenz, Kanäle und Nachrichtenformate, sodass niemand während der Krise nach Informationen hetzen muss. Stellen Sie sicher, dass jeder Projektbeteiligte, von Ingenieuren bis hin zu Führungskräften, weiß, wann Updates erwartet werden und wann eine Eskalation erforderlich ist.

  1. Reagieren Sie sofort, wenn Warnungen oder Benutzerberichte auf ein Problem hinweisen. Verwenden Sie Observability- und Leistungstools, um Anomalien mit Systemänderungen zu korrelieren. Der Vorfallempfänger richtet ein Triageteam (Brückenteam) mit den richtigen Mitgliedern ein und stimmt dem Kommunikationsmodus, der Statusnachverfolgung und dem Zugriff auf Vorfallressourcen zu.

  2. Mobilisieren Sie die Engineering-Brücke, um die Auswirkungen und den Schweregrad zu bewerten. Bewerten Sie die Auswirkungen des Vorfalls mithilfe Ihrer vordefinierten Schweregradklassifizierungen. Verwenden Sie Daten, um Kriterien zu rechtfertigen, die im Plan für die Reaktion auf Vorfälle beschrieben sind, z. B. die Anzahl der betroffenen Benutzer, geschäftsfunktionen gestört, Sicherheits- und Compliance-Auswirkungen sowie potenzielle Auswirkungen auf Kundenvertrauen und Zuverlässigkeit. Diese Bewertung bestimmt die entsprechende Reaktionsebene und leitet die nächsten Gegenmaßnahmenschritte.

  3. Die Untersuchungsphase beginnt, wenn die richtigen Entwicklungsteams engagiert sind und ein RCA starten. Dieser Prozess umfasst eine umfassende technische Analyse, um die Ursache zu bestimmen und die Auswirkungen zu enthalten. Techniker verwenden Observability-Daten, Telemetriedashboards, Systemprotokolle und Änderungshistorien, um Anomalien zu verfolgen und Fehlerpunkte zu identifizieren. Sie konzentrieren sich darauf, das Problem schnell zu isolieren, Hypothesen mithilfe von Echtzeitdaten zu validieren und einen präzisen Entschärfungsplan zu entwickeln, mit dem die Dienststabilität wiederhergestellt wird, ohne ein neues Risiko einzuführen.

    Kompromiss: Ein RCA kann erhebliche Zeit in Anspruch nehmen. Um Leistungsprobleme zu korrelieren, müssen Sie Daten sammeln und speichern. Die erforderliche Zeit und Infrastruktur können den Betriebsteams zusätzliche Arbeit und Kosten für die Arbeitsauslastung hinzufügen.

    Risiko: Wenn Sie eine RCA ohne ordnungsgemäße Sicherheitsschutzschienen durchführen, können Sie vertrauliche Informationen verfügbar machen, wenn Sie Zugriff auf Protokolle und Daten gewähren.

  4. Folgen Sie den Eindämmungsstrategien, um betroffene Komponenten zu isolieren und den Strahlradius einzuschränken. Sie können die folgenden Aktionen ausführen:

    • Blockieren sie den Zugriff auf betroffene Komponenten, indem Sie separate Pfade für die Triage verwenden. Sie können beispielsweise eine Ressource herunterfahren, den Datenverkehr drosseln oder einen fehlerhaften Microservice deaktivieren.

    • Beschränken Sie die Reichweite des Vorfalls auf bestimmte Benutzer, Regionen oder Komponenten.

    • Verwalten Sie die Arbeitsauslastungsfunktionalität in einem beeinträchtigten Zustand, wenn möglich.

  5. Wählen Sie eine geeignete Entschärfungsstrategie aus. Wählen Sie Minderungsstrategien basierend auf dem aktuellen Zustand der Workload, den verfügbaren Ressourcen und den sofortigen Einschränkungen aus.

    Ihre Wahl hängt von Faktoren wie Infrastrukturtyp, verfügbaren Umgehungsmechanismen, Komplexität des Fixs, Datenempfindlichkeits- und Complianceanforderungen, Systemabhängigkeiten und Wiederherstellungszeitzielen (Recovery Time Objectives, RTOs) ab.

    • Rollback: Setzen Sie die Systeme auf den zuletzt bekannten funktionsfähigen Konfigurationszustand zurück. Das Workloadteam sollte definieren, was das letzte bekannte Gute bedeutet. Es bezieht sich in der Regel auf den letzten fehlerfreien Zustand der Workload, bevor die Bereitstellung begonnen hat, was möglicherweise nicht die unmittelbar vorherige Anwendungsversion ist. Ein Rollback kann komplex sein, insbesondere, wenn Schema- oder Datenänderungen beteiligt sind. Um das Risiko zu reduzieren, müssen Sie Schemaupdates additiv machen, anstatt Datensätze zu ersetzen. Die alten und neuen Daten können koexistieren, bis Sie veraltete Datensätze sicher entfernen können. Rollbacks erfordern möglicherweise eine sorgfältige Planung und Koordination in mehreren Teams.

    • Fallback: Entfernen Sie aktualisierte Systeme aus dem Produktionstraffik-Routing und leiten Sie den gesamten Datenverkehr an den stabilen Stack. Diese Strategie mit geringem Risiko behebt Bereitstellungsprobleme, ohne weitere Unterbrechungen zu verursachen. Bei Canary-Bereitstellungen kann der Fallback je nach Infrastruktur und Anwendungsdesign kompliziert sein. Stellen Sie eine ausreichende Kapazität auf dem stabilen Software-Stack sicher, bevor Sie den Datenverkehr wieder umschalten. Fallback unterstützt fortgesetzten Betrieb und isoliert die problematische Bereitstellung.

    • Umgehen Sie die beleidigende Funktion: Verwenden Sie Featurekennzeichnungen oder Laufzeitkonfigurationseigenschaften, um die problematische Funktionalität zu umgehen. Mit diesem Ansatz kann der Rollout fortgesetzt und das Problem isoliert werden. Bewerten Sie Trade-Offs und kommunizieren Sie sie mit den Projektbeteiligten. Geben Sie an, wie lange Sie einen beeinträchtigten Zustand und die geschätzte Zeit tolerieren können, um das Problem vollständig zu beheben. Erhalten Sie die Genehmigung der Projektbeteiligten für den Plan.

    • Notfallbereitstellung (Hot Fix): Stellen Sie während des Rollouts einen Hot Fix bereit, um das Problem schnell zu beheben. Folgen Sie sicheren Bereitstellungspraktiken, einschließlich des Code-Deployments über verschiedene Umgebungen und Qualitätsgate-Kontrollen, aber beschleunigen Sie die Prozesse. Kürzen oder ändern Sie Backzeiten und Tests, um die Bereitstellung zu beschleunigen. Verwenden Sie automatisierte Tests, um zuverlässigkeit zu gewährleisten. Hot Fixes erfordern Koordination und sorgfältige Planung, um Risiken zu minimieren und das Problem umgehend zu beheben.

    Von Bedeutung

    Stellen Sie sicher, dass Entschärfungsentscheidungen vordefinierten Autorisierungsregeln entsprechen. Der Vorfallsmanager sollte alle Gegenmaßnahmen übernehmen. Fordern Sie autorisierte Mitarbeiter auf, die Schritte mit hoher Auswirkung zu genehmigen und jede Aktion zu dokumentieren. Halten Sie die Aktionen kontrolliert, sicher und verantwortlich, während Sie das System wiederherstellen.

    Wenn ungefähr zu dem Zeitpunkt, zu dem Ihr Team eine Änderung ausgerollt hat, ein benutzerrelevantes Problem auftritt, gehen Sie davon aus, dass die Änderung die wahrscheinliche Ursache ist, und rollen Sie sie sofort zurück, anstatt zunächst lange zu untersuchen. Die Zeit, in der Sie die Risikominderungsstrategie auswählen, wird in Ihrer mittleren Zeit für die Wiederherstellung (MTTR) berücksichtigt. Optimieren Sie diese Zeit, indem Sie Sofortmaßnahmen ergreifen.

  6. Wenden Sie die Auflösung an. Dieser Schritt konzentriert sich auf die Wiederherstellung des Systems auf den vollständigen Betriebszustand und verhindert gleichzeitig die Wiederholung. Entwicklungsteams wenden überprüfte Korrekturen an, die teamspezifischen Skriptprozeduren folgen. Sie verwenden Protokollanalyse- und Überwachungstools, um die Untersuchung zu leiten. Rollbackschritte machen unwirksame Änderungen rückgängig, um sicherzustellen, dass jede Aktion das System stetig in Richtung vollständige Wiederherstellung steuert.

  7. Generieren Sie einen RCA-Bericht. Nachdem Sie einen Vorfall behoben haben, generieren Sie den RCA-Bericht innerhalb des SLA-Zeitrahmens. Der Vorfallbesitzer oder ein eng eingebundenes Teammitglied, wenn der Besitzer nicht verfügbar ist, sollte den Bericht erstellen, um die Genauigkeit sicherzustellen. Befolgen Sie eine definierte RCA-Vorlage, die klare Richtlinien darüber enthält, welche Informationen einbezogen und freigegeben werden sollen, oder erstellen und genehmigen Sie eine neue Vorlage über die Überprüfung der Projektbeteiligten.

Aktivitäten nach dem Vorfall

Retrospektiven nach jedem Vorfall durchführen. Sie bieten wichtige Lernmöglichkeiten, heben Schwachstellen in Reaktion, Bereitstellung oder Infrastruktur hervor und tragen zur Verbesserung bei. Dokumentieren Sie Aktionselemente, und verfolgen Sie sie in einem Backlog für die iterative Implementierung.

Das Ziel ist nicht, Schuld zuzuweisen, sondern umsetzbare Verbesserungen zu identifizieren. Ein unparteiischer Vermittler sollte diesen Prozess führen. Personen, die an der Reaktion gearbeitet haben, müssen jedes Team darstellen, das an dem Vorfall beteiligt ist. Sie müssen mit Beobachtungen über Erfolge und Verbesserungsbereiche vorbereitet werden:

  • Verbesserungen des Antwortplans: Aktualisieren Sie Prozesse oder Verfahren, um klarere, effektivere Aktionen sicherzustellen.

  • Verbesserungen der Observability: Passen Sie Schwellenwerte an, fügen Sie Überwachung hinzu oder implementieren Sie Warnungen, um ähnliche Vorfälle früher zu erkennen.

  • Workload-Korrekturmaßnahmen: Beheben Sie Sicherheitsrisiken, die während des Vorfalls aufgedeckt wurden, um dauerhafte Lösungen umzusetzen.

Beispiel: Antwort auf Bereitstellungsfehler

Im folgenden Beispiel wird ein bereitstellungsbezogener Vorfall beschrieben. Auch bei sorgfältiger Planung und Tests können Bereitstellungen manchmal Probleme verursachen, die sich auf die Systemleistung oder die Benutzererfahrung auswirken.

In diesem Beispiel führt ein Workloadteam ein Feature zur Verbesserung der Suche aus, das mehrere Komponenten umfasst:

  • Ein neuer Such-API-Endpunkt mit erweiterter Filterfunktionalität
  • Ein aktualisiertes Datenbankschema
  • Ein neu gestaltetes Benutzeroberflächen-Such-Widget
  • Neue Zwischenspeicherungslogik

Das Team führt die folgenden Schritte aus, um den Vorfall zu erkennen, zu mindern und zu beheben:

  1. Erkennung: Das Team bemerkt ein Problem, wenn Fehlerraten in einer der Canary-Rollout-Gruppen steigen. Das Team verwendet ihre Observability-Tools sofort, z. B. Anwendungsleistungsüberwachung (Application Performance Monitoring, APM), Protokollierung und Telemetrie, um Benutzer mit Rollout-Phasen zu verknüpfen, um die betroffene Gruppe zu identifizieren.

    Das Team hat sich auf dieses Szenario vorbereitet, indem es starke Beobachtbarkeit in seinen Bereitstellungsprozess integriert. Sie führten Rauchtests und Qualitätsprüfungen in jeder Rolloutphase durch und instrumentierten ihre Anwendung mit Protokollierung, Ablaufverfolgung und Leistungsmetriken. Telemetrie verknüpft Benutzer mit bestimmten Rolloutgruppen, sodass sie schnell erkennen können, welche Version welche Benutzer betroffen hat. Sie planten auch Bereitstellungen während der Arbeitszeiten, wenn vollständige Unterstützung verfügbar war, und stellten sicher, dass die Supportmitarbeiter wussten, wie Probleme gemäß dem Notfallreaktionsplan eskaliert werden. Diese Vorbereitung ermöglicht es ihnen, die Spitze der Fehlerraten schnell zu erkennen und ohne Verzögerung zu reagieren.

  2. Milderung: Das Team entscheidet schnell über eine Entschärfungsstrategie. Sie überlegen, ob sie ein Rollback auf die letzte bekannte gute Version ausführen, auf die stabile Umgebung zurückgreifen, die problematische Funktion umgehen, indem sie ein Feature-Flag verwenden, oder einen Hotfix bereitstellen. Die Entscheidungsstruktur und der Genehmigungsprozess sind bereits definiert.

    Nachdem das Team alle verfügbaren Strategien überprüft hat, schränken sie ihre Wahl entweder auf Rollback oder Fallback ein und entscheiden letztendlich über Fallback. Sie stellen fest, dass das Umleiten des Verkehrs zum stabilen Stack schneller und mit geringerem Risiko verbunden ist als ein vollständiges Rollback, das komplexe Daten- und Schemavorgänge erfordern könnte. Das Team bestätigt, dass der stabile Stapel über genügend Kapazität verfügt, um die volle Produktionslast zu bewältigen, und sie können die aktualisierten Systeme vom Produktionsverkehrsrouting isolieren.

    Das Team gebündelt mehrere zusammenhängende Änderungen, einschließlich der API, des Datenbankschemas, der UI-Komponenten und der Zwischenspeicherungslogik, sodass die Identifizierung der spezifischen Komponente, die die Fehler verursacht hat, schwieriger und zeitaufwändig ist, als wenn sie jede Änderung separat bereitgestellt hatten.

  3. Auflösung: Das Team implementiert die Fallbackprozedur. Sie leiten den Datenverkehr aus der aktualisierten Umgebung heraus, um die problematische Bereitstellung zu isolieren. Das Team kann das zugrunde liegende Problem beheben, ohne die meisten Benutzer zu beeinträchtigen.

    Die Fallbackimplementierung zeigt operative Lücken. Sie finden veraltete Kontaktinformationen für zwei wichtige Teammitglieder, und ein Techniker in der Eskalationskette verließ das Unternehmen Monate zuvor. Das Team verliert Zeit, die verantwortungsvolle Person zu ermitteln. Wenn sie versuchen, die aktualisierte Bereitstellung aus dem Lastenausgleich zu entfernen, verweist die Dokumentation auf eine veraltete Konfiguration des Lastenausgleichs, die in einem kürzlichen Azure-Update geändert wurde. Sie müssen das richtige Verfahren unter Zeitdruck finden.

    Kommunikation ist ein wichtiger Bestandteil des Entschärfungsplans. Das Team informiert die Beteiligten über die Entscheidung und ihre Auswirkungen, einschließlich des erwarteten Zeitrahmens zur Lösung des Problems in der isolierten Umgebung. Das Team hat bereits den Rhythmus für die Bereitstellung von Statusupdates während Bereitstellungsvorfällen standardisiert, sodass die Beteiligten wissen, wann Statusberichte und Updates erwartet werden. Das Team hat außerdem den Typ und die Detailebene definiert, um sie mit Benutzern zu teilen und die Einhaltung anderer Anforderungen für die Kommunikation zwischen Bereitstellungsvorfällen sicherzustellen. Dieser strukturierte Ansatz minimiert Verwirrung und trägt dazu bei, das Vertrauen in den Antwortprozess aufrechtzuerhalten.

  4. Rückblickend: Nachdem das Team den Bereitstellungsvorfall entschärft hat, führen sie eine Retrospektive aus, um gelernte Erkenntnisse zu erfassen und zukünftige Prozesse zu verbessern. Die Sitzung umfasst alle Beteiligten am Rollout, von Entwicklern und Betreibern bis hin zu Unterstützung und Stakeholder-Vertretern. Das Team überprüft die Abfolge von Ereignissen, von der Erkennung bis hin zur Entschärfung, um zu verstehen, was gut ging und wo Lücken vorhanden waren.

    Eine wichtige Erkenntnis besteht darin, dass das Bündeln der Such-API-Änderungen, Datenbankschema-Aktualisierungen, UI-Neugestaltung und Änderungen an der Caching-Schicht sowohl die Problembehandlung als auch die Wiederherstellungskomplikationen verschärft hat.

  5. Verbesserungen nach Vorfällen: Aus der Retrospektive implementiert das Team mehrere betriebliche Verbesserungen, um zukünftige Bereitstellungen sicherer und zuverlässiger zu gestalten:

    • Kleinere, häufige Änderungen: Das Team wechselt zu kleineren, inkrementellen Bereitstellungen, um das Delta zwischen aufeinander folgenden Versionen zu reduzieren und die Risikominderung zu vereinfachen und das Risiko zu verringern.

      Für die Sucherweiterung beschließt das Team, jede Komponente unabhängig bereitzustellen. Sie stellen nun die Datenbankschemaänderungen zuerst mit abwärtskompatiblen Änderungen bereit, dann die Aktualisierungen des API-Endpunkts und anschließend andere Änderungen. Dieser Ansatz ermöglicht es dem Team, jede Ebene unabhängig zu überprüfen, bevor sie die nächste Ebene hinzufügen und Probleme einfacher zu einer bestimmten Komponente isolieren.

    • Regelmäßige Tests und Drills: Das Team richtet eine Praxis für häufige Tests für die vollständige Strategie zur Risikominderung von Bereitstellungsfehlern ein. Sie führen Chaos engineering- und Fehlerinjektionstests ein, um Fehlerszenarien zu simulieren und Risikominderungsprozesse zu validieren. Diese regelmäßigen Drills hätten die Probleme, die während des Vorfalls aufgetreten sind, einschließlich veralteter Kontaktinformationen und veralteter Runbook-Verfahren, erfasst.

Azure-Unterstützung

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

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

    Verwenden Sie Azure Monitor, um maschinelles Lernen zu integrieren. Automatisieren und Optimieren der Vorfalls-Triage und proaktiven Maßnahmen. Weitere Informationen finden Sie unter KI-Vorgänge und maschinelles Lernen in Azure Monitor.

    • Log Analytics ist ein Analysetool in Azure Monitor. Sie können Log Analytics verwenden, um Abfragen für aggregierte Protokolle auszuführen und Einblicke zu Ihrer Workload zu erhalten.

    • Application Insights ist eine Erweiterung von Azure Monitor, die APM-Funktionen bereitstellt.

  • Microsoft Sentinel ist eine Sicherheitsinformations- und Ereignismanagementlösung (SIEM) und eine Lösung für Sicherheitsorchestrierung, -automatisierung und -reaktion (SOAR). Es ist eine einzige Lösung für die Erkennung von Warnungen, die Sichtbarkeit von Bedrohungen, die proaktive Suche und die Reaktion auf Bedrohungen.

  • Azure Pipelines bietet Build- und Releasedienste zur Unterstützung der kontinuierlichen Integration und kontinuierlichen Bereitstellung (CI/CD) Ihrer Anwendungen.

  • Azure Test Plans ist eine browserbasierte Testverwaltungslösung. Diese Lösung bietet Funktionen, die für geplante manuelle Tests, Benutzerakzeptanztests und explorative Tests erforderlich sind. Azure Test Plans bietet ihnen auch die Möglichkeit, Feedback von Projektbeteiligten zu sammeln.

  • Azure Logic Apps ist eine cloudbasierte Plattform zum Ausführen automatisierter Workflows, die Apps, Daten, Dienste und Systeme integrieren. Sie können Logic Apps verwenden, um eine neue Version Ihrer Anwendung zu erstellen, wenn sie ein Update erhält. Azure verwaltet einen Verlauf der Versionen und kann jede vorherige Version wiederherstellen oder höher stufen.

  • Viele Azure-Datenbankdienste bieten Funktionen zur Punkt-in-Time-Wiederherstellung (PITR), die Ihnen helfen können, wenn Sie ein Rollback durchführen müssen:

  • Azure Chaos Studio ist ein verwalteter Dienst, der Chaos engineering verwendet, um Ihre Cloudanwendung und Dienstresilienz zu messen, zu verstehen und zu verbessern.

  • Last updated on