# Betriebsmodell-2-mal-2-Darstellungen
Diese Betriebsmodell-2-mal-2-Darstellungen sind Abbildungen, die Ihnen helfen, die Beziehungen zwischen Teams in Ihrer Umgebung zu verstehen. Diese Diagramme konzentrieren sich darauf, wer was tut und welche Beziehungen zwischen Teams bestehen. Wir werden jedoch auch Governance und Entscheidungsfindung im Kontext dieser Beispiele besprechen.
Ihre Teams haben möglicherweise Zuständigkeiten in mehreren Teilen mehrerer Modelle, abhängig von den Workloads, die sie unterstützen. Möglicherweise möchten Sie spezialisiertere Fachbereiche als die beschriebenen übergeordneten Bereiche aufschlüsseln. Es besteht das Potenzial für endlose Variationen bei diesen Modellen, wenn Sie Aktivitäten trennen oder aggregieren oder Teams überlagern und spezifischere Details bereitstellen.
Sie können feststellen, dass Sie sich überschneidende oder nicht erkannte Funktionen in Teams haben, die einen zusätzlichen Vorteil bieten oder zu Effizienzsteigerungen führen können. Sie können auch unbefriedigte Bedürfnisse in Ihrer Organisation identifizieren, die Sie berücksichtigen können.
Prüfen Sie bei der Bewertung der organisatorischen Veränderungen die Kompromisse zwischen Modellen, wo sich Ihre einzelnen Teams innerhalb der Modelle befinden (jetzt und nach der Änderung), wie sich die Beziehung und Verantwortlichkeiten Ihrer Teams ändern werden und ob die Vorteile die Auswirkungen auf Ihre Organisation rechtfertigen.
Sie können mit jedem der folgenden vier Betriebsmodelle erfolgreich sein. Einige Modelle eignen sich besser für bestimmte Anwendungsfälle oder an bestimmten Punkten in Ihrer Entwicklung. Einige dieser Modelle bieten möglicherweise Vorteile gegenüber denjenigen, die in Ihrer Umgebung verwendet werden.
**Topics**
+ [Vollständig getrenntes Betriebsmodell](fully-separated-operating-model.md)
+ [DevOps mit Cloud-verwaltetem Serviceanbieter](devops-with-cloud-managed-service-provider.md)
+ [Cloud Operations and Platform Enablement (COPE)](cloud-operations-and-platform-enablement.md)
+ [Verteilte DevOps](distributed-devops.md)
+ [Dezentralisierte DevOps](decentralized-devops.md)
+ [Weiterentwicklung Ihres Betriebsmodells](evolving-your-ops-model.md)
# Vollständig getrenntes Betriebsmodell
Im folgenden Diagramm werden auf der vertikalen Achse Anwendungen und Plattform angezeigt. Anwendungen beziehen sich auf die Workload, die einem Geschäftsergebnis dient, und können kundenspezifisch entwickelte oder gekaufte Software sein. Plattform bezieht sich auf die physische und virtuelle Infrastruktur und andere Software, die diese Workload unterstützt.
Auf der horizontalen Achse haben wir Technik und Betrieb. Technik bezieht sich auf die Entwicklung, Erstellung und das Testen von Anwendungen und Infrastruktur. Betrieb ist die Bereitstellung, Aktualisierung und laufende Unterstützung von Anwendungen und Infrastruktur.
![\[Diagramm des traditionellen Modells\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png)
In der Vergangenheit nutzten Organisationen Frameworks wie ITIL oder Standards wie ISO und richteten ihre betrieblichen Aktivitäten danach aus, was oft zu einer völlig getrennten Topologie führte. In diesem Modell werden die Aktivitäten in jedem Quadranten von einem separaten Team ausgeführt. Die Arbeit wird zwischen Teams über Mechanismen wie Arbeitsanforderungen, Warteschlangen, Tickets oder über ein IT-Service-Management (ITSM)-System weitergegeben.
Der Übergang von Aufgaben zu oder zwischen Teams erhöht die Komplexität und schafft Engpässe und Verzögerungen. Anfragen können verzögert werden, bis sie eine Priorität haben. Verspätet erkannte Fehler erfordern möglicherweise eine erhebliche Nachbearbeitung und müssen möglicherweise die gleichen Teams und ihre Funktionen erneut durchlaufen. Wenn es Vorfälle gibt, die Maßnahmen durch Technikerteams erfordern, verzögern sich ihre Antworten durch die Übergabe der Aktivität.
Es besteht ein höheres Risiko einer Fehlausrichtung, wenn Geschäfts-, Entwicklungs- und Betriebsteams um die ausgeführten Aktivitäten oder Funktionen herum organisiert sind. Dies kann dazu führen, dass Teams sich auf ihre spezifischen Verantwortlichkeiten konzentrieren, anstatt sich auf das Erreichen von Geschäftsergebnissen zu konzentrieren. Teams können eng spezifiziert, physisch isoliert oder logisch isoliert sein, was die Kommunikation und Zusammenarbeit behindert.
# DevOps mit Cloud-verwaltetem Serviceanbieter
Das DevOps-Modell mit Cloud-verwalteten Serviceanbietern folgt einer Methodik für Anwendungsteams, bei der Sie die Anwendung *erstellen und betreiben*. Möglicherweise sind in Ihrer Organisation jedoch nicht die Fähigkeiten oder Teammitglieder vorhanden, um ein dediziertes Team für die Entwicklung und den Betrieb der Plattform zu unterstützen, oder Sie sind nicht in der Lage, die dafür erforderlichen Investitionen in Zeit und Aufwand zu tätigen.
Oder Sie möchten ein Plattformteam haben, das sich auf die Entwicklung von Funktionen konzentriert, die Ihr Unternehmen von anderen abheben, aber Sie möchten den undifferenzierten Tagesbetrieb auslagern.
Anbieter von verwalteten Services wie [AWS Managed Services](https://aws.amazon.com/managed-services/) oder Anbieter im [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider) bieten Fachwissen zur Implementierung von Cloud-Umgebungen und unterstützen Ihre Sicherheits- und Compliance-Anforderungen sowie Ihre Geschäftsziele.
![\[DevOps mit Cloud-verwaltetem Serviceanbieter\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png)
Bei dieser Variante betrachten wir die Governance als zentralisiert und vom Plattformteam verwaltet, wobei die Kontoerstellung und die Richtlinien mit AWS Organizations und AWS Control Tower verwaltet werden.
Bei diesem Modell müssen Sie Ihre Mechanismen so anpassen, dass sie mit denen Ihres Serviceanbieters zusammenarbeiten. Es löst nicht Engpässe und Verzögerungen, die durch den Übergang von Aufgaben zwischen Teams, einschließlich Ihres Serviceanbieters, oder durch den potenziellen Nachbearbeitungsaufwand im Zusammenhang mit der verspäteten Fehlererkennung entstehen.
Sie profitieren von den Standards, bewährten Methoden, Prozessen und dem Fachwissen Ihrer Anbieter. Außerdem profitieren Sie von den Vorteilen der fortlaufenden Entwicklung ihrer Service-Angebote.
Durch die Aufnahme von verwalteten Services in Ihr Betriebsmodell können Sie Zeit und Ressourcen sparen, und Ihre internen Teams bleiben klein und konzentrieren sich auf strategische Ergebnisse, die Ihr Unternehmen von anderen abheben, anstatt neue Fähigkeiten und Fertigkeiten zu entwickeln. Außerdem können Sie so Zeit gewinnen, um Ihre eigenen Plattformkapazitäten aufzubauen und zu entwickeln, ohne Ihre Cloud-Migrationsprogramme zu verlangsamen.
# Cloud Operations and Platform Enablement (COPE)
Ziel dieses Modells für Cloud-Betrieb und Plattformunterstützung (Cloud Operations and Platform Enablement (COPE) ist es, eine *You build it, you run it*-Methodik zu etablieren, indem Anwendungsteams bei der Durchführung der technischen und operativen Aktivitäten für ihre Workloads unterstützt werden und eine DevOps-Kultur übernommen wird.
Ihre Anwendungsteams können mit der Migration, der Einführung der Cloud oder der Modernisierung Ihrer Workloads beauftragt werden, verfügen aber möglicherweise nicht über die vorhandenen Fähigkeiten, um die Cloud-Architektur und den Cloud-Betrieb angemessen zu unterstützen. Dieser Mangel an Fähigkeiten und Vertrautheit der Anwendungsteams wird wahrscheinlich die Agilität Ihrer Organisation verlangsamen und die Geschäftsergebnisse beeinträchtigen.
Um dieses Problem zu lösen, nutzen Sie das vorhandene operative Fachwissen innerhalb Ihrer Organisation, um die Anwendungsteams auf ihrem Weg zum Cloud-Betrieb zu unterstützen. Dies kann ein dediziertes Expertenteam oder ein virtuelles Team mit Teilnehmern aus der gesamten Organisation sein. Das Ziel bleibt jedoch dasselbe, nämlich die Bereitstellung von operativer Unterstützung, die die Fähigkeiten des Workload-Teams stärkt, indem die Cloud-First-Prinzipien der Automatisierung genutzt werden, undifferenzierte Schwerstarbeit beseitigt wird, standardisierte Muster bereitgestellt werden und die Autonomie gefördert wird. Ziel ist es, eine ausreichende Reife der Cloud-Fähigkeiten zu erreichen und die Hürde der operativen Verantwortlichkeiten zu senken, damit die Anwendungsteams keine zusätzliche Unterstützung mehr benötigen.
Das COPE-Modell konzentriert sich auf die Workload-Ebene. Wenn dieser Ansatz für mehrere Teams gleichzeitig erforderlich ist, wenn Sie ein komplexes, umfangreiches, mehrjähriges Migrationsprojekt durchführen oder wenn Sie eine Plattform zur Unterstützung dieser Initiativen aufbauen, sollten Sie die Verwendung eines Cloud-Kompetenzzentrums (CCoE) in Betracht ziehen. Dies ist ein Mechanismus, der sich für viele als erfolgreich erwiesen hat, wenn es darum geht, ihre Migrationen in die Cloud zu beschleunigen und ihre Organisation umfassend zu transformieren.
![\[Diagramm von Cloud Operations and Platform Enablement (COPE)\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png)
Ihr Plattform-Technikteam baut eine dünne Schicht von Kernfunktionen für gemeinsam genutzte Plattformen auf, die auf vordefinierten Standards basieren, die von Anwendungsteams übernommen werden müssen, und die vom COPE-Team bereitgestellt werden. Das Plattform-Technikteam kodifiziert die Referenzarchitekturen und Muster des Unternehmens, die den Anwendungsteams über einen Selfservice-Mechanismus zur Verfügung gestellt werden. Mithilfe eines Service wie AWS Service Catalog können die Anwendungsteams genehmigte Referenzarchitekturen, Muster, Services und Konfigurationen bereitstellen, die standardmäßig mit den zentralisierten Governance- und Sicherheitsstandards konform sind.
Das Plattform-Technikteam stellt den Anwendungsteams außerdem eine standardisierte Reihe von Services (z. B. Entwicklungstools, Tools für Beobachtbarkeit, Sicherungs- und Wiederherstellungstools und Netzwerkservices) zur Verfügung.
Das COPE-Team verwaltet und unterstützt die standardisierten Services und unterstützt die Anwendungsteams beim Aufbau ihrer Cloud-Präsenz auf der Grundlage der Referenzarchitekturen und -muster. Sie arbeiten mit den Anwendungsteams zusammen, um sie bei der Einrichtung grundlegender Abläufe zu unterstützen. Im Laufe dieses Prozesses übernehmen die Anwendungsteams nach und nach mehr Verantwortung für ihre Systeme und Ressourcen. Das COPE-Team treibt gemeinsam mit dem Plattform-Engineering-Team die kontinuierliche Verbesserung voran und fungiert als Fürsprecher für die Anwendungsteams.
Die Anwendungsteams erhalten Unterstützung bei der Einrichtung von Umgebungen, CI/CD-Pipelines, Änderungsmanagement, Beobachtbarkeit und Überwachung sowie bei der Einrichtung von Prozessen für das Management von Vorfällen und Ereignissen, wobei das COPE-Team nach Bedarf integriert wird. Das COPE-Team beteiligt sich zusammen mit den Anwendungsteams an der Durchführung dieser Betriebsaktivitäten und zieht sich mit der Zeit zurück, wenn die Anwendungsteams die Verantwortung übernehmen.
Das Anwendungsteam profitiert von den Fähigkeiten des COPE-Teams und den Erfahrungen der Organisation. Es wird durch die durch die zentralisierte Governance festgelegten Leitplanken geschützt. Das Anwendungsteam baut auf anerkannten Erfolgen auf und profitiert von der kontinuierlichen Weiterentwicklung der von ihm übernommenen Organisationsstandards. Durch die Einführung von Beobachtbarkeit und Überwachung erhalten sie einen besseren Einblick in den Betrieb ihrer Workloads und können die Auswirkungen von Änderungen, die sie auf ihre Workloads vornehmen, besser nachvollziehen.
Das COPE-Team kann auch den erforderlichen Zugriff behalten, um operative Aktivitäten zu unterstützen, eine unternehmensweite Sicht auf die Anwendungsteams zu bieten und Unterstützung beim Management kritischer Vorfälle zu leisten. Das COPE-Team behält die Verantwortung für Aktivitäten bei, die als undifferenzierte Schwerstarbeit gelten, die es durch Standardlösungen erfüllt, die in großem Maßstab unterstützt werden können. Es verwaltet auch weiterhin wohlüberlegte programmgesteuerte und automatisierte Betriebsaktivitäten für die Anwendungsteams, damit diese sich auf die Differenzierung ihrer Anwendungen konzentrieren können.
Sie profitieren von den Standards, bewährten Methoden, Prozessen und dem Fachwissen Ihrer Organisation, die sich aus den Erfolgen Ihrer Teams ergeben. Sie schaffen einen Mechanismus, um diese erfolgreichen Muster für neue Teams zu replizieren, die die Cloud einführen oder modernisieren. Dieses Modell legt den Schwerpunkt auf die Fähigkeit des COPE-Teams, Anwendungsteams bei der Etablierung und beim Transfer von Wissen und Artefakten zu unterstützen. Es reduziert die operative Belastung der Anwendungsteams, wobei das Risiko besteht, dass die Anwendungsteams nicht unabhängig werden können. Es stellt Beziehungen zwischen Teams für Plattformentwicklung und COPE sowie Anwendungsteams her und schafft eine Feedback-Schleife, um weitere Entwicklungen und Innovationen zu unterstützen.
Die Einrichtung Ihrer Teams für Plattformentwicklung und COPE bei gleichzeitiger Definition unternehmensweiter Standards kann die Einführung der Cloud erleichtern und Modernisierungsbemühungen unterstützen. Durch die zusätzliche Unterstützung durch ein COPE-Team, das als Berater und Partner für Ihre Anwendungsteams fungiert, können Sie Hindernisse auf Workload-Ebene beseitigen, die die Einführung nützlicher Cloud-Funktionen durch Anwendungsteams verzögern.
# Verteilte DevOps
Das Modell der verteilten DevOps trennt (oder verteilt) die Verantwortlichkeiten für die Anwendungsentwicklung und die Infrastrukturentwicklung auf die Entwicklungsteams, wobei die [COPE-Methodik](cloud-operations-and-platform-enablement.md) befolgt wird.
Ihre Anwendungstechniker führen sowohl die Entwicklung als auch den Betrieb ihrer Workloads durch. Ebenso führen Ihre Infrastrukturtechniker sowohl die Entwicklung als auch den Betrieb der Plattformen durch, die sie zur Unterstützung der Anwendungsteams einsetzen.
![\[Diagramm des Modells der verteilten DevOps\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png)
In diesem Beispiel behandeln wir Governance als zentralisiert an anderer Stelle innerhalb der Organisation. Standards werden an die Anwendungs- und Plattformteams verteilt, bereitgestellt oder weitergegeben.
Verwenden Sie Tools oder Services, mit denen Sie Ihre Umgebungen kontenübergreifend zentral steuern können, z. B. [AWS Organizations](https://aws.amazon.com/organizations/). Services wie [AWS Control Tower](https://aws.amazon.com/controltower/features/) erweitern diese Verwaltungsfunktion, sodass Sie Vorlagen (die Ihre Betriebsmodelle unterstützen) für die Einrichtung von Konten definieren, laufende Governance mit AWS Organizations anwenden und die Bereitstellung neuer Konten automatisieren können.
*You build it you run it* bedeutet nicht, dass das Anwendungsteam für den Full Stack, die Toolkette und die Plattform verantwortlich ist.
Das Plattform-Technikteam stellt dem Anwendungsteam eine standardisierte Reihe von Services (z. B. Entwicklungstools, Überwachungstools, Sicherungs- und Wiederherstellungstools und Netzwerkservices) zur Verfügung. Das Plattformteam kann dem Anwendungsteam auch Zugriff auf genehmigte Cloud-Anbieter-Services, bestimmte Konfigurationen derselben oder beides gewähren.
Mechanismen, die eine Selfservice-Funktion zum Bereitstellen genehmigter Services und Konfigurationen bieten, wie z. B. Service Catalog, können dazu beitragen, Verzögerungen im Zusammenhang mit Erfüllungsanforderungen zu begrenzen und gleichzeitig Governance durchzusetzen.
Das Plattformteam ermöglicht eine vollständige Stack-Transparenz, sodass Anwendungsteams, die ihre Anwendungen nutzen, zwischen Problemen mit ihren Anwendungskomponenten und den Services und Infrastrukturkomponenten unterscheiden können. Das Plattformteam kann auch Unterstützung bei der Konfiguration dieser Services leisten und Anleitungen zur Verbesserung des Betriebs eines Anwendungsteams bieten.
Wie bereits erwähnt, ist es wichtig, dass Mechanismen für Anwendungsteams vorhanden sind, um Ergänzungen, Änderungen und Ausnahmen zu Standards zur Unterstützung der Aktivitäten und der Innovation ihrer Anwendung anzufordern.
Das Modell der verteilten DevOps bietet starke Feedback-Schleifen für Anwendungsteams. Der tägliche Betrieb einer Workload erhöht den Kontakt mit Kunden entweder durch direkte Interaktion oder indirekt durch Support- und Featureanfragen. Durch diese erhöhte Sichtbarkeit können Anwendungsteams Probleme schneller beheben. Das tiefere Engagement und die engere Beziehung bieten Einblicke in die Kundenbedürfnisse und ermöglichen schnellere Innovationen.
All dies gilt auch für das Plattformteam, das die Anwendungsteams unterstützt, da das Plattformteam diese Anwendungsteams als seine Kunden betrachten sollte.
Übernommene Standards können vorab für die Verwendung genehmigt werden, wodurch der für die Produktion erforderliche Prüfungsumfang reduziert wird. Durch den Einsatz von durch das Plattformteam bereitgestellte unterstützte und getestete Standards kann die Häufigkeit von Problemen mit diesen Services reduziert werden. Durch die Übernahme von Standards können sich Anwendungsteams auf die Differenzierung ihrer Workloads konzentrieren.
# Dezentralisierte DevOps
Das Modell der dezentralisierten DevOps ist eine Variante der *You build it, you run it*-Methode, bei der die Betriebsabläufe in erster Linie in der Verantwortung von Workload-Teams liegen.
Ihre Anwendungstechniker führen sowohl die Entwicklung als auch den Betrieb ihrer Workloads durch. Ebenso führen Ihre Infrastrukturtechniker sowohl die Entwicklung als auch den Betrieb der Plattformen durch, die sie zur Unterstützung der Anwendungsteams einsetzen.
![\[Diagramm der der dezentralisierten DevOps\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png)
In diesem Beispiel behandeln wir Governance als dezentralisiert. Standards werden nach wie vor vom Plattformteam verteilt, bereitgestellt oder an Anwendungsteams weitergegeben, aber Anwendungsteams können neue Plattformfunktionen zur Unterstützung ihrer Workload entwickeln und betreiben.
Bei diesem Modell gibt es weniger Einschränkungen für das Anwendungsteam, aber das ist mit einer erheblichen Zunahme der Verantwortlichkeiten verbunden. Zusätzliche Fähigkeiten und potenziell auch zusätzliche Teammitglieder müssen vorhanden sein, um die zusätzlichen Plattformfunktionen zu unterstützen. Das Risiko signifikanter Nachbearbeitung wird erhöht, wenn die Qualifikationen nicht ausreichend sind und Fehler nicht frühzeitig erkannt werden.
Setzen Sie Richtlinien durch, die nicht spezifisch an Anwendungsteams delegiert sind. Verwenden Sie Tools oder Services, mit denen Sie Ihre Umgebungen kontenübergreifend zentral steuern können, z. B. [AWS Organizations](https://aws.amazon.com/organizations/). Services wie [AWS Control Tower](https://aws.amazon.com/controltower/features/) erweitern diese Verwaltungsfunktion, sodass Sie Vorlagen (die Ihre Betriebsmodelle unterstützen) für die Einrichtung von Konten definieren, laufende Governance mit AWS Organizations anwenden und die Bereitstellung neuer Konten automatisieren können.
Es ist vorteilhaft, dass das Anwendungsteam Mechanismen hat, um Ergänzungen und Änderungen an Standards anzufordern. Es kann neue Standards beitragen, die anderen Anwendungsteams Vorteile bieten können. Die Plattformteams können entscheiden, dass die direkte Unterstützung für diese zusätzlichen Funktionen eine effektive Unterstützung für Geschäftsergebnisse darstellt.
Dieses Modell begrenzt Einschränkungen bei einer Innovation mit erheblichen Anforderungen an Fähigkeiten und Teammitglieder. Es behebt viele der Engpässe und Verzögerungen, die durch den Übergang von Aufgaben zwischen Teams entstehen, und fördert gleichzeitig die Entwicklung effektiver Beziehungen zwischen Teams und Kunden.
# Weiterentwicklung Ihres Betriebsmodells
Die bereitgestellten Modelle bewegen sich schrittweise in Richtung mehr Autonomie auf der Workload-Ebene, was dem Zwei-Pizza-Team-Prinzip entspricht. Es ist wichtig zu verstehen, dass dieser Übergang von einem traditionellen Ansatz zu dezentralisierten DevOps (als Grundlage für die kontinuierliche Weiterentwicklung zu einem Zwei-Pizza-Team-Modell) wahrscheinlich Zeit in Anspruch nehmen und den Aufbau von Reife in einer Reihe von Fähigkeiten erfordern wird. Daher haben wir ein Beispiel dafür gegeben, wie Sie zwischen den Modellen wechseln können, während sich Ihr Team und Ihre Organisation auf dem Weg der Unternehmenstransformation befinden. Mit jeder Änderung oder jedem Modell entwickeln Sie sich zu einem autonomeren, aber dennoch organisatorisch ausgerichteten Team.
![\[Diagramm der Weiterentwicklung des Cloud-Betriebsmodells von On-Premises zu automatisierten Wertströmen und Prozessen\]](http://docs.aws.amazon.com/de_de/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)
Bei der Bewertung, wie Ihr Team die Entwicklung Ihrer Organisation unterstützen kann, sollten Sie die Kompromisse zwischen den Modellen untersuchen, wo Ihre einzelnen Teams innerhalb der Modelle vorhanden sind (während sie sich verändern und weiterentwickeln), wie sich die Beziehung und die Verantwortlichkeiten Ihres Teams ändern könnten und ob die Vorteile die Auswirkungen auf Ihre Organisation rechtfertigen. Denken Sie daran, dass Veränderungen nie linear verlaufen. Einige Modelle eignen sich besser für bestimmte Anwendungsfälle oder Punkte auf dem Weg, und einige dieser Modelle können Vorteile gegenüber den Modellen in Ihrer Umgebung bieten.