Freigeben über

Empfehlungen für das Entwerfen einer Strategie zur Risikominderung von Bereitstellungsfehlern

  • Artikel

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

OE:12 Implementieren Sie eine Strategie zur Risikominderung von Bereitstellungsfehlern, die unerwartete Mid-Rollout-Probleme mit der schnellen Wiederherstellung behebt. Kombinieren Sie mehrere Ansätze, z. B. Rollback, Feature deaktivieren oder die systemeigenen Funktionen Ihres Bereitstellungsmusters verwenden.

In diesem Handbuch werden die Empfehlungen zum Entwerfen einer standardisierten Strategie beschrieben, um Bereitstellungsfehler effektiv zu behandeln. Wie andere Workloadprobleme sind Bereitstellungsfehler ein unvermeidlicher Teil eines Workload-Lebenszyklus. Mit dieser Denkweise können Sie proaktiv sein, indem Sie eine gut durchdachte, beabsichtigte Strategie für den Umgang mit Bereitstellungsfehlern haben. Eine solche Strategie ermöglicht Es Ihrem Workloadteam, Fehler mit möglichst geringen Auswirkungen auf Ihre Endbenutzer effizient abzumildern.

Das Fehlen eines solchen Plans kann zu chaotischen und potenziell schädlichen Reaktionen auf Probleme führen, die sich erheblich auf den Team- und organisationsweiten Zusammenhalt, das Kundenvertrauen und die Finanzen auswirken können.

Wichtige Entwurfsstrategien

Gelegentlich treten trotz der Reife Ihrer Entwicklungspraktiken Bereitstellungsprobleme auf. Die Verwendung sicherer Bereitstellungsmethoden und das Ausführen einer robusten Workload-Lieferkette kann Ihnen helfen, die Häufigkeit der fehlgeschlagenen Bereitstellungen zu minimieren. Sie müssen aber auch eine standardisierte Strategie entwerfen, um fehlgeschlagene Bereitstellungen zu behandeln, wenn sie auftreten.

Wenn Sie ein progressives Expositionsbereitstellungsmodell als Standardpraxis 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 Risikominderung 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 mehrere 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 spezifischen Fehlertyp am besten geeignet ist.

  3. Entschärfung: Sie führen die identifizierte Gegenmaßnahme aus. Die Entschärfung kann in Form eines Fallbacks, rollbacks, roll forward oder der Verwendung einer Laufzeitkonfiguration verwendet werden, um die problematische Funktion zu umgehen.

  4. Kommunikation: Interessengruppen und betroffene Endbenutzer müssen sich den Status bewusst gemacht werden, wenn Sie das Problem wie in Ihrem Notfallreaktionsplan erkennen und bearbeiten.

  5. Postmortem: Schuldlose Postmortems bieten dem Workload-Team Möglichkeiten, Bereiche zur Verbesserung zu identifizieren und Pläne für die Anwendung von Lernen zu erstellen.

In den folgenden Abschnitten finden Sie detaillierte Empfehlungen für diese Phasen. In diesen Abschnitten wird davon ausgegangen, dass Sie ein Problem erkennen, nachdem Sie Ihre Änderungen in einer oder mehreren Benutzergruppen oder Systemen bereitgestellt haben, aber bevor Sie alle Gruppen in Ihrem Rolloutplan aktualisieren.

Entwerfen von Fehlererkennungsmechanismen

Um Probleme mit Bereitstellungen schnell zu identifizieren, benötigen Sie robuste Test- und Observability-Praktiken , wenn sie sich auf Bereitstellungen beziehen. Um Anomalien schnell zu erkennen, können Sie ihre Workloadüberwachung und -warnung ergänzen, indem Sie die folgenden Schritte ausführen:

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

Rauchtests und andere Qualitätstests sollten in jeder Phase Ihres Rollouts erfolgen. Erfolgreiche Tests in einer Bereitstellungsgruppe sollten keine Entscheidungen beeinflussen, die in nachfolgenden Gruppen getestet werden sollen.

Sie können Telemetrie implementieren, die Benutzerprobleme mit einer Bereitstellungsphase korreliert. Anschließend können Sie schnell erkennen, mit welcher Rolloutgruppe ein bestimmter Benutzer verknüpft ist. Dieser Ansatz ist besonders wichtig für progressive Belichtungsbereitstellungen, da sie möglicherweise an einem bestimmten Punkt in der Bereitstellung über mehrere Konfigurationen hinweg auf Der Benutzerbasis ausgeführt werden.

Sie sollten bereit sein, sofort auf vom Benutzer gemeldete Probleme zu reagieren. Stellen Sie bei jeder praktischen Bereitstellungsphase während der Arbeitszeit ihre Rolloutphase bereit, wenn Sie ein vollständiges Supportteam zur Verfügung haben. Stellen Sie sicher, dass Supportmitarbeiter geschult werden, wie Bereitstellungsprobleme für ein ordnungsgemäßes Routing eskaliert werden. Eskalationen sollten mit Ihrem Workload-Notfallreaktionsplan übereinstimmen.

