Planen der cloudeigenen Lösungen

Eine cloud-native Lösung schafft neuen Geschäftswert, indem neue Workloads (Anwendungen) entwickelt oder vorhandene Workloads um neue Features erweitert werden. Ganz gleich, ob Sie eine brandneue Anwendung entwickeln oder einem vorhandenen System neue Features hinzufügen, cloudeigene Entwicklung ist eine Reise durch Planung, Erstellung, Bereitstellung und Optimierung Ihrer Workloads. Dieses Framework bietet eine vollständige Anleitung, um sicherzustellen, dass Ihre Cloud-native-Anwendung mit den Geschäftszielen übereinstimmt, gut konzipiert ist und mit minimalem Risiko ausgeliefert wird.

Voraussetzungen:Azure-Zielzone

Auf der linken Seite werden drei beschriftete Felder, Startups, Unternehmen und vorhandene Arbeitslasten unter der Überschrift "Neuen Geschäftswert erstellen" gruppiert. Pfeile führen von diesen Feldern zu einer vertikalen Abfolge von vier Schritten: 1 Cloud-nativ planen, 2 Cloud-nativ entwickeln, 3 Cloud-nativ bereitstellen und 4 Cloud-nativ optimieren. Ein abschließender Pfeil verweist auf Azure, wo "Cloud-native Apps, Workloads und Features" zu finden sind.

Definieren von Geschäftszielen für cloudeigene Lösungen

1. Beginnen Sie mit klaren Geschäftszielen. Definieren Sie die spezifischen Ergebnisse, die Ihre cloudeigene Lösung erzielen sollte, z. B. das Aktivieren eines neuen digitalen Produkts, das Betreten eines neuen Marktes, die Verbesserung der Kundenerfahrung oder die Reduzierung der Betriebskosten. Verwenden Sie messbare Indikatoren wie Umsatzwachstum, Zeit-zu-Markt-Reduzierung oder Supportticketvolumen, um den Erfolg zu quantifizieren. Definieren Sie für neue Features Ziele, z. B. die Verbesserung der Kundenerfahrung, die Reduzierung der Betriebskosten oder die Erhöhung der Systemskalierbarkeit.

2. Identifizieren sie Einschränkungen und Erfolgskriterien. Dokumentieren Sie Geschäftseinschränkungen wie Budget, Compliance oder Lieferfristen. Definieren Sie, wie der Erfolg für jedes Ziel aussieht. Beispiel: "Starten Eines neuen Kundenportals nach Q4" oder "Reduzieren der Auschecklatenz um 40%" Diese Kriterien leiten die Priorisierung und helfen bei der Bewertung von Kompromissen während der Planung.

3. Überprüfen sie die Ausrichtung der Projektbeteiligten. Bestätigen Sie, dass alle Projektbeteiligten (geschäftliche und technische) den Zielen, Rahmenbedingungen und Erfolgskriterien zustimmen. Diese Ausrichtung kann Workshops oder formale Abmeldung umfassen. Eine frühzeitige Ausrichtung verhindert spätere Fehlkommunikation und vermeidet kostspielige Überarbeitungen, um sicherzustellen, dass alle die gleichen Erwartungen von Anfang an teilen.

Definieren von Anforderungen für cloudeigene Lösungen

1. Dokumentieren Sie funktionale Anforderungen. Dokumentieren Sie die Funktionen und Features, die das System bereitstellen muss, um den Benutzeranforderungen gerecht zu werden. Jede Anforderung sollte mit einem Geschäftsziel in Verbindung stehen, um sicherzustellen, dass der Entwicklungsaufwand die gewünschten Ergebnisse direkt unterstützt. Verwenden Sie Stakeholder-Interviews und Geschäftsstrategiedokumente, um hochwertige Ergebnisse zu identifizieren. Priorisieren Sie Features basierend auf dem Geschäftlichen Wert und der technischen Machbarkeit. Verfolgen Sie jede Anforderung auf ein messbares Geschäftsziel, um ihre Einbeziehung zu rechtfertigen.

2. Bestimmen Sie nichtfunktionale Anforderungen. Nicht funktionsfähige Anforderungen definieren technische Anforderungen, um funktionale Anforderungen und Governance zu erfüllen. Legen Sie die Qualitätsattribute und technischen Ziele fest, die für die Unterstützung dieser Features erforderlich sind. Definieren Sie Zielsicherheitsmetriken wie Ziele auf Dienstebene (SLOs) für Betriebszeit, Wiederherstellungspunktziele (RPOs) und Wiederherstellungszeitziele (Recovery Time Objectives, RTOs). Richten Sie einen Sicherheitsgrundwert ein. Kostenmodell erstellen. Legen Sie Leistungsziele fest.

3. Steuern Sie cloud-native Lösungen. Definieren Sie eindeutig, was im Bereich und außerhalb des Gültigkeitsbereichs für die erste Version ist. Es ist verlockend, mehr "Nice-to-have"-Funktionen einzubeziehen, aber Umfangserweiterung kann Zeitpläne und Budgets gefährden. Dokumentieren Sie die Grenzen Ihrer Lösung, und implementieren Sie einen Änderungskontrollesprozess für alle neuen Anforderungen. Genehmigen Sie nur Änderungen, die die definierten Ziele direkt unterstützen und die ohne Unterminierung des Zeitplans oder Budgets bereitgestellt werden können. Ideen mit niedrigerer Priorität für zukünftige Backlogs zurückstellen. Die strenge Verwaltung des Bereichs hält das Team auf die Bereitstellung der wertvollsten Funktionen zuerst innerhalb von Einschränkungen konzentriert.

Planen der cloudeigenen Architekturen

Eine gut geplante Architektur ist wichtig, um Ihre Ziele und Anforderungen zu erfüllen. Jede wichtige architekturbezogene Entscheidung umfasst Kompromisse bei Skalierbarkeit, Komplexität, Kosten und Agilität. Mit den folgenden Schritten und Entscheidungspunkten können Sie ein cloudeigenes Design erstellen, das an bewährten Methoden ausgerichtet ist:

Erkunden überprüfter cloudnativer Architekturen

1. Überprüfen Sie die Architekturgrundsätze und bewährten Methoden. Bevor Sie eine Architektur von Grund auf neu erfinden, überprüfen Sie überprüfte Referenzarchitekturen und Grundlagen aus dem Azure Architecture Center. Vertraute Architekturstile umfassen die Erkundung überprüfter Referenzarchitekturen für allgemeine Workloads. Diese Architekturen helfen dabei, Entwurfsentscheidungen zu beschleunigen und Risiken zu reduzieren.

2. Wählen Sie einen geeigneten Architekturstil aus. Wählen Sie einen Architekturstil basierend auf den Merkmalen und Teamfunktionen Ihrer Workload aus. Architekturstile umfassen N-Ebenen (monolithisch), Microservices, nachrichtenbasierte Ereignissteuerung, Web-Queue-Worker. Wenn Sie z. B. eine schnelle Entwicklung für eine relativ einfache Anwendung benötigen, reicht möglicherweise ein gut strukturierter N-Ebene-Monolith aus. Für eine große oder sich schnell entwickelnde Anwendung mit unterschiedlichen Domänen, Microservices oder ereignisgesteuerten Ansätzen bieten Flexibilität (zu den Kosten der Komplexität). In der Praxis haben viele Systeme einen Hybridstil. Beispielsweise gibt es einen Microservices-Kern mit einigen gemeinsamen Diensten oder einem ereignisgesteuerten Subsystem. Der Schlüssel ist das Verständnis der Kompromisse der einzelnen Stile und die Auswahl des Ansatzes, der Ihre Skalierbarkeit, Resilienz und Flexibilitätsanforderungen am besten erfüllt.

3. Anwenden bewährter Methoden für den Entwurf Unabhängig davon, welcher Stil Sie auswählen, halten Sie sich an die Grundlagen und bewährten Methoden der Cloudarchitektur. Das Azure Architecture Center bietet einen Katalog von Clouddesignmustern (Retry, Circuit Breaker, CQRS), die häufige Herausforderungen in verteilten Workloads bewältigen. Durch die Integration dieser Muster in Ihr Design können Zuverlässigkeit und Leistung verbessert werden.

4. Integrieren Sie die fünf Säulen in Designentscheidungen. Verwenden Sie das Well-Architected Framework , um Entscheidungen über Zuverlässigkeit, Sicherheit, Leistungseffizienz, Kostenoptimierung und operative Exzellenz zu leiten. Diese fünf Säulen sollten alle Entwurfsentscheidungen informieren. Wenn Sie beispielsweise eine Datenbank auswählen, sollten Sie zuverlässigkeit (Redundanz, Sicherung), Leistung und Kosten zusammen berücksichtigen, um das richtige Gleichgewicht zu erzielen. Dokumentieren Sie, wo Sie Kompromisse zwischen Säulen vornehmen, z. B. mehr Kosten für höhere Leistung. Diese Hinweise sind für zukünftige Governance und Überprüfungen wertvoll.

Planen von Integrationen mit vorhandenen Systemen

1. Inventarisieren Sie alle abhängigen Systeme und Dienste. Neue cloud-native Lösungen arbeiten nur selten isoliert, es sei denn, Sie sind ein Startup in der Frühphase. Überlegen Sie, wie Ihre neue Workload oder Ihr Feature in die Umgebung passt. Ordnen Sie Datenflüsse zu, und stellen Sie die Kompatibilität mit Standards sicher. Erstellen Sie eine umfassende Liste aller Systeme, mit der Ihre Workload interagiert. Diese Liste enthält interne APIs, Datenbanken, Identitätsanbieter (Microsoft Entra ID), Überwachungstools, CI/CD-Pipelines und lokale Systeme, auf die über VPN oder ExpressRoute zugegriffen wird. Verwenden Sie Architekturdiagramme und Abhängigkeitszuordnungen, um diese Beziehungen zu visualisieren.

2. Klassifizieren von Integrationstypen und Protokollen. Kategorisieren Sie jeden Integrationspunkt nach Typ (Authentifizierung, Datenaustausch, Messaging) und Protokoll (REST, gRPC, ODBC, SAML, OAuth2). Diese Klassifizierung hilft bei der Identifizierung von Kompatibilitätsanforderungen und potenziellen Engpässen.

3. Überprüfen der Identitäts- und Zugriffsintegration. Stellen Sie sicher, dass Ihre Lösung in den Identitätsanbieter der Organisation integriert ist. Verwenden Sie z. B. Microsoft Entra-ID für die Authentifizierung und Autorisierung, anstatt ein neues Identitätssystem einzuführen. Bestätigen Sie die Unterstützung für einmaliges Anmelden (Single Sign-On, SSO), rollenbasierte Zugriffssteuerung (RBAC) und Richtlinien für bedingten Zugriff.

4. Bewerten der Netzwerkkonnektivität und -sicherheit. Überprüfen Sie, wie Ihre Workload eine Verbindung mit anderen Systemen herstellt. Überprüfen Sie Firewallregeln, DNS-Auflösung und Routingpfade. Bestätigen Sie für Hybridszenarien, dass ExpressRoute- oder VPN-Konfigurationen vorhanden sind und getestet werden. Verwenden Sie Azure Network Watcher, um die Konnektivität zu überwachen und zu beheben.

5. Sicherstellen der Kompatibilität und Compliance des Datenflusses. Datenflüsse zwischen Systemen mappen. Bestätigen Sie datenformate, Schemas und Transformationsanforderungen. Sicherstellen der Einhaltung von Datenresidenz-, Verschlüsselungs- und Aufbewahrungsrichtlinien.

6. Testen Sie Integrationspunkte frühzeitig und kontinuierlich. Führen Sie Integrationstests während der frühen Entwicklungsphasen durch. Verwenden Sie Mocks oder Stubs bei nicht verfügbaren Systemen. Automatisieren Sie diese Tests in Ihrer CI/CD-Pipeline mithilfe von Tools wie Azure DevOps oder GitHub-Aktionen. Überwachen sie auf Latenz, Durchsatz und Fehlerraten. Sie möchten beispielsweise vermeiden, dass Ihre App von einer API abhängt, die die erforderliche Last nicht unterstützt, oder dass eine Netzwerkfirewall Ihren Dienst blockiert.

7. Dokumentintegrationsverträge und SLAs. Definieren und dokumentieren Sie das erwartete Verhalten, die Verfügbarkeit und die Leistung jedes Integrationspunkts. Schließen Sie Wiederholungslogik, Timeouteinstellungen und Fallbackmechanismen ein. Stimmen Sie mit den Vereinbarungen auf Serviceebene (SLAs) der abhängigen Systeme überein.

Wählen Sie geeignete Azure-Dienste und -Dienstebenen aus.

1. Verwenden Sie Entscheidungshandbücher, um Dienste auszuwählen, die den Workloadanforderungen entsprechen. Azure bietet mehrere Optionen zum Ausführen ihres Anwendungscodes, jeweils mit Vor- und Nachteilen. Überprüfen Sie die Übersicht über die Technologieauswahl , um Dienste zu identifizieren, die ihren funktionalen und nicht funktionalen Anforderungen entsprechen. Priorisieren Sie Plattform-as-a-Service-Optionen (PaaS), da diese Dienste den Betriebsaufwand reduzieren, indem Infrastrukturverwaltung, Patching und Skalierung automatisch verarbeitet werden.

2. Definieren Sie Verwendungsmuster und Leistungsanforderungen, um Dienstebenen auszuwählen. Die Auswahl der Dienstebene wirkt sich sowohl auf Kosten als auch auf die Funktion aus. Dokumentieren Sie erwartete Transaktionsvolumen, gleichzeitige Benutzerlasten, Speicheranforderungen sowie Leistungsziele wie Antwortzeiten und Durchsatz. Verwenden Sie diese Metriken, um eine anfängliche Dienstebene (SKU) auszuwählen, die grundlegende Anforderungen ohne erhebliche Überbereitstellung erfüllt. Planen Sie, Ebenen basierend auf tatsächlichen Verwendungsmustern nach der Bereitstellung anzupassen.

3. Überprüfen der Featurekompatibilität über ausgewählte Dienstebenen hinweg. Wichtige Features wie erweiterte Sicherheitsfunktionen, Optionen für hohe Verfügbarkeit oder Integrations-APIs variieren je nach Dienstebene. Erstellen Sie eine Featurematrix, die den verfügbaren SKUs erforderliche Funktionen zuordnet. Stellen Sie sicher, dass die ausgewählte Ebene alle erforderlichen Features unterstützt, um kostspielige Migrationen oder Architekturänderungen später zu vermeiden. Referenzdienstspezifische Dokumentation zur Bestätigung der Verfügbarkeit und Einschränkungen von Features.

Wählen Sie aus, wie viele Regionen verwendet werden sollen.

1. Bewertung der Kompromisse bei Einsätzen in mehreren Regionen. Einzelregionsarchitekturen sind einfacher und billiger, aber ein regionaler Ausfall würde Ihre App außer Betrieb setzen. Bereitstellungen mit mehreren Regionen können eine höhere Verfügbarkeit erreichen (eine Region kann fehlschlagen und Benutzer werden von einer anderen bedient) und können auch die Leistung verbessern, indem Sie Benutzer aus der nächstgelegenen Region bereitstellen. Die Kehrseite ist eine erhöhte Komplexität bei der Bereitstellung und Datensynchronisierung. Sie müssen die Datenreplikation über Regionen hinweg mit potenziellen Konsistenzproblemen, globalem Traffic-Routing und höheren Kosten bewältigen. Lassen Sie Ihre Zuverlässigkeitsanforderungen diese Entscheidung vorantreiben.

2. Verwenden Sie Zuverlässigkeitsziele, um die regionale Strategie zu leiten. Definieren Sie Ziele auf Serviceebene (Service Level Objectives, SLO), Recovery Point Objectives (RPO) und Wiederherstellungszeitziele (Recovery Time Objectives, RTO), um regionale Anforderungen zu bestimmen.

3. Bestätigen Sie die Einhaltung der Datenresidenzbestimmungen. Arbeiten Sie mit Rechts- und Complianceteams zusammen, um sicherzustellen, dass regionale Entscheidungen den gesetzlichen Verpflichtungen entsprechen.

Dokumentarchitekturen

1. Erstellen Sie ein detailliertes Architekturdiagramm und ein Entwurfsdokument. Die Dokumentation unterstützt Implementierung, Überprüfung und zukünftige Wartung. Einschließen ausgewählter Azure-Dienste, SKUs, Datenflüsse und Benutzerinteraktionen. Stellen Sie sicher, dass das Diagramm eine klare visuelle Darstellung der Architektur bereitstellt, um Implementierung und Überprüfungen zu unterstützen.

2. Zeichnen Sie wichtige Designentscheidungen und Trade-Offs auf. Dokumentieren Sie die Gründe für architekturbezogene Entscheidungen, einschließlich nicht funktionsfähiger Anforderungen wie Zuverlässigkeit, Sicherheit und Leistung. Heben Sie alle Trade-Offs hervor, die zum Ausgleich konkurrierender Prioritäten gemacht werden.

Planen der Cloud-nativen Bereitstellungsstrategie

Wenn Sie die cloudeigene Lösung in der Produktion bereitstellen, folgen Sie einer geplanten Strategie anstelle eines Ad-hoc-Pushs. Ein solider Bereitstellungsplan minimiert die Auswirkungen auf Benutzer und bietet Möglichkeiten zum Wiederherstellen, wenn ein Fehler auftritt.

Planen von Entwicklungs- und Bereitstellungspraktiken

Entwicklungs- und Bereitstellungspraktiken sorgen für eine konsistente Bereitstellungs- und Betriebsbereitschaft in allen Umgebungen. Diese Methoden reduzieren das Bereitstellungsrisiko und verbessern die Teamkoordination.

1. Einrichten von DevOps-Methoden für die Bereitstellungsautomatisierung. DevOps-Praktiken bringen Entwicklungs- und Betriebsteams durch Automatisierung, Versionskontrolle und CI/CD-Pipelines in Einklang. Verwenden Sie Tools wie Azure DevOps oder GitHub-Aktionen, um Build-, Test- und Bereitstellungsworkflows zu automatisieren. Dieser Ansatz reduziert manuelle Fehler, beschleunigt Veröffentlichungszyklen und bietet konsistente Bereitstellungsprozesse in allen Umgebungen.

2. Planen Sie die betriebsbereite Bereitschaft zur Unterstützung von Bereitstellungsaktivitäten. Die Betriebsbereitschaft umfasst Überwachungs-, Warnungs- und Vorfallreaktionsverfahren für Bereitstellungsszenarien. Bereitstellungs-Dokumentationen und Automatisierungsskripte, die Rollback-Prozeduren, Gesundheitsprüfungen und Fehlerbehebungsschritte abdecken. Speichern Sie diese Ressourcen an einem zentralen Ort, z. B. azure DevOps Wiki oder GitHub, um die Barrierefreiheit während der Bereitstellungsaktivitäten sicherzustellen.

3. Definieren Sie Entwicklungspraktiken , die zuverlässige Bereitstellungen unterstützen. Verwenden Sie Codierungsstandards, Peerüberprüfungen und automatisierte Tests, um die Codequalität und Bereitstellungsbereitschaft sicherzustellen. Integrieren Sie diese Praktiken in Ihre CI/CD-Pipeline, um Qualitätsgates vor der Bereitstellung zu erzwingen. Schließen Sie bereitstellungsspezifische Tests wie Integrationstests, Rauchtests und Leistungsüberprüfung ein, um die Systembereitschaft für die Produktion zu überprüfen.

Planen der Bereitstellung für neue Workloads

1. Verwenden Sie die progressive Exposition, um die Auswirkungen zu begrenzen. Für eine neue Anwendung (grünes Feld) ohne vorhandene Benutzer sollten Sie einen soft launch durchführen. Stellen Sie in der Produktion bereit, machen Sie diese jedoch anfänglich nur für interne Benutzer oder eine Pilotgruppe verfügbar. Dieser Ansatz ist eine Canary-Bereitstellung für eine neue Workload. Wenn es wirklich neu und isoliert ist, ist eine einmalige Bereitstellung in die vollständige Produktionsumgebung möglich, aber eine schrittweise Einführung wird weiterhin empfohlen, um potenzielle Probleme in kontrollierter Weise zu identifizieren. Lassen Sie das System am ersten Tag nicht auf 100% der Benutzer los, ohne zuvor eine realitätsnahe Validierung durchzuführen. Weitere Informationen finden Sie unter WAF – Übernehmen eines progressiven Expositionsmodells.

2. Dokumentieren Sie operative Verfahren und Eskalationspfade. Erstellen Sie eine klare Dokumentation für den Neustart von Diensten, den Zugriff auf Protokolle, die Behandlung häufiger Probleme und eskalierende Vorfälle. Speichern Sie diese Dokumentation in einem freigegebenen Repository wie SharePoint oder GitHub, um die Verfügbarkeit von Supportteams sicherzustellen.

Planen der Implementierung neuer Funktionen

1. Planen Sie die Integration neuer Funktionen unter Verwendung des Änderungsmanagements. Folgen Sie dem Änderungsmanagementprozess Ihrer Organisation, um Produktionsänderungen zu steuern und zu dokumentieren. Definieren Sie Rollbackprozeduren, z. B. das Zurücksetzen von Anwendungsversionen oder das Wiederherstellen von Datenbanksicherungen. Sichern Sie die Genehmigung der Projektbeteiligten vor der Bereitstellung, um die Ausrichtung mit den Geschäftszielen sicherzustellen. Weitere Informationen finden Sie unter Änderungen verwalten im CAF.

2. Verwenden Sie In-place-Updates für kleinere oder abwärtskompatible Änderungen. Stellen Sie Updates direkt in der Produktionsumgebung mithilfe von Rollupdates oder Featurekennzeichnungen bereit. Beginnen Sie mit einem kleinen Prozentsatz der Benutzer oder Instanzen. Überwachen Sie Systemmetriken und Protokolle, um die Stabilität vor dem vollständigen Rollout zu überprüfen.

3. Verwenden Sie parallele (blaugrüne) Bereitstellungen für wichtige oder risikoreiche Änderungen. Stellen Sie die neue Version in einer separaten Umgebung bereit. Leiten Sie einen kleinen Teil des Livedatenverkehrs an die neue Version weiter, um das Verhalten zu überprüfen. Wenn dies erfolgreich ist, verschieben Sie den gesamten Datenverkehr in die neue Version. Wenn Probleme auftreten, stellen Sie den Datenverkehr auf die ursprüngliche Version zurück, um die Kontinuität sicherzustellen.

4. Planen Sie die betriebliche Übergabe für neue Arbeitslasten. Identifizieren Sie das team, das für den Betrieb und die Unterstützung der Lösung nach der Bereitstellung verantwortlich ist. Definieren Sie das Supportmodell (Support für Telefonanrufe oder Geschäftszeiten 24/7), und stellen Sie sicher, dass alle Beteiligten ihre Rollen verstehen.

5. Definieren von Besitz- und Supportverantwortlichkeiten. Vergewissern Sie sich, dass das Betriebsteam bereit ist, das neue Feature zu unterstützen. Aktualisieren Sie Dokumentations- und Eskalationspfade, um neue Verantwortlichkeiten widerzuspiegeln und eine schnelle Reaktion auf Vorfälle sicherzustellen.

Definieren des Rollbackplans für cloudeigene Lösungen

Mit einem Rollbackplan können Teams Änderungen schnell rückgängig machen, wenn eine Bereitstellung fehlschlägt oder Risiken einführt. Ein gut definierter Plan minimiert Ausfallzeiten, begrenzt geschäftliche Auswirkungen und hält die Systemsicherheit aufrecht. Richten Sie vor dem Initiieren einer Migration oder Bereitstellung immer Rollbackkriterien und -verfahren ein.

1. Fehlgeschlagene Bereitstellung definieren. Kooperieren Sie mit Geschäftsbeteiligten, Aufgabenverantwortlichen und Operationsteams, um zu bestimmen, was als fehlgeschlagene Bereitstellung gilt. Beispiele hierfür sind fehlerhafte Integritätsprüfungen, schlechte Leistung, Sicherheitsprobleme oder nicht erkannte Erfolgsmetriken. Diese Definition stellt sicher, dass Rollbackentscheidungen an die Risikotoleranz Ihrer Organisation angepasst sind. Fügen Sie bestimmte Bedingungen hinzu, die einen Rollback in Ihrem Bereitstellungsplan auslösen, z. B. CPU-Auslastungsgrenzwerte, Reaktionszeiten oder Fehlerraten. Diese Bewertung macht Rollback-Entscheidungen bei Vorfällen klar und konsistent.

2. Automatisieren Sie Rollbackschritte in CI/CD-Pipelines. Verwenden Sie Tools wie Azure Pipelines oder GitHub-Aktionen , um Rollbackprozesse zu automatisieren. Konfigurieren Sie beispielsweise Pipelines, um eine frühere Version erneut bereitzustellen, wenn Integritätsprüfungen fehlschlagen.

3. Erstellen Sie spezifische Rollback-Anweisungen für die Arbeitslast. Entwickeln Sie Rollbackschritte, die Ihrem Workloadtyp, Ihrer Umgebung und ihrer Bereitstellungsmethode entsprechen. Beispielsweise erfordern Infrastruktur-als-Code-Bereitstellungen das erneute Bereitstellen vorheriger Vorlagen. Anwendungsrollbacks umfassen die erneute Bereitstellung eines vorherigen Containerimages. Fügen Sie Rollbackskripts, Konfigurationsmomentaufnahmen und Infrastruktur-as-Code-Vorlagen an Ihren Rollbackplan an. Diese Ressourcen ermöglichen eine schnelle Ausführung und verringern die Abhängigkeit von manuellen Eingriffen.

4. Testen Sie Rollbackprozeduren. Simulieren Sie Bereitstellungsfehler in einer Vorproduktionsumgebung, um die Effektivität des Rollbacks zu überprüfen. Identifizieren und Beheben von Lücken in Automatisierung, Berechtigungen oder Abhängigkeiten. Vergewissern Sie sich, dass das Rollback das System in einen stabilen, bekannten guten Zustand wiederherstellt.

5. Verbessern von Rollbackstrategien Führen Sie nach jedem Bereitstellungs- oder Rollbackereignis eine Retrospektive aus, um zu beurteilen, was funktioniert hat und was nicht. Aktualisieren Sie Rollbackkriterien, -verfahren und -automatisierung basierend auf den gelernten Erkenntnissen, Architekturänderungen oder neuen Tools. Bewahren Sie die Dokumentation auf, um sicherzustellen, dass Rollbackstrategien aktuell und effektiv bleiben.

Nächster Schritt

Erstellen der neuen Lösung