Wenn zwanzig Teams ausliefern müssen, ohne Chaos zu verursachen

Sie arbeiten bei einem SaaS-Unternehmen mit fünf, zehn oder vielleicht zwanzig Produktteams. Ein Team besitzt die Payment-API. Ein anderes kümmert sich um Benachrichtigungen. Ein drittes verwaltet das User-Dashboard. Jedes Team hat seinen eigenen Stack, seinen eigenen Release-Rhythmus und seine eigene Arbeitsweise.

Das Problem ist hier nicht „wie liefert ein Team schnell aus“. Das Problem ist „wie liefern zwanzig Teams schnell aus, ohne sich gegenseitig auf die Füße zu treten und ohne den Betrieb zum Chaos zu machen“. Wenn jedes Team seine eigene Deploy-Methode, seine eigenen Tools und seine eigene Pipeline-Struktur wählt, entsteht keine Innovation. Es entsteht Fragmentierung. Das Operations-Team muss zwanzig verschiedene Deploy-Workflows lernen. Das Security-Team kann keine Konsistenz prüfen. Wenn ein Incident passiert, kann niemand schnell herausfinden, wer was geändert hat und wie.

Zwei Konzepte helfen hier: ein Service Catalog und ein Golden Path.

Was ein Service Catalog tatsächlich leistet

Ein Service Catalog ist ein zentrales Verzeichnis aller Dienste, die in Ihrer Organisation laufen. Es ist nicht nur eine Liste von Namen. Es enthält nützliche Informationen: in welcher Umgebung der Dienst läuft, wer ihn besitzt, wie er deployed wird, wo der Code liegt und welche Abhängigkeiten er hat.

Das folgende Diagramm zeigt, wie der Service Catalog Teams, ihre Dienste und den Golden Path miteinander verbindet.

flowchart TD SC[Service Catalog] T1[Team A] T2[Team B] T3[Team C] S1[Payment API] S2[Notifications] S3[User Dashboard] GP[Golden Path] T1 -- owns --> S1 T2 -- owns --> S2 T3 -- owns --> S3 S1 -- registered in --> SC S2 -- registered in --> SC S3 -- registered in --> SC GP -- defines deploy method --> S1 GP -- defines deploy method --> S2 GP -- defines deploy method --> S3 SC -- tracks lifecycle --> S1 SC -- tracks lifecycle --> S2 SC -- tracks lifecycle --> S3

Wenn ein Team einen neuen Dienst erstellt, registriert es ihn im Catalog. Wenn ein Dienst nicht mehr verwendet wird, verfolgt der Catalog seinen Lebenszyklus. Der Catalog wird zur einzigen Quelle der Wahrheit, um die Frage zu beantworten: „Was läuft gerade wirklich in Produktion?“

Ohne diesen Catalog landen Sie bei Tabellenkalkulationen, die niemand aktualisiert, Wiki-Seiten, die sechs Monate alt sind, und Slack-Nachrichten wie „weiß jemand, wem der Billing-Service gehört?“. Der Catalog beseitigt diese Rätselraterei. Er ist ein praktisches Werkzeug, kein theoretisches Konzept.

Warum Golden Paths besser sind als „Wähle dein eigenes Abenteuer“

Ein Golden Path ist das Gegenteil von „such dir aus, was du willst“. Anstatt jedem Team zu überlassen, wie es baut, testet und deployed, stellt die Organisation einen gut getesteten, gut dokumentierten und vollständig unterstützten Pfad bereit. Teams können einen anderen Pfad wählen, wenn sie möchten, aber sie übernehmen dann selbst den Support, die Sicherheit und die Wartung dafür.

Der Golden Path ist kein Zwang. Es ist ein Angebot, das einfacher und sicherer ist als etwas von Grund auf neu zu bauen.

Hier ist ein konkretes Beispiel. Ihr Unternehmen stellt eine Pipeline-Vorlage bereit, die Build, Unit-Tests, Security-Scans, Integrationstests und das Deployment auf Staging umfasst. Diese Vorlage ist bereits in den Service Catalog integriert. Wenn ein Team die Vorlage verwendet, wird sein Dienst automatisch registriert. Das Team muss nur ein paar Parameter ausfüllen: Dienstname, Port, Abhängigkeiten und besitzendes Team. Alles andere wird erledigt.

Wenn ein Team seine eigene Pipeline verwenden möchte, kann es das tun. Es muss die Pipeline jedoch selbst verwalten, eigene Security-Scans einrichten und den Dienst manuell im Catalog registrieren. Die meisten Teams werden den Golden Path wählen, weil er schneller ist und lästige Arbeit erspart.

Die Balance zwischen Konsistenz und Autonomie

Das Interessante an diesem Ansatz ist die Balance, die er schafft. Teams werden nicht gezwungen, alles auf die gleiche Weise zu machen. Teams, die hohe Flexibilität benötigen, können ihren eigenen Weg gehen. Aber weil der Golden Path einfacher und schneller ist, werden ihn die meisten Teams wählen. Das Ergebnis ist Konsistenz, ohne die Kreativität der Teams zu opfern.

Diese Balance ist wichtiger, als Sie vielleicht denken. Wenn Sie jedes Team in denselben Prozess zwingen, frustrieren Sie die Teams, die etwas anderes brauchen. Wenn Sie jedes Team machen lassen, was es will, schaffen Sie operatives Chaos. Der Golden-Path-Ansatz gibt Teams eine starke Standardlösung, keinen Käfig.

Wie Operations und Security profitieren

Service Catalog und Golden Path sind nicht nur Entwickler-Tools. Sie helfen Operations- und Security-Teams, besser zu schlafen.

Anstatt zwanzig verschiedene Deploy-Methoden zu auditieren, muss das Operations-Team nur überprüfen, ob der Golden Path sicher ist. Dann überwachen sie, welche Dienste den Golden Path verwenden und welche nicht. Dienste außerhalb des Golden Path erhalten zusätzliche Prüfungen oder werden zur Migration gedrängt.

Wenn ein Incident passiert, kann das Operations-Team im Service Catalog nachsehen, welches Team den Dienst besitzt, welche Deploy-Methode verwendet wird und welche Abhängigkeiten bestehen. Sie müssen nicht Leute auf Slack jagen, um grundlegende Informationen herauszufinden.

Security-Teams haben den gleichen Vorteil. Sie können ihre Energie darauf konzentrieren, den Golden Path abzusichern, anstatt zu versuchen, jede maßgeschneiderte Pipeline zu auditieren, die ein Team vor zwei Jahren in Eile gebaut hat.

Was Entwickler tatsächlich erleben

Aus Entwicklersicht reduziert der Golden Path die Entscheidungsmüdigkeit. Wenn ein Entwickler einen neuen Dienst erstellen muss, muss er nicht darüber nachdenken, „wie richte ich CI/CD richtig ein“. Er folgt der Vorlage. Er füllt ein paar Parameter aus. Fertig.

Das beschleunigt die Zeit von der Idee bis zur Produktion. Der Entwickler kann sich auf die Geschäftslogik konzentrieren, anstatt auf Pipeline-Installationen. Für ein Unternehmen mit vielen Teams summiert sich das zu einer Menge eingesparter Zeit.

Eine praktische Checkliste für den Einstieg

Wenn Sie in Ihrer Organisation einen Service Catalog und einen Golden Path einführen möchten, finden Sie hier eine kurze Checkliste für die ersten Schritte:

  • Fangen Sie klein an. Wählen Sie ein Team und einen Diensttyp aus. Bauen Sie den Golden Path für diesen spezifischen Fall. Versuchen Sie nicht, von Anfang an jedes mögliche Szenario abzudecken.
  • Integrieren Sie den Catalog mit dem Golden Path. Wenn ein Team den Golden Path verwendet, sollte sein Dienst automatisch registriert werden. Manuelle Registrierung ist eine Hürde, die Leute überspringen werden.
  • Machen Sie den Golden Path zur offensichtlichen Wahl. Er sollte schneller, sicherer und besser dokumentiert sein als eine Eigenentwicklung. Wenn das nicht der Fall ist, werden Teams ihn ignorieren.
  • Erlauben Sie Ausnahmen, aber machen Sie sie sichtbar. Teams können einen anderen Pfad wählen, aber diese Wahl sollte im Catalog festgehalten werden. Operations und Security können dann entscheiden, wie viel Prüfung diese Ausnahmen benötigen.
  • Iterieren Sie basierend auf Feedback. Der Golden Path ist nicht in Stein gemeißelt. Aktualisieren Sie ihn, wenn Teams bessere Wege finden, Dinge zu tun. Halten Sie ihn lebendig.

Die konkrete Erkenntnis

Service Catalog und Golden Path drehen sich nicht um Kontrolle. Sie drehen sich darum, Reibung für Entwickler zu beseitigen, während Operations und Security bei Verstand bleiben. Wenn zwanzig Teams ausliefern können, ohne Chaos zu verursachen, bewegt sich die gesamte Organisation schneller. Beginnen Sie mit einem Golden Path, integrieren Sie ihn in einen einfachen Catalog, und lassen Sie die Ergebnisse für sich sprechen.