Azure Well-Architected Framework-Workloads

Artikel
11/15/2023

Im Kontext des Azure Well-Architected Framework bezieht sich der Begriff Workload auf eine Sammlung von Anwendungsressourcen, Daten und unterstützenden Infrastrukturen, die zusammen funktionieren, um definierte Geschäftsergebnisse zu erzielen. Eine Workload besteht aus Komponenten sowie Entwicklungs- und Betriebsabläufen.

Architekten entwerfen Workloads, und ein Workloadteam implementiert sie. Eine Workload wird entwickelt und implementiert, um funktionale und nicht funktionale Geschäftsanforderungen zu erfüllen. Workloads können in viele Typen unterteilt werden.

Typische Kriterien für die Workloadklassifizierung sind:

Hilfsprogramm, Merkmale und Nutzungsmuster einer Workload, z. B. Webanwendungen, Batchverarbeitung und Echtzeitanalysen.
Wichtige einflussreiche Treiber, z. B. Technologieplattformen oder Ausrichtung auf eine Branche.
Beabsichtigte Zielgruppe. Beispiele für Lösungen mit unterschiedlichen Zielgruppen sind interne Branchenanwendungen innerhalb von Unternehmen, eine erworbene Lösung des unabhängigen Softwareanbieters (Independent Software Vendor, ISV) oder eine mehrinstanzenfähige Software-as-a-Service-Lösung (SaaS) für den öffentlichen Gebrauch.

Workloads, die sich in derselben Klasse befinden, können Ähnlichkeiten aufweisen, einschließlich ihrer Zielgruppe, Complianceanforderungen und Technologiestapel. Die fünf Säulen des Well-Architected Frameworks, ihre Prinzipien, Checklisten und Kompromisse sind für alle Workloadklassen relevant.

Der Workloadleitfaden des Well-Architected Frameworks beschreibt allgemeine Prioritäten und Kompromisse, die sich auf bestimmte Workloadklassen beziehen. In der Arbeitsauslastungsanleitung gelten die Säulenleitlinien für technische Entwurfsprinzipien und Entwurfsbereiche, die die Prioritäten einer Workload darstellen. Befolgen Sie die Empfehlungen, um eine erfolgreiche Workload einzurichten und an das Well-Architected Framework auszurichten.

Was ist eine Well-Architected Framework-Workload?

Entwurf und Betrieb jeder Workload müssen mit den fünf Säulen der Architektur zu kämpfen haben: Zuverlässigkeit, Sicherheit, Kostenoptimierung, Operational Excellence und Leistungseffizienz.

Um eine erfolgreiche Workload zu erstellen, entwickeln Sie sie gemäß den Well-Architected Framework-Prinzipien, die auf den folgenden Idealen basieren.

Eine Well-Architected Framework-Workload:

Verfügt über funktionale und nicht funktionale Anforderungen, die definiert und priorisiert werden, um ein Ziel zu erreichen.
Ist so konzipiert, dass Sie diese Anforderungen erreichen können, indem Sie Ressourcen verwenden und Entwurfsmuster und Kompromisse einbeziehen.
Wird nach den Spezifikationen eines Entwurfs und Zwecks gebaut und betrieben.
Wird daran gemessen, wie angemessen sie ihren Zweck erreicht.
Kann angepasst werden, wenn sein Zweck verfeinert oder geändert wird.
Ist genauso zuverlässig, wie es sein muss.
Ist genauso sicher, wie es sein muss.
Liefert einen ausreichenden Return on Investment.
Wird verantwortungsvoll entwickelt und betrieben.
Erfüllt seinen Zweck innerhalb eines akzeptablen Zeitraums.

Eine Zusammenarbeit zwischen dem Workloadteam und den zentralen Teams eines organization muss eine Workload mit den vorherigen Merkmalen erstellen. In den folgenden Abschnitten werden diese Teams und ihre Funktionen beschrieben.

Workloadteam

Erstellen Sie ein Workloadteam mit Teammitgliedern mit einer Vielzahl von technischen und geschäftlichen Disziplinen. Der Hauptfokus aller Teammitglieder sollte der Erfolg der Workload sein.

Beispiele für Workload-Teammitglieder
Anwendungssicherheitstechniker Beteiligte im Unternehmen Cloudentwickler oder Softwareentwickler Cloudlösungsarchitektinnen Data Scientists oder Analysten Datenbankadministratorinnen	DevOps-Techniker Infrastrukturtechniker Produktmanager oder -besitzer Qualitätssicherungstechniker (QA) Supportteammitglieder

Zentralisierte Teams und Stakeholder

Zentralisierte Teams unterstützen häufig das Workloadteam. Sie bieten Unterstützungsfunktionen und wenden die Governance für viele oder alle Cloudworkloads innerhalb eines organization an. Zentralisierte Teams konzentrieren sich auf den Unternehmenserfolg, der zum Teil durch den Erfolg der Workloads der organization erreicht wird. Sie bieten Dienste, Anleitungen und Leitplanken für Workloads.

Beispiele für zentralisierte Teams und Teammitglieder
Business Intelligence-Analysten Beteiligte im Unternehmen CCoE-Board (Cloud Center of Excellence) Cloudplattformteam Cybersicherheitsanalysten Datenbankadministrator*innen Unternehmensarchitekten	Finanzanalysten Infrastrukturtechniker Rechts- und Compliancebeauftragte Netzwerktechniker*innen Beschaffungsspezialisten Projektmanager

Ein Well-Architected Framework-Workloadteam konzentriert sich auf Workloadergebnisse. Sie koordinieren und profitieren von der spezialisierten Unterstützung durch zentralisierte Teammitglieder.

Modell der gemeinsamen Zuständigkeit

Eine Workload muss bereitgestellt und verwendet werden, um einen Mehrwert zu erzielen. Als Teil des Workloadteams sind Sie dafür verantwortlich, Ihre Workload auf eine Weise zu entwerfen, zu implementieren und bereitzustellen, die Einen Mehrwert für Ihre organization schafft.

Workloads befinden sich im Kontext Ihrer organization. Ein organization hat häufig geregelte Leitungs- und Autoritätsrollen. Ihr Workloadteam ist dafür verantwortlich, eine Workload innerhalb der Grundlage Ihrer organization zu entwerfen, zu implementieren und bereitzustellen.

Standardisieren Sie gemäß der Cloud Adoption Framework für Azure die Cloudressourcen Ihrer Workload. Wenden Sie die Standardisierung konsequent an, um eine verwaltete Plattform bereitzustellen, die ihnen beim Onboarding von Workloadteams hilft. Wenden Sie diese Governance gemäß dem Cloudbetriebsmodell Ihres organization an.

Sie können Azure-Zielzonen verwenden, um die Standardisierung durchzuführen. Plattformzielzonen und Anwendungszielzonen sind in Azure verfügbar. Stellen Sie Ihre Workload in einer Anwendungszielzone bereit.

Ihr organization verfügt möglicherweise über ein Cloudplattformangebot, das streng formalisiert ist und vollständig auf Azure-Zielzonen ausgerichtet ist. Oder Ihre organization hat möglicherweise eine andere Einführungsstrategie oder keine Implementierung. Wenn keine Implementierung vorhanden ist, sind Workloadteams fast vollständig autonome Entitäten.

Für jede Plattform und Governance, die Ihr organization verwendet, müssen Sie die Prinzipien des Well-Architected Frameworks auf Ihre Workloads anwenden. Das Well-Architected Framework verweist häufig auf Azure-Zielzonen, ist aber nicht von einer bestimmten Plattformimplementierung abhängig. Die Well-Architected Framework-Säulen, Prinzipien, Checklisten und Leitfäden gelten für alle Cloudplattformen und die meisten Workloadtypen.

Anforderungen erfüllen

Während des gesamten Well-Architected Frameworks, wie z. B. den Kernpfeilern und der Workloadleitfaden, stimmen Die Empfehlungen mit der Verpflichtung der Workload überein. Empfehlungen implizieren in der Regel nicht, welches Teammitglied oder Team diese Verpflichtungen erleichtert. Sie können bestimmen, wer die einzelnen Aktionen ausführen soll. Führen Sie eine Zuordnung auf Workloadebene durch, um die Rollen und Verantwortlichkeiten Ihres Teams im Zusammenhang mit der Topologie, dem Workloadtyp und der Kritikalität zu ermitteln.

Das direkte Workloadteam übernimmt die meisten Workloadanforderungen. Einige Anforderungen werden als gemeinsame Anstrengung mit zentralisierten Teams behandelt. Beispielsweise können die Implementierungsoptionen auf Leitplanken basieren, die ein zentralisiertes Team festlegt. Oder ein zentralisiertes Team kann sich ausschließlich um die Implementierungsoptionen kümmern.

