Interner Cloud Service Katalog
Zuletzt aktualisiert am
Von der IT-Abteilung zum internen Cloud-Anbieter
Abschnitt betitelt „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
Abschnitt betitelt „Was ein Servicekatalog leistet“
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
Abschnitt betitelt „Fünf Kategorien eines Cloud Service Katalogs“1. Platform Services — Infrastruktur als Produkt
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Interne Preisgestaltung — drei Modelle“Modell 1: Kostentransparenz (Showback)
Abschnitt betitelt „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)
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Aufbau des Servicekatalogs — praktische Schritte“-
Inventarisierung: Welche Services erbringt die IT bereits strukturiert oder unstrukturiert? Was wird am häufigsten nachgefragt?
-
Portfolioentscheidung: Welche Leistungen sollen standardisiert angeboten werden? Was bleibt Projektarbeit auf Anfrage? Was wird grundsätzlich abgelehnt?
-
Servicebeschreibungen erstellen: Je Service: Name, Beschreibung, Inklusivleistungen, Ausschlüsse, Preismodell, SLA, Einarbeitungsprozess.
-
Interne Preisgestaltung definieren: In Abstimmung mit der Finanzabteilung, auf Basis von STACKIT-Listenpreisen zuzüglich internem Betriebsaufwand.
-
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.
-
Bedarf messen und Katalog iterieren: Quartalsweise Überprüfung: Welche Services werden genutzt? Welche nicht? Was fehlt?