Empfehlungen für die Entwicklung einer Strategie zur Entschärfung von Bereitstellungsfehlern
Gilt für die Empfehlungen dieser Power Platform Well-Architected Operational Excellence-Checkliste
| OE:11 | Implementieren Sie eine Strategie zur Entschärfung von Bereitstellungsfehlern, die unerwartete Probleme während der Bereitstellung durch eine schnelle Wiederherstellung behebt. Kombinieren Sie mehrere Ansätze, etwa Rollback, Deaktivierung von Funktionen oder die Verwendung der nativen Funktionen Ihres Bereitstellungsmusters. |
|---|
In diesem Handbuch finden Sie die Empfehlungen zum Entwerfen einer standardisierten Strategie zum effektiven Umgang mit Bereitstellungsfehlern. Bereitstellungsfehler sind, wie andere Workload-Probleme auch, ein unvermeidlicher Teil des Lebenszyklus eines Workload. Mit dieser Einstellung können Sie proaktiv vorgehen, indem Sie eine gut durchdachte, gezielte Strategie zum Umgang mit Bereitstellungsfehlern entwickeln. Eine solche Strategie ermöglicht es Ihrem Workloadteam, Fehler effizient und mit möglichst geringen Auswirkungen auf Ihre Benutzenden einzudämmen.
Liegt ein solcher Plan nicht vor, kann es zu chaotischen und möglicherweise schädlichen Reaktionen auf Probleme kommen, die den Zusammenhalt des Teams und der Organisation, das Kundenvertrauen und die Finanzen erheblich beeinträchtigen können.
Wichtige Designstrategien
Trotz ausgereifter Entwicklungspraktiken kommt es gelegentlich zu Bereitstellungsproblemen. Mithilfe sicherer Bereitstellungspraktiken und einer robusten Workload-Lieferkette können Sie das Auftreten fehlgeschlagener Bereitstellungen minimieren. Sie müssen auch eine standardisierte Strategie entwickeln, um eventuell auftretende fehlgeschlagene Bereitstellungen zu beheben.
Eine Strategie zur Entschärfung von Bereitstellungsfehlern besteht aus fünf allgemeinen Phasen:
- Erkennung: Um auf eine fehlgeschlagene Bereitstellung zu reagieren, müssen Sie den Fehler zuerst erkennen. Die Erkennung kann verschiedene Formen annehmen, z. B. fehlgeschlagene Feuerproben, Meldungen durch Benutzende oder Warnungen, die Ihre Überwachungsplattform generiert.
- Entscheidung: Sie müssen entscheiden, welche Entschärfung für den jeweiligen Fehlertyp die beste ist.
- Risikominderung: Sie müssen die identifizierte Gegenmaßnahme durchführen. Die Entschärfung kann in Form eines Fallbacks, Rollbacks oder Rollforward erfolgen.
- Kommunikation: Stakeholder und betroffene Benutzer müssen über den Status informiert werden, wenn Sie das Problem erkennen und bearbeiten, wie es in Ihrem Notfallplan vorgeschrieben ist.
- Post-mortem: Post-mortem-Analysen ohne Schuldzuweisungen bieten dem Workload-Team die Möglichkeit, Bereiche mit Verbesserungspotenzial zu identifizieren und Pläne zur Umsetzung der Erkenntnisse zu erstellen.
Die folgenden Abschnitte enthalten detaillierte Empfehlungen zu diesen Phasen.
Erkennung
Um Probleme mit Bereitstellungen schnell zu identifizieren, benötigen Sie robuste Test- und Überwachungsabläufe, die auf Bereitstellungen eingehen. Um Anomalien schnell zu erkennen, können Sie die Überwachung und Warnungen Ihrer Workload durch ein Tool zur Verwaltung der Anwendungsleistung und die Protokollierung durch Instrumentierung ergänzen.
In jeder Phase der Einführung sollten Feuerproben und andere Qualitätstests durchgeführt werden. Die erfolgreichen Tests einer bestimmten Bereitstellungsgruppe sollte sich nicht auf Entscheidungen über das Testen in nachfolgenden Gruppen auswirken.
Sie können Telemetrie implementieren, die Benutzerprobleme mit einer Bereitstellungsphase korreliert. Dann können Sie schnell erkennen, zu welcher Einführungsgruppe ein bestimmter Benutzender gehört. Dieser Ansatz ist insbesondere bei schrittweisen Bereitstellungen wichtig, da zu jedem beliebigen Zeitpunkt der Bereitstellung für Ihre Benutzenden möglicherweise mehrere Konfigurationen ausgeführt werden.
Sie sollten bereit sein, sofort auf von Benutzenden gemeldete Probleme zu reagieren. Führen Sie Ihre Einführungsphase, wenn möglich, während der Arbeitszeiten durch, wenn Ihnen das gesamte Supportteam zur Verfügung steht. Stellen Sie sicher, dass die Supportmitarbeitenden darin geschult sind, wie Bereitstellungsprobleme eskaliert werden, damit sie an die richtige Stelle weitergeleitet werden. Eskalationen sollten auf Ihren Notfallreaktionsplan für die Workload abgestimmt sein.
Entscheidung
Bei der Entscheidung über die für ein Bereitstellungsproblem geeignete Entschärfungsstrategie müssen Faktoren wie die folgenden berücksichtigt werden:
Welche Art schrittweises Bereitstellungsmodell Sie verwenden. Sie könnten beispielsweise ein Blau-grün-Modell oder ein Canary-Modell verwenden. Wenn Sie ein Blau-Grün-Modell verwenden, ist ein Fallback praktischer als ein Rollback. Sie können den Datenverkehr problemlos zurück auf den Stapel verlagern, auf dem die nicht aktualisierte Konfiguration ausgeführt wird. Sie können das Problem dann 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. Dabei handelt es sich zum Beispiel um die Verwendung von Funktionskennzeichen, Umgebungsvariablen oder anderen Arten von Laufzeitkonfigurationseigenschaften, die Sie ein- und ausschalten können. Manchmal können Sie ein Problem einfach umgehen, indem Sie ein Funktionskennzeichen deaktivieren oder eine Einstellung umschalten. In diesem Fall können Sie vielleicht:
- Mit dem Rollout fortfahren.
- Ein Fallback vermeiden.
- Ein Rollback durchführen, während Sie den fehlerhaften Code korrigieren.
Der Aufwand, der erforderlich ist, um eine Korrektur im Code zu implementieren. Wenn der Aufwand für die Korrektur des Codes gering ist, ist ein Rollforward durch die Implementierung eines Hotfixes für bestimmte Szenarien die richtige Wahl.
Der Kritikalitätsgrad der betroffenen Workload. Um Bereitstellungen ohne Downtime durchführen zu können, sollten geschäftsentscheidende Workloads immer nebeneinander bereitgestellt werden, etwa wie in einem Blau-Grün-Modell. Deshalb ist für diese Art von Workloads der Fallback die bevorzugte Entschärfungsstrategie..
Entschärfung
Die folgenden sind einige der häufigsten Entschärfungsstrategien:
Rollback: In einem Rollback-Szenario setzen Sie aktualisierte Systeme auf den letzten als funktionierend bekannten Konfigurationszustand zurück.
Es ist wichtig, dass sich das gesamte Workloadteam über die Bedeutung des Begriffes der „letzten funktionierenden Konfiguration“ einig ist. Dieser Ausdruck bezieht sich auf den letzten Status der Workload, der vor Beginn der Bereitstellung fehlerfrei war. Dabei muss es sich nicht unbedingt um die vorherige Anwendungsversion handeln.
Das Zurücksetzen kann komplex sein, insbesondere im Hinblick auf Datenänderungen. Schemaänderungen können ein Rollback riskant machen. Ihre sichere Implementierung kann einen erheblichen Planungsaufwand mit sich bringen. Grundsätzlich empfiehlt sich, Schemaupdates additiv durchzuführen. Datensätze sollten nicht durch neue Datensätze ersetzt werden. Stattdessen sollten ältere Datensätze veralten und neben den neuen Datensätzen bestehen bleiben, bis es sicher ist, die veralteten Datensätze zu entfernen.
Fallback: In einem Fallback-Szenario werden die aktualisierten Systeme aus dem Routing des Datenverkehrs in der Produktion herausgenommen. Der gesamte Datenverkehr wird an den Stapel geleitet, der nicht aktualisiert wird. Mit dieser risikoarmen Strategie können Sie die Probleme in Ihrem Code beheben, ohne weitere Störungen zu verursachen.
Bei Canary-Bereitstellungen ist ein Fallback je nach Infrastruktur- und App-Design möglicherweise nicht so einfach oder sogar unmöglich. Wenn Sie eine Skalierung durchführen müssen, um die Last auf nicht aktualisierten Systemen zu bewältigen, führen Sie diese Skalierung vor dem Fallback durch.
Umgehen der fehlerhaften Funktion: Wenn Sie das Problem mithilfe von Funktions-Flags oder einer anderen Art von Laufzeitkonfigurationseigenschaft umgehen können, können Sie entscheiden, dass die Fortsetzung des Rollouts die richtige Strategie für ein Problem ist.
Sie müssen sich über die Nachteile im Klaren sein, die mit der Umgehung der Funktion verbunden sind, und Sie müssen den Stakeholdern diesen Kompromiss erklären können. Die Stakeholder sollten dem zukünftigen Plan zustimmen. Die Status müssen festlegen, wie lange der Betrieb in einem heruntergestuften Zustand toleriert werden kann. Sie müssen diese Feststellung auch gegen Ihrer Schätzung des Zeitaufwands abwägen, der zum Korrigieren und Bereitstellen des fehlerhaften Codes erforderlich ist.
Notfallbereitstellung (Hotfix): Wenn Sie das Problem während des Rollouts beheben können, ist ein Hotfix möglicherweise die praktischste Strategie zur Risikominderung.
Wie jeder andere Code müssen auch Hotfixe Ihre Abläufe für eine sichere Bereitstellung durchlaufen. Mit einem Hotfix geht es aber erheblich schneller. Sie müssen in Ihren gesamten Umgebungen eine Strategie für die Code-Heraufstufung verwenden. Sie müssen den Hotfix-Code auch allen Qualitätsprüfungen unterziehen. Möglicherweise müssen Sie die Bakingzeiten jedoch drastisch verkürzen und die Tests ändern, um sie zu beschleunigen. Stellen Sie sicher, dass Sie den aktualisierten Code möglichst bald nach der Bereitstellung vollständig testen können. Eine weitgehende Automatisierung der Qualitätssicherungstests trägt in diesen Szenarien zu einer effizienten Testdurchführung bei.
Kommunikation
Um das Chaos bei Vorfällen zu minimieren, ist es wichtig, die Verantwortlichkeiten für die Kommunikation klar festzulegen. Diese Verantwortlichkeiten sollten festlegen, wie das Workload-Team mit Supportteams, Stakeholdern und Mitgliedern des Notfallteams, beispielsweise der Leitung des Notfallteams, zusammenarbeitet.
Standardisieren Sie, in welchem Rhythmus das Workload-Team Statusaktualisierungen bereitstellt. Stellen Sie sicher, dass die Stakeholder diesen Standard kennen, damit sie wissen, wann sie mit Aktualisierungen rechnen können.
Wenn das Workloadteam direkt mit Benutzenden kommunizieren muss, klären Sie ab, welche Art Informationen und welcher Detailgrad weitergegeben werden dürfen. Teilen Sie dem Workload-Team auch alle weiteren Anforderungen mit, die für diese Fälle gelten.
Post-mortem-Analyse
Nach jeder fehlgeschlagenen Bereitstellung sollte ausnahmslos eine Post-mortem-Analyse durchgeführt werden. Jede fehlgeschlagene Bereitstellung ist eine Chance, zu lernen. Post-mortem-Analysen können Ihnen helfen, Schwachstellen in Ihren Bereitstellungs- und Entwicklungsprozessen sowie Fehlkonfigurationen in Ihrer Infrastruktur zu identifizieren.
Bei Post-mortem-Analysen sollte immer auf Schuldzuweisungen verzichtet werden, damit sich die am Vorfall beteiligten Personen nicht scheuen, ihre Ansichten zu Verbesserungsmöglichkeiten zu äußern. Post-mortem-Führungskräfte sollten Pläne für die Implementierung der identifizierten Verbesserungen und für das Hinzufügen dieser Pläne zum Workload-Backlog vorlegen.
Überlegungen und allgemeine Empfehlungen
Stellen Sie sicher, dass Ihre Bereitstellungspipeline unterschiedliche Versionen als Parameter akzeptieren kann, damit Sie die letzten als funktionierend bekannten Konfigurationen problemlos bereitstellen können.
Bewahren Sie beim Rollback oder Rollforward die Konsistenz mit den Verwaltungs- und Datenebenen. Schlüssel, Geheimnisse, Datenbankstatusdaten und Konfigurationen, die für Ressourcen und Richtlinien spezifisch sind, müssen alle im Umfang enthalten sein und berücksichtigt werden. Achten Sie beispielsweise auf die Gestaltung der Skalierung Ihrer Infrastruktur in Ihrer letzten als funktionierend bekannten Bereitstellung. Bestimmen Sie, ob Sie diese Konfiguration anpassen müssen, wenn Sie Ihren Code erneut bereitstellen.
Nehmen Sie eher kleine, häufige als seltene, umfangreiche Änderungen vor, damit der Unterschied zwischen Ihren neuen und den letzten als funktionierend bekannten Bereitstellungen gering ist.
Führen Sie eine Fehlermöglichkeitsanalyse Ihrer Continuous Integration und Continuous Delivery (CI/CD)-Pipelines durch, um Probleme zu identifizieren, welche die Entschärfung erschweren können. Sie können nicht nur Ihren Workload insgesamt, sondern auch Ihre Pipelines analysieren, um Bereiche zu identifizieren, die Probleme verursachen könnten, wenn Sie versuchen, eine bestimmte Art der Entschärfung einzusetzen.
Verwenden Sie die automatische Rollback-Funktionalität mit Bedacht:
- Einige CI/CD-Tools wie Azure DevOps haben eine integrierte automatische Rollback-Funktion. Ziehen Sie diese Funktion in Betracht, wenn sie für Sie einen konkreten Mehrwert bietet.
- Sie sollten die automatische Rollback-Funktion erst übernehmen, nachdem Sie Ihre Pipeline gründlich und regelmäßig getestet haben. Stellen Sie sicher, dass Ihre Pipeline ausgereift genug ist, sodass sie beim Auslösen eines automatischen Rollbacks keine zusätzlichen Probleme verursacht.
- Sie müssen darauf vertrauen können, dass die Automatisierung nur die notwendigen Änderungen vornimmt und nur bei Bedarf ausgelöst wird. Gestalten Sie Ihre Trigger sorgfältig, sodass sie diese Anforderungen erfüllen.
Verwenden Sie bei Rollbacks die von der Plattform bereitgestellten Funktionen. Sicherungen und Point-in-Time-Wiederherstellungen können beispielsweise bei Speicher- und Datenrollbacks hilfreich sein. Wenn Sie virtuelle Computer zum Hosten Ihrer Anwendung verwenden, kann es hilfreich sein, Ihre Umgebung auf einen Prüfpunkt von unmittelbar vor einem Vorfall wiederherzustellen.
Testen Sie Ihre gesamte Strategie zur Entschärfung von Bereitstellungsfehlern regelmäßig. Wie Notfallreaktionspläne und Pläne zur Notfallwiederherstellung ist auch Ihr Bereitstellungsfehlerplan nur dann erfolgreich, wenn Ihr Team darin geschult ist und ihn regelmäßig übt. Chaos Engineering und Fault-Injection-Tests können wirksame Techniken zum Testen Ihrer Entschärfungsstrategie bei der Bereitstellung sein.
Umsetzung in Power Platform
Pipelines in Power Platform zielen darauf ab, den Anwendungslebenszyklus (ALM) für Power Platform- und Dynamics 365-Kunden zu demokratisieren, indem ALM-Automatisierung sowie Continuous Integration- und Continuous Delivery-Funktionen (CI/CD) in den Dienst integriert werden.
Microsoft Power Platform Build Tools für Azure DevOps können verwendet werden, um allgemeine Build- und Bereitstellungsaufgaben in Verbindung mit auf Power Platform basierenden Apps zu automatisieren.
GitHub Actions für Power Platform ermöglichen es Entwicklern, Workflows für den automatisierten Softwareentwicklungs-Lebenszyklus zu erstellen. Mit GitHub-Aktionen für Microsoft Power Platform können Sie Workflows in Ihrem Repository erstellen, um Apps zu erstellen, zu testen, zu paketieren, freizugeben und bereitzustellen, Automatisierungen durchzuführen und Bots und andere Komponenten zu verwalten, die auf Microsoft Power Platform erstellt wurden.
ALM-Beschleuniger ist ein Open Source-Tool, das aus einer Reihe von Anwendungen, Skripten und Pipelines zur Automatisierung des kontinuierlichen Integrations-/Bereitstellungsprozesses besteht.
Tests mit Azure Pipelines automatisieren.
Verwenden Sie das Power CAT Copilot Studio Kit, um Agenten und Tests zu konfigurieren. Durch das Ausführen einzelner Tests für die Copilot Studio APIs (Direct Line), werden die Agent-Antworten anhand der erwarteten Ergebnisse ausgewertet.
Umgebungsvariablen in Lösungen speichern die Parameterschlüssel und -werte, die dann als Eingabe für verschiedene andere Anwendungsobjekte dienen. Durch Trennen der Parameter von den verwendenden Objekten können Sie die Werte in derselben Umgebung oder bei der Migration von Lösungen in andere Umgebungen ändern.
Power Platform-Umgebungen bieten eine Zeitpunktwiederherstellungsfunktion, die Ihnen beim Ausführen des Rollbacks helfen kann.
Power Platform ist Teil des Application Insights, einen Teil des Azure Monitor-Ökosystems. Verwenden Sie diese Integration für Folgendes:
Empfangen Sie Telemetriedaten zu Diagnose und Leistung, die von der Dataverse-Plattform in Application Insights erfasst werden. Sie können abonnieren, um Telemetriedaten zu Vorgängen zu erhalten, die Anwendungen in Ihrer Dataverse-Datenbank und in Modellgesteuerten Apps ausführen. Diese Telemetrie stellt Informationen bereit, mit denen Sie Probleme im Zusammenhang mit Fehlern und Leistung diagnostizieren und beheben können.
Verbinden Sie Ihre Canvas-Apps mit Application Insights. Mithilfe dieser Analysen können Sie Probleme diagnostizieren und verstehen, was Benutzer mit Ihren Apps machen. Sie können Informationen sammeln, um bessere Geschäftsentscheidungen zu treffen und die Qualität Ihrer Apps zu verbessern.
Konfigurieren Sie die Power Automate Telemetrie, die in die Application Insights einfließen sollen, z. B. um Cloud-Flow-Ausführungen zu überwachen und Warnungen für fehlgeschlagene Cloud-Flow-Ausführungen zu erstellen.
Erfassen Sie Telemetriedaten von Ihrem Microsoft Copilot Studio Agent für die Verwendung in Azure Application Insights. Sie können diese Telemetrie verwenden, um protokollierte Nachrichten und Ereignisse zu überwachen, die an und von Ihrem Agent gesendet werden, Themen, die während Benutzerunterhaltungen ausgelöst werden sollen, und benutzerdefinierte Telemetrieereignisse, die von Ihren Themen gesendet werden können.
Checkliste für betriebliche Exzellenz
Lesen Sie die vollständigen Empfehlungen.