Empfehlungen für sichere Bereitstellungsmethoden
Gilt für diese Checkliste für azure Well-Architected Framework Operational Excellence:
OE:11 | Definieren Sie klar und deutlich die Praktiken für die sichere Bereitstellung Ihrer Workload. Betonen Sie die Idealen kleiner, inkrementeller, qualitätsorientierter Freigabemethoden. Verwenden Sie moderne Bereitstellungsmuster und progressive Expositionstechniken, um Risiken zu steuern. Berücksichtigen Sie Routinebereitstellungen und Notfallbereitstellungen oder Hotfixbereitstellungen. |
---|
In diesem Leitfaden werden die Empfehlungen für die Verwendung sicherer Bereitstellungsmethoden (Safe Deployment Practices, SDP) beschrieben. Sichere Bereitstellungsprozesse und -verfahren definieren, wie Sie Änderungen an Ihrer Workload sicher vornehmen und bereitstellen können. Die Implementierung von SDP erfordert, dass Sie über Bereitstellungen über das Ziel der Risikoverwaltung nachdenken. Sie können das Risiko von menschlichem Fehler in Ihren Bereitstellungen minimieren und die Auswirkungen problematischer Bereitstellungen auf Ihre Benutzer einschränken, indem Sie SDP implementieren.
Wichtige Entwurfsstrategien
Es gibt vier wichtige Richtlinien, die Sie bei der Implementierung sicherer Bereitstellungspraktiken beachten sollten:
Sicherheit und Konsistenz: Alle Änderungen an der Produktionsauslastung sind inhärent riskant und müssen mit einem Schwerpunkt auf Sicherheit und Konsistenz erfolgen.
Progressive Exposition: Sie können den potenziellen Strahlradius der bereitstellungsbedingten Probleme minimieren, indem Sie ein progressives Expositionsbereitstellungsmodell einführen.
Integritätsmodelle: Bereitstellungen müssen Integritätsprüfungen bestehen, bevor jede Phase der progressiven Exposition beginnen kann.
Problemerkennung: Wenn Probleme erkannt werden, sollte die Bereitstellung sofort angehalten und die Wiederherstellung initiiert werden.
In den folgenden Abschnitten finden Sie detaillierte Empfehlungen zu den einzelnen Punkten.
Sicherstellen der Sicherheit und Konsistenz von Bereitstellungen
Unabhängig davon, ob Sie ein Update für Ihren Anwendungscode, Infrastructure as Code (IaC), ein Feature Flag oder ein Konfigurationsupdate bereitstellen, besteht ein Risiko für Ihre Workload. Es gibt keine Bereitstellungen mit geringem Risiko für die Produktion. Jede Bereitstellung muss einem Standardmuster folgen und sollte automatisiert werden, um Konsistenz zu erzwingen und das Risiko menschlicher Fehler zu minimieren. Es ist wichtig, dass Ihre Workload-Supply Chain- und Bereitstellungspipeline zuverlässig, sicher und klar definierte Bereitstellungsstandards aufweisen. Behandeln Sie jede Bereitstellung als mögliches Risiko und unterliegt jeder Bereitstellung dem gleichen Risikomanagementniveau. Trotz der Risiken sollten Sie weiterhin regelmäßige Änderungen an Ihrer Workload bereitstellen. Wenn sie regelmäßige Updates nicht bereitstellen, werden andere Risiken wie Sicherheitsrisiken eingeführt, die über Bereitstellungen behoben werden müssen. Weitere Informationen finden Sie unter Empfehlungen für das Entwerfen einer Workload-Entwicklungs-Lieferkette.
Häufige kleine Bereitstellungen sind seltenen großen Bereitstellungen vorzuziehen. Kleine Änderungen sind einfacher zu beheben, wenn Probleme auftreten, und häufige Bereitstellungen helfen Ihrem Team, Vertrauen in den Bereitstellungsprozess zu schaffen. Es ist auch wichtig, dass Sie von der Produktion lernen, indem Sie Ihre Workloadprozesse überprüfen, wenn während der Bereitstellung eine Anomalie auftritt. Möglicherweise finden Sie Schwachstellen im Entwurf Ihrer Infrastruktur oder Ihres Rollouts. Wenn Probleme während der Bereitstellung auftreten, stellen Sie sicher, dass schuldlose Postmortems Teil Ihres SDP-Prozesses sind, um Lektionen über den Vorfall zu erfassen.
Übernehmen eines progressiven Belichtungsmodells
Wenn Probleme bei der Bereitstellung auftreten, ist es das Ziel, diese so früh wie möglich zu erkennen, um die Auswirkungen auf die Endbenutzer*innen zu minimieren. Implementieren Sie ein schrittweises Bereitstellungsmodell, das auch als progressives Expositionsmodell bezeichnet wird, um dieses Ziel zu erreichen. Canary-Bereitstellungen sind ein gängiges Beispiel für die progressive Exposition. In diesem Bereitstellungsmodell erhalten zunächst eine kleine Gruppe interner oder externer Benutzer das neue Feature. Nachdem die erste Gruppe die neue Version ohne Problem ausgeführt hat, wird das Feature für nacheinander größere Gruppen bereitgestellt, bis die gesamte Benutzerpopulation die neue Version ausführt. Featurekennzeichnungen werden in der Regel verwendet, um die neue Version für die Zielbenutzer in Canarybereitstellungen zu aktivieren.
Ein weiteres gängiges Bereitstellungsmodell ist ein blaugrüner Ansatz. In diesem Modell werden zwei identische Gruppen oder Pools der Workloadinfrastruktur bereitgestellt. Beide Pools können eine vollständige Produktionslast verarbeiten. Der erste (blaue) Pool führt die aktuelle Version der Bereitstellung aus, in der alle Benutzer landen. Der zweite (grüne) Pool wird mit dem neuen Feature aktualisiert und intern getestet. Nach internen Tests wird eine Teilmenge des Produktionsdatenverkehrs vom blauen Pool zum grünen Pool weitergeleitet. Wie canarybereitstellungen ist das Rollout progressiver, wenn Sie mehr Datenverkehr in aufeinander folgenden größeren Rolloutwellen in den grünen Pool verschieben. Nachdem Sie das Rollout abgeschlossen haben, wird der Updatepool zum blauen Pool, und der grüne Pool ist für die nächste Bereitstellung bereit. Die beiden Pools werden logisch voneinander getrennt, um vor Fehlfunktionen zu schützen. Sie können eine Variante des blaugrünen Modells in einer Workload bereitstellen, die das Entwurfsmuster für Bereitstellungsstempel verwendet, indem Sie jeweils einen Stempel bereitstellen.
In beiden Modellen sollte die Zeit zwischen jeder Phase des Rollouts lang genug sein, damit Sie die Integritätsmetriken der Workload überwachen können. Sie sollten ausreichend Backzeit, Zeit zwischen Rolloutgruppen bereitstellen, um sicherzustellen, dass Benutzer aus verschiedenen Regionen oder Benutzern, die unterschiedliche Aufgaben ausführen, Zeit haben, die Arbeitsauslastung in ihrer normalen Kapazität zu verwenden. Backzeiten sollten in Stunden und Tagen und nicht in Minuten gemessen werden. Backzeiten sollten auch für jede Rolloutgruppe erhöht werden, damit Sie im Laufe des Tages unterschiedliche Zeitzonen und Nutzungsmuster berücksichtigen können.
Entwickeln robuster Arbeitsauslastungsintegritätsmodelle
Entwickeln Sie ein robustes Gesundheitsmodell als Teil Ihrer Observability-Plattform und Zuverlässigkeitsstrategien. Ihr Integritätsmodell sollte detaillierte Einblicke in die Komponenten und die allgemeine Integrität der Workload bieten. Wenn Sie während eines Rollouts eine Warnung über eine Änderung des Integritätszustands eines Endbenutzers bzw. einer Endbenutzerin erhalten, sollte der Rollout sofort gestoppt und die Ursache der Warnung untersucht werden, um das weitere Vorgehen zu bestimmen. Wenn von Endbenutzern keine Probleme gemeldet werden und alle Integritätsindikatoren während der Backzeit grün bleiben, sollte der Rollout fortgesetzt werden. Achten Sie darauf, Die Nutzungsmetriken in Ihr Integritätsmodell einzuschließen, um sicherzustellen, dass ein Mangel an vom Benutzer gemeldeten Problemen und negativen Gesundheitssignalen kein Problem ausblenden. Weitere Informationen finden Sie unter Erstellen eines Integritätsmodells.
Implementieren von Mechanismen zur Fehlererkennung
Wenn Ihre Bereitstellung ein Problem in einer der Rolloutgruppen verursacht, muss das Rollout sofort beendet werden. Eine Untersuchung der Ursache des Problems und des Schweregrads der Auswirkungen muss durchgeführt werden, sobald die Warnung empfangen wird. Die Wiederherstellung aus dem Problem kann Folgendes umfassen:
Rollback der Bereitstellung durch Rückgängigmachen der in der Bereitstellung vorgenommenen Änderungen und Zurücksetzen auf die letzte bekannte Arbeitskonfiguration.
Die Bereitstellung wird vorangebracht , indem das Problem inmitten des Rollouts behoben wird. Sie können Probleme in der Mitte des Rollouts beheben, indem Sie einen Hotfix anwenden oder das Problem anderweitig minimieren.
Bereitstellen einer neuen Infrastruktur mithilfe der letzten bekannten Arbeitskonfiguration.
Ein Rollback von Änderungen, insbesondere Datenbank-, Schema- oder andere zustandsbehaftete Komponentenänderungen, kann komplex sein. Ihre SDP-Richtlinien sollten klare Anweisungen zum Umgang mit Datenänderungen gemäß dem Datenbestandsentwurf für Ihre Workload bereitstellen. Ebenso muss der Roll forward sorgfältig behandelt werden, um sicherzustellen, dass SDP nicht vernachlässigt wird und dass der Hotfix oder andere Minimierungsmaßnahmen sicher durchgeführt werden.
Einrichten von Protokollen für Notfallbereitstellungen
Implementieren Sie die Versionsverwaltung in Ihren Buildartefakten, um sicherzustellen, dass Sie bei Bedarf einen Rollback und einen Roll forward durchführen können.
Verwenden Sie einen Releasefluss oder eine trunkbasierte Verzweigungsstruktur, die eine eng synchronisierte Zusammenarbeit im Entwicklungsteam anstelle einer Gitflow- oder umgebungsbasierten Verzweigungsstruktur erzwingt.
Automatisieren Sie so viel Ihrer SDP wie möglich. Ausführliche Anleitungen zur Automatisierung von IaC- und Anwendungs-kontinuierlichen Integrations- und Kontinuierlichbereitstellungsprozessen (CI/CD) finden Sie in den Empfehlungen für die Implementierung der Automatisierung.
Verwenden Sie CI-Methoden, um Codeänderungen regelmäßig in Repositorys zu integrieren. CI-Methoden können Ihnen helfen, Integrationskonflikte zu erkennen und die Wahrscheinlichkeit von großen, riskanten Zusammenführungen zu verringern. Weitere Informationen finden Sie im Leitfaden zur kontinuierlichen Integration.
Verwenden Sie Featurekennzeichnungen, um neue Features oder Änderungen in der Produktion selektiv zu aktivieren oder zu deaktivieren. Featurekennzeichnungen können Ihnen helfen, die Belichtung von neuem Code zu steuern und die Bereitstellung bei Auftreten von Problemen schnell zurück zu setzen.
Stellen Sie Änderungen an Stagingumgebungen bereit, die Ihre Produktionsumgebung spiegeln. In Übungsumgebungen können Sie Änderungen in einer kontrollierten Einstellung testen, bevor Sie sie in der Liveumgebung bereitstellen.
Richten Sie Vorabbereitstellungsprüfungen ein, einschließlich Codeüberprüfungen, Sicherheitsüberprüfungen und Complianceprüfungen, um sicherzustellen, dass Änderungen sicher bereitgestellt werden können.
Implementieren Sie Schaltkreisbrecher, um den Datenverkehr automatisch an einen Dienst zu stoppen, der Probleme hat. Dies kann dazu beitragen, eine weitere Verschlechterung des Systems zu verhindern.
Notfall-SDP-Protokolle
Richten Sie präscriptive Protokolle ein, die definieren, wie Ihre SDP für einen Hotfix oder für Notfallprobleme wie Sicherheitsverletzungen oder Sicherheitsrisiken angepasst werden kann. Ihre Notfall-SDP-Protokolle können z. B. Folgendes umfassen:
Beschleunigung der Herauf- und Genehmigungsphase.
Rauchtests und Integrationstestbeschleunigung.
Backzeitreduktion.
In einigen Fällen kann der Notfall Qualität und Testtore einschränken, aber Tore sollten so schnell wie möglich wie eine Out-of-Band-Übung ausgeführt werden. Stellen Sie sicher, dass Sie definieren, wer die SDP-Beschleunigung in einem Notfall genehmigen kann, und die Kriterien, die erfüllt sein müssen, damit die Beschleunigung genehmigt werden kann. Richten Sie Ihre Notfall-SDP-Protokolle mit Ihrem Notfallreaktionsplan aus, um sicherzustellen, dass alle Notfälle gemäß denselben Protokollen behandelt werden.
Überlegungen
Das Erstellen und Verwalten sicherer Bereitstellungsmethoden ist komplex. Ihr Erfolg bei der vollständigen Implementierung robuster Standards hängt von der Reife Ihrer Praktiken in vielen Bereichen der Softwareentwicklung ab. Verwendung von Automatisierung, IaC-only für Infrastrukturänderungen, Konsistenz bei Verzweigungsstrategien, Verwendung von Featurekennzeichnungen und viele andere Methoden können helfen, eine sichere Bereitstellung zu gewährleisten. Verwenden Sie diesen Leitfaden, um Ihre Arbeitsauslastung zu optimieren und Ihre Verbesserungspläne zu informieren, wenn Sich Ihre Praktiken entwickeln.
Umsetzung in Azure
Azure-Pipelines und GitHub-Aktionen unterstützen mehrstufige Bereitstellungen mithilfe von Genehmigungsgaten, die Ihnen helfen können, Ihr progressives Expositionsrollout für Bereitstellungen zu entwerfen.
Verwenden Sie Azure-App Dienst-Staging-Slots, um problemlos zwischen Codeversionen auszutauschen. Stagingplätze sind hilfreich für Tests in Stagingumgebungen und können für blaugrüne Bereitstellungen verwendet werden.
Speichern und verwalten Sie Ihre Web App-Featurekennzeichnungen in Azure-App-Konfiguration. Mithilfe dieses Diensts können Sie Features in einer einheitlichen Verwaltungsebene erstellen, ändern und bereitstellen.
Bereitstellen von Workloadanwendungen auf Ihrem virtuellen Computer mithilfe von VM-Anwendungen.
Verwenden Sie Azure-Lastenausgleichsgeräte , um Bereitstellungsstrategien zu implementieren und die Integrität Ihrer Workloadanwendungen mithilfe systemeigener Ressourcen verfügbar zu machen.
Verwenden Sie die Anwendungsintegritätserweiterung , um den Anwendungsstatus innerhalb einer VM-Skalierungssatzinstanz zu melden. Die Erweiterung testet auf einem lokalen Anwendungsendpunkt und aktualisiert den Integritätsstatus basierend auf TCP-/HTTP(S)-Antworten, die von der Anwendung empfangen werden.
Verwenden Sie Azure Logic Apps , um eine neue Version der Anwendung zu erstellen, wenn ein Update vorgenommen wird. Azure verwaltet einen Verlauf von Anwendungsversionen und kann auf jede frühere Version zurück- oder heraufstufen.
Viele Azure-Datenbankdienste bieten Point-in-Time-Wiederherstellungsfunktionen, die Ihnen helfen können, ein Rollback auszuführen. Zu den Diensten, die die Point-in-Time-Wiederherstellung unterstützen, gehören:
Beispiel
Ein Beispiel für die Verwendung dieses Bereitstellungsmodells finden Sie in der blaugrünen Bereitstellung von Azure Kubernetes Service (AKS)-Clustern .
Verwandte Links
- Anwendungsintegritätserweiterung
- Azure App Configuration
- Azure-App Service-Staging-Slots
- Azure Cosmos DB
- Azure Database for MySQL
- Azure-Datenbank für PostgreSQL
- Azure-Lastenausgleichsgeräte
- Azure Logic Apps
- Azure Pipelines
- Azure SQL-Datenbank
- Verwaltete Azure SQL-Datenbank-Instanz
- Erstellen eines Integritätsmodells
- Leitfaden zur kontinuierlichen Integration
- Bereitstellungsstempel
- Leistungsüberlegungen für Ihre Bereitstellungsinfrastruktur
- Release engineering: Anwendungsentwicklung
- Release Engineering: Kontinuierliche Integration
- Release engineering: Rollback
- Testen Ihrer Anwendung und Azure-Umgebung
- VM-Anwendungen
Communitylinks
Checkliste für operative Exzellenz
Lesen Sie den vollständigen Satz von Empfehlungen.