Freigeben über

Empfehlungen zum Entwerfen einer Strategie zur Risikominderung von Bereitstellungsfehlern

  • Artikel

Gilt für diese Empfehlung der Prüfliste "Operational Excellence" für Azure Well-Architected Framework:

OE:12 Implementieren Sie eine Strategie zur Behebung von Bereitstellungsfehlern, die unerwartete Probleme während des Rollouts mit einer schnellen Wiederherstellung behebt. Kombinieren Sie mehrere Ansätze, z. B. Rollback, Feature deaktivieren oder die nativen Funktionen Ihres Bereitstellungsmusters verwenden.

In diesem Leitfaden werden die Empfehlungen für das Entwerfen einer standardisierten Strategie beschrieben, um Bereitstellungsfehler effektiv zu behandeln. Wie bei anderen Workloadproblemen sind Bereitstellungsfehler ein unvermeidlicher Teil eines Workloadlebenszyklus. Mit dieser Denkweise können Sie proaktiv sein, indem Sie eine gut konzipierte, absichtliche Strategie für den Umgang mit Bereitstellungsfehlern haben. Eine solche Strategie ermöglicht es Ihrem Workloadteam, Fehler effizient zu entschärfen, und zwar mit möglichst geringen Auswirkungen auf Ihre Endbenutzer.

Das Fehlen eines solchen Plans kann zu chaotischen und potenziell schädlichen Reaktionen auf Probleme führen, was sich erheblich auf den Zusammenhalt von Team und Organisation, Kundenvertrauen und Finanzen auswirken kann.

Wichtige Entwurfsstrategien

Gelegentlich treten trotz des Reifegrads Ihrer Entwicklungsmethoden Bereitstellungsprobleme auf. Die Verwendung sicherer Bereitstellungsmethoden und der Betrieb einer stabilen Workload-Lieferkette kann Ihnen dabei helfen, die Häufigkeit fehlerhafter Bereitstellungen zu minimieren. Sie müssen aber auch eine standardisierte Strategie entwerfen, um fehlerhafte Bereitstellungen zu behandeln, wenn sie auftreten.

Wenn Sie ein progressives Bereitstellungsmodell für die Exposition als Standard verwenden:

  • Sie haben die richtige Grundlage, um die Auswirkungen auf Ihre Kunden oder interne Benutzer zu minimieren, wenn Bereitstellungen fehlschlagen.
  • Sie können Probleme effizient beheben.

Eine Strategie zur Entschärfung von Bereitstellungsfehlern besteht aus fünf allgemeinen Phasen:

  1. Erkennung: Um auf eine fehlgeschlagene Bereitstellung zu reagieren, müssen Sie zuerst den Fehler erkennen. Die Erkennung kann verschiedene Formen annehmen, z. B. fehlgeschlagene Rauchtests, vom Benutzer gemeldete Probleme oder Warnungen, die Ihre Überwachungsplattform generiert.

  2. Entscheidung: Sie müssen entscheiden, welche Risikominderungsstrategie für den jeweiligen Fehlertyp am besten geeignet ist.

  3. Entschärfung: Sie führen die identifizierte Entschärfungsaktion aus. Die Entschärfung kann in Form eines Fallbacks, Rollbacks, Rollforwards oder der Verwendung einer Laufzeitkonfiguration erfolgen, um die beleidigende Funktion zu umgehen.

  4. Kommunikation: Beteiligte und betroffene Endbenutzer müssen über die status informiert werden, wenn Sie das Problem erkennen und bearbeiten, wie in Ihrem Notfallplan erforderlich.

  5. Postmortem: Schuldlose Postmortems bieten dem Workloadteam die Möglichkeit, Verbesserungsbereiche zu identifizieren und Pläne für die Anwendung von Erkenntnissen zu erstellen.

Die folgenden Abschnitte enthalten ausführliche Empfehlungen für diese Phasen. In diesen Abschnitten wird davon ausgegangen, dass Sie ein Problem erkennen, nachdem Sie Ihre Änderungen in einer oder mehreren Gruppen von Benutzern oder Systemen bereitgestellt haben, aber bevor Sie alle Gruppen in Ihrem Rolloutplan aktualisieren.

Erkennung

Um Probleme mit Bereitstellungen schnell zu identifizieren, benötigen Sie robuste Test- und Beobachtbarkeitsmethoden im Zusammenhang mit Bereitstellungen. Um Anomalien schnell zu erkennen, können Sie ihre Workloadüberwachung und Warnungen ergänzen, indem Sie die folgenden Schritte ausführen:

  • Verwenden Sie ein Tool für die Anwendungsleistungsverwaltung.
  • Aktivieren Sie die Protokollierung über die Instrumentierung.

Rauchtests und andere Qualitätstests sollten in jeder Phase Ihres Rollouts durchgeführt werden. Erfolgreiche Tests in einer Bereitstellungsgruppe sollten sich nicht auf die Entscheidungen zum Testen in nachfolgenden Gruppen auswirken.

Sie können Telemetriedaten implementieren, die Benutzerprobleme mit einer Bereitstellungsphase korrelieren. Anschließend können Sie schnell erkennen, welcher Rolloutgruppe ein bestimmter Benutzer zugeordnet ist. Dieser Ansatz ist besonders wichtig für Bereitstellungen mit progressiver Exposition, da Sie möglicherweise mehrere Konfigurationen in Ihrer Benutzerbasis zu einem bestimmten Zeitpunkt in der Bereitstellung ausführen.

Sie sollten bereit sein, sofort auf vom Benutzer gemeldete Probleme zu reagieren. Stellen Sie Ihre Rolloutphase jederzeit während der Arbeitszeit bereit, wenn Ein vollständiges Supportteam zur Verfügung steht. Stellen Sie sicher, dass die Supportmitarbeiter in der Eskalation von Bereitstellungsproblemen für ein ordnungsgemäßes Routing geschult sind. Eskalationen sollten mit Ihrem Workload-Notfallreaktionsplan übereinstimmen.

Entscheidung

Die Entscheidung über eine geeignete Entschärfungsstrategie für ein bestimmtes Bereitstellungsproblem umfasst viele Faktoren, einschließlich:

  • Der Typ des progressiven Belichtungsmodells, das Sie verwenden. Sie können beispielsweise ein blaugrünes Modell oder ein Canary-Modell verwenden.

    Wenn Sie ein blau-grünes Modell verwenden, ist das Zurückfallen praktischer als ein Rollback. Sie können den Datenverkehr problemlos zurück in den Stapel verschieben, der die konfiguration ausführt, die nicht aktualisiert wird. Anschließend können Sie das Problem in der problematischen Umgebung beheben und die Bereitstellung zu einem geeigneten Zeitpunkt erneut versuchen.

  • Die Methoden, die Ihnen zur Umgehung des Problems zur Verfügung stehen. Beispiele hierfür sind die Verwendung von Featureflags, Umgebungsvariablen oder anderen Arten von Laufzeitkonfigurationseigenschaften, die Sie ein- und ausschalten können.

    Manchmal können Sie ein Problem einfach umgehen, indem Sie ein Featureflag deaktivieren oder eine Einstellung umschalten. In diesem Fall können Sie möglicherweise Folgendes ausführen:

    • Fahren Sie mit dem Rollout fort.
    • Vermeiden Sie rückfallen.
    • Führen Sie ein Rollback aus, während Sie den beleidigenden Code beheben.

  • Der Aufwand, der erforderlich ist, um eine Korrektur im Code zu implementieren.

    Wenn der Aufwand zum Beheben des Codes gering ist, ist ein Rollforward durch Implementieren einer Hot Fix-Lösung die richtige Wahl für bestimmte Szenarien.

  • Die Wichtigkeitsstufe für die betroffene Workload.

    Unternehmenskritische Workloads sollten immer parallel bereitgestellt werden, z. B. in einem blau-grünen Modell, um Bereitstellungen ohne Ausfallzeiten zu erreichen. Daher ist ein Fallback die bevorzugte Entschärfungsstrategie für diese Arten von Workloads.

  • Der Typ der Infrastruktur, die von der Workload verwendet wird– veränderlich oder unveränderlich.

    Wenn Ihre Workload so konzipiert ist, dass sie veränderliche Infrastruktur verwendet, kann das Rollforward sinnvoll sein, da die vorhandene Infrastruktur aktualisiert wird. Umgekehrt kann ein Rollback oder Fallback sinnvoll sein, wenn Sie eine unveränderliche Infrastruktur verwenden.

Unabhängig davon, welche Entscheidungen Sie treffen, sollten Sie entsprechende Genehmigungen in Ihren Entscheidungsprozess einbeziehen und sie in Ihrer Entscheidungsstruktur kodifizieren.

Abhilfemaßnahmen

  • Rollback: In einem Rollbackszenario rückgängig machen Sie Die Systeme auf den Konfigurationszustand des letzten bekannten Zustands aktualisiert.

    Es ist wichtig, dass das gesamte Workloadteam sich über die Bedeutung des letzten bekannten Guts einig ist. Dieser Ausdruck bezieht sich auf den letzten Zustand der Workload, der vor Beginn der Bereitstellung fehlerfrei war, wobei es sich nicht unbedingt um die vorherige Anwendungsversion handelt.

    Das Rollback kann komplex sein, insbesondere im Zusammenhang mit Datenänderungen. Schemaänderungen können ein Rollback riskant machen. Die sichere Implementierung kann eine erhebliche Planung erfordern. Als allgemeine Empfehlung sollten Schemaupdates additiv sein. Sie sollten keine Ersatzänderungen sein– Datensätze sollten nicht durch neue Datensätze ersetzt werden. Stattdessen sollten ältere Datensätze veraltet sein und mit neuen Datensätzen gleichzeitig vorhanden sein, bis die veralteten Datensätze sicher entfernt werden können.

  • Fallback: In einem Fallbackszenario werden die aktualisierten Systeme aus dem Routing des Produktionsdatenverkehrs entfernt. Der gesamte Datenverkehr wird an den Stapel geleitet, der nicht aktualisiert wird. Diese Strategie mit geringem Risiko bietet Ihnen eine Möglichkeit, die Probleme in Ihrem Code zu beheben, ohne weitere Unterbrechungen zu führen.

    Bei Canary-Bereitstellungen ist ein Fallback je nach Infrastruktur und App-Design möglicherweise nicht einfach oder sogar möglich. Wenn Sie eine Skalierung durchführen müssen, um die Last von Systemen zu verarbeiten, die nicht aktualisiert werden, führen Sie diese Skalierung vor dem Fallback aus.

  • Umgehen der beleidigenden Funktion: Wenn Sie das Problem umgehen können, indem Sie Featureflags oder einen anderen Typ von Laufzeitkonfigurationseigenschaft verwenden, können Sie entscheiden, dass die Fortsetzung des Rollouts die richtige Strategie für ein bestimmtes Problem ist.

    Sie sollten den Kompromiss der Umgehung der Funktion klar verstehen, und Sie sollten in der Lage sein, diesen Kompromiss den Beteiligten mitzuteilen. Die Beteiligten sollten den Go-Forward-Plan genehmigen. Die Projektbeteiligten müssen die Dauer bestimmen, die für den Betrieb in einem heruntergestuften Zustand tolerierbar ist. Sie müssen diese Entscheidung auch mit Ihrer Schätzung der Zeit abwägen, die erforderlich ist, um den beleidigenden Code zu beheben und bereitzustellen.

  • Notfallbereitstellung (hot fix): Wenn Sie das Problem während des Rollouts beheben können, ist eine hot fix möglicherweise die praktischste Lösungsstrategie.

    Wie jeder andere Code müssen hot fixes Ihre sicheren Bereitstellungsmethoden durchlaufen. Aber mit einer heißen Lösung wird die Zeitleiste erheblich beschleunigt. Sie müssen in Ihren Umgebungen eine Code-Heraufstufungsstrategie verwenden. Sie müssen auch Hot Fix-Code an allen Qualitätsgates überprüfen. Möglicherweise müssen Sie jedoch die Backzeiten drastisch verkürzen, und Möglicherweise müssen Sie Tests ändern, um sie zu beschleunigen. Stellen Sie sicher, dass Sie nach der Bereitstellung so bald wie möglich vollständige Tests für den aktualisierten Code ausführen können. Eine hohe Automatisierung der Qualitätssicherungstests trägt dazu bei, das Testen in diesen Szenarien effizient zu gestalten.

Kompromisse:

  • Ein Fallback bedeutet in der Regel, dass Sie ausreichend Infrastrukturkapazität benötigen, um zwei Versionen Ihrer Workloadkonfiguration gleichzeitig verarbeiten zu können. Ihre Workloadteams müssen auch in der Lage sein, zwei Versionen gleichzeitig in der Produktion zu unterstützen.
  • Die Möglichkeit, ein effektives Rollback auszuführen, kann das Refactoring von Elementen Ihrer Workload umfassen. Beispielsweise müssen Sie Funktionen entkoppeln oder Ihr Datenmodell ändern.

Kommunikation

Es ist wichtig, klar definierte Kommunikationsaufgaben zu haben, um das Chaos bei Vorfällen zu minimieren. Diese Zuständigkeiten sollten festlegen, wie das Workloadteam mit Supportteams, Projektbeteiligten und Mitarbeitern des Notfalleinsatzteams wie dem Notfallreaktionsmanager zusammenarbeitet.

Standardisieren Sie den Rhythmus, den das Workloadteam für die Bereitstellung status Updates befolgt. Stellen Sie sicher, dass die Projektbeteiligten diesen Standard kennen, damit sie wissen, wann Updates zu erwarten sind.

Wenn das Workloadteam direkt mit Endbenutzern kommunizieren muss, klären Sie die Art der Informationen und den Detailgrad, die für die Freigabe mit Benutzern geeignet sind. Informieren Sie das Workloadteam auch über alle anderen Anforderungen, die für diese Fälle gelten.

Postmortem

Postmortems sollten ausnahmslos auf alle fehlgeschlagenen Bereitstellungen folgen. Jede fehlgeschlagene Bereitstellung ist eine Lernmöglichkeit. Postmortems können Ihnen helfen, Schwachstellen in Ihren Bereitstellungs- und Entwicklungsprozessen zu identifizieren. Unter vielen anderen Möglichkeiten können Sie auch Fehlkonfigurationen in Ihrer Infrastruktur feststellen.

Postmortems sollten immer schuldlos sein, damit sich Personen, die an dem Vorfall beteiligt sind, sicher fühlen, wenn sie ihre Sichtweisen darüber teilen, was verbessert werden kann. Postmortem-Führungskräfte sollten pläne für die Implementierung der identifizierten Verbesserungen nachverfolgen und diese Pläne zum Workloadbacklog hinzufügen.

Überlegungen und allgemeine Empfehlungen

Stellen Sie sicher, dass Ihre Bereitstellungspipeline unterschiedliche Versionen als Parameter akzeptieren kann, sodass Sie konfigurationen der letzten als bekannt gut bekannten Konfigurationen problemlos bereitstellen können.

Sorgen Sie beim Rollback oder Rollforward für die Konsistenz mit den Verwaltungs- und Datenebenen. Schlüssel, Geheimnisse, Datenbankstatusdaten und Konfigurationen, die spezifisch für Ressourcen und Richtlinien sind, müssen alle im Bereich liegen und berücksichtigt werden. Achten Sie beispielsweise auf den Entwurf ihrer Infrastrukturskalierung in Ihrer letzten als bekannt gut geeigneten Bereitstellung. Bestimmen Sie, ob Sie diese Konfiguration anpassen müssen, wenn Sie Ihren Code erneut bereitstellen.

Bevorzugen Sie kleine, häufige Änderungen gegenüber seltenen, großen Änderungen, damit das Delta zwischen Ihren neuen und letzten als bekannt bekannten Bereitstellungen klein ist.

Führen Sie eine Fehlermodusanalyse (FMA) für Ihre CI/CD-Pipelines (Continuous Integration und Continuous Delivery) durch, um Probleme zu identifizieren, die die Entschärfung erschweren können. Wie Ihre Workload als Ganzes können Ihre Pipelines analysiert werden, um Bereiche zu identifizieren, die beim Versuch eines bestimmten Entschärfungstyps problematisch sein können.

Verwenden Sie die automatisierte Rollbackfunktionalität mit Bedacht:

  • Einige CI/CD-Tools wie Azure DevOps verfügen über integrierte automatische Rollbackfunktionen. Erwägen Sie die Verwendung dieser Funktionalität, wenn sie Ihnen einen spürbaren Nutzen bietet.
  • Sie sollten automatische Rollbackfunktionen erst einführen, nachdem Sie Ihre Pipeline gründlich und regelmäßig getestet haben. Stellen Sie sicher, dass Ihre Pipeline so ausgereift ist, dass zusätzliche Probleme auftreten, wenn ein automatisches Rollback ausgelöst wird.
  • Sie müssen darauf vertrauen, dass die Automatisierung nur erforderliche Änderungen bereitstellt und nur bei Bedarf ausgelöst wird. Entwerfen Sie Ihre Trigger sorgfältig, um diese Anforderungen zu erfüllen.

Verwenden Sie plattformseitig bereitgestellte Funktionen während Rollbacks. Beispielsweise können Sicherungen und Zeitpunktwiederherstellungen bei Speicher- und Datenrollbacks hilfreich sein. Oder wenn Sie virtuelle Computer (VMs) zum Hosten Ihrer Anwendung verwenden, kann es hilfreich sein, Ihre Umgebung auf einem Prüfpunkt wiederherzustellen, der sich unmittelbar vor einem Incident befindet.

Testen Sie ihre gesamte Strategie zur Risikominderung von Bereitstellungsfehlern häufig. Wie Notfallpläne und Notfallwiederherstellungspläne ist Ihr Bereitstellungsfehlerplan nur erfolgreich, wenn Ihr Team darauf trainiert und regelmäßig praktiziert. Chaos engineering und Fault Injection Testing können effektive Techniken zum Testen Ihrer Bereitstellungsminderungsstrategie sein.

Kompromiss: Supportteammitglieder müssen in der Lage sein, ihre normalen Aufgaben zu erfüllen und auch Notfälle zu unterstützen. Möglicherweise müssen Sie die Anzahl der Mitarbeiter erhöhen, um sicherzustellen, dass das Supportteam ordnungsgemäß besetzt ist und alle erforderlichen Aufgaben ausführen kann. Testen Sie Bereitstellungen gründlich, wenn Sie in niedrigeren Entwicklungsumgebungen bereitstellen. Diese Vorgehensweise hilft Ihnen, Fehler und Fehlkonfigurationen zu erkennen, bevor sie in die Produktion gelangen.

Azure-Erleichterung

  • Azure Pipelines bietet Build- und Releasedienste zur Unterstützung von CI/CD Ihrer Anwendungen.

  • Azure Test Plans ist eine browserbasierte Testverwaltungslösung, die einfach zu bedienen ist. 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 Monitor ist eine umfassende Überwachungslösung zum Sammeln, Analysieren und Reagieren auf Überwachungsdaten aus Ihren Cloud- und lokalen Umgebungen. Der Monitor umfasst eine stabile Warnplattform. Sie können dieses System für automatische Benachrichtigungen und andere Aktionen konfigurieren, z. B. automatische Skalierung und andere Mechanismen zur Selbstreparatur.

  • Application Insights ist eine Erweiterung von Monitor, die Funktionen zur Anwendungsleistungsüberwachung (Application Performance Monitoring, APM) bereitstellt.

  • 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 eine Aktualisierung vorgenommen wird. Azure verwaltet einen Verlauf der Versionen und kann jede vorherige Version rückgängig machen oder höher stufen.

  • Viele Azure-Datenbankdienste bieten Funktionen zur Point-in-Time-Wiederherstellung, die Ihnen beim Ausführen eines Rollbacks helfen können:

  • Azure Chaos Studio (Vorschau) ist ein verwalteter Dienst, der Chaos-Engineering verwendet, um Sie beim Messen, Verstehen und Verbessern der Resilienz Ihrer Cloudanwendungen und Dienste zu unterstützen.

Checkliste "Operational Excellence"

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

Checkliste "Operational Excellence"