Blog

Welche DevOps-Topologie ist die richtige für mich?

Pavel Goultiaev

Aktualisiert Oktober 21, 2025

7 Minuten

Warum sollte ich das lesen?

Sie arbeiten in einem Unternehmen, das die Vorteile der Arbeit nach DevOps-Prinzipien erforschen möchte. Sie haben schon Begriffe wie "Plattformteam" und "SRE" gehört und Sie haben eine Vorstellung davon, was "you build, you run it" bedeutet. Diese Begriffe haben Ihre Erkundung von DevOps jedoch komplizierter gemacht und jetzt müssen Sie sich sogar entscheiden, wie Sie Ihr(e) Team(s) organisieren wollen. Dieser Blog bietet einen Überblick über die drei am häufigsten verwendeten DevOps-Topologien und darüber, unter welchen Bedingungen eine bestimmte Topologie für Ihr Unternehmen geeignet ist.

Als Referenz dient Matthew Skeltons "DevOps-Topologien" (https://web.devopstopologies.com/) gibt einen guten Überblick über alle Arten von Organisationstopologien. Diese Topologien wurden von Unternehmen auf der ganzen Welt in ihrem Streben nach Agilität und operativer Exzellenz durch DevOps implementiert. Obwohl viele Topologien dokumentiert wurden, glaube ich, dass sie alle Varianten dieser drei Topologien sind:

1. Alle Teams sind Produktteams. Jedes Team kümmert sich um alles, was zum Betrieb seiner Software erforderlich ist, einschließlich der Nutzung von Infrastrukturkomponenten, in der Regel Cloud-basierte PaaS.

2. Interne(s) Plattformteam(s) und Produktteam(s). Die Produktteams nutzen die Infrastruktur/Plattformdienste, die von den internen Plattformteams bereitgestellt werden. Die von dem/den Plattformteam(s) bereitgestellten Dienste können von Infrastruktur- und "Betriebs"-Diensten wie Überwachung bis hin zu Tools für die kontinuierliche Integration und Dashboarding-Tools reichen.

3. Interne(s) Plattformteam(s), Produktteam(s) und Site Reliability Engineering Team(s) (SRE). Diese Topologie basiert auf den Best Practices von Google für die Ausführung von Software. Die Produktteams können die Unterstützung der SRE-Teams bei der Ausführung ihrer Software in Anspruch nehmen, wenn sie diese benötigen und wenn ihre Software den von den SRE-Teams definierten Standards entspricht. SRE-Teams können auch die Verantwortung für die Rufbereitschaft mit den Produktteams teilen. Das/die Plattform-Team(s) stellen Infrastruktur-/Plattform-Dienste bereit.

Die DevOps-Topologie, die am besten in Ihr Unternehmen passt, hängt von Ihrer aktuellen Organisationshierarchie, dem Umfang, den gesetzlichen Anforderungen und den Fähigkeiten der Mitarbeiter ab. Es ist auch wichtig zu erkennen, dass jede gewählte Topologie ihre Tücken hat, die es zu bewältigen gilt.

Alle Teams sind Produktteams

Diese Topologie ist wahrscheinlich am häufigsten anzutreffen. Jedes Team hält sich an das Mantra "Sie bauen es, Sie betreiben es" und verwendet (und pflegt daher) die Infrastruktur und Tools seiner Wahl. Das bedeutet, dass die Teams viel Fachwissen benötigen, um ihre Dienste/Anwendungen betreiben zu können.

Beispiel für eine Topologie, in der alle Teams Produktteams sind.

Mögliche Gewinne:

Die Teams genießen volle Autonomie bei der Entwicklung und dem Betrieb ihrer Produkte
Die Teams müssen sich keine Infrastruktur oder Tools teilen.
Keine gemeinsame Verantwortung für laufende Software.
Verantwortung ist leicht zu regieren.
Produktteams können in ihrem eigenen Tempo auf Automatisierungsziele hinarbeiten

Mögliche Fallstricke:

Potenzielle Ineffizienzen; Teams können und werden für jedes Problem ihre eigenen Lösungen entwickeln. Die Wiederverwendung von Tools und Infrastrukturkomponenten zwischen Teams ist begrenzt.
Jedes autonome Team braucht seinen eigenen Infrastruktur-, Sicherheits- und Compliance-Experten
Jedes Team muss Zeit für die Pflege seiner Infrastruktur und seiner Tools aufwenden.
Jedes Team muss Lösungen entwickeln, um alle gesetzlichen Anforderungen zu erfüllen.

Diese Topologie eignet sich gut für Ihr Unternehmen, wenn:

Ihr Unternehmen nutzt Cloud-Services (die automatisiert werden können) für die Infrastruktur.
Ihr Unternehmen/Ihre Abteilung besteht aus 1-5 Teams oder kann jedes Team mit dem nötigen Fachwissen ausstatten
Regulatorische Anforderungen wie die Protokollierung von Audits müssen nicht standardisiert werden.
Es bringt keinen wirtschaftlichen Vorteil, ein separates Team für die Bereitstellung von Infrastruktur oder Tools für Produktteams zu schaffen.
Ihr Fokus liegt auf Geschwindigkeit und Sie machen sich nicht viel aus Standardisierung. Der Fokus auf Geschwindigkeit ist eine gute Idee, wenn Sie die Vorteile von DevOps erforschen und kennenlernen möchten, ohne die Teams in Ihrem Unternehmen umorganisieren zu müssen,
Sie haben keine alte IT-Ops-Abteilung/kein altes IT-Team, weil Sie das nächste Einhorn-Startup sind.

Interne(s) Plattformteam(s) und Produktteams

Sobald Ihr Unternehmen eine bestimmte Größe überschreitet, ist es sinnvoll, dass ein oder mehrere Plattformteams allgemeine Plattformdienste (wie Infrastruktur und/oder CI/CD-Tools) bereitstellen. Plattformteams bieten alle ihre Dienste in Form von Self-Service-APIs für die verschiedenen Produktteams an. Häufig nutzen die Plattformteams selbst Cloud-Infrastrukturdienste und kombinieren diese, um einen größeren Mehrwert zu bieten. So kann ein Plattformteam beispielsweise eine Container-Plattform als Service anbieten, bei der die Konnektivität und das Zugriffsmanagement bereits so eingerichtet sind, dass sie den Anforderungen des Unternehmens entsprechen.

Beispiel für eine Plattformteam/Produktteam-Topologie.

Mögliche Gewinne:

Effiziente Wiederverwendung von Plattformdiensten zwischen Produktteams.
Die Wiederverwendung von Infrastrukturkomponenten bietet als Nebeneffekt eine Standardisierung
Die Produktteams werden bei der Wartung von Infrastruktur und Tools entlastet.
Die Trennung von Plattform- und Produktteams bedeutet, dass sich die Produktteams auf die Bereitstellung von Mehrwert für die Kunden konzentrieren können. Die Plattformteams können sich also darauf konzentrieren, die Produktteams bei der Ausführung ihrer Software zu unterstützen.
Gesetzliche Anforderungen wie die Protokollierung von Audits können durch die Nutzung der von den Plattform-Teams angebotenen Dienste leicht erfüllt werden.

Mögliche Fallstricke:

Der Product Owner der Plattform-Teams muss sowohl eine Vision für die Zukunft der Plattform haben als auch die Anforderungen aller Produktteams verwalten.
Die Produktteams müssen dazu angehalten werden, dem Plattformteam regelmäßig Feedback zu geben, anstatt ihre eigenen Tools zu entwickeln, wenn die Plattform diese Tools nicht bereitstellen kann.
Plattformteams müssen in der Lage sein, Feedback von Produktteams einzuholen

Diese Topologie eignet sich gut für Ihr Unternehmen, wenn:

Es ist billiger, ein Plattformteam zu betreiben, das allgemeine Infrastrukturen/Dienste aufbaut, als jedes Team einzeln zu beauftragen. Diese Grenze hängt von Ihrem organisatorischen Kontext ab.
Regulatorische Anforderungen wie die Protokollierung von Audits müssen standardisiert werden.
Sie können nicht jedem Produktteam einen eigenen Infrastruktur-, Sicherheits- und Compliance-Experten zur Seite stellen.
Sie möchten Ihre Infrastruktur und Tools standardisieren
Sie haben Ihre Infrastruktur und/oder Tools ausgelagert
Sie haben eine bestehende IT-Abteilung und betreiben ein (stark) reguliertes Unternehmen wie eine Bank oder eine Behörde.

Interne(s) Plattformteam(s), Produktteam(s) und Site Reliability Engineering Team(s) (SRE),

Laut Ben Traynor, der das erste SRE-Team bei Google gegründet hat, ist das SRE-Team "das, was passiert, wenn ein Software-Ingenieur mit dem betraut wird, was früher als Betrieb bezeichnet wurde". Man könnte argumentieren, dass ein SRE-Team wie ein klassisches IT-Operations-Team ist und nicht mit DevOps-Prinzipien wie der End-to-End-Verantwortung übereinstimmt. Der Unterschied des SRE-Modells liegt in dem Modell der geteilten Verantwortung zwischen Produktteams und SRE-Teams. Weiteres Referenzmaterial zum SRE-Modell finden Sie in Googles Buch zu diesem Thema, das online kostenlos unter https://landing.google.com/sre/book.html verfügbar ist.

Die Plattformteams stellen den verschiedenen Produktteams alle ihre Dienste in Form von Self-Service-APIs zur Verfügung.

Beispiel für eine SRE/Plattformteam/Produktteam-Topologie.

Mögliche Gewinne:

Produktteams benötigen viel weniger Ops-Fachwissen als die zuvor genannten Topologien. Dieses Fachwissen kann in den SRE-Teams gebündelt werden.
Das SRE-Team coacht Produktteams aktiv bei der Verbesserung der Qualität ihrer Software und beim Betrieb der Software
SRE-Teams suchen aktiv nach Möglichkeiten, die Bereitstellung und den Betrieb von Software zu automatisieren und zu verbessern.
Produktteams, die für geschäftskritische Anwendungen verantwortlich sind, fühlen sich aufgrund der Unterstützung durch die SRE-Teams sicherer beim Betrieb ihrer Software

Mögliche Fallstricke:

Der Unterschied zwischen SRE und klassischen IT-OPs-Teams ist nuanciert. Wenn Sie diese Nuance missverstehen, führt dies zu mehr organisatorischer Komplexität.
SRE-Teammitglieder benötigen Software-Engineering- und Coaching-Fähigkeiten

Diese Topologie eignet sich gut für Ihr Unternehmen, wenn:

Es gibt nur eine begrenzte Anzahl von IT-ops Spezialisten
Die vorhandenen IT-ops-Spezialisten verfügen über umfassende Coaching-Fähigkeiten
Die Anforderungen an die Ops-Expertise sind je nach Produktteam unterschiedlich. So benötigen beispielsweise nur Produktteams, die geschäftskritische Software entwickeln, die Unterstützung eines SRE-Teams, während andere Teams ihre Software selbst betreiben.
Ihr Unternehmen hat mehr als fünf Produktteams
Sie haben eine bestehende IT-Ops-Organisation, die Infrastruktur-Ops-Teams von Anwendungs-Ops-Teams trennt.
Sie sind in einer (stark) regulierten Branche wie dem Bankwesen oder der Regierung tätig
Sie haben Ihre Infrastruktur und/oder Tools ausgelagert
Sie möchten sicherstellen, dass Produktteams, die geschäftskritische Software liefern, einen definierten Schwellenwert für die Softwarequalität einhalten.

Ich habe Ihren Blog gelesen. Was nun?

Ob eine DevOps-Topologie für Sie geeignet ist, hängt stark von Ihrem aktuellen organisatorischen Kontext ab. Die in diesem Blog erwähnten Topologien schließen sich nicht gegenseitig aus. Ziehen Sie also in Erwägung, sie zu kombinieren, wenn Sie sich entscheiden, eine Reise in Richtung DevOps anzutreten. Denken Sie daran, dass es zu Beginn Ihrer Reise wichtig ist, Ihre Lernerfahrung zu maximieren. Nur wenn Sie aus Ihren Erfahrungen lernen, werden Sie wissen, welche Topologie an einem bestimmten Punkt Ihrer Reise am besten passt.

Eines ist sicher: Ein anderes Unternehmen und seine DevOps-Erfolgsgeschichten zu kopieren wird nicht funktionieren, aber lassen Sie sich inspirieren.

Weitere Lektüre zu diesem Thema: