Freigeben über

Empfehlungen für das Entwerfen einer Workloadentwicklungs-Lieferkette

  • Artikel

Gilt für diese Checklistenempfehlung für Azure Well-Architected Framework Operational Excellence:

OE:06 Erstellen Sie eine Workload-Lieferkette, die vorgeschlagene Änderungen über vorhersagbare, automatisierte Pipelines antreibt. Die Pipelines testen und fördern diese Änderungen in allen Umgebungen. Optimieren Sie eine Lieferkette, um Ihre Workload zuverlässig, sicher, kostengünstig und leistungsfähig zu machen.

In diesem Leitfaden werden die Empfehlungen zum Entwerfen einer Lieferkette für die Workloadentwicklung beschrieben, die auf CI/CD-Pipelines (Continuous Integration und Continuous Delivery) basiert. Entwickeln Sie eine Lieferkette, um sicherzustellen, dass Sie über eine vorhersagbare, standardisierte Methode zum Verwalten Ihrer Workload verfügen. CI/CD-Pipelines sind die Manifestation der Lieferkette, aber Sie sollten über eine einzelne Lieferkette verfügen. Außerdem verfügen Sie möglicherweise über mehrere Pipelines, die den gleichen Prozessen folgen und dieselben Tools verwenden.

Integrieren Sie eine Lieferkette, um Ihre Workload vor Schäden zu schützen, die auftreten können, wenn Sie Workloadänderungen nicht ordnungsgemäß verwalten. Achten Sie immer auf den Zustand Ihrer Workload, damit Sie nicht Gefahr laufen, unvorhersehbares Verhalten zu erleben. Dies ist risikobehaftet, wenn Sie kritische Zeit damit verbringen müssen, änderungen nicht berücksichtigt zu verfolgen, 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 auf ihre Verwendung verpflichtet.

Definition

Begriff Definition
Lieferkette In Cloudworkloads ist eine Lieferkette eine standardisierte Suite von Tools und Prozessen, die Sie verwenden, um Infrastruktur- und Anwendungsänderungen in verschiedenen Umgebungen zu beeinflussen.

Wichtige Entwurfsstrategien

Hinweis

Die Empfehlungen in diesem Leitfaden beziehen sich auf Workloadumgebungen in einer Codeaufstufungskette. Sandbox- oder andere Explorative- und Proof-of-Concept-Umgebungen erfordern weniger Strenge und Struktur.

Kernsätze

Die folgenden Empfehlungen können Ihnen helfen, die kernigen Grundsätze Ihrer Lieferkette zu definieren.

Nehmen Sie vorgeschlagene Workloadä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, klar definiert und streng kontrolliert wird. Führen Sie für Umgebungen in einer Codeaufstufungskette keine Updates 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 befolgen. Um diese Richtlinie zu erzwingen, erwägen Sie, den Zugriff standardmäßig auf schreibgeschützt zu beschränken und ein Zugriffsautorisierungsgate zum Zulassen des Schreibzugriffs zu verwenden.

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

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

Integrieren Sie IaC, um sicherzustellen, dass Ihr Team einem bewährten Standardprozess folgt. Einige Organisationen legen eine einzelne einzelne oder kleine Gruppe von Einzelpersonen zum Bereitstellen und Konfigurieren der Infrastruktur fest. Wenn Sie einen vollständig automatisierten Prozess implementieren, erfordern Infrastrukturbereitstellungen weniger Verwaltung durch Einzelpersonen. Die Verantwortung wird auf den Automatisierungsprozess und die Tools übertragen. Teammitglieder können Infrastrukturbereitstellungen initiieren, um Konsistenz und Qualität zu gewährleisten.

Entwerfen Sie Ihre Workload 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 hochskaliert zu werden, stellen Sie einen Stempel mithilfe einer Pipeline bereit. Je nachdem, wie Sie Ihre Stempel entwerfen, stellen Sie möglicherweise eine Teilmenge Ihrer Workload anstelle der gesamten Workload bereit. 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 auf Konsistenz und Effizienz zu optimieren, entwerfen Sie eine unveränderliche Infrastruktur anstelle einer veränderlichen 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 eine Gruppe von Coderessourcen und Artefakten in allen Umgebungen und Pipelines. Ein häufiger Problempunkt für Organisationen ist, wenn sich Nichtproduktionsumgebungen von Produktionsumgebungen unterscheiden. Das manuelle Erstellen von Produktions- und Nichtproduktionsumgebungen kann zu nicht übereinstimmender Konfigurationen zwischen den Umgebungen führen. Diese Fehlende Übereinstimmung verlangsamt tests und macht es wahrscheinlicher, dass Änderungen einem Produktionssystem schaden könnten. Ein IaC-Ansatz minimiert diese Probleme. Wenn Sie die IaC-Automatisierung verwenden, können Sie dieselben Infrastrukturkonfigurationsdateien für alle Umgebungen verwenden, um nahezu identische Umgebungen zu erstellen. Sie können den Infrastrukturkonfigurationsdateien Parameter hinzufügen und sie so anpassen, dass sie die Anforderungen für jede Umgebung erfüllen.

