DevOps-Teamtopologien

Die Verteilung von Rollen, Zuständigkeiten und Vertrauensbeziehungen zwischen IT-Teams und Anwendungsteams ist von entscheidender Bedeutung für die operativen Veränderungen bei der umfassenden Einführung der Cloud.

IT-Teams bemühen sich, die Kontrolle zu behalten. Anwendungsbesitzer*innen versuchen, maximale Flexibilität zu erhalten. Die Balance, die Sie letztendlich zwischen diesen beiden Zielen herstellen müssen, beeinflusst den Erfolg Ihres Cloudbetriebsmodells erheblich.

Nach dem Gesetz von Conway produzieren Teams Architekturen basierend auf ihrer Kommunikationsstruktur. Sie sollten dieses Prinzip verinnerlicht haben, wenn Sie daran arbeiten, die notwendige Balance zwischen Autonomie und Kontrolle zu erreichen. Jede Organisation, die ein System (im weitesten Sinne) entwirft, erstellt ein Design, dessen Struktur ein Abbild der Kommunikationsstruktur der Organisation ist.

Aus DevOps-Sicht müssen Organisationen für eine schnelle Reaktion auf Kundenanforderungen optimiert werden. Teams, die ihre Anwendungen und Systeme besitzen, entwerfen und implementieren, finden das höchst Maß an Autonomie in Architekturen mit den folgenden Merkmalen:

• Über lange Zeit entwickelte Architektur, die fortlaufende Änderungen unterstützt
• Bereitstellbarkeit
• Prüfbarkeit

Die Lösung von Conway besteht darin, das Gesetz von Conway zu umgehen. Wenn Ihre Organisation einer bestimmten Struktur folgt, um Dienste und Produkte zu erstellen und zu optimieren, müssen Sie Ihre Organisationsstruktur überdenken. Entwickeln Sie Ihre Team- und Organisationsstruktur weiter, um die gewünschte Architektur zu erreichen.

Dieses Prinzip führt zu geplanten Teamtopologien, in denen die Teams vollumfänglich für die Anwendungen, Systeme oder Plattformen in ihrem Besitz verantwortlich sind, um im Gegenzug volle Kontrolle über DevOps zu erhalten.

Die folgende Tabelle enthält eine vereinfachte Kategorisierung dieser Teams.

Überlegungen zum Entwurf

• Richten Sie ein funktionsübergreifendes Plattformteam ein, um den Lebenszyklus Ihrer Azure-Zielzone zu entwerfen, zu erstellen, bereitzustellen, zu verwalten und aufrechtzuerhalten. Dieses Team kann Mitglieder aus Ihrem zentralen IT-Team, aus Sicherheits- und Complianceteams sowie aus Geschäftseinheiten umfassen, um sicherzustellen, dass ein möglichst breites Spektrum Ihres Unternehmens abgebildet wird. Stellen Sie sicher, dass Sie Antimuster vermeiden.

• Erwägen Sie die Einrichtung eines Supportteams, das DevOps-Funktionen zur Unterstützung von Anwendungen und Plattformen bereitstellt, für die weder DevOps-Funktionen vorhanden sind noch ein Geschäftsszenario vorliegt (z. B. Legacyanwendungen mit minimalen Entwicklungsfunktionen).

• Beschränken Sie Ihre Teams für Anwendungsworkloads nicht auf zentrale Artefakte, da dies ihre Agilität behindern können. Sie können richtliniengesteuerte Governance und die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) verwenden, um konsistente Baselinekonfigurationen zu erzwingen und sicherzustellen, dass Anwendungsteams (Geschäftseinheit) flexibel genug bleiben, um innovativ zu sein, und dennoch einen vordefinierten Satz von Vorlagen verwenden können.

• Zwingen Sie Ihre Anwendungsteams nicht, einen zentralen Prozess oder eine zentrale Bereitstellungspipeline für die Instanziierung oder Verwaltung von Anwendungsressourcen zu verwenden. Bestehende Teams, die bereits eine DevOps-Pipeline für die Anwendungsbereitstellung nutzen, können weiterhin ihre vorhandenen Tools verwenden. Denken Sie daran, dass Sie Azure Policy verwenden können, um organisatorische Standards durchzusetzen, die Compliance im großen Maßstab zu bewerten und Sicherheitsaspekte für Ihre DevOps-Prozesse zu berücksichtigen.

• Die reine Anwendung eines DevOps-Modells führt nicht sofort zu leistungsfähigen DevOps-Teams.

• Investitionen in technische Funktionen und Ressourcen sind von entscheidender Bedeutung.

• Für einige Legacyanwendungen verfügen die Anwendungsteams möglicherweise nicht über die Entwicklungsressourcen, die für die Anpassung an eine DevOps-Strategie erforderlich sind.

Entwurfsempfehlungen

Die folgenden Abschnitte enthalten Entwurfsempfehlungen, die Sie beim Entwerfen Ihrer Teamtopologien unterstützen.

Anpassen von Teamtopologien an Ihr Cloudbetriebsmodell

Stellen Sie sicher, dass Sie Ihre Teamtopologien an Ihrem gewünschten Cloudbetriebsmodell ausrichten.

Richten Sie einen Kernprozess für die Überprüfung der Eignung für den Betrieb ein, damit Sie die Probleme, die sich aus Ihren Teamstrukturen ergeben können, vollständig verstehen.

Definieren von Funktionen für Ihr Plattformteam

Die folgende Liste enthält empfohlene Funktionen für das Plattformteam, das für Ihre Azure-Zielzonen verantwortlich ist:

• Kontrolle über die Architektur
• Abonnementbereitstellung und -delegierung der erforderlichen Richtlinien für Netzwerk-, Identitäts- und Zugriffsverwaltung
• Plattformverwaltung und -überwachung (ganzheitlich)
• Kostenverwaltung (ganzheitlich)
• Platform-as-Code (Verwaltung von Vorlagen, Skripts und anderen Ressourcen)
• Allgemeine Vorgänge in Microsoft Azure in Ihrem Microsoft Entra-Mandanten (Verwaltung von Dienstprinzipalen, Microsoft Graph-API-Registrierung und Rollendefinitionen)
• Azure RBAC (ganzheitlich)
• Schlüsselverwaltung für zentrale Dienste (SMTP und Domänencontroller)
• Richtlinienverwaltung und -erzwingung (ganzheitlich)
• Sicherheitsüberwachung (ganzheitlich)
• Netzwerkverwaltung (ganzheitlich)

Definieren von Funktionen für Ihre Anwendungsworkloadteams

Die folgende Liste enthält empfohlene Funktionen für Ihre Anwendungsteams, die für Anwendungsworkloads verantwortlich sind:

• Erstellen und Verwalten von Anwendungsressourcen über ein DevOps-Modell
• Datenbankverwaltung
• Anwendungsmigration oder -transformation
• Anwendungsverwaltung und -überwachung (Anwendungsressourcen)
• Azure RBAC (Anwendungsressourcen)
• Sicherheitsüberwachung (Anwendungsressourcen)
• Geheimnis- und Schlüsselverwaltung (Anwendungsschlüssel)
• Kostenverwaltung (Anwendungsressourcen)
• Netzwerkverwaltung (Anwendungsressourcen)

Definieren von Funktionen für Supportteams

Die folgende Liste enthält empfohlene Funktionen für das Supportteam, das für die Unterstützung Ihrer anderen Teams zuständig ist:

• Definition der horizontalen (funktionsübergreifenden) Leitfäden und Funktionen, um die richtige Expertise für Ihre Organisation zu erwerben und so die Eignung für Ihr gesamtes Zielbetriebsmodell in der Cloud (z. B. DevOps) sicherzustellen
• Unterstützung, Schulung und Coaching für andere Teams, um das notwendige Fachwissen zu erlangen
• Einrichten gemeinsamer, wiederverwendbarer Vorlagen und Bibliotheken für Ihre Anwendungs- oder Plattformteams und Förderung von InnerSourcing, z. B. den Azure Verified Modules.

Definieren der Interaktionsmodi zwischen Teams

Folgende Ziele hat die Interaktion zwischen Ihren Teams:

• Erreichen von Autonomie
• Freigeben von Abhängigkeiten
• Minimieren von Zeitverschwendung
• Vermeiden von Engpässen

In Teamtopologien werden drei Modi für die Interaktion zwischen Teams beschrieben: