Überprüfen und Vergleichen allgemeiner Cloudbetriebsmodelle

Betriebsmodelle sind einzigartig und spezifisch für das Unternehmen, das sie unterstützen, basierend auf ihren aktuellen Anforderungen und Einschränkungen. Betriebsmodelle sind jedoch keine Snowflakes. Es gibt mehrere gängige Muster in Kundenbetriebsmodellen; In diesem Artikel werden die vier am häufigsten verwendeten Muster beschrieben.

Vergleich des Betriebssystemmodells

Die folgende Abbildung zeigt gängige Betriebsmodelle basierend auf der Komplexitätsspanne, von der am wenigsten komplexen (dezentral) bis zu den am komplexesten (weltweite Operationen). In den folgenden Tabellen werden dieselben Betriebsmodelle verglichen, die auf dem relativen Wert einiger anderer Attribute basieren.

Prioritäten oder Umfang

Ein Cloudbetriebsmodell wird in erster Linie von zwei Faktoren gesteuert:

• Strategische Prioritäten oder Motivationen
• Umfang des zu verwaltenden Portfolios

	Dezentralisierte betriebliche Abläufe (ops)	Zentralisierte betriebliche Abläufe (ops)	Betriebliche Abläufe (ops) auf Unternehmensebene	Verteilte betriebliche Abläufe (ops)
Strategische Prioritäten oder Motivationen	Innovation	Steuerung	Demokratisierung	Integration
Umfang des Portfolios	Arbeitsbelastung	Landezone	Cloudplattform	Vollständiges Portfolio
Workloadumgebung	Hohe Komplexität	Geringe Komplexität	Mittlere Komplexität	Mittlere oder variable Komplexität
Landezone	N/V	Hohe Komplexität	Mittlere bis geringe Komplexität	Geringe Komplexität
Grundlegende Hilfsprogramme	N/V	N/A oder niedriger Support	Zentralisiert und höhere Unterstützung	Höchste Unterstützung
Cloudgrundlagen	N/V	N/V	Hybrid-, anbieterspezifische oder regionale Grundlagen	Verteilt und synchronisiert

• Strategische Prioritäten oder Motivationen: Jedes Betriebsmodell liefert die typischen strategischen Motivationen für die Einführung der Cloud. Aber einige Betriebsmodelle vereinfachen bestimmte Motivationen.

• Portfoliobereich: Der Portfoliobereich identifiziert den größten Bereich, den ein bestimmtes Betriebssystemdesign unterstützt. Beispielsweise sind zentralisierte Operationen für einige Landungszonen konzipiert. Die Entscheidung über das Betriebsmodell kann jedoch operative Risiken für eine Organisation darstellen. Operative Risiken ergeben sich beim Versuch, ein großes komplexes Portfolio zu verwalten. Diese Portfolios erfordern möglicherweise viele Landezonen oder eine variable Komplexität im Design der Landezone.

Wichtig

Die Einführung der Cloud löst häufig Überlegungen zum aktuellen Betriebssystem aus und kann zu einer Umstellung von einem gemeinsamen Betriebssystem zu einem anderen führen. Die Cloudakzeptanz ist jedoch nicht der einzige Auslöser. Geschäftsprioritäten und der Umfang der Cloud-Einführung können beeinflussen, wie das Portfolio unterstützt werden muss. Und auch bei einem optimal ausgerichteten Betriebsmodell kann es zu Veränderungen kommen. Wenn das Board oder andere Geschäftsleitungsteams 5 bis 10 Jahre Geschäftspläne entwickeln, umfassen diese Pläne häufig eine Anforderung (explizit oder impliziert), um das Betriebsmodell anzupassen. Betriebsmodelle sind ein guter Bezug für die Entscheidungsfindung. Diese Modelle können sich ändern oder müssen angepasst werden, um Ihre Anforderungen und Einschränkungen zu erfüllen.

Ausrichtung der Verantwortlichkeiten

Viele Teams und Einzelpersonen sind für die Unterstützung verschiedener Funktionen verantwortlich. Jedes gemeinsame Betriebssystem weist jedoch einem Team oder einer Person die endgültige Rechenschaftspflicht für Entscheidungsergebnisse zu. Dieser Ansatz wirkt sich darauf aus, wie das Betriebsmodell finanziert wird und welche Unterstützung für jede Funktion bereitgestellt wird.

	Dezentrale Operationen	Zentralisierte Operationen	Betriebliche Abläufe auf Unternehmensebene	Verteilte Operationen
Geschäftliche Ausrichtung	Workloadteam	zentrale Cloudstrategie	CCoE	Variable – allgemeines Cloudstrategieteam bilden?
Cloudoperationen	Workloadteam	Zentrale IT	CCoE	Basierend auf einer Portfolioanalyse – weitere Informationen finden Sie unter Geschäftliche Ausrichtung und Geschäftliche Verpflichtungen
Cloud-Governance	Workloadteam	Zentrale IT-Abteilung	CCoE	Mehrere Governanceebenen
Cloud-Sicherheit	Workloadteam	Security Operations Center (SOC) / DevSecOps-Funktion	CCoE + SOC	Gemischt – siehe Eine Sicherheitsstrategie festlegen
Cloudautomatisierung und DevOps	Workloadteam	Zentrales IT-Team oder nicht verfügbar	CCoE	Basierend auf einer Portfolioanalyse – weitere Informationen finden Sie unter Geschäftliche Ausrichtung und Geschäftliche Verpflichtungen

Beschleunigung der Umsetzung des Betriebsmodells in Azure

Wie in Definieren des Betriebsmodellsbesprochen, bietet jede Methodik des Cloud Adoption Framework einen strukturierten Weg für die Entwicklung Ihres Betriebsmodells. Diese Methoden können Ihnen helfen, Blocker zu überwinden, die aus Lücken bei der Einführung des Cloudbetriebsmodells resultieren.

In der folgenden Tabelle werden Möglichkeiten zum Beschleunigen der Implementierung des Betriebssystemmodells beschrieben.

	Dezentrale Operationen	Zentralisierte Operationen	Betriebliche Abläufe auf Unternehmensebene	Verteilte Operationen
Ausgangspunkt	Azure Well-Architected Framework (WAF)	Azure-Zielzonen: Optionen zum einfachen Starten	Azure-Zielzonen: CAF auf Unternehmensebene	Geschäftliche Ausrichtung
Iterationen	Ein Fokus auf Workloads ermöglicht es dem Team, innerhalb der WAF zu iterieren.	Bei der Option für einen einfachen Start sind mehr Iterationen für die einzelnen Methodiken erforderlich. Diese können jedoch durchgeführt werden, wenn die Cloudeinführung weiter vorangeschritten ist.	Wie in den Referenzimplementierungen dargestellt, konzentrieren sich zukünftige Iterationen in der Regel auf Nebenkonfigurationszusätze.	Sehen Sie sich den Artikel Implementierungsoptionen für Zielzonen an, um mit der Option zu beginnen, die den Grundlagen Ihrer betrieblichen Abläufe am besten entspricht. Folgen Sie dem Iterationspfad, der in den Entwurfsprinzipien dieser Option definiert ist.

Dezentrale Vorgänge

Vorgänge sind immer komplex. Wenn Sie den Umfang Ihrer Vorgänge auf eine Arbeitslast oder eine kleine Sammlung von Arbeitslasten beschränken, haben Sie die Komplexität im Griff. Dezentrale Vorgänge sind die am wenigsten komplexen gängigen Betriebsmodelle. Bei dieser Form des Betriebs werden alle Workloads unabhängig von dedizierten Workload-Teams ausgeführt.

• Prioritäten: Ihr Team misst Innovation über zentralisierte Kontrolle oder Standardisierung über mehrere Workloads hinweg.
• Eindeutiger Vorteil: Maximieren Sie die Innovationsgeschwindigkeit, indem Sie Workload- und Geschäftsteams uneingeschränkte Kontrolle über Entwurf, Erstellung und betriebliche Abläufe geben.
• Eindeutiger Nachteil: Bei der workloadübergreifenden Standardisierung, bei Größenvorteilen über gemeinsam genutzte Dienste und bei einer konsistenten Governance für eine zentralisierte Compliance müssen Einbußen gemacht werden.
• Risiko: Dieser Ansatz kann Risiken einführen, wenn ein Workloadportfolio verwaltet wird. Workloadteams verfügen möglicherweise über spezielle Teams für zentrale IT-Funktionen. Dieses Betriebsmodell wird von einigen Organisationen als Option mit hohem Risiko betrachtet, insbesondere von Unternehmen, die dazu verpflichtet sind, Vorgaben von Drittanbietern einzuhalten.
• Leitfaden: Dezentrale betriebliche Abläufe sind auf Entscheidungen auf Workload-Ebene beschränkt. Microsoft Azure Well-Architected Framework unterstützt die in diesem Bereich getroffenen Entscheidungen. Die Prozesse und Anleitungen im Cloud Adoption Framework können zusätzlichen Aufwand verursachen, der von dezentralen Vorgängen nicht benötigt wird.

Vorteile dezentraler Vorgänge

• Kostenmanagement: Die Betriebskosten werden einfach einer einzelnen Geschäftseinheit zugeordnet. Workloadspezifische betriebliche Abläufe unterstützen eine bessere Workload-Optimierung.
• Verantwortlichkeiten: In der Regel hängt diese Art von Vorgängen stark von der Automatisierung ab, um den Aufwand zu minimieren. Verantwortlichkeiten konzentrieren sich in der Regel auf DevOps und Pipelines für die Releaseverwaltung. Diese Art von Vorgängen unterstützt schnellere Bereitstellungen und kürzere Feedbackzyklen während der Entwicklung.
• Standardisierung: Verwenden Sie eine Quellcode- und Bereitstellungspipeline, um die Umgebung von Release zu Release zu standardisieren.
• Unterstützung von Vorgängen: Entscheidungen, die sich auf Vorgänge auswirken, beziehen sich nur auf die Bedürfnisse dieser Arbeitslast und die Vereinfachung von Entscheidungsprozessen. Mitglieder der DevOps-Community sagen, dass es sich beim Support für betriebliche Abläufe aufgrund des engeren Umfangs um die reinste Form von betrieblichen Abläufen handelt.
• Erfahrung: DevOps- und Entwicklungsteams erhalten die meisten Vorteile durch diesen Ansatz und werden durch Marktänderungen am wenigsten beeinflusst.
• Design des Landebereichs: Kein bestimmter betrieblicher Vorteil.
• Grundlegende Dienstleistungen: Kein spezifischer betrieblicher Vorteil.
• Aufgabentrennung: Kein spezifischer betriebstechnischer Vorteil.

