Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Stellen Sie nun die Lösung nach der geplanten Strategie in der Live-Azure-Umgebung bereit. Diese Phase umfasst endgültige Vorbereitungen, die Bereitstellungsausführung und die Überprüfung und Unterstützung nach der Bereitstellung.
Vorbereiten von Projektbeteiligten für cloudeigene Bereitstellungen
Melden Sie den Bereitstellungszeitplan und die erwarteten Auswirkungen an. Bevor Sie mit der Produktionsbereitstellung beginnen, kommunizieren Sie den Plan und den Wert allen relevanten Beteiligten. Melden Sie den Bereitstellungszeitplan und die erwarteten Benutzereffekte an. Beachten Sie z. B. für neue Funktionen alle Ausfallzeiten oder benutzer sichtbare Änderungen im Voraus. Projektbeteiligte können Konflikte mit Geschäftsereignissen erkennen oder Bedenken bezüglich der Zeitplanung auslösen. Geben Sie einen Kanal für Feedback an, und stellen Sie sicher, dass das Bereitstellungsfenster den operativen Prioritäten entspricht. Passen Sie den Zeitplan bei Bedarf an, um Unterbrechungen zu vermeiden.
Benachrichtigen Sie Supportteams und betroffene Gruppen. Stellen Sie sicher, dass Supportteams im Standbymodus sind und wissen, was freigegeben wird, damit sie alle Benutzerprobleme oder Anfragen behandeln können. Wenn sich die Bereitstellung möglicherweise auf Endbenutzer oder andere Systeme auswirkt, benachrichtigen Sie diese Gruppen ebenfalls.
Legen Sie die Erwartungen für die Funktionalität während des Bereitstellungsfensters fest. Ein Bereitstellungsfenster kann eingeschränkte Funktionen oder temporäre Verzögerungen umfassen. Informieren Sie die Beteiligten über diese Bedingungen, um Verwirrung zu vermeiden und die Geschäftskontinuität sicherzustellen. Schließen Sie Fallbackprozeduren oder Problemumgehungen ein, falls zutreffend.
Führen Sie eine Überprüfung der Bereitschaft vor der Bereitstellung durch. Eine Bereitschaftsüberprüfung bestätigt, dass alle Teams ihre Rollen verstehen und über erforderlichen Zugriff verfügen. Führen Sie eine Besprechung mit Vertretern der einzelnen Supportteams durch, um den Bereitstellungsplan, die Erfolgskriterien und die Rollbackkriterien zu überprüfen. Stellen Sie sicher, dass Supportteams über geeignete Systemzugriffs- und Überwachungstools verfügen. Diese Vorbereitung stellt eine koordinierte Reaktion auf alle Probleme sicher, die während der Migration auftreten.
Ausführen der cloudeigenen Bereitstellungen
Die Bereitstellungsschritte unterscheiden sich geringfügig, je nachdem, ob es sich um eine neue eigenständige Workload oder ein Featureupdate auf ein vorhandenes System handelt:
Bereitstellen neuer cloudeigener Workloads
Erstellen Sie eine Produktionsumgebung. Verwenden Sie Ihre CI/CD-Pipeline, um die Bereitstellungspipeline für die Produktion mit derselben Konfiguration, die im Staging getestet wurde, bereitzustellen. Verwenden Sie dieselben Buildartefakte, IaC-Vorlagen und Bereitstellungsskripts, die die Validierung im Staging bestanden haben. Da Sie in einer separaten Umgebung bereitstellen, erstellen Sie alle erforderlichen Azure-Ressourcen über Ihre IaC-Vorlagen, und stellen Sie dann den Anwendungscode oder die Artefakte bereit.
Rauchtest. Führen Sie nach der Bereitstellung Smoke-Tests in der Produktionsumgebung (grundlegende Prüfungen) durch, um sicherzustellen, dass alle Dienste verfügbar und funktionsfähig sind und die Kernfunktionalität in der Liveumgebung funktioniert. Stellen Sie sicher, dass wichtige Dienste ausgeführt werden, auf Datenbanken zugegriffen werden kann, und die Anwendung reagiert (drücken Sie einen Integritätsprüfungsendpunkt oder einige schlüsselseitige Seiten). Überprüfen Sie Azure Service Health auf alle Plattformprobleme in Ihrer Region, die sich auf Ihre Komponenten auswirken können. Bei diesen Tests handelt es sich um eine Überprüfung, bevor benutzer an das System weitergeleitet werden.
Rollout für eine kleine Gruppe von Benutzern. Implementieren Sie das progressive Rollout, indem Sie das neue System für eine kleine Gruppe von Benutzern verfügbar machen. Dieses Rollout kann durch die Veröffentlichung eines Features nur für interne Benutzer oder das Weiterleiten eines kleinen Prozentsatzes von Live an die neue Bereitstellung erfolgen. Überwachen Sie genau auf Fehler oder Leistungsprobleme. Verwenden Sie Application Insights und benutzerdefinierte Dashboards, um Fehlerraten, Reaktionszeiten und Ressourcennutzung in Echtzeit zu beobachten. Sammeln Sie auch qualitatives Feedback von allen Pilotbenutzern auf der Canary-Version.
Überwachen und schrittweise erweitern. Das graduelle Rollout reduziert das Risiko und ermöglicht eine echte Validierung vor der vollständigen Veröffentlichung. Geben Sie die Anwendung für eine kleine Gruppe von Canarybenutzern frei. Verwenden Sie einen Lastenausgleich, z. B. Azure Front Door oder Traffic Manager, um eine Teilmenge des Datenverkehrs an die neue Bereitstellung weiterzuleiten. Sammeln Sie Feedback und überwachen Sie die Leistung. Skalieren oder öffnen Sie den Zugriff auf alle Benutzer nach erfolgreicher Überprüfung.
Bereitstellen neuer cloudeigener Features für eine vorhandene Workload
Wenn Sie ein neues Feature für eine vorhandene cloudeigene Workload bereitstellen, wählen Sie die Bereitstellungsstrategie aus, die sich an Ihre Risikotoleranz, Infrastruktureinschränkungen und Rolloutziele richtet. Zwei gängige Ansätze sind die In-Place-Bereitstellung und die Blue-Green-Bereitstellung (parallele Umgebung).
Verwenden der In-Place-Bereitstellung für einen schrittweisen Rollout innerhalb derselben Umgebung
Verwenden Sie die direkte Bereitstellung, wenn Sie einem vorhandenen Workload ein neues Feature hinzufügen, ohne eine separate Umgebung bereitzustellen. Dieser Ansatz ermöglicht einen sicheren, inkrementellen Rollout mit minimalem Infrastrukturaufwand.
Feature für kleines Benutzersegment aktivieren Setzen Sie das neue Feature in der vorhandenen Umgebung mithilfe von Feature-Flags oder Konfigurationstoggles ein. Aktivieren Sie zunächst das Feature für eine begrenzte Zielgruppe, z. B. interne Benutzer, Betatester oder einen kleinen Prozentsatz des Livedatenverkehrs. Dieser Ansatz ermöglicht eine echte Validierung, während gleichzeitig die Möglichkeit erhalten bleibt, das Feature schnell zu deaktivieren, wenn Probleme auftreten. Stellen Sie sicher, dass Benutzerinteraktionen markiert sind, um zwischen Benutzern oder Sitzungen zu unterscheiden, bei denen das Feature aktiviert oder deaktiviert ist, sodass ein paralleler Vergleich möglich ist.
Rauchtest. Führen Sie nach der Bereitstellung Smoke-Tests in der Produktionsumgebung (grundlegende Prüfungen) durch, um sicherzustellen, dass alle Dienste verfügbar und funktionsfähig sind und die Kernfunktionalität in der Liveumgebung funktioniert. Stellen Sie sicher, dass wichtige Dienste ausgeführt werden, auf Datenbanken zugegriffen werden kann, und die Anwendung reagiert (drücken Sie einen Integritätsprüfungsendpunkt oder einige schlüsselseitige Seiten).
Überwachen und schrittweise erweitern. Überwachen Sie die Anwendungsintegrität, Leistung und Fehlerraten kontinuierlich mithilfe von Tools wie Application Insights oder Azure Monitor. Vergleichen Sie Metriken zwischen Benutzern mit und ohne das Feature, das zum Erkennen von Anomalien aktiviert ist. Wenn keine Probleme erkannt werden, erhöhen Sie schrittweise den Prozentsatz des Feature-Flag-Rollouts oder erweitern Sie die Benutzergruppe. Wiederholen Sie die Überwachung nach jeder Erhöhung. Führen Sie nach dem vollständigen Rollout eine endgültige Überprüfung durch, um ein einheitliches Verhalten für alle Instanzen und Benutzersegmente sicherzustellen.
Bereitstellen neuer Features in einer parallelen Umgebung
Verwenden Sie eine blaugrüne Bereitstellung, wenn Sie ein neues Feature in eine vorhandene Workload einführen, indem Sie es in einer parallelen Produktionsumgebung bereitstellen. Dieser Ansatz minimiert das Risiko, indem eine vollständige Überprüfung zugelassen wird, bevor der Benutzerdatenverkehr zur neuen Version gewechselt wird.
Erstellen sie parallele Umgebung (grün). Verwenden Sie Ihre CI/CD-Pipeline, um die Bereitstellungspipeline für die Produktion mit derselben Konfiguration, die im Staging getestet wurde, bereitzustellen. Verwenden Sie dieselben Buildartefakte, IaC-Vorlagen und Bereitstellungsskripts, die die Validierung im Staging bestanden haben. Da Sie in einer separaten Umgebung bereitstellen, erstellen Sie alle erforderlichen Azure-Ressourcen über Ihre IaC-Vorlagen, und stellen Sie dann den Anwendungscode oder die Artefakte bereit.
Führen Sie einen Smoke-Test der parallelen Umgebung durch. Führen Sie nach der Bereitstellung Smoke-Tests in der Produktionsumgebung (grundlegende Prüfungen) durch, um sicherzustellen, dass alle Dienste verfügbar und funktionsfähig sind und die Kernfunktionalität in der Liveumgebung funktioniert. Stellen Sie sicher, dass wichtige Dienste ausgeführt werden, auf Datenbanken zugegriffen werden kann, und die Anwendung reagiert (drücken Sie einen Integritätsprüfungsendpunkt oder einige schlüsselseitige Seiten). Überprüfen Sie Azure Service Health auf alle Plattformprobleme in Ihrer Region, die sich auf Ihre Komponenten auswirken können. Dieser Rauchtest ist eine Prüfung, bevor benutzer an das System weitergeleitet werden.
Leiten Sie eine Teilmenge des Netzwerkverkehrs an parallele Umgebungen weiter. Das graduelle Rollout reduziert das Risiko und ermöglicht eine echte Validierung vor der vollständigen Veröffentlichung. Geben Sie die Anwendung für eine kleine Gruppe von Canarybenutzern frei. Verwenden Sie einen Lastenausgleich, z. B. Azure Front Door oder Traffic Manager, um eine Teilmenge des Datenverkehrs an die neue Bereitstellung weiterzuleiten. Alternativ können Sie das neue Feature nur für ein bestimmtes Benutzersegment über Routingregeln oder Featurekennzeichnungen verfügbar machen. Überwachen Der Leistung, der Fehlerraten und der Benutzererfahrung mithilfe von Application Insights oder Azure Monitor. Vergleichen Sie den Benutzerdatenverkehr zwischen den blauen und grünen Umgebungen, um Regressionen oder Anomalien zu erkennen.
Überwachen und schrittweise erweitern. Wenn die neue Version gut funktioniert, erhöhen Sie das Datenverkehrsrouting inkrementell, bis sie 100% der Last verarbeitet. Fördern Sie die "grüne" Bereitstellung als vorrangiges Ziel. Die alte "blaue" Bereitstellung bleibt während dieses Prozesses erhalten, wodurch das Rollback vereinfacht wird. Wenn ein schwerwiegendes Problem erkannt wird, können Sie sofort den gesamten Datenverkehr zurück zur stabilen Version wechseln.
Abschluss des Umschaltens. Nach erfolgreicher Validierung leiten Sie alle Benutzer auf das neue System weiter oder geben Sie es offiziell bekannt, wenn es zuvor versteckt war. Die alte Umgebung, falls es eine für eine aktualisierte Funktion gab, kann nach einem sicheren Validierungszeitraum für die Außerbetriebnahme in Betracht gezogen werden.
Überprüfen des Bereitstellungserfolgs
Nachdem Sie eine neue Workload oder ein neues Feature bereitgestellt haben, müssen Sie sicherstellen, dass das System sowohl technisch als auch aus Sicht des Benutzers ordnungsgemäß funktioniert.
Überprüfen Sie kritische Benutzererfahrungen. Gehen Sie über Rauchtests hinaus, um sicherzustellen, dass alle wichtigen Benutzerflüsse wie erwartet in der Liveumgebung funktionieren. Verwenden Sie automatisierte Testsuiten oder manuelle QA, um reale Szenarien zu überprüfen. Konzentrieren Sie sich auf hochwertige Pfade wie Authentifizierung, Transaktionen und Datenworkflows. Diese Tests kommen zur Anwendung, unabhängig davon, ob durch die Bereitstellung ein neues System eingeführt oder ein vorhandenes System erweitert wurde.
Überprüfen Sie Hintergrundprozesse und Integrationen. Überprüfen Sie, ob Hintergrundprozesse, Integrationen und geplante Aufträge ordnungsgemäß ausgeführt werden. Überprüfen Sie Protokolle, Auftragsstatus und Integrationsendpunkte, um sicherzustellen, dass sie erwartungsgemäß funktionieren. Dieser Schritt verhindert stille Fehler, die für die Nutzer möglicherweise nicht sofort sichtbar sind.
Überprüfen Sie Überwachungsdashboards für die Systemgesundheit. Verwenden Sie Azure Monitor und Application Insights, um Protokolle und Metriken zu prüfen. Suchen Sie nach Anomalien in Fehlerraten, Latenz, CPU-/Speicherauslastung und Durchsatz. Vergewissern Sie sich, dass Überwachungsdaten ordnungsgemäß fließen und dass keine Daten fehlen oder falsch umgeleitet werden.
Überprüfen Sie warnungen auf unerwartete Auslöser. Überprüfen Sie konfigurierte Warnungen auf Fehlerraten, Latenz oder Ressourcennutzung. Vergewissern Sie sich, dass keine Warnungen unerwartet ausgelöst werden. Wenn Warnungen ausgelöst werden, untersuchen Sie die Ursachen, und bewerten Sie, ob sie ein bereitstellungsbezogenes Problem angeben.
Führen Sie Stakeholder und Benutzer-Check-Ins durch. Es ist auch sinnvoll, einen schnellen Check-In mit einigen Endbenutzern oder Projektbeteiligten nach der Bereitstellung zu haben, um eine menschliche Bestätigung zu erhalten, dass Dinge aus der Sicht des Benutzers funktionieren.
Deklarieren Sie die Bereitstellung erst nach der vollständigen Überprüfung. Betrachten Sie die Bereitstellung erst als abgeschlossen, wenn alle Validierungsschritte erfolgreich abgeschlossen sind und das System Ihre Akzeptanzkriterien erfüllt. Wenn Probleme gefunden werden, beheben Sie kritische Probleme sofort. Protokollieren Sie kleinere Probleme zur Lösung in zukünftigen Aktualisierungen.
Unterstützen von Workloads während der Stabilisierung
Etablieren Sie einen verstärkten Überwachungs- und Unterstützungsansatz. Die Bereitstellung in der Produktionsumgebung ist nicht das Ende der Reise. Erhöhen Sie in den Stunden und Tagen, die unmittelbar auf ein Go-Live folgen, Ihre Überwachung und unterstützen Sie die Wachsamkeit, während das System unter realen Lasten "hochgefahren" wird. Es ist ratsam, das Entwicklungsteam zusammen mit dem Betriebsteam aufzurufen, um probleme schnell zu untersuchen und zu lösen, da sie die neuen Änderungen am besten kennen.
Verfolgen Sie Systemmetriken und Benutzerfeedback kontinuierlich. Behandeln Sie die erste oder zwei Wochen als Stabilisierungszeitraum. Überwachen Sie Metriken wie CPU, Arbeitsspeicher, Fehlerraten und Reaktionszeiten mithilfe von Azure Monitor und Application Insights. Sammeln Sie Benutzerfeedback über Supportkanäle oder direkte Reichweite. Auf diese Weise können Probleme erkannt werden, die von automatisierten Systemen möglicherweise übersehen werden.
Passen Sie Konfigurationen basierend auf dem beobachteten Verhalten an. Passen Sie bei Bedarf Konfigurationen an. Skalieren Sie beispielsweise mehr, wenn die Nutzung höher ist als erwartet. Wenn Protokolle zu ausführlich oder zu knapp sind, ändern Sie die Protokollstufen. Diese Änderungen tragen dazu bei, die Leistung und Observierbarkeit während der Spitzenauslastung aufrechtzuerhalten. Stellen Sie sicher, dass alle in dieser Phase entdeckten Probleme behoben oder in Ihr Tracking-System eingegeben werden, um zukünftige Verbesserungen zu ermöglichen.
Protokollieren und Triage aller während der Stabilisierung ermittelten Probleme. Diese aktive Supportphase erfasst Probleme, die nur unter Produktionsbedingungen sichtbar werden, und sorgt dafür, dass die Arbeitsbelastung tatsächlich ihre Zielvorgaben erfüllt. Nach diesem Stabilisierungszeitraum und sobald Sie sich auf die Leistung des Systems verlassen haben, können Sie zu normalen Vorgängen und Überwachungsverfahren wechseln.
Definieren Sie die Beendigungskriterien für die Stabilisierung. Legen Sie klare Schwellenwerte für Systemleistung, Fehlerraten und Benutzerzufriedenheit fest. Sobald das System diese Kriterien konsistent erfüllt, wechseln Sie zu Standardvorgängen und Überwachungsverfahren. Diese Kriterien sorgen für eine reibungslose Übergabe und vermeiden vorzeitige Schließung der Unterstützungsphase.