BEKOM MANAGEDService-Levels für PlattformenMessbare Verfügbarkeit pro Dienst
BEKOM vereinbart Service-Levels für Plattformdienste – Kubernetes, Datenbanken und Middleware – mit definierten Verfügbarkeitszielen und Reaktionszeiten.
Service-Level-Management für Plattformen im Überblick
Zwischen IT-Infrastruktur und Geschäftsanwendungen liegt eine technische Schicht: Kubernetes-Cluster, Datenbanksysteme und Middleware-Dienste. Diese Plattformdienste bilden die Betriebsgrundlage für Anwendungen – und erfordern eigene Service-Level-Vereinbarungen, die weder durch Infrastructure-SLAs noch durch Application-SLAs abgedeckt werden.
Plattformdienste bilden die Betriebsgrundlage geschäftskritischer Anwendungen – ihre Verfügbarkeit ist direkte Voraussetzung für die Auftragsverarbeitung und den operativen Betrieb standortübergreifender Geschäftsprozesse.
BEKOM vereinbart individuelle Service-Levels, die den Betrieb von Kubernetes-Clustern, Datenbanken und Middleware-Diensten auf eine verbindliche Grundlage stellen: Verfügbarkeitsziele pro Dienst, Recovery-Ziele für Datenbanken, Durchsatzzusagen für Middleware und definierte Upgrade-Zyklen. Die Vereinbarung orientiert sich an der Geschäftsrelevanz der jeweiligen Plattformkomponente und ist Bestandteil von BEKOM MANAGED Platforms.
Warum Plattformen eigene Service-Levels brauchen
Plattformdienste haben einen eigenen Lebenszyklus, der sich von der darunterliegenden Infrastruktur unterscheidet.
Kubernetes-Cluster durchlaufen regelmäßige Versionsupgrades, Datenbanken erfordern spezifische Recovery-Ziele und Middleware-Dienste benötigen Durchsatz- und Latenzzusagen.
Typische Herausforderungen ohne Plattform-SLAs:
Was BEKOM unter Plattform-SLAs versteht
BEKOM vereinbart Plattform-SLAs gemeinsam mit Ihrem Team.
Ausgangspunkt sind standardisierte Service-Level-Bausteine für Leistungskennzahlen auf Plattformebene – oberhalb der Infrastruktur, unterhalb der Anwendung.
Standardisierte Bausteine:
Wann Plattform-SLAs Infrastruktur-SLAs ergänzen müssen
Plattform-SLAs ersetzen keine Infrastruktur-SLAs, sondern setzen darauf auf.
Compute- und Speicher-Verfügbarkeit auf Infrastruktur-Ebene sagt noch nichts darüber aus, ob ein Kubernetes-Cluster Pods schedulen kann oder eine Datenbank ihre Recovery-Ziele einhält. Erst das Zusammenspiel aller drei Schichten – Infrastruktur, Plattform und Anwendung – ergibt ein belastbares Service-Level-Modell.
Plattformkategorien mit eigenen SLAs:
SLA-Bausteine pro Plattformkategorie
Jede Plattformkategorie hat eigene Betriebsanforderungen, Lifecycle-Zyklen und Leistungskennzahlen. Die Plattform-SLAs werden nicht pauschal festgelegt, sondern pro Kategorie – abgestimmt auf die jeweiligen technischen Besonderheiten.
Kubernetes: Cluster-Verfügbarkeit und Upgrade-Zyklen
Cluster-SLAs: BEKOM vereinbart Verfügbarkeitsziele auf Cluster-Ebene, getrennt nach Control Plane und Worker Nodes. Produktive Cluster erhalten höhere Ziele als Staging- oder Entwicklungsumgebungen. Bei SLA-Unterschreitungen analysiert BEKOM clusterspezifische Ursachen und leitet gezielte Gegenmaßnahmen ein.
Control-Plane-Verfügbarkeit: API-Server, etcd und Scheduler werden separat überwacht und mit eigenen Verfügbarkeitszielen versehen
Worker-Node-Bereitschaft: Pod-Scheduling-Latenz und Cluster-Autoscaling-Reaktionszeiten bei Lastspitzen als messbare Kennzahlen
Upgrade-Zyklen: Minor-Version-Upgrades nach definierten Testzeitfenstern mit dokumentierter Rückfallstrategie, Sicherheitspatches nach Kritikalität
Koordination: Kompatibilitätsprüfung mit Ihrem Entwicklungsteam vor jeder Produktivsetzung, abgestimmter Zeitplan pro Cluster
Datenbanken: Recovery-Ziele und Replikation
Datenbank-SLAs: Der Fokus liegt auf Datensicherheit und Wiederherstellbarkeit. BEKOM legt Recovery-Ziele pro Datenbank-Instanz und Kritikalitätsstufe fest und dokumentiert RPO und RTO im Service-Design-Dokument. Die tatsächliche Einhaltung wird in den regelmäßigen Service-Level-Berichten ausgewiesen.
RPO (Recovery Point Objective): Maximaler tolerierbarer Datenverlust pro Datenbank-Instanz – geschäftskritische Systeme erhalten engere Ziele als Entwicklungsinstanzen
RTO (Recovery Time Objective): Maximale Wiederherstellungsdauer nach Ausfall, definiert pro Kritikalitätsstufe
Replikation und Backup: Replikationsstatus, Replikationsverzögerung bei Cluster-Konfigurationen, Backup-Erfolgsrate und regelmäßige Wiederherstellungstests
Patch-Zyklen: Datenbank-Engine-Updates nach Release-Zyklen der jeweiligen Distribution (PostgreSQL, MariaDB, Redis), Kompatibilitätsprüfung vor jedem Major-Update, koordinierte Migration mit dokumentiertem Rollback-Plan
Middleware: Durchsatz und Nachrichtenverarbeitung
Middleware-SLAs: Für Message Broker, API Gateways und Integrationsdienste gelten eigene Leistungskennzahlen. Die Vereinbarung umfasst neben Verfügbarkeitszielen auch Durchsatzzusagen, die im Service-Design-Dokument pro Dienst festgehalten werden.
Nachrichtendurchsatz: Messages pro Sekunde für RabbitMQ und Kafka, Verarbeitungslatenz für eingehende Nachrichten als messbare Kennzahl im Service-Level-Bericht
Verfügbarkeit: Pro Middleware-Instanz und Cluster-Konfiguration definiert, Queue-Tiefe und Verarbeitungsrückstand als Frühwarnindikatoren
Kapazitätsplanung: Planung bei steigendem Nachrichtenvolumen, Konfigurationsanpassungen nach dokumentiertem Change-Prozess
Betriebsüberwachung: Monitoring von Cluster-Health und Partitionsstatus bei verteilten Systemen, dokumentiert im regelmäßigen Service-Review
Wie Plattform-SLAs gemessen werden
Die Einhaltung vereinbarter Plattform-SLAs erfordert plattformspezifisches Monitoring, strukturierte Berichterstattung und regelmäßige Service-Reviews. BEKOM integriert alle drei Aspekte in den laufenden Betrieb.
Plattform-Monitoring und Messung
Plattform-Monitoring: BEKOM überwacht Plattformdienste über eine zentrale Monitoring-Plattform, die Kennzahlen auf Plattformebene erfasst – getrennt von Infrastruktur- und Anwendungs-Monitoring. Geplante Wartungsfenster werden bei der Verfügbarkeitsberechnung berücksichtigt und separat ausgewiesen.
Kubernetes: Control-Plane-Health, Node-Status, Pod-Scheduling, Cluster-Events
Datenbanken: Replikationsstatus, Backup-Erfolg, Query-Performance, Speicherauslastung
Middleware: Queue-Tiefe, Nachrichtendurchsatz, Verarbeitungslatenz, Cluster-Partitionsstatus
Reporting und Service-Reviews
Strukturierte Berichte: BEKOM erstellt regelmäßige Plattform-SLA-Berichte pro Dienstkategorie. Die Berichtsfrequenz und der Detailgrad werden im Service-Design-Dokument vereinbart.
Verfügbarkeitskennzahlen: Pro Plattformdienst im Vergleich zum vereinbarten Ziel, RPO/RTO-Einhaltung und Ergebnisse regelmäßiger Backup-Wiederherstellungstests
Change-Dokumentation: Durchgeführte Upgrades und Patches mit Ergebnis und dokumentierter Auswirkung auf die Plattformlandschaft
Inzidenz-Übersichten: Nach Priorität und Bearbeitungsdauer, aufgeschlüsselt pro Plattformdienst
Kontinuierliche Verbesserung
Problem-Management: In regelmäßigen Service-Reviews analysiert BEKOM die SLA-Einhaltung, bewertet Inzidenz-Trends und identifiziert Verbesserungspotenziale. Wiederkehrende Störungen werden im Problem-Management-Prozess erfasst und dauerhaft behoben.
Trend-Analyse: Auswertung wiederkehrender Störungsmuster pro Plattformdienst als Grundlage für gezielte Gegenmaßnahmen
Monitoring-Optimierung: Anpassung von Schwellenwerten und Alarmierungsregeln auf Basis der Review-Ergebnisse
Upgrade-Optimierung: Bewertung der Upgrade-Zyklen und Wartungsfenster anhand tatsächlicher Auswirkungen auf die Verfügbarkeit
Wann Plattform-SLAs relevant werden
Die Einführung plattformspezifischer Service-Levels ist eine Frage der Betriebsanforderungen – nicht der Unternehmensgröße. BEKOM unterstützt Organisationen in unterschiedlichen Ausgangssituationen.
| Aspekt | Produktive Plattformdienste ohne formale SLAs | Auslagerung des Plattformbetriebs oder Compliance-Anforderungen |
|---|---|---|
Merkmale | Kubernetes-Cluster, Datenbanken oder Middleware-Dienste laufen in der Produktion, aber Verfügbarkeitsziele, Recovery-Zeiten und Upgrade-Zyklen sind nicht formal vereinbart. Mehrere Geschäftsanwendungen hängen von denselben Plattformdiensten ab. Upgrades werden aufgeschoben, weil Verantwortlichkeiten und Testzeitfenster nicht dokumentiert sind. Recovery-Erwartungen weichen zwischen IT-Team und Geschäftsleitung voneinander ab. | Die Organisation übergibt den Plattformbetrieb erstmals an BEKOM und benötigt eine verbindliche Leistungsbeschreibung als Entscheidungsgrundlage. Oder: Regulierte Branchen verlangen dokumentierte Recovery-Ziele, nachweisbare Backup-Prozesse und auditierbare Betriebsprozesse für Datenbanksysteme. Beide Szenarien erfordern formale, nachprüfbare Vereinbarungen. |
Empfohlener Ansatz | Plattform-Assessment pro Dienst: BEKOM ermittelt die Geschäftsrelevanz jeder Plattformkomponente und leitet daraus individuelle Verfügbarkeitsziele, Recovery-Zeiten und Upgrade-Zyklen ab. Das Ergebnis ist ein Service-Design-Dokument mit verbindlichen Kennzahlen pro Plattformdienst. | SLA-Konzept vor Übergabe: BEKOM dokumentiert Verfügbarkeitsziele, Recovery-Zeiten und Upgrade-Zyklen pro Plattformdienst, bevor der Betrieb übergeht. Für Compliance-Szenarien ergänzt BEKOM RPO/RTO-Dokumentation, Backup-Wiederherstellungstests und Audit-Trails für Konfigurationsänderungen. |
Vorteil | Verbindliche Grundlage für den Betrieb geschäftskritischer Plattformdienste. Nachvollziehbare Priorisierung bei Störungen. Messbare Betriebsqualität durch strukturiertes Reporting. | Vergleichbarkeit und Transparenz für die fundierte Bewertung des Betriebsmodells. Strukturierte Dokumentation für ISO-Zertifizierungen, branchenspezifische Regularien und externe Audits. |
Trade-off | Die Verfügbarkeitsziele unterscheiden sich nach Kritikalitätsstufe – Produktivsysteme erhalten engere Ziele als Entwicklungs- oder Testinstanzen. Das Assessment erfordert Mitwirkung des internen Teams zur Bewertung der Geschäftsrelevanz. | Bei Compliance-Szenarien sind branchenspezifische Anforderungen (Finanzdienstleistungen, Gesundheitswesen, Energieversorgung) frühzeitig in die SLA-Planung einzubeziehen. Die Nachweispflichten bestimmen den Detailgrad des Reportings. |
Fazit | Kostentreiber beim Eigenbetrieb von Plattform-Service-LevelsDie Entwicklung und Durchsetzung von Service-Level-Vereinbarungen für Plattformdienste verursacht im Eigenbetrieb erhebliche variable Aufwände. Kubernetes-Upgrade-Zyklen erfordern dedizierte Testumgebungen und Rollback-Szenarien, während Datenbank-Recovery-Verfahren regelmäßige Restore-Tests und dokumentierte Ablaufpläne benötigen. Monitoring-Systeme für Middleware-Durchsatz und Container-Verfügbarkeit müssen konfiguriert, kalibriert und kontinuierlich angepasst werden. Diese Kostentreiber entstehen durch die Komplexität unterschiedlicher Plattform-Lebenszyklen und deren individuelle Verfügbarkeitsanforderungen. BEKOM stellt diese Leistungen über eine planbare Monatspauschale bereit, die sowohl das Service-Level-Management als auch die damit verbundenen Assessment- und Dokumentationsaufwände umfasst. Verwandte Themen: Plattform-SLAs verzahnen sich mit Managed Kubernetes und Managed Middleware; die zugehörige Open-Source-Plattform-Sicht erschließt Container-Orchestrierung; für Hypervisor-Ablösungen unterhalb der Plattformen siehe das Szenario VMware-Exit. | |
Häufige Fragen zu Plattform-SLAs
Was unterscheidet einen Plattform-SLA von einem Infrastructure-SLA?
Ein Infrastructure-SLA misst, ob Server, Speicher und Netzwerk verfügbar sind. Ein Plattform-SLA misst, ob die darauf laufenden Kubernetes-Cluster, Datenbanken und Middleware-Dienste funktionieren. Die Unterscheidung ist relevant: Ein Server kann erreichbar sein, während der darauf betriebene Kubernetes-Cluster durch ein fehlerhaftes Upgrade beeinträchtigt ist. Plattform-SLAs ergänzen die Infrastrukturebene um plattformspezifische Kennzahlen wie Cluster-Verfügbarkeit, Recovery-Ziele und Durchsatzzusagen.
Wie legt BEKOM Recovery-Ziele für Datenbanken fest?
BEKOM ermittelt im Plattform-Assessment die Geschäftsrelevanz jeder Datenbank-Instanz und leitet daraus individuelle RPO- und RTO-Werte ab. RPO definiert den maximal tolerierbaren Datenverlust, RTO die maximale Wiederherstellungsdauer. Geschäftskritische Produktivdatenbanken erhalten engere Recovery-Ziele als Entwicklungs- oder Testinstanzen. Die konkreten Werte, die Backup-Strategie und die Wiederherstellungsmethodik werden im Service-Design-Dokument festgehalten und durch regelmäßige Restore-Tests validiert.
Was passiert bei einer Plattform-SLA-Unterschreitung?
Bei Unterschreitung vereinbarter Plattform-SLAs greift ein definierter Prozess: BEKOM analysiert die plattformspezifische Ursache, implementiert Gegenmaßnahmen und dokumentiert die Ergebnisse im Service-Report. Service-Credits gemäß vertraglicher Regelung werden angewendet, sofern im Service-Design-Dokument vereinbart. Der Fokus liegt auf der dauerhaften Vermeidung künftiger Abweichungen. Im nächsten Service-Review werden Ursache und Wirksamkeit der Maßnahmen gemeinsam bewertet.
Wie werden Kubernetes-Upgrade-Zyklen vereinbart?
BEKOM dokumentiert im Service-Design-Dokument die Upgrade-Strategie pro Cluster: Unterstützte Kubernetes-Versionen, Zeitrahmen für Minor- und Patch-Upgrades, Testzeitfenster und Rückfallstrategie. Vor jedem Upgrade führt BEKOM Kompatibilitätsprüfungen durch und stimmt den Zeitplan mit Ihrem Entwicklungsteam ab. Die tatsächlich durchgeführten Upgrades werden im Service-Level-Bericht dokumentiert, sodass für beide Seiten nachvollziehbar ist, welche Versionen im Einsatz sind und wann das nächste Upgrade ansteht.
Gelten Plattform-SLAs für On-Premise und Cloud gleichermaßen?
Die Plattform-SLA-Vereinbarung ist modellunabhängig: Verfügbarkeitsziele, Recovery-Ziele und Upgrade-Zyklen werden pro Dienst definiert – unabhängig vom Betriebsmodell. Umgebungsbedingte Unterschiede, etwa bei der Redundanz von Datenbankknoten oder der Netzwerklatenz zwischen Standorten, dokumentiert BEKOM transparent im Service-Design und berücksichtigt sie bei der Zielvereinbarung. BEKOM betreibt On-Premise- und Cloud-Plattformen mit identischen Betriebsprozessen und derselben Eskalationsstruktur.
Können Plattform-SLAs nachträglich angepasst werden?
Plattform-SLAs sind nicht statisch. Änderungen an der Plattformlandschaft, neue Geschäftsanforderungen oder Erkenntnisse aus den Service-Reviews können eine Anpassung der vereinbarten Ziele erfordern. BEKOM dokumentiert Änderungen formal im Service-Design-Dokument und versioniert den aktuellen Stand, sodass beide Seiten die Vereinbarungshistorie nachvollziehen können. Anpassungen werden gemeinsam abgestimmt, freigegeben und im nächsten Service-Level-Bericht berücksichtigt.
Wie funktioniert die Eskalation bei plattformspezifischen Störungen?
Bei Plattform-Inzidenzen greift ein dreistufiger Eskalationsprozess. Stufe 1: Der Platform-Spezialist klassifiziert den Inzidenz nach Geschäftsauswirkung und beginnt mit der Analyse. Stufe 2: Der Service-Manager wird bei verzögerter Lösung oder steigender Auswirkung einbezogen. Stufe 3: Der Delivery-Lead koordiniert bei übergreifenden Inzidenzen. Bei jeder Eskalationsstufe erhalten Sie ein strukturiertes Update mit aktuellem Stand und geplantem nächstem Schritt.
Wie werden Performance-Anomalien proaktiv erkannt?
BEKOM setzt automatisiertes Monitoring ein, das Performance-Kennzahlen aller Plattformdienste kontinuierlich erfasst: CPU-Auslastung, Speicherverbrauch, I/O-Latenz und Netzwerkdurchsatz. Bei Abweichungen von definierten Schwellenwerten oder ungewöhnlichen Mustern erfolgt eine automatische Alarmierung. Das Betriebsteam analysiert die Ursache und leitet Gegenmaßnahmen ein, bevor die Abweichung die vereinbarten Service-Levels beeinträchtigt.
Welche Kosten entstehen für Service-Level-Vereinbarungen bei Plattformdiensten?
Die Kosten richten sich nach der Anzahl und Komplexität der zu verwaltenden Plattformdienste. Kubernetes-Cluster, Datenbanksysteme und Middleware-Komponenten erhalten jeweils individuelle Service-Level-Definitionen mit entsprechenden Monitoring- und Reporting-Verfahren. BEKOM kalkuliert transparent nach dem tatsächlichen Verwaltungsaufwand pro Plattform-Stack, einschließlich der erforderlichen Test- und Validierungsverfahren für Recovery-Ziele und Upgrade-Zyklen.
Kann das Unternehmen später zum Eigenbetrieb der Plattform-SLAs zurückkehren?
BEKOM dokumentiert alle Service-Level-Definitionen, Monitoring-Konfigurationen und Testverfahren in strukturierter Form. Die entwickelten SLA-Frameworks, Recovery-Prozeduren und Upgrade-Richtlinien werden als vollständige Dokumentation übergeben. Etablierte Monitoring-Dashboards und Alerting-Regeln können in die interne Infrastruktur migriert werden. Der Wissenstransfer umfasst auch die Kalibrierung von Schwellwerten und die Anpassung von Service-Level-Zielen an veränderte Geschäftsanforderungen.
Nächster Schritt: Service-Level-Konzept besprechen
Der Einstieg beginnt mit der Analyse Ihrer Plattformlandschaft und der Anforderungen an Verfügbarkeit, Recovery-Ziele und Upgrade-Zyklen.
Das Assessment liefert eine vollständige Bestandsaufnahme aller Plattformdienste mit individuellen Service-Level-Empfehlungen pro Komponente. BEKOM erstellt konkrete Service-Design-Dokumente für Kubernetes-Verfügbarkeitsziele, Datenbank-Recovery-Verfahren und Middleware-Durchsatzzusagen. Die Analyse umfasst auch die Integration bestehender Monitoring-Systeme und definiert messbare Kriterien für Upgrade-Zyklen und Wartungsfenster.
Plattformlandschaft besprechen
Kontaktieren Sie BEKOM für ein Gespräch zu Ihrer Plattformlandschaft. Gemeinsam erfasst BEKOM die betriebenen Plattformdienste – Kubernetes-Cluster, Datenbanken, Middleware –, deren Kritikalität und Ihre Anforderungen an Verfügbarkeit und Recovery.
Plattform-SLA-Konzept erstellen
Auf Basis der Analyse erstellt BEKOM ein dokumentiertes Plattform-SLA-Konzept: Verfügbarkeitsziele pro Dienst, Recovery-Ziele für Datenbanken, Upgrade-Zyklen für Kubernetes und Reporting-Frequenz – abgestimmt auf die Geschäftsrelevanz jeder Plattformkomponente.
Vereinbarung finalisieren
Nach Ihrer Freigabe entsteht die formale Plattform-SLA-Vereinbarung als Teil des Service-Design-Dokuments: verbindliche Leistungsziele auf Plattformebene, definierte Messmethodik und plattformspezifisches Reporting – als Ergänzung zur bestehenden Infrastruktur-Vereinbarung oder als eigenständige SLA.