Nachteile dezentraler Vorgänge

• Kostenverwaltung: Enterprise-Kosten sind schwieriger zu berechnen. Der Mangel an zentralisierten Governance-Teams macht es schwieriger, einheitliche Kostenkontrollen oder Optimierungen zu implementieren. In großem Maßstab kann dieses Modell kostspielig sein, da jede Arbeitslast möglicherweise Duplikationen in den bereitgestellten Ressourcen und Personalzuweisungen aufweist.
• Zuständigkeiten: Fehlender zentralisierter Support bedeutet, dass das Workloadteam vollständig für Governance, Sicherheit, betriebliche Abläufe und Change Management verantwortlich ist. Der Mangel an Unterstützung ist problematisch, wenn diese Aufgaben in Codeüberprüfungs- und Freigabepipelinen nicht automatisiert wurden.
• Standardisierung: Die Standardisierung für ein gesamtes Workloadportfolio ist variabel und inkonsistent.
• Support für betriebliche Abläufe: Skaleneffizienzen werden bei der Erstellung bewährter Methoden für mehrere Workloads häufig übersehen.
• Expertise: Teammitglieder haben eine größere Verantwortung, kluge und ethische Entscheidungen über Governance, Sicherheit, Betrieb und Change Management innerhalb des Anwendungsdesigns und der Konfiguration zu treffen. Wenden Sie sich häufig an das Microsoft Azure Well-Architected Review and Azure Well-Architected Framework, um die erforderliche Expertise zu verbessern.
• Design der Landezone: Landezonen sind nicht auf spezifische Arbeitslasten ausgerichtet und werden in diesem Ansatz nicht berücksichtigt.
• Grundlagen-Dienstprogramme: Nur wenige (falls überhaupt) grundlegende Dienstprogramme werden über Arbeitslasten hinweg gemeinsam genutzt, was die Skaleneffizienz verringert.
• Trennung von Aufgaben: Höhere Anforderungen an DevOps- und Entwicklungsteams führen zu einer verstärkten Nutzung erweiterter Berechtigungen durch diese Teams. Wenn Sie eine Trennung von Aufgaben benötigen, müssen Sie möglicherweise stark in DevOps-Reife investieren, um mit diesem Ansatz zu arbeiten.

Zentralisierte Vorgänge

Stabile Zustandsumgebungen erfordern möglicherweise keinen Fokus auf die Architektur oder die unterschiedlichen betrieblichen Anforderungen der einzelnen Workloads. Zentralisierte Abläufe sind typischerweise die Norm für Technologieumgebungen, die hauptsächlich aus stabilisierten Arbeitslasten bestehen. Beispiele für betriebliche Abläufe mit stabilem Zustand sind COTS-Anwendungen (commercial off-the-shelf) und bewährte benutzerdefinierte Anwendungen mit einem langsamen Releaserhythmus. Wenn eine Änderungsrate durch regelmäßige Updates und Patches gesteuert wird, kann die Zentralisierung von Vorgängen eine effektive Möglichkeit zur Verwaltung Ihres Portfolios sein.

• Prioritäten: Prioritäten sind der zentrale Steuermechanismus für Innovationen und messen die bestehenden betrieblichen Prozesse in Bezug auf den kulturellen Wandel hin zu modernen Cloud-Operationen.
• Eindeutiger Vorteil: Zentralisierung führt zu Größenvorteilen, branchenführenden Steuerungsmöglichkeiten und standardisierten betrieblichen Abläufen. Sie funktioniert am besten mit der Cloudumgebung. Diese Umgebungen benötigen spezifische Konfigurationen, um Cloudvorgänge in vorhandene Vorgänge und Prozesse zu integrieren. Die Zentralisierung ist mit einem Portfolio von wenigen hundert Arbeitslasten mit bescheidener Architekturkomplexität und Compliance-Anforderungen am vorteilhaftsten.
• Eindeutiger Nachteil: Die Skalierung, um die Anforderungen eines großen Portfolios von Workloads zu erfüllen, kann erhebliche Belastung für zentralisierte Teams bedeuten, die operative Entscheidungen für Produktionsworkloads treffen. Wenn erwartet wird, dass technische Ressourcen über 1.000 VMs, Anwendungen oder Datenquellen hinaus skaliert werden, sollten Sie ein Unternehmensmodell in Betracht ziehen, wenn dies innerhalb von 18 bis 24 Monaten der Fall ist.
• Risiko: Dieser Ansatz begrenzt die Zentralisierung auf eine kleinere Anzahl an Abonnements (oft ein Produktionsabonnement). Ein späteres Refactoring im Rahmen Ihrer Cloud Journey ist mit einem erheblichen Risiko verbunden und kann zu Problemen mit Ihren Einführungsplänen führen. Um Überarbeitungen zu vermeiden, versuchen Sie, sich auf Segmentierung, Umgebungsgrenzen, Identitätstools und andere grundlegende Elemente zu konzentrieren.
• Leitfaden: Implementierungsoptionen für Azure-Zielzonen, die dem Entwicklungsprinzip „klein beginnen und dann größer werden“ entsprechen, sind ein geeigneter Startpunkt. Sie können diese Optionen verwenden, um die Einführungsbemühungen zu beschleunigen. Um erfolgreich zu sein, richten Sie jedoch klare Richtlinien ein, um frühzeitige Einführungsbemühungen innerhalb akzeptabler Risikotoleranzen zu unterstützen. Methodiken für Governance und Verwaltung helfen bei der Erstellung von Prozessen, mit denen betriebliche Abläufe parallel weiterentwickelt werden können. Diese Schritte dienen als Stufensperren, die abgeschlossen werden müssen, bevor im Zuge der weiteren Entwicklung betrieblicher Abläufe höhere Risiken akzeptiert werden.

Vorteile zentralisierter Vorgänge

• Kostenverwaltung: Durch die Zentralisierung von gemeinsamen Diensten über viele Arbeitslasten hinweg werden Skalenvorteile geschaffen und doppelte Aufgaben beseitigt. Zentrale Teams können durch unternehmensweite Größen- und Skalierungsoptimierungen schnell Kostenreduzierungen implementieren.
• Verantwortlichkeiten: Zentralisierte Expertise und Standardisierung können zu einer höheren Stabilität, einer besseren betrieblichen Leistung und minimalen Ausfällen im Zusammenhang mit Änderungen führen. Dieser Ansatz reduziert den allgemeinen Qualifizierungsdruck auf die workloadorientierten Teams.
• Standardisierung: Im Allgemeinen ist Standardisierung und Betriebskosten mit einem zentralisierten Modell am niedrigsten, da weniger duplizierte Systeme oder Vorgänge vorhanden sind.
• Unterstützung der Betriebsvorgänge: Das Reduzieren von Komplexität und die Zentralisierung von Vorgängen erleichtert es kleineren IT-Teams, Betriebsvorgänge zu unterstützen.
• Fachwissen: Die Zentralisierung unterstützender Teams ermöglicht es Experten in den Bereichen Sicherheit, Risiko, Governance und Betrieb, geschäftskritische Entscheidungen voranzutreiben.
• Zielzonenentwurf: Die Zentralisierung der IT minimiert die Anzahl von Zielzonen und Abonnements und verringert so die Komplexität. Zielzonendesigns neigen dazu, die vorherigen Rechenzentrumsdesigns nachzuahmen, wodurch die Übergangszeit reduziert wird. Im weiteren Verlauf der Einführung können gemeinsam genutzte Ressourcen in ein separates Abonnement oder in eine separate Plattformumgebung verschoben werden.
• Grundlegende Dienste: Indem Sie bestehende Rechenzentrumsdesigns in die Cloud übertragen, ergeben sich grundlegende, gemeinsame Dienste, die vor Ort bereitgestellte Tools und Abläufe imitieren. Wenn On-Premises-Betriebsabläufe Ihr primäres Betriebsmodell sind, kann dies von Vorteil sein, aber Vorsicht vor einigen Nachteilen. Vor-Ort-Betrieb reduziert die Übergangszeit, nutzt Größenvorteile und unterstützt konsistente betriebliche Abläufe zwischen lokalem Betrieb und in der Cloud gehosteten Workloads. Dieser Ansatz kann die kurzfristige Komplexität und den Aufwand reduzieren und kleineren Teams die Unterstützung von Cloud-Vorgängen mit reduzierten Lernkurven ermöglichen.
• Aufgabenteilung: Eine Aufgabenteilung ist essentiell für zentrale betriebliche Abläufe. Die zentrale IT kontrolliert die Produktionsumgebungen und reduziert die Notwendigkeit erhöhter Berechtigungen von anderen Teams. Dieser Ansatz reduziert Sicherheitsverletzungen, indem die Anzahl der Konten mit erhöhten Berechtigungen eingeschränkt wird.

Nachteile zentralisierter Vorgänge

• Kostenmanagement: Zentrale Teams haben nicht immer das nötige Verständnis für Workload-Architekturen, um effektive Optimierungen auf Workloadebene durchzuführen. Dieser Mangel an Verständnis begrenzt den Umfang der Kosteneinsparungen, die aus gut abgestimmten Arbeitslastvorgängen stammen. Mangelndes Verständnis der Workloadarchitektur kann sich auf zentralisierte Kostenoptimierungen auswirken, was wiederum Auswirkungen auf die Leistung, Skalierung und andere Säulen eines gut ausgearbeiteten Workload hat. Bevor Sie unternehmensweite Kostenänderungen auf hochprofilige Workloads anwenden, sollte Ihr zentrales IT-Team die Überprüfung von Microsoft Azure Well-Architected verstehen und abschließen.
• Zuständigkeiten: Die Zentralisierung des Produktionssupports und des Zugriffs ist mit einer hohen betrieblichen Auslastung einiger weniger Personen verbunden und erhöht den Druck auf jeden Einzelnen. Der Druck auf diese Personen führt dazu, dass tiefere Überprüfungen der implementierten Workloads durchgeführt werden müssen. Dadurch wird die Einhaltung detaillierter Sicherheits-Governance- und Complianceanforderungen überprüft.
• Standardisierung: Zentrale IT-Ansätze erschweren es, die Standardisierung zu skalieren, ohne dass auch das zentrale IT-Personal linear mitwächst.
• Support für betriebliche Abläufe: Die größten Nachteile dieses Ansatzes hängen mit der erheblichen Skalierung und wesentlichen Änderungen zur Messung der Innovation zusammen.
• Expertise: Entwickler- und DevOps-Experten laufen Gefahr, in dieser Art von Umgebung unterbewertet oder zu sehr eingeschränkt zu werden.
• Zielzonenaufbau: Rechenzentrumsentwürfe basieren auf Einschränkungen vorheriger Ansätze, die nicht immer eine Rolle für die Cloud spielen müssen. Im Anschluss an diesen Ansatz werden die Möglichkeiten reduziert, die Segmentierung des Umfelds zu überdenken und Möglichkeiten für Innovationen zu fördern. Das Fehlen einer Zielzonensegmentierung erhöht die potenziellen Auswirkungen von Sicherheitsverletzungen, die Komplexität der Governance und die Einhaltung von Vorschriften und kann Hindernisse für die Einführung in die Cloud schaffen. Siehe oben den Abschnitt "Risiken".
• Foundational Utilities: Während der digitalen Transformation kann die Cloud zum primären Betriebssystemmodell werden. Zentrale Tools, die für lokale Vorgänge aufgebaut sind, reduzieren die Möglichkeiten zur Modernisierung von Vorgängen und verringern die betriebliche Effizienz. Die Entscheidung, Vorgänge nicht frühzeitig im Einführungsprozess zu modernisieren, ist auch eine Option. Die Modernisierung kann durch die Erstellung eines Plattformgrundlagenabonnements im Zuge der Cloudeinführung erreicht werden. Dieser Aufwand kann komplex, kostspielig und zeitaufwendig sein, ohne fortgeschrittene Planung.
• Trennung von Aufgaben: Zentrale Vorgänge folgen in der Regel einem von zwei Wegen und können beide Innovationen behindern.
  • Option 1: Teams außerhalb der zentralen IT erhalten eingeschränkten Zugriff auf Entwicklungsumgebungen, die die Produktion imitieren. Diese Option behindert das Experimentieren.
  • Option 2: Teams entwickeln und testen in nicht unterstützten Umgebungen. Diese Option behindert Bereitstellungsprozesse und verlangsamt Integrationstests nach der Bereitstellung.

Enterprise-Vorgänge

Enterprise-Vorgänge sind der vorgeschlagene Zielzustand für alle Cloudvorgänge. Unternehmensabläufe balancieren das Bedürfnis nach Kontrolle und Innovation aus, indem sie Entscheidungen und Verantwortlichkeiten vereinfachen. Die Zentrale IT wird durch ein unterstützenderes Exzellenz-Zentrum für Cloud-Technologien beziehungsweise CCoE-Team ersetzt, das die Workload-Teams unterstützt. Das CCoE-Team zieht die Workload-Teams für ihre Entscheidungen zur Verantwortung, anstatt ihre Handlungen zu kontrollieren oder einzuschränken. Teams mit hoher Arbeitsbelastung erhalten mehr Befugnisse und Verantwortung, um Innovationen voranzutreiben, innerhalb klar definierter Leitplanken.

• Prioritäten: Prioritäten sind die Demokratisierung technischer Entscheidungen. Die Demokratisierung technischer Entscheidungen verlagert die Verantwortlichkeiten, die zuvor von der zentralen IT gehalten wurden, auf die Workload-Teams. Um diese Verschiebung der Prioritäten zu ermöglichen, sind Entscheidungen weniger abhängig von von Menschen geführten Prüfungsprozessen. Dieser Ansatz unterstützt automatisierte Überprüfungen, Governance und Durchsetzung mithilfe von cloudeigenen Tools.
• Eindeutiger Vorteil: Segmentierung von Umgebungen und Trennung von Aufgaben ermöglichen ein Gleichgewicht zwischen Kontrolle und Innovation. Bei zentralisierten betrieblichen Abläufen werden Workloads verwaltet, die eine höhere Compliance und stabile betriebliche Abläufe erfordern oder größere Sicherheitsrisiken darstellen. Umgekehrt unterstützt dieser Ansatz die Reduzierung der zentralen Kontrolle von Arbeitslasten und Umgebungen, die eine größere Innovation erfordern. Größere Portfolios könnten mit dem Gleichgewicht zwischen Kontrolle und Innovation kämpfen. Diese Flexibilität erleichtert das Skalieren von Tausenden von Arbeitslasten mit einer Verringerung der operativen Belastungen.
• Eindeutiger Nachteil: Was lokal funktioniert hat, funktioniert möglicherweise nicht gut im Cloud-Betrieb von Unternehmen. Dieser Ansatz für Vorgänge erfordert Änderungen an vielen Fronten. Kulturelle Veränderungen in Kontrolle und Verantwortung sind oft die größte Herausforderung. Operationelle Umstellungen, die dem kulturellen Wandel folgen, benötigen Zeit und engagierte Anstrengungen, um umgesetzt, gereift und stabilisiert zu werden. Architektonische Verschiebungen können bei stabilen Arbeitslasten erforderlich sein, während Werkzeuganpassungen notwendig sind, um die kulturellen, betrieblichen und architektonischen Verschiebungen zu stärken und zu unterstützen. Diese Änderungen erfordern möglicherweise Verpflichtungen an einen primären Cloudanbieter. Bereits vor diesen Änderungen unternommene Einführungsbemühungen können erhebliche Überarbeitungen erfordern, die über typische Umgestaltungsmaßnahmen hinausgehen.
• Risiko: Dieser Ansatz erfordert ein Engagement der Geschäftsleitung für die Änderungsstrategie. Es erfordert auch Engagement von den technischen Teams, um Lernkurven zu überwinden und die erforderliche Änderung zu liefern. Langfristige Zusammenarbeit zwischen Unternehmen, CCoE, der zentralen IT-Abteilung und den Workload-Teams ist erforderlich, um langfristige Vorteile zu erzielen.
• Leitfaden: Azure-Zielzonenoptionen sind als Unternehmensebene definiert. Diese Optionen stellen Referenzimplementierungen bereit, um zu demonstrieren, wie technische Änderungen mit cloudnativen Tools in Azure bereitgestellt werden. Der unternehmensweite Ansatz führt Teams durch die betrieblichen und kulturellen Schichten, die erforderlich sind, um diese Implementierungen vollständig nutzen zu können. Der gleiche Ansatz kann verwendet werden, um die Referenzarchitektur anzupassen und die Umgebung so zu konfigurieren, dass sie Ihrer Einführungsstrategie und Ihren Complianceeinschränkungen entspricht. Wenn Sie in Unternehmensmaßstab arbeiten, können die Methoden "Steuern" und "Verwalten" helfen, Prozesse zu definieren. Diese Prozesse können Ihre Compliance- und Betriebsfunktionen erweitern, um Ihre betrieblichen Anforderungen zu erfüllen.

Vorteile von Unternehmensvorgängen

• Kostenverwaltung: Zentrale Teams arbeiten an Optimierungen für das gesamte Portfolio. Einzelne Teams sind dabei für tiefergreifende Workloadoptimierungen verantwortlich. Auf Workload fokussierte Teams werden in die Lage versetzt, Entscheidungen zu treffen und Klarheit zu schaffen, wenn diese Entscheidungen negative Auswirkungen auf die Kosten haben. Zentrale Teams und Workloadteams sind gemeinsam für Kostenentscheidungen auf entsprechender Ebene verantwortlich.
• Verantwortlichkeiten: Zentrale Teams verwenden Cloud-native Tools, um Leitplanken zu definieren, durchzusetzen und zu automatisieren. Die Arbeit von Workloadteams wird durch CCoE-Automatisierung und entsprechende Methoden beschleunigt. Workload-Teams sind ermächtigt, Innovationen voranzutreiben und Entscheidungen innerhalb dieser Leitplanken zu treffen.
• Standardisierung: Zentrale Schutzschienen und grundlegende Dienste schaffen Einheitlichkeit über alle Umgebungen hinweg.
• Support für betriebliche Abläufe: Workloads, für die Unterstützung für zentralisierte betriebliche Abläufe erforderlich ist, werden in Umgebungen mit stabilen Steuerungsoptionen unterteilt. Die Segmentierung und die Aufgabenteilung motivieren Workloadteams, die Verantwortung für die betriebliche Unterstützung ihrer eigenen dedizierten Umgebungen zu übernehmen. Automatisierte cloudeigene Tools stellen einen Minimalbetriebsbasisplan für alle Umgebungen mit zentralisierter betrieblicher Unterstützung sicher.
• Erfahrung: Die Zentralisierung von Kerndiensten wie Sicherheit, Risiko, Governance und betriebliche Abläufe gewährleistet angemessenes zentrales Fachwissen. Eindeutige Prozesse und Schutzmaßnahmen sorgen für Klarheit bei Workloadteams und ermöglichen es ihnen, detailliertere Entscheidungen zu treffen. Diese Entscheidungen erweitern die Wirkung der zentralisierten Experten, ohne die Mitarbeiter linear mit Technologiemaßstab skalieren zu müssen.
• Zielzonenentwurf: Der Zielzonenentwurf spiegelt die Anforderungen des Portfolios wider und sorgt für eine klare Abgrenzung in den Bereichen Sicherheit, Governance und Verantwortlichkeit. Diese Grenzen sind erforderlich, um Workloads in der Cloud zu betreiben. Es ist unwahrscheinlich, dass Segmentierungspraktiken den durch frühere Rechenzentrumsgestaltungen geschaffenen Einschränkungen ähneln. Bei betrieblichen Abläufen auf Unternehmensebene ist der Zielzonenentwurf weniger komplex, ermöglicht eine schnellere Skalierung und senkt die Hürden für Self-Service-Nachfrage.
• Grundlegende Dienste: Grundlegende Dienste werden in separaten zentral gesteuerten Abonnements gehostet, die als Plattform-Grundlage bekannt sind. Zentrale Tools werden dann als Hilfsprogramme in jede Zielzone geleitet. Die Trennung der grundlegenden Hilfsprogramme von den Zielzonen maximiert Konsistenz und Skalierung. Diese Hilfsprogramme sorgen außerdem für eine klare Unterscheidung zwischen zentral verwalteten Zuständigkeiten und Zuständigkeiten auf Workloadebene.
• Aufgabentrennung: Eine klare Aufgabentrennung zwischen grundlegenden Hilfsprogrammen und Zielzonen ist einer der größten Vorteile des Ansatzes für betriebliche Abläufe. Cloudeigene Tools und Prozesse unterstützen den Zugriff und die richtige Balance der Kontrolle zwischen zentralisierten Teams und Workload-Teams. Dieser Ansatz basiert auf den Anforderungen einzelner Zielzonen und den Workloads, die in Zielzonensegmenten gehostet werden.

Nachteile von Unternehmensvorgängen

• Kostenverwaltung: Zentrale Teams sind stärker davon abhängig, dass Workloadteams Produktionsänderungen in den Zielzonen vornehmen. Dadurch besteht die Gefahr möglicher Budgetüberschreitungen und einer langsameren richtigen Dimensionierung der tatsächlichen Ausgaben. Kostensteuerungsprozesse, klare Budgets, automatisierte Kontrollen und regelmäßige Überprüfungen müssen frühzeitig durchgeführt werden, um Kostenwunder zu vermeiden.
• Verantwortlichkeiten: Unternehmensvorgänge erfordern größere kulturelle und betriebliche Anforderungen. Diese Anforderungen sorgen für Klarheit bei den Zuständigkeiten und bei der Verantwortung zwischen zentralen Teams und Workloadteams.
• Herkömmliche Change Management-Prozesse oder Änderungsbeiräte (Cabs) behalten möglicherweise nicht das Tempo und das Gleichgewicht bei, das in diesem Betriebsmodell erforderlich ist. Diese Prozesse spiegeln sich in der Automatisierung von Prozessen und Verfahren wider, die die Cloudakzeptanz sicher skalieren.
• Mangel an Veränderungsbereitschaft zeigt sich zuerst bei der Verhandlung und Abstimmung von Verantwortlichkeiten. Eine Unfähigkeit, sich an Änderungen der Verantwortungen anzupassen, ist ein Indikator dafür, dass zentrale IT-Betriebsmodelle während kurzfristigen Cloudeinführungsbemühungen erforderlich sein könnten.
• Standardisierung: Fehlende Investitionen in zentralisierte Schutzschienen oder Automatisierung schaffen Risiken für die Standardisierung, was durch manuelle Überprüfungsprozesse schwieriger zu überwinden ist. Betriebliche Abhängigkeiten zwischen Workloads in Zielzonen und freigegebenen Diensten erhöhen das Risiko. Dieses Risiko geht von der Standardisierung im Rahmen von Upgradezyklen oder zukünftigen Versionen der grundlegenden Hilfsprogramme aus. Bei Überarbeitungen der Plattformumgebung sind verbesserte oder sogar automatisierte Tests für alle unterstützten Zielzonen und darin gehosteten Workloads erforderlich.
• Unterstützung der Abläufe: Die durch Automatisierung und zentralisierte Vorgänge bereitgestellten Betriebsgrundlagen reichen möglicherweise für Arbeitslasten mit geringer Auswirkung oder geringer Kritikalität aus. Für komplexe oder hochkritische Workloads können jedoch Workload-Teams oder andere Formen dedizierter Vorgänge erforderlich sein. Wenn ja, kann dies zu einer Verlagerung der Betriebsbudgets führen, sodass Geschäftseinheiten diesen Formen erweiterter Vorgänge Betriebsausgaben zuordnen müssen. Wenn die zentrale IT erforderlich ist, um die alleinige Rechenschaftspflicht für die Betriebskosten zu gewährleisten, kann die Implementierung von Unternehmensvorgängen schwierig sein.
• Fachwissen: Die Mitglieder des zentralen IT-Teams müssen möglicherweise Fachwissen zur Automatisierung zentraler Steuerung entwickeln, die zuvor über manuelle Prozesse bereitgestellt wurde. Darüber hinaus müssen sich diese Teams ggf. mit Infrastructure-as-Code-Ansätzen zum Definieren der Umgebung sowie mit Verzweigungen, Zusammenführungen und Bereitstellungspipelines vertraut machen. Zumindest benötigt ein Plattformautomatisierungs-Team möglicherweise Entscheidungskompetenzen, um Verständnis für Entscheidungen zu haben, die vom Cloud Centre of Excellence oder von zentralen Betriebsteams getroffen werden. Workloadteams müssen unter Umständen zusätzliches Wissen zu Steuerungsmöglichkeiten und Prozessen sammeln, die ihre Entscheidungen stützen.
• Design der Landezone: Das Design der Landezone hängt von grundlegenden Diensten ab. Workloadteams sollten verstehen, was im Entwurf enthalten ist und was nicht enthalten sein darf. Dieses Verständnis kann dazu beitragen, Doppelarbeit, Fehler oder Konflikte zu vermeiden. Um Flexibilität zu schaffen, können Sie Ausnahmeprozesse in Ihre Landing Zone-Designs einbeziehen.
• Grundlegende Hilfsprogramme: Die Zentralisierung grundlegender Hilfsprogramme benötigt Zeit. Diese Hilfsprogramme berücksichtigen letztendlich Optionen und entwickeln Lösungen, die skaliert werden können, um die Anforderungen verschiedener Einführungspläne zu erfüllen. Verzögerungen bei frühen Einführungsbemühungen sind möglich. Verzögerungen können langfristig durch Beschleunigungen und Vermeidung von Blockaden zu einem späteren Zeitpunkt im Prozess ausgeglichen werden.
• Trennung von Aufgaben: Eine klare Trennung der Aufgaben erfordert reife Identitätsmanagementprozesse. Mit der richtigen Ausrichtung von Benutzer*innen, Gruppen und Onboarding- und Offboarding-Aktivitäten ist möglicherweise mehr Wartung verbunden. Möglicherweise müssen Sie neue Prozesse einführen, um den Just-in-Time-Zugriff über erhöhte Berechtigungen zu ermöglichen.

Verteilte Operationen

Das bestehende Betriebsmodell ist möglicherweise zu stark verankert, als dass die gesamte Organisation zu einem neuen Betriebsmodell wechseln könnte. Für andere können globale Vorgänge und verschiedene Complianceanforderungen möglicherweise verhindern, dass bestimmte Geschäftseinheiten eine Änderung vornehmen. In diesem Fall ist möglicherweise ein Ansatz zur Verteilung von Operationen erforderlich. Dieser Ansatz ist bei weitem der komplexeste, da er eine oder mehrere der zuvor erwähnten Betriebsmodelle integriert.

Obwohl von diesem Betriebsansatz dringend abgeraten wird, kann es für einige Organisationen erforderlich sein. Der Ansatz bezieht sich hauptsächlich auf Organisationen, die über eine lose Sammlung unterschiedlicher Geschäftseinheiten, vielfältige Kundensegmente oder regionale Geschäftsaktivitäten verfügen.

• Prioritäten: Integrieren mehrerer vorhandener Betriebsmodelle.
• Übergangszustand mit Fokus auf der Umstellung der gesamten Organisation auf eines der zuvor erwähnten Betriebsmodelle.
• Langfristiger betrieblicher Ansatz, wenn die Organisation zu groß oder zu komplex ist, um sich an ein einzelnes Betriebssystem auszurichten.
• Unterschiedlicher Vorteil: Integrieren Sie allgemeine Betriebssystemelemente aus den einzelnen Geschäftseinheiten. Mit diesem Ansatz wird ein Mittel geschaffen, um Betriebseinheiten in einer Hierarchie zu strukturieren, die ihnen dabei hilft, die Abläufe durch konsistente, wiederholbare Prozesse zu optimieren und reifen zu lassen.
• Unterschiedlicher Nachteil: Konsistenz und Standardisierung in mehreren Betriebsmodellen ist für längere Zeiträume schwierig zu halten. Dieser betriebliche Ansatz erfordert ein tiefes Bewusstsein für das Portfolio und die Funktionsweise verschiedener Segmente des Technologieportfolios.
• Risiko: Mangelnde Verpflichtung zu einem primären Betriebsmodell könnte zu Verwirrung in allen Teams führen. Verwenden Sie dieses Betriebsmodell, wenn es keine Möglichkeit gibt, sich auf ein einziges Betriebsmodell auszurichten.
• Leitfaden: Beginnen Sie mit einer gründlichen Überprüfung des Portfolios. Verwenden Sie dazu den Ansatz, der im Artikel Geschäftliche Ausrichtung beschrieben ist. Versuchen Sie, das Portfolio nach dem staatlichen Betriebsmodell (dezentral, zentral oder unternehmen) zu gruppieren.
• Entwickeln Sie eine Verwaltungsgruppenhierarchie, die die Betriebsmodellgruppierungen widerspiegelt. Diese Anordnung umfasst andere Organisationsmuster für Region, Unternehmenseinheit oder andere Kriterien, die die Workloadcluster von den am wenigsten verbreiteten zu den häufigsten Buckets abbilden.
• Bewerten Sie die Ausrichtung der Workloads für Betriebsmodelle, um für den Beginn den relevantesten Betriebsmodellcluster zu finden. Orientieren Sie sich bei allen Workloads unter der Knoten- und Verwaltungsgruppenhierarchie an dem Leitfaden, der dem Betriebsmodell zugeordnet ist.
• Verwenden Sie Governance- und Managementmethoden, um allgemeine Unternehmensrichtlinien zu finden, einschließlich erforderlicher betrieblicher Managementpraktiken an verschiedenen Stellen der Hierarchie. Wenden Sie allgemeine Azure-Richtlinien an, um die gemeinsamen Unternehmensrichtlinien zu automatisieren.
• Wenn Sie Azure-Richtlinien mit verschiedenen Bereitstellungen testen, versuchen Sie, sie in der Verwaltungsgruppenhierarchie höher zu verschieben. Die Richtlinien können auf viele Workloads angewendet werden, die möglicherweise Gemeinsamkeiten und unterschiedliche Betriebsanforderungen finden.
• Dieser Ansatz könnte Ihnen helfen, ein Modell zu definieren, das sich auf verschiedene Betriebsmodelle skalieren lässt. Dieser Ansatz kann auch Teams durch eine Reihe gemeinsamer Richtlinien und Verfahren vereinheitlichen.

Vor- und Nachteile dieses Ansatzes sind absichtlich leer. Nachdem Sie die Geschäftsausrichtung Ihres Portfolios abgeschlossen haben, finden Sie im vorstehenden Abschnitt des vorherrschenden Betriebsmodells Klarheit über Vor- und Nachteile.

Nächste Schritte

Lernen Sie die Terminologie kennen, die mit Betriebsmodellen verknüpft ist. Die Terminologie hilft Ihnen zu verstehen, wie ein Betriebsmodell in das größere Thema der Unternehmensplanung passt.

Terminologie des Betriebssystemmodells

Erfahren Sie, wie eine Landing Zone den Grundstein jeder Cloud-Einführungsumgebung bildet.

Was ist eine Landezone?