Bereitstellung und Tests für unternehmenskritische Workloads in Azure

Fehlerhafte Bereitstellungen und fehlerhafte Versionen sind häufige Ursachen für Anwendungsausfälle. Ihr Ansatz für Bereitstellung und Tests spielt eine wichtige Rolle bei der Gesamtzuverlässigkeit einer unternehmenskritischen Anwendung.

Bereitstellung und Tests sollten die Grundlage für alle Anwendungs- und Infrastrukturvorgänge bilden, um konsistente Ergebnisse für unternehmenskritische Workloads sicherzustellen. Seien Sie bereit, wöchentlich, täglich oder häufiger bereitzustellen. Entwerfen Sie Ihre pipelines für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD), um diese Ziele zu unterstützen.

Die Strategie sollte folgendes umsetzen:

• Strenge Vorabtests. Updates sollten keine Fehler, Sicherheitsrisiken oder andere Faktoren aufweisen, die den Anwendungsstatus gefährden könnten.

• Transparente Bereitstellungen. Es sollte jederzeit möglich sein, Updates ohne Auswirkungen auf Benutzer zu bereitstellen. Benutzer sollten ihre Interaktionen mit der Anwendung ohne Unterbrechung fortsetzen können.

• Hoch verfügbare Vorgänge. Bereitstellungs- und Testprozesse und -tools müssen hoch verfügbar sein, um die gesamte Anwendungszuverlässigkeit zu unterstützen.

• Konsistente Bereitstellungsprozesse. Die gleichen Anwendungsartefakte und -prozesse sollten zum Bereitstellen der Infrastruktur und des Anwendungscodes in verschiedenen Umgebungen verwendet werden. Die End-to-End-Automatisierung ist obligatorisch. Manuelle Eingriffe müssen vermieden werden, da sie Zuverlässigkeitsrisiken mit sich bringen können.

Dieser Entwurfsbereich enthält Empfehlungen zur Optimierung von Bereitstellungs- und Testprozessen mit dem Ziel, Ausfallzeiten zu minimieren und den Anwendungsstatus und die Verfügbarkeit aufrechtzuerhalten.

Bereitstellung ohne Ausfallzeit

Sehen Sie sich das folgende Video an, um eine Übersicht über die Bereitstellung von Null-Ausfallzeiten zu erfahren.

Das Erreichen von Bereitstellungen ohne Ausfallzeiten ist ein grundlegendes Ziel für unternehmenskritische Anwendungen. Ihre Anwendung muss täglich verfügbar sein, auch wenn neue Versionen während der Geschäftszeiten eingeführt werden. Investieren Sie Ihre Bemühungen im Vorfeld, um Bereitstellungsprozesse zu definieren und zu planen, um wichtige Entwurfsentscheidungen zu fördern, z. B. ob Ressourcen als kurzlebig behandelt werden sollen.

Um die Bereitstellung von Null-Ausfallzeiten zu erreichen, stellen Sie neben der vorhandenen Infrastruktur eine neue Infrastruktur bereit, testen Sie sie gründlich, stellen Sie den Endbenutzerdatenverkehr um, und setzen Sie dann die vorherige Infrastruktur nur außer Betrieb. Andere Methoden, wie die Skalierungseinheitsarchitektur, sind ebenfalls wichtig.

Die Referenzimplementierungen "Mission-Critical Online " und "Azure Mission-Critical Connected " veranschaulichen diesen Bereitstellungsansatz, wie in diesem Diagramm dargestellt:

Anwendungsumgebungen

Sehen Sie sich das folgende Video an, um eine Übersicht über Empfehlungen für Anwendungsumgebungen zu erfahren.

Sie benötigen verschiedene Typen von Umgebungen, um Bereitstellungsvorgänge zu überprüfen und zu stufen. Die Typen weisen unterschiedliche Funktionen und Lebenszyklus auf. Einige Umgebungen spiegeln möglicherweise die Produktionsumgebung wider und sind langlebig, andere sind möglicherweise kurzlebig und verfügen über weniger Funktionen als die Produktion. Die Einrichtung dieser Umgebungen frühzeitig im Entwicklungszyklus trägt dazu bei, Flexibilität, Trennung von Produktions- und Vorproduktionsressourcen und gründliche Tests von Vorgängen vor der Freigabe in die Produktionsumgebung sicherzustellen. Alle Umgebungen sollten die Produktionsumgebung so weit wie möglich widerspiegeln, obwohl Sie bei Bedarf Vereinfachungen auf niedrigere Umgebungen anwenden können. Dieses Diagramm zeigt eine unternehmenskritische Architektur:

Es gibt einige häufige Überlegungen:

• Komponenten sollten nicht in allen Umgebungen gemeinsam genutzt werden. Mögliche Ausnahmen sind nachgeschaltete Sicherheitsgeräte wie Firewalls und Quellspeicherorte für synthetische Testdaten.

• Alle Umgebungen sollten Infrastruktur als Codeartefakte (IaC) wie Terraform oder Azure Resource Manager (ARM)-Vorlagen verwenden.

Entwicklungsumgebungen

Sehen Sie sich das folgende Video an, um Informationen zu kurzlebigen Entwicklungsumgebungen und zur automatisierten Featureüberprüfung zu erfahren.

Überlegungen zum Entwurf

• Funktionen. Niedrigere Anforderungen an Zuverlässigkeit, Kapazität und Sicherheit sind für Entwicklungsumgebungen akzeptabel.

• Lebenszyklus. Entwicklungsumgebungen sollten nach Bedarf erstellt werden und für kurze Zeit vorhanden sein. Kürzere Lebenszyklus tragen dazu bei, konfigurationsabweichungen von der Codebasis zu verhindern und Kosten zu senken. Darüber hinaus teilen sich Entwicklungsumgebungen häufig den Lebenszyklus eines Featurebranches.

• Dichte: Teams benötigen mehrere Umgebungen, um die parallele Featureentwicklung zu unterstützen. Sie können innerhalb eines einzelnen Abonnements koexistieren.

Entwurfsempfehlungen

• Behalten Sie die Umgebung in einem dedizierten Abonnement bei, wobei der Kontext für Entwicklungszwecke festgelegt ist.

• Verwenden Sie einen automatisierten Prozess, um Code aus einer Featurebranch in einer Entwicklungsumgebung bereitzustellen.

Test- oder Stagingumgebungen

Diese Umgebungen werden für Tests und Validierungen verwendet. Viele Testzyklen werden durchgeführt, um eine fehlerfreie Bereitstellung in der Produktion sicherzustellen. Die geeigneten Tests für eine unternehmenskritische Arbeitsauslastung werden im Abschnitt "Fortlaufende Validierung und Tests " beschrieben.

Überlegungen zum Entwurf

• Funktionen. Diese Umgebungen sollten die Produktionsumgebung für Zuverlässigkeit, Kapazität und Sicherheit widerspiegeln. Verwenden Sie in Abwesenheit einer Produktionslast eine synthetische Benutzerlast, um realistische Metriken und wertvolle Eingaben zur Integritätsmodellierung bereitzustellen.

• Lebenszyklus. Diese Umgebungen sind kurzlebig. Sie sollten nach Abschluss der Testüberprüfungen zerstört werden.

• Dichte: Sie können viele unabhängige Umgebungen in einem Abonnement ausführen. Sie sollten auch die Verwendung mehrerer Umgebungen in einem dedizierten Abonnement in Betracht ziehen.

Entwurfsempfehlungen

• Stellen Sie sicher, dass mindestens eine Stagingumgebung die Produktion vollständig widerspiegelt, um produktionsähnliche Tests und Validierungen zu ermöglichen. Die Kapazität in dieser Umgebung kann basierend auf der Ausführung von Testaktivitäten flexibel sein.

• Generieren Sie synthetische Benutzerlasten, um einen realistischen Testfall für Änderungen in einer der Umgebungen bereitzustellen.

  Hinweis

  Die Mission Critical Online-Referenzimplementierung stellt ein Beispiel für einen Benutzerladegenerator bereit.

• Definieren Sie die Anzahl der Stagingumgebungen und deren Zwecke innerhalb des Entwicklungs- und Veröffentlichungszyklus.

Produktionsumgebungen

Überlegungen zum Entwurf

• Funktionen. Die höchsten Zuverlässigkeits-, Kapazitäts- und Sicherheitsfunktionen für die Anwendung sind erforderlich.

• Lebenszyklus. Während der Lebenszyklus der Workload und der Infrastruktur gleich bleibt, benötigen alle Daten, einschließlich Überwachung und Protokollierung, spezielle Verwaltung. Beispielsweise ist die Verwaltung für Sicherung und Wiederherstellung erforderlich.

