Ein Service-Katalog, der aktuell bleibt, weil er aus Telemetrie entsteht

Was ist ein Service-Katalog?

Ein Service-Katalog ist ein zentrales Verzeichnis der Services, aus denen ein Softwaresystem besteht – zusammen mit den Informationen, die für ihren Betrieb nötig sind: Wem gehört ein Service, wovon hängt er ab, welche Services hängen von ihm ab, wie zuverlässig soll er sein, wo liegen Code und Runbooks, und wie geht es ihm gerade? Im Platform Engineering bildet er häufig das Rückgrat eines internen Entwicklerportals.

Die größte Herausforderung der meisten Kataloge ist Aktualität. Wird der Katalog von Hand in einem Wiki oder einer Tabelle gepflegt, veraltet er ab dem Tag der Veröffentlichung. Neue Services entstehen ohne Eintrag, Zuständigkeiten ändern sich nach einer Umstrukturierung und Abhängigkeitsdiagramme stimmen nicht mehr mit der Realität überein. Im Incident ist ein veralteter Katalog schlimmer als gar keiner, weil er in die falsche Richtung führt.

Warum ein Service-Katalog wichtig ist

Wächst ein System auf Dutzende oder Hunderte Services, wird die Frage „Wem gehört das?“ zu einer der teuersten im Engineering. Sie bremst die Incident Response, verzögert Security-Fixes und erschwert die Verteilung von Zuverlässigkeitsarbeit. Ein aktueller Katalog beantwortet sie in Sekunden.

Er macht Zuverlässigkeit außerdem steuerbar. Hat jeder Service ein definiertes Tier und ein SLO, können Teams sich darauf einigen, was „gut genug“ bedeutet, Arbeit nach Error Budgets priorisieren und erkennen, welchen kritischen Services grundlegende Absicherungen wie Runbooks oder Alerting fehlen. Für Engineering-Verantwortliche wird der Katalog zur Landkarte für Plattforminvestitionen und Migrationen.

Nicht zuletzt verkürzt ein guter Katalog das Onboarding. Neue Teammitglieder sehen auf einen Blick, welche Services ihr Team betreibt, wie diese zusammenhängen und wo Runbooks und Dokumentation liegen.

Was in einen Service-Katalog gehört

Ein nützlicher Katalogeintrag verbindet statische Metadaten mit Live-Betriebsdaten:

• Ownership: verantwortliches Team, On-Call-Plan, Chat-Channel und Eskalationskontakt.
• Einordnung: Tier bzw. Kritikalität, Lebenszyklusphase, Sprache und Runtime.
• Abhängigkeiten: aufrufende Services, nachgelagerte Services, Datenbanken, Queues und Drittanbieter-APIs.
• Zuverlässigkeit: SLOs, verbleibendes Error Budget, letzte Incidents und Golden Signals.
• Änderungen: aktuelle Version, letzte Deployments und Verweise auf das Repository.
• Dokumentation: Runbooks, Architekturnotizen und API-Spezifikationen.

So entsteht der Service-Katalog in Obseria

Obseria beginnt mit dem, was sich beobachten lässt. Services werden aus OpenTelemetry-Resource-Attributen wie service.name und service.namespace, aus dem Obseria Agent und aus Kubernetes-Metadaten erkannt. Obseria TopoGraph leitet Abhängigkeiten aus Traces und Netzwerkdaten ab. Der Katalog zeigt also, welche Services sich tatsächlich aufrufen, wie viel Traffic fließt und wo Fehler auftreten. Auch nicht registrierte Services tauchen auf – Lücken werden so sichtbar.

Teams ergänzen, was Telemetrie nicht liefern kann. Eine kleine YAML-Datei im Repository oder ein API-Aufruf aus Ihrer Provisioning-Pipeline setzt Owner, Tier, Runbooks und Links:

service: checkout
owner: team-payments
tier: 1
oncall: payments-primary
runbook: docs/runbooks/checkout.md
slo:
  availability: 99.9
  latency_p95_ms: 400

Diese Metadaten steuern den Rest der Plattform. Das Incident Management leitet Alarme an die Rufbereitschaft des verantwortlichen Teams. Statusseiten bilden Komponenten aus Katalog-Services. Für SLOs am Service entstehen automatisch Error Budgets und Burn-Rate-Alerts. Scorecards zeigen, welche Services Ihre Standards erfüllen, etwa ob ein Tier-1-Service ein SLO, ein Runbook und vollständige Trace-Abdeckung hat.

Da Ownership und Abhängigkeiten bekannt sind, beantwortet der Katalog auch Fragen zur Auswirkung einer Änderung, bevor sie passiert: Welche Teams müssen informiert werden, wenn eine gemeinsam genutzte Datenbank migriert wird? Welche Tier-1-Services wären betroffen, wenn eine bestimmte Queue langsamer wird? Security- und Compliance-Teams nutzen dasselbe Verzeichnis, um zu sehen, welche Services personenbezogene Daten verarbeiten und wer dafür verantwortlich ist – hilfreich etwa für Nachweise im Rahmen von DSGVO, NIS2 oder DORA.

Best Practices für den Service-Katalog

1. Erkennung automatisieren. Verlassen Sie sich nie darauf, dass Menschen Services registrieren; lassen Sie Telemetrie sie finden und fragen Sie Metadaten ab.
2. Metadaten neben dem Code halten. YAML im Repository wird wie alles andere reviewt und versioniert.
3. Ownership verpflichtend machen. Ein Service ohne Owner sollte sichtbar markiert sein.
4. SLOs bei kritischen Services beginnen. Definieren Sie zuerst SLOs für Tier 1 und erweitern Sie dann.
5. Scorecards zur Orientierung nutzen. Verfolgen Sie Fortschritte bei Standards, statt Teams an den Pranger zu stellen.