--- title: "Interner Cloud Service Katalog" description: "Wie eine IT-Abteilung Cloud-Services als interne Produkte anbietet: Aufbau des Servicekatalogs, interne Preisgestaltung, SLA-Definition und der Wandel von der Kostenstelle zur Service-Provider-Mentalität." sidebar: order: 7 label: "Servicekatalog" source_url: "https://framework.stackit.cloud/de/adoption/adapting-operating-models/service-catalogue/" source_file: "docs/de/adoption/adapting-operating-models/service-catalogue.mdx" --- ## Von der IT-Abteilung zum internen Cloud-Anbieter Die Cloud-Transformation verändert die Rolle der IT-Abteilung grundlegend. Anstatt Systeme zu verwalten, werden Plattformdienste bereitgestellt. Anstatt auf Tickets zu reagieren, werden Produkte angeboten, die die Sparten selbst konsumieren können. Diese Verschiebung erfordert einen Servicekatalog: die strukturierte Übersicht aller Cloud-Services, die die IT intern anbietet — mit klaren Servicebeschreibungen, Preisen und Qualitätsversprechen. Ohne Servicekatalog entstehen Sprawl-Umgebungen, in denen jedes Team seinen eigenen Weg geht, die IT den Überblick verliert und die Kosten unkontrolliert ansteigen. ## Was ein Servicekatalog leistet ![Servicekatalog Übersicht](./files/service-catalogue-overview.svg) **Für die Sparten:** Eine klare Übersicht, was die IT zu welchen Konditionen und in welchem Qualitätsniveau anbieten kann. Kein ewiges Hin und Her, welche Cloud-Dienste erlaubt sind und welche nicht. **Für die IT-Abteilung:** Strukturierte Nachfrage statt Ad-hoc-Anfragen. Planbare Kapazität. Die Basis für Kostentransparenz und interne Kostenverrechnung. **Für das Management:** Transparenz darüber, welche Services es gibt, was diese kosten und welche Sparten sie nutzen. Die Basis für fundierte Make-or-Buy-Entscheidungen. ## Fünf Kategorien eines Cloud Service Katalogs ### 1. Platform Services — Infrastruktur als Produkt Was STACKIT liefert, verpackt als internes Angebot mit klarer Governance: | Service | Beschreibung | Internes SLA | Preismodell | | -------------------- | ----------------------------------------------- | ---------------------- | ---------------------- | | Compute Standard | Virtuelle Maschinen, Standard-Tiers | 99,5 % Verfügbarkeit | pro vCPU/Monat | | Kubernetes Managed | Managed Kubernetes Cluster auf STACKIT SKE | 99,9 % Control Plane | pro Knotenstunden | | Object Storage | S3-kompatibler Object Storage | 99,9 % Haltbarkeit | pro GB/Monat | | Managed Database | PostgreSQL/MySQL managed, tägliche Backups | 99,5 % Verfügbarkeit | je RAM/Storage | | Privates Netzwerk | Dedizierte VPC mit Firewalling | Best Effort | Pauschale pro Projekt | ### 2. Security Services — Sicherheit als Standard Sicherheit wird nicht bestellt, sondern gehört zu jedem Projekt. Dennoch gibt es optionale Add-ons: | Service | Beschreibung | Zielgruppe | | ----------------------- | ------------------------------------------------ | -------------------------- | | Vulnerability Scanning | Regelmäßige Container- und IaC-Scans | alle Produktivsysteme | | Secrets Management | Zentraler Tresor für Credentials und API-Keys | alle Teams mit Secrets | | PAM | Privileged Access Management für Admin-Zugriffe | Tier-1- und Tier-2-Systeme | | Compliance Reporting | Automatisierter Nachweis für DSGVO, TISAX, BAIT | regulierte Workloads | ### 3. Data Services — Daten als Asset | Service | Beschreibung | SLA | | ----------------------- | --------------------------------------------------------- | ----------- | | Data Lake Standard | STACKIT Object Storage mit Partitionierung und Katalog | 99,5 % | | Managed Analytics | On-Demand-Analytics-Umgebungen (Spark, Jupyter) | Best Effort | | Data Pipeline Standard | Managed ETL-Infrastruktur auf STACKIT | 99 % | ### 4. DevOps Services — Entwicklungsplattform | Service | Beschreibung | Zielgruppe | | ---------------------- | ------------------------------------------------------------ | ----------------- | | CI/CD-Plattform | Managed Pipelines mit STACKIT Registry und Deployment | Entwicklungsteams | | Entwicklungsumgebungen | Standardisierte Entwicklungsumgebungen on Demand | Entwickler | | IaC-Templates | Validierte Terraform-Module für STACKIT-Ressourcen | alle Cloud-Teams | ### 5. Support Services — Wissen und Hilfe | Service | Beschreibung | Kanal | | -------------------- | --------------------------------------------------------- | ---------------------- | | Cloud Onboarding | Einführung für neue Teams: Architektur, Billing, IAM | Workshop (2 Tage) | | Architektur-Review | Technische Bewertung neuer Workload-Konzepte | asynchrone Prüfung | | FinOps Consulting | Kostenanalyse und Optimierungsempfehlungen | Monatlich | | Incident Support | Eskalationsweg bei kritischen Produktionsvorfällen | Pager/Slack | ## Interne Preisgestaltung — drei Modelle ### Modell 1: Kostentransparenz (Showback) Die IT weist jeder Sparte aus, was ihre Cloud-Nutzung kostet — ohne interne Abrechnung. Ziel: Kostenbewusstsein schaffen ohne administrativen Aufwand. Als Einstieg geeignet. Die Verhaltensänderung vollzieht sich langsam, da es keinen direkten finanziellen Anreiz gibt. ### Modell 2: Interne Kostenverrechnung (Chargeback) Kosten werden tatsächlich auf Kostenstellen gebucht. Die Cloud-Nutzung der Sparten wird in Rechnung gestellt. Das stärkste Instrument für Kostendisziplin. Erfordert eine saubere Tagging-Governance (Projekt-Tag für jede Ressource), einen klaren Preiskatalog und eine Abstimmung der Abrechnungsmodalitäten mit dem Finanzbereich. ### Modell 3: Pauschalbudgets mit Limits Sparten erhalten ein monatliches Cloud-Budget. Wer darüber hinausgeht, eskaliert in einen Freigabeprozess. Ressourcengrenzen werden technisch erzwungen. Eine Kombination aus Planungssicherheit für die Finanzabteilung und Autonomie für die Sparten. ## SLA — was intern zugesagt werden kann Ein Servicekatalog ohne SLAs ist eine Wunschliste. Interne SLAs müssen realistisch sein: Sie sollten leicht unter den STACKIT-SLAs liegen, um Puffer für Betrieb, Monitoring und Incident Response zu lassen. **Grundregel:** Internes Verfügbarkeits-SLA = STACKIT-SLA minus 0,5 Prozentpunkte Betriebspuffer. Reaktionszeiten klar definiert: | Schweregrad | Definition | Reaktionszeit | Lösungszeit | | ------------- | ------------------------------------------------------ | ------------- | ---------------- | | P1 — Kritisch | Produktionsausfall, geschäftskritisch | 15 Minuten | 4 Stunden | | P2 — Hoch | Erhebliche Beeinträchtigung, Workaround möglich | 1 Stunde | 24 Stunden | | P3 — Mittel | Teilbeeinträchtigung, Workaround vorhanden | 4 Stunden | 72 Stunden | | P4 — Niedrig | Kosmetisches Problem, keine Auswirkung auf Produktion | 1 Werktag | nächster Sprint | ## Aufbau des Servicekatalogs — praktische Schritte 1. **Inventarisierung:** Welche Services erbringt die IT bereits strukturiert oder unstrukturiert? Was wird am häufigsten nachgefragt? 2. **Portfolioentscheidung:** Welche Leistungen sollen standardisiert angeboten werden? Was bleibt Projektarbeit auf Anfrage? Was wird grundsätzlich abgelehnt? 3. **Servicebeschreibungen erstellen:** Je Service: Name, Beschreibung, Inklusivleistungen, Ausschlüsse, Preismodell, SLA, Einarbeitungsprozess. 4. **Interne Preisgestaltung definieren:** In Abstimmung mit der Finanzabteilung, auf Basis von STACKIT-Listenpreisen zuzüglich internem Betriebsaufwand. 5. **Portal oder Katalog veröffentlichen:** STACKIT bietet einen serviceaccountbasierten Zugang an, den die IT als Self-Service-Portal konfigurieren kann. Alternativ: ein einfaches Confluence-Wiki als Ausgangspunkt. 6. **Bedarf messen und Katalog iterieren:** Quartalsweise Überprüfung: Welche Services werden genutzt? Welche nicht? Was fehlt?