Betriebsverfahren für unternehmenskritische Workloads in Azure
Zuverlässige und effektive Vorgänge müssen nach Möglichkeit auf den Prinzipien der Automatisierung und der Konfiguration als Code basieren. Dieser Ansatz erfordert erhebliche Technische Investitionen in DevOps-Prozesse. Automatisierte Pipelines werden verwendet, um Anwendungs- und Infrastrukturcodeartefakte bereitzustellen. Zu den Vorteilen dieses Ansatzes gehören konsistente und genaue Betriebsergebnisse mit minimalen manuellen Betriebsabläufen.
In diesem Entwurfsbereich wird untersucht, wie effektive und konsistente betriebsbezogene Verfahren implementiert werden.
Wichtig
Dieser Artikel ist Teil der unternehmenskritischen Workloadreihe von Azure Well-Architected Framework . Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit Was ist eine unternehmenskritische Workload zu beginnen?
DevOps-Prozesse
DevOps kombiniert Entwicklungs- und Betriebsprozesse und -teams in einer einzigen Engineering-Funktion. Es umfasst den gesamten Anwendungslebenszyklus und verwendet Automatisierungs- und DevOps-Tools, um Bereitstellungsvorgänge schnell, effizient und zuverlässig durchzuführen. DevOps-Prozesse unterstützen und unterstützen Continuous Integration und Continuous Delivery (CI/CD) und fördern gleichzeitig eine Kultur der kontinuierlichen Verbesserung.
Das DevOps-Team für eine unternehmenskritische Anwendung muss für diese Aufgaben verantwortlich sein:
- Erstellung und Verwaltung von Anwendungs- und Infrastrukturressourcen über CI/CD-Automatisierung.
- Anwendungsüberwachung und -beobachtbarkeit.
- Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Azure und Identitätsverwaltung für Anwendungskomponenten.
- Netzwerkverwaltung für Anwendungskomponenten.
- Kostenverwaltung für Anwendungsressourcen.
DevSecOps erweitert das DevOps-Modell durch die Integration von Sicherheitsüberwachung, Anwendungsüberwachungen und Qualitätssicherung in Entwicklung und Betrieb während des gesamten Anwendungslebenszyklus. DevOps-Teams werden für sicherheitsrelevante und streng regulierte Szenarien benötigt, um sicherzustellen, dass die Sicherheit während des gesamten Entwicklungslebenszyklus integriert wird und nicht in einer bestimmten Releasephase oder einem bestimmten Gate.
Überlegungen zum Entwurf
Release- und Updateprozess. Vermeiden Sie manuelle Prozesse für änderungen an Anwendungskomponenten oder der zugrunde liegenden Infrastruktur. Manuelle Prozesse können zu inkonsistenten Ergebnissen führen.
Abhängigkeiten von zentralen IT-Teams. DevOps-Prozesse können schwierig anzuwenden sein, wenn es feste Abhängigkeiten von zentralisierten Funktionen gibt, da diese Abhängigkeiten End-to-End-Vorgänge verhindern.
Identitäts- und Zugriffsverwaltung. DevOps-Teams können differenzierte Azure RBAC-Rollen für verschiedene technische Funktionen wie AppDataOps für die Datenbankverwaltung in Betracht ziehen. Wenden Sie ein Zero-Trust-Modell auf DevOps-Rollen an.
Entwurfsempfehlungen
Definieren Sie Konfigurationseinstellungen und Updates als Code. Wenden Sie die Änderungsverwaltung über Code an, um konsistente Release- und Updateprozesse zu ermöglichen, einschließlich Aufgaben wie Schlüssel- oder Geheimnisrotation und Berechtigungsverwaltung. Verwenden Sie von der Pipeline verwaltete Updateprozesse, z. B. geplante Pipelineausführungen, anstatt integrierte Mechanismen für automatische Updates zu verwenden.
Verwenden Sie keine zentralen Prozesse oder Bereitstellungspipelines für die Instanziierung oder Verwaltung von Anwendungsressourcen. Dadurch werden externe Anwendungsabhängigkeiten und zusätzliche Risikovektoren eingeführt, z. B. solche, die mit Szenarios für verrauschte Nachbarn verbunden sind.
Wenn Sie zentralisierte Bereitstellungsprozesse verwenden müssen, stellen Sie sicher, dass die Verfügbarkeitsanforderungen der Abhängigkeiten vollständig auf unternehmenskritische Anforderungen abgestimmt sind. Zentrale Teams müssen für Transparenz sorgen, damit eine ganzheitliche Operationalisierung der End-to-End-Anwendung erreicht wird.
Weisen Sie während jedes Sprints einen Teil der Engineeringkapazität auf, um grundlegende Plattformverbesserungen zu verbessern und die Zuverlässigkeit zu erhöhen. Es wird empfohlen, diesen Verbesserungen 20 bis 40 Prozent der Kapazität zuzuweisen.
Entwickeln Sie allgemeine Technische Kriterien, Referenzarchitekturen und Bibliotheken, die mit den grundlegenden Entwurfsprinzipien abgestimmt sind. Erzwingen Sie eine konsistente Baselinekonfiguration für Zuverlässigkeit, Sicherheit und Vorgänge über einen richtliniengesteuerten Ansatz, der Azure Policy verwendet.
Sie können auch die allgemeinen Technischen Kriterien und zugehörigen Artefakte wie Azure-Richtlinien und Terraform-Ressourcen für allgemeine Entwurfsmuster für andere Workloads innerhalb des breiteren Anwendungsökosystems Ihrer organization verwenden.
Wenden Sie ein Zero-Trust-Modell in kritischen Anwendungsumgebungen an. Verwenden Sie Technologien wie Microsoft Entra Privileged Identity Management, um sicherzustellen, dass Vorgänge konsistent sind und nur über CI/CD-Prozesse oder automatisierte Betriebsprozeduren erfolgen.
Teammitglieder sollten keinen ständigen Schreibzugriff auf eine Umgebung haben. Möglicherweise möchten Sie Ausnahmen in Entwicklungsumgebungen vornehmen, um das Testen und Debuggen zu vereinfachen.
Definieren Sie Notfallprozesse für den Just-in-Time-Zugriff auf Produktionsumgebungen. Stellen Sie sicher, dass Bei schwerwiegenden Problemen mit dem Authentifizierungsanbieter Break glass-Konten vorhanden sind.
Erwägen Sie die Verwendung von AIOps, um operative Verfahren und Trigger kontinuierlich zu verbessern.
Anwendungsvorgänge
Der Anwendungsentwurf und die Plattformempfehlungen beeinflussen die betrieblichen Abläufe. Es gibt auch Betriebsfunktionen, die von verschiedenen Azure-Diensten bereitgestellt werden, insbesondere für Hochverfügbarkeit und Wiederherstellung.
Überlegungen zum Entwurf
Integrierte Vorgänge von Azure-Diensten. Azure-Dienste bieten integrierte (standardmäßig aktivierte) und konfigurierbare Plattformfunktionen wie Zonenredundanz und Georeplikation. Die Zuverlässigkeit einer Anwendung hängt von diesen Vorgängen ab. Bestimmte konfigurierbare Funktionen verursachen zusätzliche Kosten, z. B. die Konfiguration der Bereitstellung mit mehreren Schreibvorgängen für Azure Cosmos DB. Vermeiden Sie das Erstellen benutzerdefinierter Lösungen, es sei denn, Dies ist unbedingt erforderlich.
Betriebszugriff und Ausführungszeit. Die meisten erforderlichen Vorgänge werden über die Azure Resource Manager-API oder die Azure-Portal verfügbar gemacht und zugänglich gemacht. Bestimmte Vorgänge erfordern jedoch Unterstützung von Supporttechnikern. Beispielsweise kann eine Wiederherstellung aus einer regelmäßigen Sicherung einer Azure Cosmos DB-Datenbank oder die Wiederherstellung einer gelöschten Ressource nur von Azure-Support Technikern über einen Supportfall durchgeführt werden. Diese Abhängigkeit kann sich auf die Ausfallzeit der Anwendung auswirken. Für zustandslose Ressourcen wird empfohlen, dass Sie erneut bereitstellen, anstatt darauf zu warten, dass Supporttechniker versuchen, gelöschte Ressourcen wiederherzustellen.
Richtlinienerzwingung. Azure Policy bietet ein Framework zum Erzwingen und Überwachen von Sicherheits- und Zuverlässigkeitsbaselines, um die Einhaltung gängiger Technischer Kriterien für unternehmenskritische Anwendungen sicherzustellen. Genauer gesagt bildet Azure Policy einen wichtigen Bestandteil der Steuerungsebene von Azure Resource Manager und ergänzt RBAC, indem die Aktionen eingeschränkt werden, die autorisierte Benutzer ausführen können. Sie können Azure Policy verwenden, um wichtige Sicherheits- und Zuverlässigkeitskonventionen für plattformübergreifende Dienste durchzusetzen.
Ändern und Löschen von Ressourcen. Sie können Azure-Ressourcen sperren , um zu verhindern, dass sie geändert oder gelöscht werden. Sperren führen jedoch zu Verwaltungsaufwand in Bereitstellungspipelines. Für die meisten Ressourcen empfehlen wir einen robusten RBAC-Prozess mit engen Einschränkungen anstelle von Ressourcensperren.
Entwurfsempfehlungen
Automatisieren von Failoverprozeduren Verwenden Sie für ein Aktiv/Aktiv-Modell ein Integritätsmodell und automatisierte Skalierungsvorgänge, um sicherzustellen, dass kein Failovereingriff erforderlich ist. Stellen Sie bei einem Aktiv/Passiv-Modell sicher, dass Failoverprozeduren innerhalb von Pipelines automatisiert oder zumindest kodifiziert sind.
Priorisieren Sie die Verwendung der nativen automatischen Skalierung von Azure für Dienste, die dies unterstützen. Verwenden Sie für Dienste, die keine native automatische Skalierung unterstützen, automatisierte betriebliche Prozesse, um Dienste zu skalieren. Verwenden Sie Skalierungseinheiten mit mehreren Diensten, um Skalierbarkeit zu erzielen.
Verwenden Sie plattformnative Funktionen für Sicherung und Wiederherstellung, um sicherzustellen, dass sie ihren RTO/RPO- und Datenaufbewahrungsanforderungen entsprechen. Definieren Sie bei Bedarf eine Strategie für die langfristige Aufbewahrung von Sicherungen.
Verwenden Sie integrierte Funktionen für die SSL-Zertifikatverwaltung und -verlängerung, wie sie von Azure Front Door bereitgestellt werden.
Richten Sie für externe Teams einen Wiederherstellungsprozess für Ressourcen ein, die Unterstützung benötigen. Wenn die Datenplattform beispielsweise fälschlicherweise geändert oder gelöscht wird, sollten die Wiederherstellungsmethoden gut verstanden werden, und es sollte ein Wiederherstellungsprozess vorhanden sein. Richten Sie auf ähnliche Weise Verfahren zum Verwalten außer Betrieb gesetzter Containerimages in der Registrierung ein.
Üben Sie Recovery-Vorgänge im Voraus auf Nichtproduktionsressourcen und -daten als Teil der standardmäßigen Vorbereitungen für die Geschäftskontinuität.
Identifizieren sie kritische Warnungen und definieren Sie Zielgruppen und Systeme. Definieren Sie klare Kanäle, um geeignete Stakeholder zu erreichen. Senden Sie nur umsetzbare Warnungen, um weißes Rauschen zu vermeiden und zu verhindern, dass betriebsbeteiligte Personen Warnungen ignorieren und wichtige Informationen fehlen. Implementieren Sie kontinuierliche Verbesserungen, um Warnungen zu optimieren und beobachtetes weißes Rauschen zu entfernen.
Wenden Sie richtliniengesteuerte Governance und Azure Policy an, um eine angemessene Nutzung der operativen Funktionen und eine zuverlässige Konfigurationsbaseline für alle Anwendungsdienste sicherzustellen.
Vermeiden Sie die Verwendung von Ressourcensperren für kurzlebige regionale Ressourcen. Verwenden Sie stattdessen die geeignete Verwendung von RBAC- und CI/CD-Pipelines, um betriebsbezogene Updates zu steuern. Sie können Ressourcensperren anwenden, um das Löschen langlebiger globaler Ressourcen zu verhindern.
Updateverwaltung
Der unternehmenskritische Entwurf unterstützt nachdrücklich das Prinzip kurzlebiger zustandsloser Anwendungsressourcen. Wenn Sie dieses Prinzip anwenden, können Sie in der Regel ein Update mithilfe einer neuen Bereitstellungs- und Standardbereitstellungspipeline durchführen.
Überlegungen zum Entwurf
Ausrichtung auf Azure-Roadmaps. Richten Sie Ihre Workload an Azure-Roadmaps aus, sodass Plattformressourcen und Laufzeitabhängigkeiten regelmäßig aktualisiert werden.
Automatische Erkennung von Updates. Richten Sie Prozesse ein, um Updates zu überwachen und automatisch zu erkennen. Verwenden Sie Tools wie GitHub Dependabot.
Testen und Überprüfen. Testen und überprüfen Sie neue Versionen von Paketen, Komponenten und Abhängigkeiten in einem Produktionskontext vor jeder Veröffentlichung. Neue Versionen können breaking changes enthalten.
Laufzeitabhängigkeiten. Behandeln Sie Laufzeitabhängigkeiten wie andere Änderungen an der Anwendung. Ältere Versionen können Sicherheitsrisiken mit sich bringen und sich negativ auf die Leistung auswirken. Überwachen Sie die Anwendungslaufzeitumgebung, und halten Sie sie auf dem neuesten Stand.
Komponentenhygiene und Housekeeping. Außerbetriebnahme oder Entfernen von Ressourcen, die nicht verwendet werden. Überwachen Sie beispielsweise Containerregistrierungen und löschen Sie alte Imageversionen, die Sie nicht verwenden.
Entwurfsempfehlungen
Überwachen Sie diese Ressourcen, und halten Sie sie auf dem neuesten Stand:
- Die Anwendungshostingplattform. Beispielsweise müssen Sie die Kubernetes-Version in Azure Kubernetes Service (AKS) regelmäßig aktualisieren, insbesondere, wenn die Unterstützung für ältere Versionen nicht aufrechterhalten wird. Sie müssen auch Komponenten aktualisieren, die auf Kubernetes ausgeführt werden, z. B. cert-manager und azure Key Vault CSI, und sie an die Kubernetes-Version in AKS ausrichten.
- Externe Bibliotheken und SDKs (.NET, Java, Python).
- Terraform-Anbieter.
Vermeiden Sie manuelle betriebliche Änderungen beim Aktualisieren von Komponenten. Erwägen Sie die Verwendung manueller Änderungen nur in Notfallsituationen. Stellen Sie sicher, dass Sie über einen Prozess zum Abgleich manueller Änderungen wieder im Quellrepository verfügen, um Drift und Wiederholungen zu vermeiden.
Richten Sie ein automatisiertes Verfahren zum Entfernen alter Versionen von Images aus Azure Container Registry ein.
Verwaltung von Geheimnissen
Ablaufzeiten von Schlüsseln, Geheimnissen und Zertifikaten sind eine häufige Ursache für Anwendungsausfälle. Die Geheimverwaltung für eine unternehmenskritische Anwendung muss die erforderliche Sicherheit bieten und ein angemessenes Maß an Verfügbarkeit bieten, um Ihren Anforderungen an die maximale Zuverlässigkeit gerecht zu werden. Sie müssen die Schlüssel-, Geheimnis- und Zertifikatrotation regelmäßig mithilfe eines verwalteten Diensts oder im Rahmen der Updateverwaltung durchführen und Prozesse für Code- und Konfigurationsänderungen anwenden.
Viele Azure-Dienste unterstützen Microsoft Entra-Authentifizierung, anstatt sich auf Verbindungszeichenfolgen/-schlüssel zu verlassen. Die Verwendung Microsoft Entra ID reduziert den Betriebsaufwand erheblich. Wenn Sie eine Geheimnisverwaltungslösung verwenden, sollte sie in andere Dienste integriert werden, zonenbezogene und regionale Redundanz unterstützen und die Integration mit Microsoft Entra ID für Authentifizierung und Autorisierung ermöglichen. Key Vault stellt diese Features bereit.
Überlegungen zum Entwurf
Es gibt drei gängige Ansätze für die Verwaltung von Geheimnissen. Jeder Ansatz liest Geheimnisse aus dem Geheimspeicher und fügt sie zu einem anderen Zeitpunkt in die Anwendung ein.
Abruf der Bereitstellungszeit. Der Vorteil dieses Ansatzes besteht darin, dass die Lösung für die Geheimverwaltung nur zur Bereitstellungszeit verfügbar sein muss, da es nach diesem Zeitpunkt keine direkten Abhängigkeiten mehr gibt. Beispiele hierfür sind das Einfügen von Geheimnissen als Umgebungsvariablen in eine Kubernetes-Bereitstellung oder in ein Kubernetes-Geheimnis.
Nur der Bereitstellungsdienstprinzipal muss auf Geheimnisse zugreifen können, was RBAC-Berechtigungen innerhalb des Geheimverwaltungssystems vereinfacht.
Dieser Ansatz hat jedoch Nachteile. Es führt RBAC-Komplexität in DevOps-Tools in Bezug auf die Steuerung des Dienstprinzipalszugriffs und in der Anwendung in Bezug auf den Schutz abgerufener Geheimnisse ein. Außerdem werden die Sicherheitsvorteile der Geheimverwaltungslösung nicht angewendet, da dieser Ansatz nur von der Zugriffssteuerung auf der Anwendungsplattform abhängt.
Um geheime Updates oder Rotationen zu implementieren, müssen Sie eine vollständige erneute Bereitstellung durchführen.
Anwendungsstartabruf. Bei diesem Ansatz werden Geheimnisse abgerufen und beim Anwendungsstart eingefügt. Der Vorteil besteht darin, dass Sie Geheimnisse problemlos aktualisieren oder rotieren können. Sie müssen keine Geheimnisse auf der Anwendungsplattform speichern. Ein Neustart der Anwendung ist erforderlich, um den neuesten Wert abzurufen.
Zu den gängigen Speicheroptionen gehören azure Key Vault Provider for Secrets Store CSI Driver und akv2k8s. Eine native Azure-Lösung Key Vault App-Einstellungen, auf die verwiesen wird, ist ebenfalls verfügbar.
Ein Nachteil dieses Ansatzes ist, dass eine Laufzeitabhängigkeit von der Lösung für die Geheimverwaltung erstellt wird. Wenn die Geheimnisverwaltungslösung zu einem Ausfall kommt, können bereits ausgeführte Anwendungskomponenten möglicherweise weiterhin Anforderungen bereitstellen. Jeder Neustart- oder Horizontalskalierungsvorgang würde wahrscheinlich zu einem Fehler führen.
Runtimeabruf. Das Abrufen von Geheimnissen zur Laufzeit aus der Anwendung selbst ist der sicherste Ansatz, da selbst die Anwendungsplattform nie Zugriff auf Geheimnisse hat. Die Anwendung muss sich beim Geheimverwaltungssystem authentifizieren.
Für diesen Ansatz erfordern Anwendungskomponenten jedoch eine direkte Abhängigkeit und eine Verbindung mit dem Geheimverwaltungssystem. Dies erschwert das individuelle Testen von Komponenten und erfordert in der Regel die Verwendung eines SDK.
Entwurfsempfehlungen
Verwenden Sie nach Möglichkeit Microsoft Entra Authentifizierung, um eine Verbindung mit Diensten herzustellen, anstatt Verbindungszeichenfolgen oder -schlüssel zu verwenden. Verwenden Sie diese Authentifizierungsmethode zusammen mit verwalteten Azure-Identitäten, damit Sie keine Geheimnisse auf der Anwendungsplattform speichern müssen.
Nutzen Sie die Ablaufeinstellung in Key Vault, und konfigurieren Sie Warnungen für bevorstehende Ablaufvorgänge. Führen Sie alle Schlüssel-, Geheimnis- und Zertifikatupdates mithilfe des Standardversionsprozesses aus.
Stellen Sie Key Vault-Instanzen als Teil eines regionalen Stempels bereit, um die potenziellen Auswirkungen eines Fehlers auf einen einzelnen Bereitstellungsstempel zu minimieren. Verwenden Sie eine separate instance für globale Ressourcen. Informationen zu diesen Ressourcen finden Sie im typischen Architekturmuster für unternehmenskritische Workloads.
Um die Verwaltung von Dienstprinzipalanmeldeinformationen oder API-Schlüsseln zu vermeiden, verwenden Sie verwaltete Identitäten anstelle von Dienstprinzipalen, um nach Möglichkeit auf Key Vault zuzugreifen.
Implementieren Sie Codierungsmuster, um sicherzustellen, dass Geheimnisse erneut abgerufen werden, wenn zur Laufzeit ein Autorisierungsfehler auftritt.
Wenden Sie einen vollständig automatisierten Schlüsselrotationsprozess an, der in regelmäßigen Abständen innerhalb der Lösung ausgeführt wird.
Verwenden Sie die Benachrichtigung zum nahen Ablauf des Schlüssels in Azure Key Vault, um Warnungen zu bevorstehenden Ablaufen zu erhalten.
IaaS-spezifische Überlegungen bei der Verwendung von VMs
Wenn Sie IaaS-VMs verwenden müssen, können sich einige der weiter oben in diesem Dokument beschriebenen Verfahren und Methoden unterscheiden. Die Verwendung von VMs bietet mehr Flexibilität bei Konfigurationsoptionen, Betriebssystemen, Treiberzugriff, Betriebssystemzugriff auf niedriger Ebene und der Art von Software, die Sie installieren können. Die Nachteile sind erhöhte Betriebskosten und die Verantwortung für Aufgaben, die normalerweise vom Cloudanbieter ausgeführt werden, wenn Sie PaaS-Dienste verwenden.
Überlegungen zum Entwurf
- Einzelne VMs bieten keine Hochverfügbarkeit, Zonenredundanz oder Georedundanz.
- Einzelne VMs werden nach der Bereitstellung nicht automatisch aktualisiert. Beispielsweise wird eine bereitgestellte SQL Server 2019 unter Windows Server 2019 nicht automatisch auf eine neuere Version aktualisiert.
- Dienste, die auf einem virtuellen Computer ausgeführt werden, benötigen eine spezielle Behandlung und zusätzliche Tools, wenn Sie sie über die Infrastruktur als Code bereitstellen und konfigurieren möchten.
- Azure aktualisiert seine Plattform in regelmäßigen Abständen. Für diese Updates müssen möglicherweise VM-Neustarts durchgeführt werden. Updates, die einen Neustart erfordern, werden in der Regel im Voraus angekündigt. Weitere Informationen finden Sie unter Wartung für virtuelle Computer in Azure und Behandeln geplanter Wartungsbenachrichtigungen.
Entwurfsempfehlungen
Vermeiden Sie manuelle Vorgänge auf virtuellen Computern, und implementieren Sie geeignete Prozesse zum Bereitstellen und Rollout von Änderungen.
- Automatisieren Sie die Bereitstellung von Azure-Ressourcen mithilfe von Infrastructure-as-Code-Lösungen wie Arm-Vorlagen (Azure Resource Manager), Bicep, Terraform oder anderen Lösungen.
Stellen Sie sicher, dass die betrieblichen Prozesse für die Bereitstellung von VMs, Updates sowie Sicherung und Wiederherstellung vorhanden und ordnungsgemäß getestet werden. Um die Resilienz zu testen, fügen Sie Fehler in die Anwendung ein, notieren Sie Fehler, und minimieren Sie diese Fehler.
Stellen Sie sicher, dass Strategien vorhanden sind, um zum letzten bekannten fehlerfreien Zustand zurückzukehren, wenn eine neuere Version nicht ordnungsgemäß funktioniert.
Erstellen Sie häufige Sicherungen für zustandsbehaftete Workloads, stellen Sie sicher, dass Sicherungsaufgaben effektiv funktionieren, und implementieren Sie Warnungen für fehlgeschlagene Sicherungsprozesse.
Überwachen Sie VMs, und erkennen Sie Fehler. Die Rohdaten für die Überwachung können aus einer Vielzahl von Quellen stammen. Analysieren sie die Ursachen von Problemen.
Stellen Sie sicher, dass geplante Sicherungen wie erwartet ausgeführt werden und dass regelmäßige Sicherungen nach Bedarf erstellt werden. Sie können das Sicherungscenter verwenden, um Erkenntnisse zu erhalten.
Priorisieren Sie die Verwendung von Virtual Machine Scale Sets anstelle von VMs, um Funktionen wie Skalierung, automatische Skalierung und Zonenredundanz zu ermöglichen.
Priorisieren Sie die Verwendung von Standardimages aus Azure Marketplace anstelle von benutzerdefinierten Images, die verwaltet werden müssen.
Verwenden Sie Azure VM Image Builder oder andere Tools, um Build- und Wartungsprozesse für angepasste Images nach Bedarf zu automatisieren.
Wenden Sie über diese spezifischen Empfehlungen hinaus nach Bedarf bewährte Methoden für betriebsbezogene Verfahren für unternehmenskritische Anwendungsszenarien an.
Nächster Schritt
Überprüfen Sie das Architekturmuster für unternehmenskritische Anwendungsszenarien: