Empfehlungen für das Entwerfen einer Arbeitsauslastungsentwicklungs-Lieferkette

Gilt für diese Checkliste für azure Well-Architected Framework Operational Excellence:

In diesem Leitfaden werden die Empfehlungen für das Entwerfen einer Workload Development Supply Chain beschrieben, die auf kontinuierlichen Integrations- und Kontinuierlichen Übermittlungspipelines (CI/CD) basiert. Entwickeln Sie eine Lieferkette, um sicherzustellen, dass Sie über eine vorhersehbare, standardisierte Methode zur Aufrechterhaltung Ihrer Arbeitsauslastung verfügen. CI/CD-Pipelines sind die Manifestation der Lieferkette, aber Sie sollten eine einzige Lieferkette haben. Und Sie haben möglicherweise mehrere Pipelines, die denselben Prozessen folgen und dieselben Tools verwenden.

Integrieren Sie eine Lieferkette, um Ihre Arbeitsauslastung vor Schäden zu schützen, die auftreten können, wenn Sie Keine ordnungsgemäßen Workloadänderungen verwalten. Achten Sie immer auf den Zustand Ihrer Workload, sodass Sie nicht gefahren, unvorhersehbares Verhalten zu erleben. Diese Risikoverbindungen, wenn Sie kritische Zeit aufwenden müssen, um nicht berücksichtigte Änderungen zu berechnen, wenn Probleme auftreten. Um diese Risiken zu minimieren, standardisieren Sie die Prozesse und Tools, die Ihre Lieferkette definieren, und stellen Sie sicher, dass Ihr Workloadteam sich vollständig für die Verwendung einsetzt.

Definition

Wichtige Entwurfsstrategien

Die folgenden Empfehlungen können Ihnen dabei helfen, die kernen Sätze Ihrer Lieferkette zu definieren.

Erzwingen einer strengen Richtlinie für automatisierte vorlagenbasierte Bereitstellungen

Nehmen Sie vorgeschlagene Arbeitsauslastungsänderungen über Lieferkettenprozesse und -tools vor. Erzwingen Sie eine strenge Richtlinie für automatisierte vorlagenbasierte Bereitstellungen. Mit dieser Methode wird sichergestellt, dass die Konfiguration Ihrer Workload in allen Umgebungen standardisiert, gut definiert und eng gesteuert wird. Führen Sie für Umgebungen in einer Code-Heraufstufungskette keine Aktualisierungen mithilfe manueller Prozesse oder menschlicher Interaktion mit der Steuerungsebene der Cloudplattform aus, z. B. dem Portal oder einer API. Integrieren Sie alle Änderungen an der Umgebung über eine Pipeline, indem Sie die von Ihnen definierten Bereitstellungsmethoden ausführen. Um diese Richtlinie zu erzwingen, erwägen Sie, den Zugriff auf schreibgeschützt als Standard zu beschränken und ein Zugriffsautorisierungsgate zu verwenden, um Schreibzugriff zuzulassen.

Ein wichtiger Aspekt dieses Tenets ist, dass alle Änderungen bis zur Bereitstellung in der Produktion vorgeschlagen werden. Durch automatisierte Tests wie Integrations- und Rauchtests ermöglichen Sie Ihrer Lieferkette, Änderungen automatisch abzulehnen.

Bereitstellen einer wiederholbaren und unveränderlichen Infrastruktur als Code

Stellen Sie wiederholbare und unveränderliche Infrastruktur als Code (IaC) bereit. IaC ist die Verwaltung der Infrastruktur in einem beschreibenden Modell, das ein Versionierungssystem verwendet, das den Quellcode widerspiegelt. Wenn Sie eine Anwendung erstellen, sollte derselbe Quellcode jedes Mal, wenn er kompiliert wird, dieselbe Binärdatei erzeugen. Auf ähnliche Weise generiert ein IaC-Modell jedes Mal, wenn es angewendet wird, dieselbe Umgebung.

Integrieren Sie IaC, um sicherzustellen, dass Ihr Team einen standardmäßigen, bewährten Prozess befolgt. Einige Organisationen legen eine einzelne oder kleine Gruppe von Einzelpersonen fest, um Infrastruktur bereitzustellen und zu konfigurieren. Wenn Sie einen vollständig automatisierten Prozess implementieren, benötigen Infrastrukturbereitstellungen weniger Verwaltung von Einzelpersonen. Die Verantwortung wird an den Automatisierungsprozess und die Werkzeugerstellung übertragen. Teammitglieder können Infrastrukturbereitstellungen initiieren, um Konsistenz und Qualität aufrechtzuerhalten.

Entwerfen Sie Ihre Arbeitsauslastung als logische Gruppe von Komponenten, die Sie in einer Vorlage bündeln können, um Bereitstellungen einfach und wiederholbar zu machen. Sie können sich diese Bündel als Stempel oder Skalierungseinheiten vorstellen. Weitere Informationen finden Sie unter Bereitstellungsstempelmuster. Wenn Sie Ihre Workload bereitstellen müssen, um in eine andere Region oder Zone innerhalb derselben Region zu skalieren, stellen Sie einen Stempel mithilfe einer Pipeline bereit. Je nachdem, wie Sie Ihre Stempel entwerfen, können Sie eine Teilmenge Ihrer Workload anstelle der gesamten Workload bereitstellen. Schließen Sie Netzwerkkomponenten in Ihre IaC-Pipelines ein, um sicherzustellen, dass Ihre Bereitstellungsstempel automatisch eine Verbindung mit vorhandenen Ressourcen herstellen.

Um Ihre IaC-Pipeline für Konsistenz und Effizienz zu optimieren, entwerfen Sie eine unveränderliche Infrastruktur anstelle einer änderbaren Infrastruktur. Implementieren Sie eine unveränderliche Infrastruktur, um sicherzustellen, dass alle Systeme im Bereich gleichzeitig und identisch mit jeder Bereitstellung durch die aktualisierte Konfiguration ersetzt werden.

Verwenden Sie den gleichen Satz von Bereitstellungsartefakten in allen Umgebungen.

Verwenden Sie eine Gruppe von Coderessourcen und Artefakten in allen Umgebungen und Pipelines. Ein häufiges Problem für Organisationen ist, dass sich die Nicht-Produktivumgebungen von den Produktivumgebungen unterscheiden. Die manuelle Erstellung von Produktivumgebungen und Nicht-Produktivumgebungen kann dazu führen, dass die Konfigurationen der beiden Umgebungen nicht übereinstimmen. Diese Übereinstimmung verlangsamt Tests und macht wahrscheinlicher, dass Änderungen ein Produktionssystem beschädigen könnten. Ein IaC-Ansatz minimiert diese Probleme. Wenn Sie die IaC-Automatisierung verwenden, können Sie die gleichen Infrastrukturkonfigurationsdateien für alle Umgebungen verwenden, um nahezu identische Umgebungen zu erzeugen. Sie können den Infrastrukturkonfigurationsdateien Parameter hinzufügen und sie an die Anforderungen für jede Umgebung anpassen.

Zur Kontrolle der Kosten gibt es in der Regel eine Varianz zwischen Produktions- und Nichtproduktionsumgebungen. Häufig benötigen Sie nicht den gleichen Grad an Redundanz und Leistung in Nichtproduktionsumgebungen wie in der Produktion. Die Anzahl und SKU Ihrer Ressourcen können sich zwischen Umgebungen unterscheiden. Stellen Sie sicher, dass Sie die Varianz steuern und verstehen, indem Sie standardisierte Parameter verwenden, um die Vorhersagbarkeit zu gewährleisten, während Sie Änderungen vornehmen.

Widerspiegeln der Organisationsstruktur in der Lieferkette

Spiegeln Sie Ihre Organisationsstruktur in Ihren Lieferketten- und Pipelinedesigns wider. Ihre Organisation kann zwischen Teams isoliert werden. Jedes Team kann einen Teil der Lieferkette verwalten. Beispielsweise verfügen viele Organisationen über Teams, die Infrastrukturdomänen verwalten, z. B. Netzwerk, Daten und Computeressourcen. Diese Teams sind von Entwicklungsteams getrennt, die Anwendungsentwicklung, Tests und Bereitstellungen verwalten. In einigen Organisationen werden Entwicklungs- und Infrastrukturteams in DevOps-Teams integriert, die alle Infrastruktur- und Anwendungsbereitstellungen gemeinsam verwalten. Es gibt viele Möglichkeiten, die Teams zu organisieren, die an einer Lieferkette beteiligt sind. Ihre Lieferkette basiert auf allen Teams, die nahtlos zusammenarbeiten. Stellen Sie sicher, dass alle Teams Standardprozesse befolgen und Standardtools verwenden, um die Lieferkette so effizient wie möglich zu gestalten.

Ihre Lieferkette hängt möglicherweise von Drittanbietern ab, wenn Sie Teile des Workload-Lebenszyklus auslagern. Diese Anbieter sind ebenso wichtig für den Erfolg Ihrer Lieferkette wie interne Ressourcen. Stellen Sie sicher, dass es in allen Teams eine gegenseitige Vereinbarung über die von Ihnen verwendeten Prozesse und Tools gibt.

Auswählen der richtigen Bereitstellungsmethode

Standardisieren Sie Ihre Bereitstellungsmethode. Sprechen Sie mit dem Product Owner über den akzeptablen Umfang der Produktionsausfallzeit für Ihre Workload. Je nachdem, wie viel, wenn überhaupt, Ausfallzeit akzeptabel ist, können Sie die Methode der Bereitstellung wählen, die für Ihre Anforderungen geeignet ist. Idealerweise sollten Sie die Bereitstellung während eines Wartungsfensters durchführen, um die Komplexität und das Risiko zu reduzieren. Wenn keine Ausfallzeiten akzeptabel sind, sollten Sie eine blau-grüne Bereitstellungsmethode anwenden.

Verwenden Sie einen progressiven Expositionsansatz, um das Risiko zu verringern, dass nicht erkannte Fehler für Ihre Kunden in großem Umfang eingeführt werden. Diese Methode wird auch als Canarybereitstellungen bezeichnet, die für kontrollierte Benutzergruppen in einer graduellen Sequenz bereitgestellt werden. Es erfasst Probleme, bevor sie mehr Benutzer betreffen. Die anfängliche Rolloutgruppe kann ein Unterabschnitt Ihrer Kunden sein, der sich der Rolloutstrategie bewusst ist. Dieser Unterabschnitt von Kunden kann ein unerwartetes Verhalten tolerieren und Feedback geben. Oder es kann sich um eine Gruppe interner Benutzer handeln, die den Strahlradius von Fehlern während des Rollouts enthalten kann.

Wenn Sie Ihre Bereitstellungsmethode definieren, übernehmen Sie eine Standardrichtlinie, mit der nur die kleinsten lebensfähigen Änderungen in jeder Bereitstellung bereitgestellt werden. Bestimmen Sie abhängig von Faktoren wie der Kritischität der Arbeitsauslastung und Komplexität der Komponenten die kleinste lebensfähige Änderung. Wenn Sie eine unveränderliche Infrastruktur verwenden, ist die kleinste lebensfähige Änderung in der Regel die Bereitstellung von Ressourcen mit der neuesten Konfiguration, um Ressourcen zu ersetzen, die die vorherige Version ausführen. Wenn Sie eine veränderbare Infrastruktur verwenden, können Sie entscheiden, dass die kleinste lebensfähige Änderung nur eine einzige Aktualisierung der Ressourcengruppe im Bereich ist.

Verfolgen eines mehrschichtigen Ansatzes

Folgen Sie einem mehrschichtigen Ansatz, um verschiedene Lebenszyklus zu berücksichtigen. Die grundlegenden Schichten sollten während des größten Teils des Lebenszyklus Ihrer Workload statisch bleiben, während sich die Anwendungsschichten häufig ändern. Um diese Unterschiede zu berücksichtigen, sollten Sie verschiedene Pipelines haben, um Änderungen auf jeder Ebene vorzunehmen.

Eine Landungszone befindet sich auf der niedrigsten Ebene. Eine Zielzone ist eine logische Gruppierung von grundlegenden Elementen wie Abonnements, Verwaltungsgruppen, Ressourcengruppen, Governancefunktionen und Netzwerktopologie. Mit einer Zielzone können Sie Ihre Arbeitsauslastung ganz einfach bereitstellen und verwalten und zentrale Betriebsteams oder Plattformteams mit einem wiederholbaren Ansatz für eine Umgebungskonfiguration bereitstellen und verwalten. Um konsistente Umgebungen bereitzustellen, bieten alle Azure-Zielzonen eine Reihe allgemeiner Entwurfsbereiche, eine Referenzarchitektur, eine Referenzimplementierung und einen Prozess zum Ändern einer Bereitstellung an Ihre Entwurfsanforderungen. Die Designprinzipien der Azure-Zielzone bieten empfohlene Methoden basierend auf der richtliniengesteuerten Governance zusammen mit der Abonnementdemokratisierung. Eine Landezone sollte im Laufe des Workloadlebenszyklus minimale Änderungen erfordern. Ein Beispiel für eine Landungszone finden Sie unter "Was ist eine Azure-Landezone". Diese konzeptionelle Architektur enthält eine Reihe von Meinungen, die für Azure empfohlen werden.

Ihre Kerninfrastruktur und -funktionen, z. B. Eingangs- und Übergabenetzwerkcontroller, Lastenausgleich, Netzwerkroutinglösungen, DNS-Verwaltung und Kernserver, sollten auch seltene wichtige Änderungen erfordern. Möglicherweise sind jedoch häufige Konfigurationsupdates erforderlich.

Ihre Anwendungs- und Datenschicht erfordert häufige Konfigurationsupdates und häufige Infrastrukturänderungen. Diese Komponenten sollten über die dynamischsten Pipelines verfügen.

Integrieren umfassender Testtypen

Planen Sie eine ganzheitliche Teststrategie. Ein kernes Prinzip der Systemsicherheit ist das Shift Left-Prinzip . Das Entwickeln und Bereitstellen einer Anwendung ist ein Prozess, der als eine Reihe von Schritten dargestellt wird, die von links nach rechts gehen. Sie sollten das Testen nicht auf das Ende des Prozesses beschränken. So viel wie möglich, verschieben Sie Tests an den Anfang oder nach links. Fehler sind billiger zu reparieren, wenn Sie sie frühzeitig abfangen. Sie können teuer oder unmöglich sein, später im Anwendungslebenszyklus zu beheben.

Testen Sie den gesamten Code, einschließlich Anwendungscode, Infrastrukturvorlagen und Konfigurationsskripts. Die Umgebung, in der Anwendungen ausgeführt werden, sollte versionsgesteuert und über die gleichen Mechanismen wie Anwendungscode bereitgestellt werden. Sie können die Umgebung testen und überprüfen, indem Sie dieselben Testparadigma verwenden, die Ihre Teams bereits für Anwendungscode verwenden.

Verwenden Sie nach Möglichkeit automatisierte Tests, um Konsistenz sicherzustellen. Schließen Sie die folgenden Arten von Tests in Ihr Supply Chain-Design ein.

• Komponententests: Komponententests werden in der Regel als Teil einer kontinuierlichen Integrationsroutine ausgeführt. Komponententests sollten umfangreich und schnell sein. Sie sollten idealerweise 100 Prozent des Codes abdecken und in weniger als 30 Sekunden ausgeführt werden.

  Implementieren Sie Komponententests, um zu überprüfen, ob die Syntax und Funktionalität einzelner Codemodule funktionieren, z. B. die Erstellung einer definierten Ausgabe für eine bekannte Eingabe. Sie können auch Komponententests verwenden, um zu überprüfen, ob IaC-Ressourcen gültig sind.

  Anwenden von Komponententests auf alle Coderessourcen, einschließlich Vorlagen und Skripts.

• Rauchtests: Rauchtests stellen sicher, dass eine Arbeitsauslastung in einer Testumgebung aufstanden und wie erwartet ausgeführt werden kann. Rauchtests überprüfen nicht die Interoperabilität von Komponenten.

  Rauchtests überprüfen, ob die Bereitstellungsmethode für die Infrastruktur und die Anwendung funktioniert und dass das System nach Abschluss des Prozesses wie vorgesehen reagiert.

• Integrationstests: Integrationstests stellen sicher, dass die Anwendungskomponenten einzeln funktionieren, und ermitteln Sie dann, ob Komponenten wie erforderlich miteinander interagieren können.

  Es kann viel Zeit dauern, bis eine große Integrationstestsuite ausgeführt wird. Deshalb empfiehlt es sich, das Shift Left-Prinzip zu integrieren und Frühzeitiges Testen im Softwareentwicklungslebenszyklus durchzuführen. Reservieren Sie Integrationstests für Szenarien, die Sie nicht mit einem Rauchtest oder Komponententest testen können.

  Bei Bedarf können Sie lang ausgeführte Testprozesse in einem regelmäßigen Intervall ausführen. Ein normales Intervall bietet eine gute Kompromittierung und erkennt Interoperabilitätsprobleme zwischen Anwendungskomponenten spätestens einen Tag nach der Einführung.

  Einige Testszenarien profitieren von manuellen Ausführungen. Verwenden Sie manuelle Tests, wenn Sie menschliche Interaktivitätselemente in Tests einführen müssen.

• Akzeptanztests: Je nach Kontext können Sie akzeptanztests manuell durchführen. Sie kann teilweise oder vollständig automatisiert werden. Akzeptanztests bestimmen, ob das Softwaresystem die Anforderungsspezifikationen erfüllt.

  Der Hauptzweck dieses Tests besteht darin, die Einhaltung der Geschäftsanforderungen des Systems zu bewerten und zu bestimmen, ob das System die erforderlichen Kriterien für die Übermittlung an Endbenutzer erfüllt.

Implementieren von Qualitätstoren in Codeförderungsprozessen

Implementieren Sie Qualitätstore im gesamten Codeförderungsprozess über Tests. Stellen Sie Ihren Code in niedrigeren Umgebungen bereit, z. B. in Entwicklungs- und Testumgebungen und in höheren Umgebungen, z. B. Staging und Produktion. Wenn Ihre Bereitstellung über Qualitätsgates verläuft, stellen Sie sicher, dass sie Ihre Qualitätsziele erfüllt, bevor Änderungen an der Produktion vorgenommen werden. Ihre geschäftlichen Anforderungen bestimmen, was der Schwerpunkt Ihrer Qualitätstore ist. Berücksichtigen Sie auch die grundlegenden Prinzipien des Well-Architected Framework: Sicherheit, Zuverlässigkeit und Leistungseffizienz.

Integrieren Sie auch Genehmigungsworkflows in Ihre Qualitätstore. Definieren und automatisieren Sie genehmigungsworkflows bei Bedarf klar. Definieren Sie Qualitätsakzeptanzkriterien in Ihrer Automatisierung, damit Sie effizient und sicher durch Ihre Tore navigieren können.

Azure-Erleichterung

Azure DevOps ist eine Sammlung von Diensten, die Ihnen helfen, eine zusammenarbeitende, effiziente und konsistente Entwicklungspraxis zu entwickeln.

Azure Pipelines bietet Build- und Releasedienste zur Unterstützung von CI/CD in Ihren Anwendungen.

GitHub-Aktionen für Azure werden in Azure integriert, um Bereitstellungen zu vereinfachen. Verwenden Sie GitHub-Aktionen, um CI/CD-Prozesse zu automatisieren. Sie können Workflows erstellen, die jede Pullanforderung an Ihr Repository erstellen und testen oder zusammengeführte Pullanforderungen in der Produktion bereitstellen.

Sie können Terraform, Bicep und Azure Resource Manager für IaC-Bereitstellungen verwenden. Je nach Ihren Anforderungen und der Vertrautheit Ihres Teams mit den Tools können Sie ein oder mehrere dieser Tools für Ihre Bereitstellungen und die Verwaltung der Ressourcen verwenden.

Beispiel

Ein Beispiel, das zeigt, wie Sie Azure Pipelines zum Erstellen einer CI/CD-Pipeline verwenden, finden Sie unter Azure Pipelines-Basisarchitektur.

Verwandte Links

• Azure DevOps
• Azure Pipelines
• Muster mit Bereitstellungsstempeln
• GitHub Actions für die Bereitstellung in Azure
• Säule "Leistungseffizienz"
• Zuverlässigkeitssäule
• Sicherheitssäule

Checkliste für Operation Excellence

Lesen Sie den vollständigen Satz von Empfehlungen.