Entscheidung über die Risikominderungsstrategie

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

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

    Wenn Sie ein blaugrünes Modell verwenden, ist der Rückfall praktischer als ein Rollback. Sie können den Datenverkehr ganz einfach zurück in den Stapel verschieben, der die nicht aktualisierte Konfiguration ausführt. Anschließend können Sie das Problem in der problematischen Umgebung beheben und die Bereitstellung zu einem geeigneten Zeitpunkt erneut versuchen.

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

    Manchmal können Sie ein Problem einfach umgehen, indem Sie eine Featurekennzeichnung deaktivieren oder eine Einstellung umschalten. In diesem Fall können Sie folgende Aktionen ausführen:

    • Fahren Sie mit dem Rollout fort.
    • Vermeiden Sie einen Rückfall.
    • Führen Sie einen Rollback durch, während Sie den beleidigenden Code beheben.

  • Der Aufwand, der zum Implementieren eines Fixs im Code erforderlich ist.

    Wenn der Aufwand zum Beheben des Codes gering ist, ist die Einführung eines Hot Fixs die richtige Wahl für bestimmte Szenarien.

  • Der Grad der Kritischen Für die betroffene Workload.

    Geschäftskritische Workloads sollten immer nebeneinander bereitgestellt werden, z. B. in einem blaugrünen Modell, um Bereitstellungen ohne Ausfallzeiten zu erzielen. Ein Rückfall ist daher die bevorzugte Entschärfungsstrategie für diese Arten von Workloads.

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

    Wenn Ihre Workload für die Verwendung einer veränderbaren Infrastruktur konzipiert ist, kann ein Roll forward sinnvoll sein, da dies die Aktualisierung der Infrastruktur erfordert. Umgekehrt kann ein Rollback oder Rückfall sinnvoll sein, wenn Sie unveränderliche Infrastruktur verwenden.

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

Implementieren der Entschärfungsstrategie

  • Rollback: In einem Rollbackszenario stellen Sie aktualisierte Systeme auf den zuletzt bekannten Konfigurationszustand zurück.

    Es ist wichtig, dass sich das gesamte Workloadteam über die Bedeutung des letzten bekannten Guten einig ist. Dieser Ausdruck bezieht sich auf den letzten Zustand der Arbeitsauslastung, die vor Beginn der Bereitstellung fehlerfrei war, was nicht unbedingt die vorherige Anwendungsversion ist.

    Ein Rollback kann komplex sein, insbesondere im Zusammenhang mit Datenänderungen. Schemaänderungen können ein Rollback riskant vornehmen. Die sichere Implementierung kann eine erhebliche Planung erfordern. Als allgemeine Empfehlung sollten Schemaaktualisierungen additiv sein. Sie sollten keine Ersetzungsänderungen sein – Datensätze sollten nicht durch neue Datensätze ersetzt werden. Stattdessen sollten ältere Datensätze veraltet sein und mit neuen Datensätzen koexistieren, bis sie sicher sind, die veralteten Datensätze zu entfernen.

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

    Bei Canarybereitstellungen ist der Rückfall je nach Infrastruktur und App-Design möglicherweise nicht einfach oder sogar möglich. Wenn Sie die Skalierung durchführen müssen, um die Last auf nicht aktualisierten Systemen zu verarbeiten, führen Sie diese Skalierung aus, bevor Sie zurückfallen.

  • Umgehen Sie die problematische Funktion: Wenn Sie das Problem umgehen können, indem Sie Featurekennzeichen oder eine andere Art von Laufzeitkonfigurationseigenschaft verwenden, können Sie entscheiden, dass das Fortsetzen 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 mit den Beteiligten zu kommunizieren. Die Projektbeteiligten sollten den Go-Forward-Plan genehmigen. Die Projektbeteiligten müssen die Dauer bestimmen, die für den Betrieb in einem beeinträchtigten Zustand tolerierbar ist. Sie müssen diese Bestimmung auch gegen Ihre Schätzung der Zeit abwägen, die erforderlich ist, um den beleidigenden Code zu beheben und bereitzustellen.

  • Notfallbereitstellung (Hot Fix): Wenn Sie das Problem mitte des Rollouts beheben können, ist ein Hot Fix möglicherweise die praktischste Entschärfungsstrategie.

    Wie bei jedem anderen Code müssen Hot Fixes Ihre sicheren Bereitstellungspraktiken durchlaufen. Aber mit einem heißen Fix wird die Zeitachse erheblich beschleunigt. Sie müssen eine Code-Heraufstufungsstrategie in allen Umgebungen verwenden. Sie müssen auch hot fix code at all quality gates überprüfen. Vielleicht müssen Sie aber die Backzeiten erheblich verkürzen, und Sie müssen tests ändern, um sie zu beschleunigen. Stellen Sie sicher, dass Sie nach der Bereitstellung möglichst bald vollständige Tests für den aktualisierten Code ausführen können. Durch die Automatisierung von Qualitätssicherungstests in hohem Maße können Tests in diesen Szenarien effizient getestet werden.

Tradeoffs:

  • Wenn Sie in der Regel zurückfallen können, benötigen Sie ausreichend Infrastrukturkapazität, um zwei Versionen Ihrer Workloadkonfiguration gleichzeitig zu verarbeiten. Ihre Workloadteams müssen auch in der Lage sein, zwei Versionen in der Produktion gleichzeitig zu unterstützen.
  • Ein effektives Rollback kann eine Umgestaltung von Elementen Ihrer Workload umfassen. Beispielsweise müssen Sie Funktionen entkoppeln oder das Datenmodell ändern.

Standardisieren von Statusupdates während eines Vorfalls

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

Standardisieren Sie die Häufigkeit, nach der das Workloadteam folgt, um Statusupdates bereitzustellen. Stellen Sie sicher, dass die Projektbeteiligten diesen Standard kennen, damit sie wissen, wann Updates erwartet werden.

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

Durchführen von Vorfällen nachmortems

Postmortems sollten alle fehlgeschlagenen Bereitstellungen ohne Ausnahme befolgen. Jede fehlgeschlagene Bereitstellung ist eine Möglichkeit zum Lernen. Postmortems können Ihnen helfen, Schwachstellen in Ihren Bereitstellungs- und Entwicklungsprozessen zu identifizieren. Sie können auch Fehlkonfigurationen in Ihrer Infrastruktur identifizieren, unter anderem.

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

Operationalisieren von Entschärfungsprozessen

Stellen Sie sicher, dass Ihre Bereitstellungspipeline unterschiedliche Versionen als Parameter akzeptieren kann, damit Sie zuletzt bekannte Konfigurationen problemlos bereitstellen können.

Behalten Sie die Konsistenz mit den Verwaltungs- und Datenebenen bei, während Sie einen Rollback oder einen Roll forward ausführen. Schlüssel, geheime Schlüssel, Datenbankstatusdaten und Konfigurationen, die für Ressourcen und Richtlinien spezifisch sind, müssen sich im Umfang befinden und berücksichtigt werden. Achten Sie beispielsweise auf den Entwurf der Infrastrukturskalierung in Ihrer letzten bekannten Bereitstellung. Ermitteln Sie, ob Sie diese Konfiguration anpassen müssen, wenn Sie Den Code erneut bereitstellen.

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

Führen Sie eine Fehlermodusanalyse (Failure Mode Analysis, FMA) für Ihre pipelines für kontinuierliche Integration und kontinuierliche Übermittlung (CI/CD) durch, um Probleme zu identifizieren, die Entschärfungen 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önnten.

Verwenden Sie automatisierte Rollbackfunktionen sorgfältig:

  • Einige CI/CD-Tools wie Azure DevOps verfügen über automatische Rollbackfunktionen, die integriert sind. Erwägen Sie die Verwendung dieser Funktionalität, wenn sie Für Sie greifbare Vorteile bietet.
  • Sie sollten automatische Rollbackfunktionen erst übernehmen, nachdem Sie Ihre Pipeline gründlich und regelmäßig getestet haben. Stellen Sie sicher, dass Ihre Pipeline reif genug ist, um zusätzliche Probleme einzuführen, wenn ein automatisches Rollback ausgelöst wird.
  • Sie müssen 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 die von der Plattform bereitgestellten Funktionen während rollbacks. Sicherungen und Point-in-Time-Wiederherstellungen können beispielsweise bei Speicher- und Datenrollbacks helfen. Oder wenn Sie virtuelle Computer (VMs) zum Hosten Ihrer Anwendung verwenden, kann es hilfreich sein, Ihre Umgebung auf einen Prüfpunkt wiederherzustellen, der unmittelbar vor einem Vorfall liegt.

Testen Sie ihre gesamte Strategie zur Risikominderung bei Bereitstellungsfehlern häufig. Wie Notfallreaktionspläne und Notfallwiederherstellungspläne ist Ihr Bereitstellungsfehlerplan nur erfolgreich, wenn Ihr Team regelmäßig darauf trainiert wird. Chaos engineering and fault injection testing can be effective techniques for testing your deployment mitigation strategy.

Kompromiss: Supportteammitglieder müssen in der Lage sein, ihre normalen Aufgaben auszuführen 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 sie in niedrigeren Entwicklungsumgebungen bereitstellen. Mit dieser Übung können Sie Fehler und Fehlkonfigurationen erkennen, bevor sie zur 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 verwenden 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 Ihrer Cloud und lokalen Umgebungen. Monitor umfasst eine robuste Warnplattform. Sie können dieses System für automatische Benachrichtigungen und andere Aktionen konfigurieren, z. B. automatische Skalierung und andere Selbstheilungsmechanismen.

  • Application Insights ist eine Erweiterung von Monitor, die APM-Features (Application Performance Monitoring) 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 ein Update vorgenommen wird. Azure verwaltet einen Verlauf der Versionen und kann jede vorherige Version wiederherstellen oder höher stufen.

  • Viele Azure-Datenbankdienste bieten Punkt-in-Time-Wiederherstellungsfunktionen, die Ihnen helfen können, wenn Sie ein Rollback durchführen müssen:

  • 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 für operative Exzellenz

Lesen Sie den vollständigen Satz von Empfehlungen.

Checkliste für operative Exzellenz