SLA für Managed Hosting prüfen: Verfügbarkeit, Reaktion und Wiederanlauf

Kurzantwort: Was muss ein belastbares Hosting-SLA enthalten?

Ein belastbares SLA nennt den konkreten Dienst, seine Abhängigkeiten und die verantworteten Betriebsschichten. Es definiert, wo und wann Verfügbarkeit gemessen wird, welche Ereignisse als Ausfall gelten, wie Störungen priorisiert werden und welche Zielzeiten für Reaktion, Zwischenmaßnahme und Wiederherstellung gelten. Dazu kommen Meldeweg, Eskalation, Wartungsregeln, Nachweis, Berichterstattung und ein Verfahren für wiederholte Abweichungen.

Das SLA wird gegen den eigenen Geschäftsbedarf geprüft. Wenn der Auftragseingang nur während bestimmter Zeiten kritisch ist, kann eine passend zugeschnittene Servicezeit sinnvoller sein als eine isolierte Prozentzahl. Wenn ein Prozess auch Identität, Datenbank, Schnittstelle und Anwendung benötigt, reicht eine Zusage für die virtuelle Maschine nicht aus. Der Vertrag muss verständlich zeigen, welche Lücke beim Auftraggeber verbleibt.

Leistungsgrenze und Verantwortungen vor jeder Kennzahl klären

Managed Hosting kann Infrastruktur, Betriebssystem, Datenbank, Laufzeitumgebung, Anwendung, Monitoring, Backup oder nur ausgewählte Teile umfassen. Listen Sie diese Schichten einzeln auf und ordnen Sie Anbieter, Auftraggeber sowie weitere Dienstleister zu. Der Begriff „managed“ begründet allein keine konkrete Leistung. Auch eine Störung kann an einer Komponente entstehen, die außerhalb der vereinbarten Grenze liegt.

Prüfen Sie zusätzlich die fachliche Funktion. Ein Server kann technisch erreichbar sein, während Anmeldung, Dokumentenabruf oder ERP-Übergabe nicht funktionieren. Definieren Sie deshalb technische Messobjekte und – soweit vereinbart – einen repräsentativen End-to-End-Prüfpunkt. Der Fachbereich beschreibt, welche Funktion für den Geschäftsprozess erforderlich ist; der Betrieb legt fest, wie sie verlässlich gemessen werden kann.

• Infrastruktur, Netzwerk und Plattform
• Betriebssystem, Datenbank und Laufzeit
• Anwendung und definierte Schnittstellen
• Identität, Zertifikate und externe Abhängigkeiten
• Monitoring, Wartung, Backup und Wiederherstellung
• fachliche Funktionsprüfung und Abnahme

Verfügbarkeit mit Messpunkt, Zeitraum und Nenner lesen

Eine Verfügbarkeitsquote ist nur interpretierbar, wenn der vereinbarte Messzeitraum und die zugrunde liegende Servicezeit bekannt sind. Klären Sie, ob Kalendermonat, Vertragsmonat oder ein anderer Zeitraum gilt und ob nur definierte Betriebsstunden oder der gesamte Zeitraum im Nenner stehen. Ebenso wichtig ist der Messpunkt: Netzschnittstelle, virtuelle Maschine, HTTP-Endpunkt oder fachliche Transaktion können unterschiedliche Ergebnisse liefern.

Die Messmethode muss kurze Unterbrechungen, Teilstörungen und wiederkehrende Fehler angemessen erfassen. Ein einzelner externer Prüfknoten kann ein Netzproblem außerhalb des Dienstes melden; eine interne Messung kann Probleme auf dem Nutzerweg übersehen. Sinnvoll ist ein dokumentiertes Messkonzept mit Quelle, Intervall, Bestätigung und nachvollziehbarer Aggregation. Widersprechen sich Messungen, braucht es ein festgelegtes Klärungsverfahren.

Reaktion, Workaround, Wiederherstellung und Behebung trennen

Reaktionszeit bezeichnet üblicherweise den Zeitraum bis zur qualifizierten Aufnahme oder ersten Bearbeitung. Sie sagt nicht, wann der Dienst wieder nutzbar ist. Ein Workaround kann eine eingeschränkte Funktion bereitstellen. Die Wiederherstellungszeit zielt auf die Rückkehr eines vereinbarten Dienstzustands. Die endgültige Behebung beseitigt die Ursache oder setzt eine dauerhafte Korrektur um. Diese vier Ereignisse dürfen im SLA nicht unter einem unscharfen Begriff verschwimmen.

Definieren Sie außerdem Start und Ende jeder Uhr. Beginnt die Zeit mit der automatischen Erkennung, dem Eingang über einen festgelegten Kanal oder erst nach Bestätigung? Pausiert sie, wenn Informationen des Auftraggebers fehlen? Wer bestätigt den wiederhergestellten Zustand? Eine technische Entstörung ist erst dann abgeschlossen, wenn der vereinbarte Prüfpunkt wieder funktioniert und offene Folgearbeiten dokumentiert sind.

Prioritäten an Wirkung und nicht nur an Technik koppeln

Prioritätsklassen verbinden Ausmaß, betroffene Nutzer, Geschäftsprozess, Datenrisiko und vorhandene Ausweichmöglichkeit. Eine ausgefallene Nebenfunktion kann anders bewertet werden als eine fehlerhafte Auftragserstellung mit möglicher Datenbeschädigung. Formulierungen wie „kritisch“ oder „hoch“ benötigen konkrete Kriterien, damit Auftraggeber und Dienstleister denselben Vorfall gleich einordnen.

Regeln Sie, wer eine Priorität setzen oder ändern darf und wie eine Abweichung begründet wird. Eine automatische Herabstufung ohne Rücksprache kann Zielzeiten entwerten; eine beliebige Hochstufung jedes Tickets macht die Steuerung wirkungslos. Bei Streit sollte zunächst die höhere Schutzmaßnahme greifen, während die Einstufung parallel geklärt und dokumentiert wird.

Servicezeit, Meldekanal und Eskalation zusammen prüfen

Eine Zielzeit gilt häufig nur innerhalb definierter Servicezeiten. Prüfen Sie Zeitzone, Werktage, Feiertage, Randzeiten und den Umgang mit Meldungen außerhalb des Fensters. Wenn eine Alarmierung rund um die Uhr erfolgt, aber die Bearbeitung erst am nächsten Servicetag beginnt, muss dieser Unterschied sichtbar sein. Bereitschaft oder 24/7-Bearbeitung sind eigenständige Leistungen und dürfen nicht aus einem Monitoring-Begriff abgeleitet werden.

Der Meldekanal muss auch bei Ausfall der gehosteten Umgebung erreichbar sein. Legen Sie Ticket, Telefon oder einen anderen vereinbarten Weg und die erforderlichen Angaben fest. Die Eskalationskette nennt Rollen statt nur einzelner Personen, enthält Vertretungen und verbindet technische mit geschäftlicher Eskalation. Für schwerwiegende Vorfälle braucht es einen festen Kommunikationsrhythmus, auch wenn noch keine Lösung vorliegt.

Wartung, Ausschlüsse und Abhängigkeiten begrenzen

Geplante Wartung kann aus der Verfügbarkeitsberechnung ausgenommen sein. Dann müssen Ankündigungsfrist, erlaubtes Fenster, erwartete Wirkung, maximale Dauer, Verschiebung und Notfallwartung geregelt sein. Ein pauschaler Ausschluss jeder angekündigten Unterbrechung würde die Kennzahl entwerten. Auch nach einer Wartung gehören technische und fachliche Funktionsprüfungen in den Ablauf.

Ausschlüsse für höhere Gewalt, Internetwege, Fremddienste oder Handlungen des Auftraggebers müssen so konkret sein, dass ihre Anwendung nachweisbar bleibt. Unterauftragnehmer oder Plattformanbieter bilden keine automatische Verantwortungslücke: Der Vertrag sollte zeigen, welche Leistung der Managed-Hosting-Anbieter trotz Abhängigkeit koordiniert und wie der Auftraggeber informiert wird. Der eigene Notfallplan berücksichtigt dennoch Ausfälle außerhalb der Anbietersteuerung.

Backup und Wiederherstellung getrennt vom SLA für Erreichbarkeit vereinbaren