Ihr Workloadteam muss eine Arbeitsbeziehung mit anderen Teams aufbauen, um das Codeliver für Workloadziele zu unterstützen. Wenn Sie Komponenten oder Zuständigkeiten auslagern, müssen Sie diese Verpflichtungen erfolgreich erfüllen.

Lernen Sie die Einschränkungen kennen

Ein zentralisiertes Team unterstützt verschiedene Workloads basierend auf den Kernfunktionen und der Kerninfrastruktur des Teams. Um diesen Support auf organisatorischer Ebene bereitzustellen, kann das zentralisierte Team Uniformität und Einschränkungen für den angebotenen Dienst oder die Infrastruktur implementieren. Beim Entwerfen Ihrer Workload ist es wichtig, dass Sie diese Einschränkungen verstehen und nach Möglichkeit mit Unternehmensarchitekten zusammenarbeiten, die diese Einschränkungen kennen. Lernen Sie so viel wie möglich von früheren Implementierungen.

Jede Plattformgovernance ist anders, aber die folgenden Einschränkungen sind für viele Workloads üblich:

Zulassungslisten für Cloudressourcen
Konfigurationsmandate für Cloudressourcen
Regionale Zulassungslisten für Cloudressourcen und standortübergreifende Konnektivitätsverfügbarkeit
Eingeschränkter oder kein Plattformsupport außerhalb der Geschäftszeiten
Patchanforderungen
Spezifische Hub-Spoke-Implementierung, die DNS-Implementierungen (Domain Name System) und private Endpunktimplementierungen antreibt
Anforderungen an die Lieferkettensteuerung

Anforderungen explizit kommunizieren

Wenn Ihre Workloadanforderung mit einer Einschränkung oder einer Vereinbarung zum Servicelevel (SLA) konfrontiert ist, die eine Kernfunktion oder ein Infrastrukturangebot nicht eindeutig definiert, behandeln Sie diese Situation als Risiko. Um dieses Risiko zu beheben, muss Ihr Workloadteam den anderen Teams Klarheit darüber bieten, wie sich das Problem auf die Workload auswirkt. Möglicherweise müssen Sie die Workloadanforderungen, den Entwurf oder die Implementierung ändern oder das Infrastrukturangebot ändern.

Wenn Sie die Verpflichtungen des Plattformteams in Bezug auf Organisationsanweisungen und die Verpflichtungen Ihres Workloadteams verstehen, können Sie workloadanforderungen mit realistischen Erwartungen und Empfehlungen kommunizieren.

Kommunizieren allgemeiner Workloadanforderungen

Jede Plattformpartnerschaft ist anders, aber die folgenden Bereiche sind häufige Themen in Gesprächen mit gemeinsamer Verantwortung:

Compliance und gesetzliche Anforderungen
Netzwerkspezifische Daten, z. B. die Notwendigkeit statischer eingehender oder ausgehender IP-Adressen
Beobachtbarkeitsanforderungen für eine effektive Live-Site-Triage
Leistungsanforderungen, z. B. Netzwerkdurchsatz, Verfügbarkeit von Cloudressourcen oder regionale Verfügbarkeit
Erwartungen an den öffentlichen Internetzugriff aus sicht des ausgehenden und ausgehenden Internets
Servicelevelziele (SLOs) oder SLAs, die den Benutzern der Workload angeboten werden
Verfügbarkeit des technischen Supports

Suche nach vereinheitlichten Gewinnen

Bei geteilter Verantwortung geht es nicht nur um Kompromisse, Einschränkungen und Kompromisse. Plattformteams verfügen häufig über hochspezialisierte Fähigkeiten und dedizierte Budgets, die über das hinausgehen können, was ein einzelnes Workloadteam tragen kann. Betrachten Sie die folgenden Beispiele.

Sicherheitsexperten. Ihre Workload kann einen sicheren Entwicklungslebenszyklus aufweisen. Da ein zentralisiertes Sicherheitsteam sichere Entwicklungsaufgaben im großen Stil in Ihrem organization ausführt, führt es möglicherweise routinemäßige Penetrationstests durch, die Über Ihre Bemühungen hinausgehen. Es kann auch bei der Planung und Durchführung einer Strategie zur Reaktion auf Vorfälle helfen.

Leitfaden zur Unternehmensarchitektur. Sie können Zeit und Aufwand sparen, wenn Sie sich an den Mustern und Methoden eines Unternehmensarchitekturteams orientieren, da das Team die Prozesse bereits optimiert hat. Sie können nacharbeiten auch verhindern, wenn eine Lösung innerhalb der Partnerschaft ohne Verhandlungen nicht möglich ist.

Große Ausgaben. Plattformteams hosten häufig Komponenten oder Dienste, die für ein einzelnes Workloadteam zu teuer oder zu umfangreich verwaltet werden. Plattformteams können sich diese Komponenten und Dienste leisten, da sie die Kosten auf Workloads verteilen.

Häufig werden diese Dienste oder zentralisierten Plattformen als reines Showback angeboten, sodass die Workloadkosten optimiert werden. Und wenn sie als Rückbuchung angeboten werden, sind sie aufgrund von Größenvorteilen und Zentralisierung oft billiger.

Plattformteams bieten häufig Self-Service-Optionen für Workloadteams für verschiedene Aktivitäten. Beispiel:

Bereitstellen eines Dokumentationsrepositorys für selbstgeführte Bildung
Onboarding zum Kostenmanagement über spezifische Ressourcentaggings
Anbieten von Abonnements über einen formalen Abonnementverkaufsprozess

Erkunden Sie Self-Service-Optionen, die für Ihre Workload geeignet sein könnten.

Gemeinsame Verantwortung mit anderen Teams bedeutet auch das Teilen von Erfolgen und Herausforderungen einer Workload. Wenn Ihre Workload ihre Verpflichtungen erfüllt und den beabsichtigten Wert erhält, teilen Sie dies mit Ihren Partnerteams. Teilen Sie ihnen mit, wie sie zum Erfolg der Workload beigetragen haben. Wenn Ihre Workload ihre Verpflichtungen nicht erfüllt, teilen Sie, was nicht funktioniert, und arbeiten Sie zusammen und kalibrieren Sie neu, um wieder auf den Richtigen zu kommen.

Plattformteams haben auch Verpflichtungen und Erfolgskriterien. Sie sollten erwarten, dass Ihre Partner Ihnen mitteilen, ob Ihre Workload mit einem Angebot gut funktioniert oder ob sie gefährdet ist, ein lauter Nachbar zu sein.

Streben nach kontinuierlicher Verbesserung an

Ein Thema in allen Well-Architected Framework-Säulen ist die kontinuierliche Verbesserung. Übernehmen Sie eine progressive Denkweise. Sie können sich mit neuen Ansätzen für bestehende Probleme befassen, neue Technologien einführen, neue Anforderungen erfüllen oder unter neuen Einschränkungen arbeiten. Wenn sich Ihre Workload im Laufe der Zeit verbessert, erwarten Sie dieselbe Denkweise von Ihren Partnerteams. Jede Verbesserungsmöglichkeit bedeutet jedoch auch Änderungen und sollte von einem ordnungsgemäßen Verwaltungsprozess unterstützt werden.

Workloadteams sind verpflichtet, mit Plattformteams über vorgeschlagene Änderungen an Workloadanforderungen zu kommunizieren, die sich auf die Dienste des Plattformteams auswirken können. Ebenso sind Plattformteams verpflichtet, ihre Workloadpartner in Änderungssteuerungsprozesse einzubeziehen und die auswirkungenreichen Plattformänderungen klar zu kommunizieren. Richten Sie einen regelmäßigen Kommunikationsrhythmus mit Partnern ein, um mehr über die Entwicklung eines Produkts zu erfahren und zu teilen.

Ein erfolgreiches Ergebnis erzielen

Workloads haben viele Erwartungen von Benutzern, Aktionären, Aufsichtsbehörden, Mitarbeitern, dem Kompetenzzentrum und Chief Experience Officers. Erwartungen können festlegen, dass sich der Richtungskompass dreht. Das Well-Architected Framework bietet Klarheit in Bezug auf den Entwurf und die Implementierung, indem es explizite Rationalisierungen für Architekturentscheidungen bietet, um ein erfolgreiches Ergebnis zu erzielen. Entwickeln Sie eine erfolgreiche Workload, und teilen Sie diesen Erfolg mit Ihrem organization.