Um die Kosten zu kontrollieren, gibt es in der Regel Unterschiede zwischen Produktions- und Nichtproduktionsumgebungen. In Nichtproduktionsumgebungen benötigen Sie häufig nicht den gleichen Grad an Redundanz und Leistung wie in der Produktion. Die Anzahl und SKU Ihrer Ressourcen kann sich zwischen den Umgebungen unterscheiden. Stellen Sie sicher, dass Sie die Varianz steuern und verstehen, indem Sie standardisierte Parameter verwenden, um die Vorhersagbarkeit beim Vornehmen von Änderungen zu gewährleisten.

Spiegeln Sie Ihre Organisationsstruktur in Ihren Lieferketten- und Pipelinedesigns wider. Ihre organization können zwischen Teams isoliert sein. Jedes Team kann einen Teil der Lieferkette verwalten. Beispielsweise verfügen viele Organisationen über Teams, die Infrastrukturdomänen wie Netzwerke, Daten und Computeressourcen verwalten. Diese Teams sind getrennt von Entwicklungsteams, die Anwendungsentwicklung, Tests und Bereitstellungen verwalten. In einigen Organisationen sind 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 ist darauf angewiesen, dass alle Teams nahtlos zusammenarbeiten. Stellen Sie sicher, dass alle Teams Standardprozesse befolgen, und verwenden Sie Standardtools, um die Lieferkette so effizient wie möglich zu gestalten.

Ihre Lieferkette kann von Drittanbietern abhängig sein, wenn Sie Teile des Workloadlebenszyklus auslagern. Diese Anbieter sind genauso entscheidend 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.

Standardisieren Sie Ihre Bereitstellungsmethode. Sprechen Sie mit dem Produktbesitzer über die akzeptable Menge an Produktionsausfällen für Ihre Workload. Je nachdem, wie viel Ausfallzeiten akzeptabel sind, können Sie die Bereitstellungsmethode auswählen, die für Ihre Anforderungen geeignet ist. Idealerweise sollten Sie Bereitstellungen während eines Wartungsfensters durchführen, um Komplexität und Risiko zu verringern. Wenn keine Ausfallzeiten akzeptabel sind, verwenden Sie eine blau-grüne Bereitstellungsmethode.

Verwenden Sie einen Progressive-Exposure-Ansatz, um das Risiko zu verringern, dass Ihre Kunden unerkannt Fehler einführen. Diese Methode wird auch als Canary-Bereitstellungen bezeichnet und wird in einer schrittweisen Sequenz für kontrollierte Benutzergruppen bereitgestellt. Es fängt Probleme ab, bevor sie mehr Benutzer betreffen. Die anfängliche Rolloutgruppe kann ein Unterabschnitt Ihrer Kunden sein, die die Rolloutstrategie kennen. Dieser Unterabschnitt von Kunden kann ein gewisses Maß an unerwartetem Verhalten tolerieren und Feedback geben. Oder es kann sich um eine Gruppe interner Benutzer handeln, die den Explosionsradius von Fehlern während des Rollouts eindämmte.

Wenn Sie Ihre Bereitstellungsmethode definieren, übernehmen Sie eine Standardrichtlinie, in der nur die kleinste praktikable Änderung in jeder Bereitstellung bereitgestellt wird. Bestimmen Sie abhängig von Faktoren wie der Kritikalität der Workload und der Komplexität der Komponenten die kleinste realisierbare Änderung. Wenn Sie eine unveränderliche Infrastruktur verwenden, ist die kleinste realisierbare Ä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änderliche Infrastruktur verwenden, können Sie entscheiden, dass die kleinste realisierbare Änderung nur ein einzelnes Update für die Gruppe von Ressourcen im Bereich ist.

Folgen Sie einem mehrschichtigen Ansatz, um unterschiedliche Lebenszyklen widerzuspiegeln. Grundlegende Ebenen sollten während des gesamten Workloadlebenszyklus statisch bleiben, und Anwendungsebenen ändern sich häufig. Um diese Unterschiede zu berücksichtigen, sollten Sie über unterschiedliche Pipelines verfügen, um Änderungen auf jeder Ebene vorzunehmen.

Eine Zielzone befindet sich auf der niedrigsten Ebene. Eine Zielzone ist eine logische Gruppierung grundlegender Elemente wie Abonnements, Verwaltungsgruppen, Ressourcengruppen, Governancefunktionen und Netzwerktopologie. Eine Zielzone ermöglicht Ihnen die einfache Bereitstellung und Verwaltung Ihrer Workload und bietet zentralen Betriebsteams oder Plattformteams einen wiederholbaren Ansatz für eine Umgebungskonfiguration. Um konsistente Umgebungen bereitzustellen, stellen alle Azure-Zielzonen eine Reihe allgemeiner Entwurfsbereiche, eine Referenzarchitektur, eine Referenzimplementierung und einen Prozess zum Ändern einer Bereitstellung an Ihre Entwurfsanforderungen bereit. Die Entwurfsprinzipien für Azure-Zielzonen bieten empfohlene Methoden, die auf der richtliniengesteuerten Governance neben der Demokratisierung von Abonnements basieren. Eine Zielzone sollte im Laufe des Workloadlebenszyklus minimale Änderungen erfordern. Ein Beispiel für eine Zielzone finden Sie unter Was ist eine Azure-Zielzone? Diese konzeptionelle Architektur enthält eine Reihe von Meinungen, die für Azure empfohlen werden.

Ihre Kerninfrastruktur und -funktionen wie ein- und ausgehende Netzwerkcontroller, Lastenausgleich, Netzwerkroutinglösungen, DNS-Verwaltung und Kernserver sollten ebenfalls seltene größere Änderungen erfordern. Sie erfordern jedoch möglicherweise häufige Konfigurationsupdates.

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

Planen Sie eine ganzheitliche Teststrategie. Ein Kernprinzip 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 tests nicht auf das Ende des Prozesses beschränken. Verschieben Sie die Tests so weit wie möglich an den Anfang oder nach links. Fehler sind billiger zu reparieren, wenn Sie sie frühzeitig abfangen. Sie können teuer sein oder später im Anwendungslebenszyklus nicht mehr behoben werden.

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. Fügen Sie die folgenden Testtypen in Ihren Lieferkettenentwurf ein.

  • Komponententests: Komponententests werden in der Regel als Teil einer Continuous Integration-Routine ausgeführt. Komponententests sollten umfassend 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 so funktionieren, wie sie sollten, 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.

    Wenden Sie Komponententests auf alle Coderessourcen an, einschließlich Vorlagen und Skripts.

  • Rauchtests: Rauchtests überprüfen, ob eine Workload in einer Testumgebung ausgeführt werden kann und wie erwartet ausgeführt wird. Rauchtests überprüfen nicht die Interoperabilität von Komponenten.

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

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

    Die Ausführung einer umfangreichen Integrationstestsuite kann viel Zeit in Anspruch nehmen. Aus diesem Grund ist es am besten, das Shift-Left-Prinzip zu integrieren und Tests frühzeitig im Lebenszyklus der Softwareentwicklung durchzuführen. Reservieren Sie Integrationstests für Szenarien, die Sie nicht mit einem Rauchtest oder Komponententest testen können.

    Bei Bedarf können Sie Testprozesse mit langer Ausführungsdauer in einem regelmäßigen Intervall ausführen. Ein regelmäßiges 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. Es kann teilweise oder vollständig automatisiert sein. Akzeptanztests bestimmen, ob das Softwaresystem die Anforderungsspezifikationen erfüllt.

    Der Standard Zweck dieses Tests besteht darin, die Konformität des Systems mit den Geschäftsanforderungen zu bewerten und zu ermitteln, ob das System die erforderlichen Kriterien für die Übermittlung an Endbenutzer erfüllt.

Implementieren Sie Qualitätsgates während Des gesamten Codeprostufungsprozesses über Tests. Stellen Sie Ihren Code in niedrigeren Umgebungen bereit, z. B. Entwicklung und Tests, und über höhere Umgebungen wie Staging und Produktion. Wenn Ihre Bereitstellung Qualitätsgates durchläuft, stellen Sie sicher, dass sie Ihre Qualitätsziele erfüllt, bevor Änderungen in die Produktion übergehen. Ihre geschäftlichen Anforderungen bestimmen den Fokus Ihrer Qualitätsgates. Berücksichtigen Sie auch die grundlegenden Well-Architected Framework-Prinzipien: Sicherheit, Zuverlässigkeit und Leistungseffizienz.

Integrieren Sie auch Genehmigungsworkflows in Ihre Qualitätsgates. Definieren und automatisieren Sie Genehmigungsworkflows bei Bedarf eindeutig. Definieren Sie Qualitätsakzeptanzkriterien in Ihre Automatisierung, damit Sie effizient und sicher durch Ihre Tore gelangen können.

Azure-Erleichterung

Azure DevOps ist eine Sammlung von Diensten, mit denen Sie eine gemeinsame, effiziente und konsistente Entwicklungsmethode erstellen können.

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

GitHub Actions für Azure ist in Azure integriert, um Bereitstellungen zu vereinfachen. Verwenden Sie GitHub Actions, um CI/CD-Prozesse zu automatisieren. Sie können Workflows erstellen, die alle Pull Requests in Ihrem Repository erstellen und testen, oder zusammengeführte Pull Requests in der Produktion bereitstellen.

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

Beispiel

Ein Beispiel für die Verwendung von Azure Pipelines zum Erstellen einer CI/CD-Pipeline finden Sie unter Basisarchitektur von Azure Pipelines.

Prüfliste "Operation Excellence"

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Checkliste für operationale Exzellenz