Verfügbarkeit schützt nicht automatisch vor Datenverlust. Für Sicherungen werden Umfang, Frequenz, Aufbewahrung, Trennung, Verschlüsselung, Überwachung und Fehlerbehandlung beschrieben. RPO und RTO sind betriebliche Ziele: Der Recovery Point Objective beschreibt den maximal tolerierten Datenrückstand, der Recovery Time Objective die angestrebte Zeit bis zur Wiederherstellung eines definierten Zustands. Beide müssen zum konkreten System und Prozess passen.

Ein vorhandenes Backup belegt noch keine Wiederherstellbarkeit. Restore-Tests prüfen Daten, Anwendung, Konfiguration, Identitäten und Schnittstellen in einer geeigneten Umgebung. Das SLA oder die Leistungsbeschreibung klärt, wer den Restore auslöst, wer priorisiert, welche Mitwirkung erforderlich ist und wie die fachliche Abnahme erfolgt. Ergebnisse und Abweichungen werden nachverfolgt.

Messdaten, Betriebsberichte und Service Reviews als Nachweis nutzen

Der BSI-Kriterienkatalog C5 behandelt unter anderem Kapazitäts- und Verfügbarkeitsmonitoring, Datensicherung und Wiederherstellung sowie den Umgang mit Sicherheitsvorfällen. Für die Steuerung eines konkreten Dienstes benötigen Sie daraus ableitbare Nachweise: Messwerte zur vereinbarten Leistung, relevante Vorfälle, Zielzeitverletzungen, Wartungen, wiederkehrende Ursachen, Backup- und Restore-Befunde sowie offene Risiken.

Ein Monatsbericht sollte nicht nur eine grüne Quote zeigen. Er erklärt Abweichungen, Ausschlüsse und Messlücken und verbindet sie mit Maßnahmen, Eigentümern und Terminen. Im Service Review werden Trends und wiederholte Schwächen bewertet. Einzelne Gutschriften können vertraglich vorgesehen sein, ersetzen aber weder Ursachenbehebung noch Kontinuitätsplanung.

Das SLA vor Vertragsstart mit realistischen Vorfällen testen

Führen Sie einen Tischtest mit mehreren Beispielvorfällen durch: Anwendung nicht erreichbar, Anmeldung gestört, Datenbank langsam, Backup fehlgeschlagen, Wiederherstellung erforderlich und Fremddienst ausgefallen. Für jeden Fall wird geprüft, wer erkennt oder meldet, welche Priorität gilt, wann die Uhr startet, wer kommuniziert und welcher Zustand als wiederhergestellt zählt.

Der Test legt unklare Übergänge offen, ohne einen Produktivdienst absichtlich zu stören. Anschließend kann ein kontrollierter Alarm- oder Wiederherstellungstest den vereinbarten Ablauf praktisch prüfen. Ergebnisse fließen in Kontaktlisten, Runbooks, Monitoring und Vertrag ein. Ein SLA ist damit kein statischer Anhang, sondern Teil des gemeinsamen Betriebsmodells.

Ein Managed-Hosting-SLA in neun Schritten prüfen

Die Prüfung verbindet geschäftliche Kritikalität, technische Leistung und vertragliche Klarheit. Sie ist eine betriebliche Orientierung und ersetzt keine rechtliche Prüfung des konkreten Vertrags.

• 1. Kritische Geschäftsprozesse, Nutzungszeiten und tolerierbare Unterbrechungen festlegen.
• 2. Dienst, Betriebsschichten, Abhängigkeiten und verbleibende Eigenverantwortung abgrenzen.
• 3. Verfügbarkeit mit Messpunkt, Zeitraum, Nenner, Quelle und Ausfallkriterium definieren.
• 4. Prioritäten anhand von Wirkung, Ausmaß, Datenrisiko und Ausweichmöglichkeit festlegen.
• 5. Reaktion, Workaround, Wiederherstellung und endgültige Behebung getrennt vereinbaren.
• 6. Servicezeiten, Meldewege, Mitwirkung, Kommunikation und Eskalation abstimmen.
• 7. Wartung, Ausschlüsse, Unterauftragnehmer, Backup und Restore konkretisieren.
• 8. Messdaten, Berichte, Service Reviews und Umgang mit Zielverletzungen festlegen.
• 9. Ablauf mit Beispielvorfällen testen und nach wesentlichen Änderungen neu prüfen.