Service-Level-Management¶

Service-Level-Management bedeutet, zu vereinbaren, was das Plattform-Team liefert, es zu messen und über das Ergebnis zu sprechen. Diese Seite ist ein Rahmen. Sie enthält keine festen Zahlen: Die Ziele hängen von deinem Betriebsmodell und von deinem Vertrag oder deiner internen Vereinbarung ab. Fülle die Platzhalter aus oder halte die Werte in deinem Onboarding-Dokument fest.

Managed Service (XMMS): Die Ziele sind Teil des Vertrags. Das Plattform-Team berichtet dagegen, und der Service Owner des Kunden prüft den Bericht.
Eigenbetrieb: Dein eigenes Plattform-Team definiert die Ziele (oft Objectives oder SLOs genannt) mit seinen Stakeholdern und berichtet auf dieselbe Weise.

Für einen ersten Satz von Beispielwerten (Schweregrade, Reaktionszeiten, ein Verfügbarkeitsziel für den hub) siehe Verantwortlichkeiten im Betrieb.

Umfang: was das Service Level abdeckt¶

Vom Service Level der Plattform abgedeckt	Nicht abgedeckt
Hub-Komponenten: firewall, Virtual WAN und hub, Gateways, DNS, Application Gateway, Bastion	Die Anwendung des Workload-Teams, einschließlich ihrer Verfügbarkeit und Performance (Verantwortlichkeiten)
Pipelines und Runner der Plattform	Ressourcen, die ein Workload-Team in seinem eigenen spoke deployt
Die spoke-Baseline und Standardänderungen	Störungen in Azure selbst. Sie werden durch Eskalation an den Cloud-Anbieter behandelt (Incident-Management), aber das Plattform-Team berichtet trotzdem darüber
Monitoring der Plattform und ihre Alerts

Workload-Teams haben für ihre Anwendung ein eigenes Service Level, mit eigenen Business Ownern. Das Level der Plattform ist das Fundament dafür, also sag den Workload-Teams, wie es aussieht.

Was zu definieren ist¶

Schreibe eine Tabelle in dein Onboarding-Dokument, mit diesen Punkten.

Punkt	Was zu vereinbaren ist	Wert
Servicezeiten	Wann Anfragen und Incidents bearbeitet werden. Ist der hub außerhalb der Geschäftszeiten abgedeckt, und wenn ja, welche Alerts?	`<hours>`
Intake	Wo Anfragen und Incidents erfasst werden	`<support channel>`
Definitionen der Schweregrade	Siehe Incident-Management	`<table>`
Reaktionszeit pro Schweregrad	Zeit von der Registrierung bis zur ersten Reaktion eines Engineers	`<minutes / hours>`
Lösungsziel pro Schweregrad	Optional. Zeit bis zur Wiederherstellung des Services	`<hours>`
Durchlaufzeit von Standardänderungen	Zeit von der vollständigen Anfrage bis zur Erledigung, pro Art der Änderung	`<working days>`
Verfügbarkeit der Hub-Komponenten	Prozentsatz pro Monat und ein Limit für eine einzelne Störung	`<percentage>`, `<minutes>`
Geplante Wartung	Vorlaufzeit der Ankündigung, Fenster, wie viele pro Zeitraum	`<n days>`, siehe Wartungskalender
Ausnahmen	Was nicht zählt (siehe unten)
Reporting	Was berichtet wird, wie oft, an wen	Monatlicher Health Check
Review	Wie oft das Service Level selbst überprüft wird	`<quarterly / yearly>`

Messen¶

Miss nur, was du aus einem System ablesen kannst, damit die Zahlen nicht jeden Monat diskutiert werden.

Service Level	Quelle	Hinweis
Verfügbarkeit des Application Gateways	Availability-Metrik pro Gateway	Monatlicher Prozentsatz, wie im Health Check
Verfügbarkeit der firewall	Health-Metrik der firewall	Monatsdurchschnitt
Verbindungen zu On-Premises	Verkehr auf der Verbindung sowie ihr Status	Der Status allein kann bei einem Ausfall connected anzeigen (Post-Mortems)
Reaktionszeit	Ticketsystem: Registrierungszeit und Zeitpunkt der ersten Antwort eines Engineers	Lege fest, ob Geschäftszeiten zählen
Lösungszeit von Incidents und Standardänderungen	Ticketsystem: Registrierungszeit bis Lösungszeit	Berichte den Durchschnitt und die einzelnen Einträge. Einige lange Einträge verzerren einen Durchschnitt

Ausnahmen¶

Entscheide vorher, welche Zeit nicht gegen das Plattform-Team zählt. Übliche Optionen:

geplante Wartung, die rechtzeitig angekündigt wurde;
Zeit, in der auf den Kunden gewartet wird, zum Beispiel auf eine Genehmigung oder Informationen;
Zeit, in der auf ein Plattform-release gewartet wird, auf das der Kunde zu warten zugestimmt hat. Berichte sie mit einem Kommentar, damit sie sichtbar ist, ohne die Durchschnitte zu verzerren;
Störungen in Azure selbst, in den Verfügbarkeitszahlen. Der Incident wird trotzdem bearbeitet und berichtet.

Reporting und Review¶

Nimm die Zahlen in den monatlichen Health Check auf und besprich sie im taktischen Meeting.
Wenn ein Ziel verfehlt wird, sag warum und entscheide über eine Maßnahme: eine Verbesserung, ein geändertes Ziel oder ein akzeptiertes Risiko.
Überprüfe das Service Level im vereinbarten Intervall. Ein Ziel, das immer erreicht wird, ist vielleicht zu weich. Ein Ziel, das nie erreicht wird, braucht eine Entscheidung, nicht mehr Erklärungen.

Verantwortung¶

Rolle	Aufgabe
Service Owner (Kundenseite)	Besitzt die Vereinbarung und liest die Berichte
Leitung des Plattform-Teams	Liefert den Service und berichtet darüber
Enterprise-Architektur und Security	Stellt eine Standardvorlage für das Service Level für die gesamte Organisation bereit, damit Service Levels von Plattform und Workloads zusammenpassen

Wenn deine Organisation noch keine Standardvorlage hat, nutze die Tabelle unter Was zu definieren ist als Start und ändere sie, wenn die Vorlage kommt.