Service Catalog: Das Inventar der Organisation
Un Servicekatalog und das zentrale und maßgebliche Register aller Dienste, Softwarekomponenten und Ressourcen einer Organisation. Es stellt die „Karte“ der Technologielandschaft dar Unternehmen: Wem gehört was, wie sind Dienste miteinander verbunden, welche SLAs werden garantiert und Wie ist der Gesundheitszustand jeder Komponente?
Ohne einen Servicekatalog leiden wachsende Unternehmen Schatten-IT: Dienste, von denen niemand etwas weiß, undokumentierte Abhängigkeiten, unklare Eigentumsverhältnisse, z.B Vorfälle, deren Lösung Stunden in Anspruch nimmt, weil niemand weiß, an wen er sich wenden kann. Der Leistungskatalog löst diese Probleme, indem es eine einzige Informationsquelle für das gesamte Software-Ökosystem bereitstellt.
Was Sie Lernen Werden
- So modellieren Sie einen Servicekatalog: Entitäten, Beziehungen, Metadaten
- Service ownership: team, on-call, escalation paths
- SLA tracking: RTO, RPO, availability targets e compliance
- CMDB (Configuration Management Database): configuration items e change tracking
- Abhängigkeitszuordnung: Abhängigkeitsdiagramme und Auswirkungsanalyse
- Auto-discovery: popolamento automatico del catalogo
Den Service Catalog Modellieren
Ein wirksamer Leistungskatalog basiert auf a Datenmodell gut gestaltet, das einfängt wesentliche Informationen zu jeder Komponente des Ökosystems. Die wichtigsten Einheiten sind:
- Service: Ein Mikroservice, eine Anwendung oder ein System, das eine Geschäftsfunktion ausführt
- APIs: eine Schnittstelle, die von einem Dienst bereitgestellt oder genutzt wird (REST-, gRPC-, GraphQL-, Kafka-Ereignisse)
- Ressourcen: eine Infrastrukturressource (Datenbank, Cache, Nachrichtenwarteschlange, Speicher)
- Bibliothek: Eine gemeinsam genutzte Bibliothek, die von mehreren Diensten verwendet wird
- Team: Die Gruppe, die für die Wartung und den Betrieb eines oder mehrerer Dienste verantwortlich ist
# Service Catalog: modello dati per un servizio
service:
metadata:
name: checkout-service
display_name: "Checkout Service"
description: "Gestisce il flusso di checkout e pagamenti"
created_at: "2024-03-15"
last_updated: "2026-01-20"
classification:
type: microservice
tier: tier-1 # Critico per il business
lifecycle: production # development | staging | production | deprecated
domain: e-commerce
subdomain: payments
ownership:
team: team-checkout
team_lead: "mario.rossi"
product_owner: "anna.bianchi"
on_call:
primary: "checkout-oncall-primary"
secondary: "checkout-oncall-secondary"
escalation: "engineering-manager"
slack_channel: "#team-checkout"
email: "team-checkout@company.io"
technical:
language: TypeScript
framework: NestJS
runtime: Node.js 20
repository: "github.com/company/checkout-service"
ci_cd: GitHub Actions
deployment: ArgoCD
container_image: "ghcr.io/company/checkout-service"
infrastructure:
kubernetes:
cluster: production-eu
namespace: checkout
replicas: 3
database:
type: PostgreSQL
instance: "checkout-db-prod"
version: "15.4"
cache:
type: Redis
instance: "checkout-redis-prod"
sla:
availability: "99.95%"
rto: "15 minutes" # Recovery Time Objective
rpo: "5 minutes" # Recovery Point Objective
response_time_p99: "200ms"
throughput: "1000 rps"
dependencies:
provides:
- api: checkout-api
type: REST
docs: "https://docs.company.io/checkout-api"
consumes:
- service: payment-gateway
api: payment-api
criticality: hard
- service: inventory-service
api: inventory-api
criticality: soft
- service: notification-service
api: notification-api
criticality: soft
Service Ownership und Verantwortlichkeit
La Diensteigentum und eines der wichtigsten Konzepte des Leistungskatalogs. Jeder Dienst muss über ein Team verfügen, das eindeutig als Eigentümer identifiziert und mit Verantwortlichkeiten ausgestattet ist definiert für Entwicklung, Wartung, Bereitschaftsdienst und Reaktion auf Vorfälle.
Die Grundsätze effektiven Eigentums sind:
- Klare Eigentumsverhältnisse: Jeder Dienst hat genau einen Teambesitzer. Kein Service und „Waise“
- Vollständiger Lebenszyklus: Der Teambesitzer ist vom Entwurf bis zur Stilllegung des Dienstes verantwortlich
- Bereitschaftsrotation: Jedes Team hat eine definierte Bereitschaftsrotation mit klaren Eskalationspfaden
- Wissensaustausch: Die Dokumentation ist aktualisiert und zugänglich, wodurch der Busfaktor reduziert wird
Das Problem Verwaister Services
30-40 % der Dienste in mittelständischen Organisationen haben eindeutig keinen Eigentümer identifiziert. Diese Waisendienste Sie sind eine der Hauptursachen für Unfälle verlängert: Wenn etwas schief geht, weiß niemand, an wen er sich wenden oder wie er eingreifen kann. Der Servicekatalog beseitigt dieses Problem, indem er die Eigentümerschaft explizit und sichtbar macht.
CMDB: Configuration Management Database
Il CMDB (Konfigurationsverwaltungsdatenbank) und eine Servicekatalogkomponente welche Spuren ich Konfigurationselemente (CI): jede Ressource, Konfiguration und Beziehung das ist die IT-Infrastruktur. Während sich der Servicekatalog auf Informationen über konzentriert Geschäft (Eigentum, SLA, Abhängigkeiten) bietet die CMDB eine detaillierte Ansicht der Konfiguration Technik.
- Configuration Items: server, container, database, load balancer, certificati, DNS records
- Beziehungen: „runs-on“, „dependents-on“, „connected-to“ zwischen Konfigurationselementen
- Änderungsverfolgung: Verlauf aller Änderungen an jedem CI, mit wem, wann und warum
- Einhaltung: Überprüfen Sie, ob CIs den Organisationsrichtlinien (Versionen, Patches, Konfigurationen) entsprechen.
# CMDB: Configuration Items e relazioni
configuration_items:
- id: ci-checkout-pod-01
type: kubernetes_pod
name: "checkout-service-7d8f9b6c4d-xk2mn"
status: running
properties:
image: "ghcr.io/company/checkout:v2.3.1"
cpu_request: "500m"
memory_request: "512Mi"
node: "worker-node-03"
relationships:
- type: runs-in
target: ci-checkout-namespace
- type: connects-to
target: ci-checkout-db
- type: connects-to
target: ci-checkout-redis
- id: ci-checkout-db
type: rds_instance
name: "checkout-db-prod"
status: available
properties:
engine: "postgres 15.4"
instance_class: "db.r6g.large"
storage: "50GB"
encrypted: true
multi_az: true
backup_retention: 30
relationships:
- type: used-by
target: ci-checkout-pod-01
- type: backed-up-to
target: ci-checkout-db-snapshots
- id: ci-checkout-redis
type: elasticache_cluster
name: "checkout-redis-prod"
status: available
properties:
engine: "redis 7.0"
node_type: "cache.r6g.large"
encryption_at_rest: true
encryption_in_transit: true
change_history:
- ci_id: ci-checkout-db
timestamp: "2026-01-15T14:30:00Z"
change_type: "configuration_update"
description: "Upgraded from db.r6g.medium to db.r6g.large"
performed_by: "platform-team"
ticket: "INFRA-4521"
approved_by: "tech-lead"
Dependency Mapping und Impact Analysis
Eine der wertvollsten Funktionen des Servicekatalogs ist die Möglichkeit, Daten abzubilden Süchte zwischen Diensten und Ausführung Wirkungsanalyse. Wenn ein Wenn ein Dienst ein Problem hat, können Sie anhand der Abhängigkeitskarte sofort erkennen, um welche es sich handelt andere Dienste sind betroffen und die zuständigen Teams zu benachrichtigen.
- Harte Abhängigkeiten: Der Dienst kann ohne diese Abhängigkeit nicht funktionieren (z. B. Datenbank)
- Weiche Abhängigkeiten: Der Dienst funktioniert ohne diese Abhängigkeit eingeschränkt (z. B. Benachrichtigungsdienst).
- Upstream-Abhängigkeiten: Dienstleistungen, auf die ich angewiesen bin
- Downstream-Abhängigkeiten: Dienstleistungen, die von mir abhängen
Die Wirkungsanalyse ist besonders nützlich während Fenster wechseln: vorher Durch die Durchführung von Wartungsarbeiten an einer Komponente kann das Team die Auswirkungen auf das gesamte Ökosystem überprüfen und planen Sie notwendige Benachrichtigungen und Rollbacks.
Auto-Discovery und Synchronisierung
Ein Servicekatalog, der eine manuelle Aktualisierung erfordert, wird schnell obsolet. Aus diesem Grund, Moderne Binnenvertriebene implementieren Mechanismen von automatische Erkennung die bevölkern und aktualisieren Der Katalog automatisch:
- Kubernetes-Entdeckung: Namespaces und Bereitstellungen scannen, um aktive Dienste zu identifizieren
- GitHub/GitLab-Erkennung: Durchsuchen Sie Repositorys, um „catalog-info.yaml“-Dateien zu finden
- Erkennung von Cloud-Anbietern: Abfragen von Cloud-APIs zur Inventarisierung von Ressourcen (RDS, S3, Lambda)
- Netzwerkerkennung: Analyse des Netzwerkverkehrs zur Identifizierung undokumentierter Abhängigkeiten
# Auto-discovery: configurazione per Backstage entity provider
catalog:
providers:
# Discovery da GitHub: cerca catalog-info.yaml in tutti i repo
github:
company:
organization: "company"
catalogPath: "/catalog-info.yaml"
filters:
branch: "main"
repository: ".*" # Tutti i repository
schedule:
frequency: { minutes: 30 }
timeout: { minutes: 3 }
# Discovery da Kubernetes: importa workloads come entita
kubernetes:
production:
cluster: production-eu
processor:
namespaceOverride: false
defaultOwner: platform-team
schedule:
frequency: { minutes: 15 }
# Discovery da AWS: importa risorse cloud
awsS3:
production:
region: eu-west-1
schedule:
frequency: { hours: 1 }
rules:
- allow:
- Component
- API
- Resource
- System
- Domain
- Group
- User
Best Practice für den Service Catalog
Der Leistungskatalog muss vorhanden sein einzige Quelle der Wahrheit für alle Informationen über die Leistungen der Organisation. Jedes Tool (Überwachung, Incident Management, CI/CD) muss lesen Informationen aus dem Katalog zu entnehmen, anstatt separate Kopien zu führen. Dadurch werden Doppelarbeit vermieden und stellt die Datenkonsistenz sicher.
Governance und Audit
Der Leistungskatalog ist eine grundlegende Komponente für IT-Governance der Organisation. Damit können Sie Folgendes implementieren:
- Compliance-Prüfungen: Überprüfen Sie, ob alle Dienste den Unternehmensrichtlinien entsprechen (definierte SLAs, zugewiesener Eigentümer, vorliegende Dokumentation).
- Sicherheitsüberprüfungen: Identifizieren Sie Dienste mit anfälligen Abhängigkeiten, unsicheren Konfigurationen oder ablaufenden Zertifikaten
- Kostenverteilung: Verknüpfen Sie Infrastrukturkosten mit Teams und Diensten für vollständige Transparenz
- Audit-Trails: Behalten Sie einen vollständigen Verlauf aller Änderungen an Diensten und Konfigurationen bei
Ein gut verwalteter Servicekatalog verwandelt Governance von einem bürokratischen, reaktiven Prozess zu einem automatisierten und proaktiven System, das eine kontinuierliche Compliance ohne Verlangsamung gewährleistet Entwicklung.