• Dichte: Für einige Anwendungen sollten Sie die Verwendung verschiedener Produktionsumgebungen in Betracht ziehen, um verschiedene Clients, Benutzer oder Geschäftsfunktionen zu erfüllen.

Entwurfsempfehlungen

Verfügen Sie über eine klare Governancegrenze für Produktions- und niedrigere Umgebungen. Platzieren Sie jeden Umgebungstyp in einem dedizierten Abonnement, um dieses Ziel zu erreichen. Diese Segmentierung stellt sicher, dass sich die Ressourcenauslastung in niedrigeren Umgebungen nicht auf Produktionskontingente auswirkt. Dedizierte Abonnements legen auch Zugriffsgrenzen fest.

Kurzlebige Blau-Grün-Bereitstellungen

Für ein blaues/grünes Bereitstellungsmodell sind mindestens zwei identische Bereitstellungen erforderlich. Die blaue Bereitstellung ist die aktive Bereitstellung, die dem Benutzerdatenverkehr in der Produktion dient. Die grüne Bereitstellung ist die neue Bereitstellung, die vorbereitet und getestet wird, um Datenverkehr zu empfangen. Nachdem die grüne Bereitstellung abgeschlossen und getestet wurde, wird der Datenverkehr schrittweise von Blau zu Grün geleitet. Wenn die Lastübertragung erfolgreich ist, wird die grüne Bereitstellung zur neuen aktiven Bereitstellung. Die alte blaue Bereitstellung kann dann über einen phasenweisen Prozess außer Betrieb genommen werden. Wenn es jedoch Probleme in der neuen Bereitstellung gibt, kann sie abgebrochen werden, und der Datenverkehr kann entweder in der alten blauen Bereitstellung verbleiben oder darauf umgeleitet werden.

Azure Mission-Critical empfiehlt einen blauen/grünen Bereitstellungsansatz, bei dem Infrastruktur und Anwendungen als Teil eines Bereitstellungsstempels zusammen bereitgestellt werden. Das Rollout einer Änderung an der Infrastruktur oder Anwendung führt also immer zu einer grünen Bereitstellung, die beide Ebenen enthält. Mit diesem Ansatz können Sie die Auswirkungen der Änderung auf die Infrastruktur und das Ende der Anwendung vollständig testen und überprüfen, bevor Sie den Benutzerdatenverkehr dorthin umleiten. Der Ansatz erhöht das Vertrauen in die Freigabe von Änderungen und ermöglicht Upgrades ohne Ausfallzeiten, da Kompatibilitäten mit nachgelagerten Abhängigkeiten wie der Azure-Plattform, Ressourcenanbietern und IaC-Modulen überprüft werden können.

Überlegungen zum Entwurf

• Technologiefunktionen. Nutzen Sie die integrierten Bereitstellungsfeatures in Azure-Diensten. Beispielsweise stellt Azure-App Dienst sekundäre Bereitstellungsplätze bereit, die nach einer Bereitstellung ausgetauscht werden können. Mit Azure Kubernetes Service (AKS) können Sie eine separate Pod-Bereitstellung auf jedem Knoten verwenden und die Dienstdefinition aktualisieren.

• Bereitstellungsdauer. Die Bereitstellung kann länger dauern, da der Stempel die Infrastruktur und Anwendung und nicht nur die geänderte Komponente enthält. Dies ist jedoch akzeptabel, da das Risiko aller Komponenten, die nicht wie erwartet funktionieren, die Zeitbedenken außer Kraft setzt.

• Kosteneinfluss. Aufgrund der beiden parallelen Bereitstellungen, die bis zum Abschluss der Bereitstellung koexistieren müssen, gibt es zusätzliche Kosten.

• Datenverkehrsübergang. Nachdem die neue Bereitstellung überprüft wurde, muss der Datenverkehr von der blauen Umgebung auf die grüne Umgebung umgestellt werden. Dieser Übergang erfordert die Orchestrierung des Benutzerdatenverkehrs zwischen den Umgebungen. Der Übergang sollte vollständig automatisiert werden.

• Lebenszyklus. Unternehmenskritische Bereitstellungsstempel sollten als kurzlebig betrachtet werden. Durch die Verwendung von kurzlebigen Stempeln wird jedes Mal ein neuer Start erstellt, bevor Ressourcen bereitgestellt werden.

Entwurfsempfehlungen

• Übernehmen Sie einen blauen/grünen Bereitstellungsansatz, um alle Produktionsänderungen freizugeben. Stellen Sie alle Infrastruktur und die Anwendung jedes Mal für jede Art von Änderung bereit, um einen konsistenten Zustand und null Ausfallzeiten zu erzielen. Obwohl Sie Umgebungen wiederverwenden können, empfehlen wir sie nicht für unternehmenskritische Workloads. Behandeln Sie jeden regionalen Bereitstellungsstempel als kurzlebig mit einem Lebenszyklus, der mit einer einzelnen Version verknüpft ist.

• Verwenden Sie einen globalen Lastenausgleich, z. B. Azure Front Door, um den automatisierten Übergang des Benutzerverkehrs zwischen den blauen und grünen Umgebungen zu koordinieren.

• Fügen Sie zum Übergang des Datenverkehrs einen grünen Back-End-Endpunkt hinzu, der einen niedrigen Datenverkehr zum Volumengewicht verwendet, z. B. 10 Prozent. Nachdem Sie überprüft haben, ob das niedrige Datenverkehrsvolumen für die grüne Bereitstellung funktioniert und den erwarteten Anwendungsstatus bereitstellt, erhöhen Sie den Datenverkehr schrittweise. Wenden Sie dabei einen kurzen Ramp-Up-Zeitraum an, um Fehler abzufangen, die möglicherweise nicht sofort offensichtlich sind.

  Nachdem der gesamte Datenverkehr umgestellt wurde, entfernen Sie das blaue Back-End aus vorhandenen Verbindungen. Entfernen Sie beispielsweise das Back-End aus dem globalen Lastenausgleichsdienst, entwässern Sie Warteschlangen und trennen Sie andere Zuordnungen. Auf diese Weise können Sie die Kosten für die Wartung der sekundären Produktionsinfrastruktur optimieren und sicherstellen, dass neue Umgebungen frei von Konfigurationsabweichungen sind.

  An dieser Stelle wird die alte und jetzt inaktive blaue Umgebung außer Betrieb genommen. Wiederholen Sie für die nächste Bereitstellung den Prozess mit blau und grün umgekehrt.

Bereitstellung mit Abonnementbereich

Abhängig von den Skalierungsanforderungen Ihrer Anwendung benötigen Sie möglicherweise mehrere Produktionsabonnements, um als Skalierungseinheiten zu dienen.

Sehen Sie sich das folgende Video an, um einen Überblick über empfehlungen für die Bereichsdefinition von Abonnements für eine unternehmenskritische Anwendung zu erhalten.

Überlegungen zum Entwurf

• Skalierbarkeit. Entwerfen Sie für szenarien mit hohem Umfang von Datenverkehr die Lösung so, dass sie über mehrere Azure-Abonnements skaliert wird, sodass die Skalierungsgrenzwerte eines einzelnen Abonnements nicht die Skalierbarkeit einschränken.

  Wichtig

  Die Verwendung mehrerer Abonnements erfordert zusätzliche CI/CD-Komplexität, die entsprechend verwaltet werden muss. Daher empfehlen wir mehrere Abonnements nur in extremen Szenarien, in denen die Grenzen eines einzelnen Abonnements wahrscheinlich zu einer Einschränkung werden.

• Umgebungsgrenzen. Stellen Sie Produktions-, Entwicklungs- und Testumgebungen in separaten Abonnements bereit. Diese Übung stellt sicher, dass niedrigere Umgebungen nicht zu Skalierungsgrenzwerten beitragen. Außerdem wird das Risiko reduziert, dass die Produktionsverschmutzung durch eine klare Verwaltungs- und Identitätsgrenze verringert wird.

• Governance. Wenn Sie mehrere Produktionsabonnements benötigen, sollten Sie eine dedizierte Anwendungsverwaltungsgruppe verwenden, um die Richtlinienzuweisung über eine Richtlinienaggregationsgrenze zu vereinfachen.

Entwurfsempfehlungen

• Stellen Sie jeden regionalen Bereitstellungsstempel in einem dedizierten Abonnement bereit, um sicherzustellen, dass die Abonnementgrenzwerte nur im Kontext eines einzelnen Bereitstellungsstempels und nicht in der gesamten Anwendung gelten. Gegebenenfalls sollten Sie mehrere Bereitstellungsstempel in einer einzelnen Region verwenden, sie sollten jedoch für unabhängige Abonnements bereitgestellt werden.

• Platzieren Sie globale freigegebene Ressourcen in einem dedizierten Abonnement, um eine konsistente regionale Abonnementbereitstellung zu ermöglichen. Vermeiden Sie die Verwendung einer speziellen Bereitstellung für die primäre Region.

Kontinuierliche Prüfung und Tests

Das Testen ist eine wichtige Aktivität, mit der Sie den Status Ihres Anwendungscodes und Ihrer Infrastruktur vollständig überprüfen können. Genauer gesagt können Sie ihre Standards für Zuverlässigkeit, Leistung, Verfügbarkeit, Sicherheit, Qualität und Skalierung erfüllen. Tests müssen im Rahmen Ihres Anwendungsdesigns und ihrer DevOps-Strategie gut definiert und angewendet werden. Tests sind ein wichtiges Anliegen während des lokalen Entwicklerprozesses (der inneren Schleife) und als Teil des vollständigen DevOps-Lebenszyklus (der äußeren Schleife), der beim Starten von Code auf dem Pfad von Releasepipelineprozessen in Richtung produktionsumgebung beginnt.

Sehen Sie sich das folgende Video an, um einen Überblick über kontinuierliche Validierung und Tests zu erhalten.

Dieser Abschnitt konzentriert sich auf äußere Schleifentests. Es beschreibt verschiedene Arten von Tests.

Überlegungen zum Entwurf

• Automatisierung. Automatisierte Tests sind unerlässlich, um Anwendungs- oder Infrastrukturänderungen zeitnah und wiederholbar zu validieren.

• Testreihenfolge. Die Reihenfolge, in der Tests durchgeführt werden, ist aufgrund verschiedener Abhängigkeiten von entscheidender Bedeutung, z. B. die Notwendigkeit, eine ausgeführte Anwendungsumgebung zu haben. Die Testdauer beeinflusst auch die Reihenfolge. Tests mit kürzeren Laufzeiten sollten früher im Zyklus ausgeführt werden, wenn möglich, um die Testeffizienz zu erhöhen.

• Skalierbarkeitsgrenzwerte. Azure-Dienste weisen unterschiedliche weiche und harte Grenzwerte auf. Erwägen Sie die Verwendung von Auslastungstests, um festzustellen, ob ein System dies während der erwarteten Produktionslast überschreitet. Auslastungstests können auch hilfreich sein, um geeignete Schwellenwerte für die automatische Skalierung festzulegen. Bei Diensten, die die automatische Skalierung nicht unterstützen, können Auslastungstests Ihnen helfen, automatisierte Betriebsabläufe zu optimieren.

  Systemkomponenten wie aktive/passive Netzwerkkomponenten oder Datenbanken können restriktiv skaliert werden. Stresstests können dabei helfen, Einschränkungen zu erkennen.

• Fehlermodusanalyse. Die Einführung von Fehlern in die Anwendung und die zugrunde liegende Infrastruktur und die Bewertung der Wirkung ist für die Bewertung der Redundanzmechanismen der Lösung von wesentlicher Bedeutung. Identifizieren Sie während dieser Analyse das Risiko, die Auswirkungen und die Breite der Auswirkungen (teilweise oder vollständiger Ausfall). Eine Beispielanalyse, die für die Mission Critical Online-Referenzimplementierung erstellt wurde, finden Sie unter Ausfallrisiken einzelner Komponenten.

• Überwachung: Sie sollten Testergebnisse einzeln erfassen und analysieren und diese auch aggregieren, um Trends im Laufe der Zeit zu bewerten. Sie sollten die Testergebnisse kontinuierlich für Genauigkeit und Abdeckung auswerten.

Entwurfsempfehlungen

Sehen Sie sich das folgende Video an, um zu sehen, wie Resilienztests in Azure DevOps CI/CD-Pipelines integriert werden können.

• Sorgen Sie für Konsistenz, indem Sie alle Tests auf Infrastruktur- und Anwendungskomponenten automatisieren. Integrieren Sie die Tests in CI/CD-Pipelines, um sie zu koordinieren und gegebenenfalls auszuführen. Informationen zu Technologieoptionen finden Sie unter DevOps-Tools.

• Behandeln Sie alle Testartefakte als Code. Sie sollten zusammen mit anderen Anwendungscodeartefakten verwaltet und versionsgesteuert werden.

• Richten Sie die SLA der Testinfrastruktur mit der SLA für Bereitstellungs- und Testzyklen aus.

• Führen Sie Rauchtests als Teil jeder Bereitstellung aus. Führen Sie auch umfangreiche Belastungstests zusammen mit Stress- und Chaostests durch, um zu überprüfen, ob die Anwendungsleistung und Die Operierbarkeit beibehalten werden.

  • Verwenden Sie Ladeprofile, die echte Spitzenauslastungsmuster widerspiegeln.
  • Führen Sie Chaosexperimente und Fehlerinjektionstests gleichzeitig mit Lasttests durch.

  Tipp

  Azure Chaos Studio ist eine native Suite von Chaosexperimentstools. Die Tools erleichtern die Durchführung von Chaosexperimenten und das Einfügen von Fehlern in Azure-Dienste und Anwendungskomponenten.

  Chaos Studio bietet integrierte Chaosexperimente für häufige Fehlerszenarien und unterstützt benutzerdefinierte Experimente, die auf Infrastruktur und Anwendungskomponenten abzielen.

• Wenn Datenbankinteraktionen wie die Erstellung von Datensätzen für Auslastungs- oder Rauchtests erforderlich sind, verwenden Sie Testkonten mit eingeschränkten Berechtigungen und machen Testdaten von echten Benutzerinhalten getrennt.

• Scannen und überwachen Sie die End-to-End-Software-Lieferkette und Paketabhängigkeiten für bekannte CVEs.

  • Verwenden Sie Dependabot für GitHub-Repositorys, um sicherzustellen, dass das Repository automatisch mit den neuesten Versionen von Paketen und Anwendungen auf dem neuesten Stand ist, von denen es abhängt.

Infrastruktur als Codebereitstellungen

Infrastruktur als Code (IaC) behandelt Infrastrukturdefinitionen als Quellcode, der zusammen mit anderen Anwendungsartefakten gesteuert wird. Die Verwendung von IaC fördert die Codekonsistenz in allen Umgebungen, beseitigt das Risiko von menschlichem Fehler während automatisierter Bereitstellungen und bietet Rückverfolgbarkeit und Rollback. Für blaue/grüne Bereitstellungen ist die Verwendung von IaC mit vollständig automatisierten Bereitstellungen zwingend erforderlich.

Ein unternehmenskritisches IaC-Repository verfügt über zwei unterschiedliche Definitionen, die globalen und regionalen Ressourcen zugeordnet sind. Informationen zu diesen Ressourcentypen finden Sie im Kernarchitekturmuster.

Überlegungen zum Entwurf

• Wiederholbare Infrastruktur. Stellen Sie unternehmenskritische Workloads auf eine Weise bereit, die jedes Mal dieselbe Umgebung generiert. IaC sollte das primäre Modell sein.

• Automatisierung. Alle Bereitstellungen müssen vollständig automatisiert sein. Menschliche Prozesse sind fehleranfällig.

Entwurfsempfehlungen

• Wenden Sie IaC an, um sicherzustellen, dass alle Azure-Ressourcen in deklarativen Vorlagen definiert und in einem Quellcodeverwaltungs-Repository verwaltet werden. Vorlagen werden bereitgestellt, und Ressourcen werden automatisch über CI/CD-Pipelines aus der Quellcodeverwaltung bereitgestellt. Es wird nicht empfohlen, imperative Skripts zu verwenden.

• Verbieten manueller Vorgänge für alle Umgebungen. Die einzige Ausnahme ist vollständig unabhängige Entwicklerumgebungen.

DevOps-Tools

Die effektive Verwendung von Bereitstellungstools ist für die allgemeine Zuverlässigkeit von entscheidender Bedeutung, da DevOps-Prozesse sich auf die gesamte Funktion und den Anwendungsentwurf auswirken. Beispielsweise können Failover- und Skalierungsvorgänge von der Automatisierung abhängen, die von DevOps-Tools bereitgestellt wird. Entwicklungsteams müssen die Auswirkungen der Nichtverfügbarkeit eines Bereitstellungsdiensts im Hinblick auf die Gesamtauslastung verstehen. Bereitstellungstools müssen zuverlässig und hoch verfügbar sein.

Microsoft bietet zwei systemeigene Azure-Toolsets, GitHub-Aktionen und Azure-Pipelines, die eine unternehmenskritische Anwendung effektiv bereitstellen und verwalten können.

Überlegungen zum Entwurf

• Technologiefunktionen. Die Funktionen von GitHub und Azure DevOps überlappen sich. Sie können sie zusammen verwenden, um das Beste aus beiden zu bekommen. Ein gängiger Ansatz besteht darin, Coderepositorys in GitHub.com oder GitHub AE zu speichern, während Azure Pipelines für die Bereitstellung verwendet werden.

  Beachten Sie die Komplexität, die bei Verwendung mehrerer Technologien hinzugefügt wird. Bewerten Sie einen umfassenden Funktionssatz anhand der gesamten Zuverlässigkeit.

• Regionale Verfügbarkeit. Hinsichtlich der maximalen Zuverlässigkeit stellt die Abhängigkeit von einer einzelnen Azure-Region ein betriebsbedingtes Risiko dar.

  Angenommen, der Verkehr erstreckt sich über zwei Regionen: Region 1 und Region 2. Region 2 hosten die Azure DevOps-Toolinstanz. Angenommen, es gibt einen Ausfall in Region 2, und die Instanz ist nicht verfügbar. Region 1 verarbeitet automatisch den gesamten Datenverkehr und muss zusätzliche Skalierungseinheiten bereitstellen, um eine gute Failovererfahrung zu bieten. Aufgrund der Azure DevOps-Abhängigkeit in Region 2 ist dies jedoch nicht möglich.

• Datenreplikation. Daten, einschließlich Metadaten, Pipelines und Quellcode, sollten in allen Regionen repliziert werden.

Entwurfsempfehlungen

• Beide Technologien werden in einer einzigen Azure-Region gehostet, wodurch Ihre Notfallwiederherstellungsstrategie restriktiver wird.

  GitHub-Aktionen eignen sich gut für Buildaufgaben (kontinuierliche Integration), aber möglicherweise fehlen Features für komplexe Bereitstellungsaufgaben (kontinuierliche Bereitstellung). Angesichts des umfangreichen Featuresatzes von Azure DevOps empfehlen wir es für unternehmenskritische Bereitstellungen. Sie sollten jedoch eine Auswahl treffen, nachdem Sie Die Trade-Offs bewertet haben.

• Definieren Sie eine Verfügbarkeits-SLA für Bereitstellungstools, und stellen Sie die Ausrichtung mit breiteren Anforderungen an die Anwendungssicherheit sicher.

• Stellen Sie bei Szenarien mit mehreren Regionen, die eine Konfiguration für die aktive/passive oder aktive/aktive Bereitstellung verwenden, sicher, dass Failover-Orchestrierungs- und Skalierungsvorgänge weiterhin funktionieren können, auch wenn die Toolsets der primären Region, die Bereitstellungstools hosten, nicht mehr verfügbar sind.

Verzweigungsstrategie

Es gibt viele gültige Ansätze zur Verzweigung. Sie sollten eine Strategie auswählen, die eine maximale Zuverlässigkeit gewährleistet. Eine gute Strategie ermöglicht parallele Entwicklung, bietet einen klaren Weg von der Entwicklung zur Produktion und unterstützt schnelle Versionen.

Überlegungen zum Entwurf

• Minimieren Sie den Zugriff. Entwickler sollten ihre Arbeit in feature/* und fix/* Zweigniederlassungen erledigen. Diese Verzweigungen werden zu Einstiegspunkten für Änderungen. Rollenbasierte Einschränkungen sollten im Rahmen der Verzweigungsstrategie auf Zweigniederlassungen angewendet werden. Ermöglichen Sie Administratoren beispielsweise nur das Erstellen von Release branches oder erzwingen Benennungskonventionen für Verzweigungen.

• Beschleunigter Prozess für Notfälle. Die Verzweigungsstrategie sollte es ermöglichen, Dass Hotfixes so schnell wie möglich zusammengeführt main werden. Auf diese Weise werden zukünftige Versionen die Lösung enthalten, und die Wiederholung des Problems wird vermieden. Verwenden Sie diesen Prozess nur für geringfügige Änderungen, die dringende Probleme behandeln, und verwenden Sie ihn mit Zurückhaltung.

Entwurfsempfehlungen

• Priorisieren Sie die Verwendung von GitHub für die Quellcodeverwaltung.

  Wichtig

  Erstellen Sie eine Verzweigungsstrategie, in der die Funktion funktioniert und veröffentlicht wird, und verwenden Sie Verzweigungsrichtlinien und -berechtigungen, um sicherzustellen, dass die Strategie ordnungsgemäß erzwungen wird.

• Auslösen eines automatisierten Testprozesses zum Überprüfen von Codeänderungsbeiträgen, bevor sie akzeptiert werden. Teammitglieder müssen auch Änderungen überprüfen.

• Behandeln Sie die main Verzweigung als kontinuierlich vorwärts bewegenden und stabilen Zweig, der in erster Linie für Integrationstests verwendet wird.

  • Stellen Sie sicher, dass Änderungen nur über PRs vorgenommen main werden. Verwenden Sie eine Verzweigungsrichtlinie, um direkte Commits zu verbieten.
  • Jedes Mal, wenn eine PR zusammengeführt mainwird, sollte sie automatisch eine Bereitstellung mit einer Integrationsumgebung starten.
  • Die main Verzweigung sollte als stabil betrachtet werden. Es sollte sicher sein, jederzeit eine Freigabe main zu erstellen.

• Verwenden Sie dedizierte release/* Verzweigungen, die aus der main Verzweigung erstellt und für die Bereitstellung in Produktionsumgebungen verwendet werden. release/* Verzweigungen sollten im Repository verbleiben und können verwendet werden, um eine Version zu patchen.

• Dokumentieren Sie einen Hotfixprozess, und verwenden Sie ihn nur bei Bedarf. Erstellen Sie Hotfixes in einer fix/* Verzweigung für die nachfolgende Zusammenführung in die Release-Verzweigung und Bereitstellung in die Produktion.

KI für DevOps

Sie können AIOps-Methoden in CI/CD-Pipelines anwenden, um herkömmliche Testansätze zu ergänzen. Auf diese Weise können potenzielle Regressionen oder Beeinträchtigungen erkannt werden und Bereitstellungen präventiv gestoppt werden, um potenzielle negative Auswirkungen zu verhindern.

Überlegungen zum Entwurf

• Volumen der Telemetriedaten. CI/CD-Pipelines und DevOps-Prozesse geben eine Vielzahl von Telemetrie für Machine Learning-Modelle aus. Die Telemetrie reicht von Testergebnissen und Bereitstellungsergebnissen bis hin zu Betriebsdaten zu Testkomponenten aus zusammengesetzten Bereitstellungsphasen.

• Skalierbarkeit. Herkömmliche Datenverarbeitungsansätze wie Extract, Transform, Load (ETL) können möglicherweise nicht den Durchsatz skalieren, um mit dem Wachstum der Bereitstellungs-Telemetrie- und Anwendungs-Observability-Daten schritt zu halten. Sie können moderne Analyseansätze verwenden, die keine ETL- und Datenverschiebung erfordern, z. B. Datenvirtualisierung, um eine fortlaufende Analyse durch AIOps-Modelle zu ermöglichen.

• Bereitstellungsänderungen. Änderungen in der Bereitstellung müssen zur automatisierten Analyse und Korrelation zu Bereitstellungsergebnissen gespeichert werden.

Entwurfsempfehlungen

• Definieren Sie die DevOps-Prozessdaten, die erfasst werden sollen, und wie sie analysiert werden. Telemetrie, z. B. Testausführungsmetriken und Zeitreihendaten von Änderungen innerhalb jeder Bereitstellung, ist wichtig.

  • Machen Sie Anwendungsbeobachtbarkeitsdaten aus Staging-, Test- und Produktionsumgebungen zur Analyse und Korrelation in AIOps-Modellen verfügbar.

• Übernehmen Sie den MLOps-Workflow.

• Entwickeln Sie analytische Modelle, die kontext- und abhängigkeitsfähig sind, um Vorhersagen mit automatisiertem Feature engineering bereitzustellen, um Schema- und Verhaltensänderungen zu behandeln.

• Operationalisieren Sie Modelle, indem Sie die am besten trainierten Modelle in Bereitstellungspipelinen registrieren und bereitstellen.

Nächster Schritt

Überprüfen Sie die Sicherheitsüberlegungen.