Service level management¶
Service level management betekent afspreken wat het platformteam levert, dat meten en het resultaat bespreken. Deze pagina is een kader. Er staan geen vaste getallen in: de doelen hangen af van je beheermodel en van je contract of interne afspraak. Vul de placeholders in, of bewaar de waarden in je onboardingdocument.
- Managed service (XMMS): de doelen maken deel uit van het contract. Het platformteam rapporteert erover en de service owner van de klant reviewt het rapport.
- Zelfbeheerd: je eigen platformteam bepaalt de doelen (vaak objectives of SLO's genoemd) samen met zijn stakeholders en rapporteert op dezelfde manier.
Voor een eerste set voorbeeldwaarden (severities, responstijden, een beschikbaarheidsdoel voor de hub) zie Operationele verantwoordelijkheden.
Scope: wat het service level dekt¶
| Gedekt door het service level van het platform | Niet gedekt |
|---|---|
| Hubcomponenten: firewall, Virtual WAN en hub, gateways, DNS, Application Gateway, Bastion | De applicatie van het workload team, inclusief beschikbaarheid en performance (Verantwoordelijkheden) |
| Pipelines en runners van het platform | Resources die een workload team in zijn eigen spoke deployt |
| De spoke-baseline en standaardwijzigingen | Storingen in Azure zelf. Die worden afgehandeld door te escaleren naar de cloudprovider (Incidentbeheer), maar het platformteam rapporteert er wel over |
| Monitoring van het platform en de bijbehorende alerts |
Workload teams hebben een eigen service level voor hun applicatie, met eigen business owners. Het level van het platform is daar de basis voor, dus vertel workload teams wat het is.
Wat je moet vastleggen¶
Schrijf in je onboardingdocument één tabel met deze onderdelen.
| Onderdeel | Wat af te spreken | Waarde |
|---|---|---|
| Servicetijden | Wanneer aanvragen en incidenten worden afgehandeld. Is de hub buiten kantooruren gedekt, en zo ja welke alerts? | <hours> |
| Intake | Waar aanvragen en incidenten worden geregistreerd | <support channel> |
| Severitydefinities | Zie Incidentbeheer | <table> |
| Responstijd per severity | Tijd van registratie tot de eerste reactie van een engineer | <minutes / hours> |
| Oplosdoel per severity | Optioneel. Tijd om de service te herstellen | <hours> |
| Doorlooptijd van standaardwijzigingen | Tijd van complete aanvraag tot afgerond, per soort wijziging | <working days> |
| Beschikbaarheid van hubcomponenten | Percentage per maand en een limiet voor één enkele verstoring | <percentage>, <minutes> |
| Gepland onderhoud | Aankondigingstermijn, vensters, hoeveel per periode | <n days>, zie Onderhoudskalender |
| Uitsluitingen | Wat niet meetelt (zie hieronder) | |
| Rapportage | Wat wordt gerapporteerd, hoe vaak, aan wie | Maandelijkse health check |
| Review | Hoe vaak het service level zelf wordt gereviewd | <quarterly / yearly> |
Meten¶
Meet alleen wat je uit een systeem kunt aflezen, zodat er elke maand niet over de cijfers wordt gediscussieerd.
| Service level | Bron | Opmerking |
|---|---|---|
| Beschikbaarheid van de Application Gateway | Beschikbaarheidsmetric per gateway | Maandelijks percentage, zoals in de health check |
| Beschikbaarheid van de firewall | Health-metric van de firewall | Maandelijks gemiddelde |
| Verbindingen met on-premises | Verkeer op de verbinding, naast de status ervan | De status alleen kan connected tonen tijdens een storing (Post-mortems) |
| Responstijd | Ticketsysteem: registratietijd en het tijdstip van het eerste antwoord van een engineer | Bepaal of kantooruren meetellen |
| Oplostijd van incidenten en standaardwijzigingen | Ticketsysteem: registratietijd tot oplostijd | Rapporteer het gemiddelde en de individuele items. Een paar lange items vertekenen een gemiddelde |
Uitsluitingen¶
Bepaal van tevoren welke tijd niet aan het platformteam wordt toegerekend. Gangbare keuzes:
- gepland onderhoud dat op tijd is aangekondigd;
- tijd die is besteed aan wachten op de klant, bijvoorbeeld op goedkeuring of informatie;
- tijd die is besteed aan wachten op een platformrelease waarop de klant akkoord was om te wachten. Rapporteer die met een toelichting, zodat het zichtbaar is zonder de gemiddelden te vertekenen;
- storingen in Azure zelf, in de beschikbaarheidscijfers. Het incident wordt nog steeds afgehandeld en gerapporteerd.
Rapportage en review¶
- Neem de cijfers op in de maandelijkse health check en bespreek ze in het tactische overleg.
- Als een doel niet wordt gehaald, zeg waarom en besluit over een actie: een verbetering, een aangepast doel of een geaccepteerd risico.
- Review het service level op het afgesproken interval. Een doel dat altijd wordt gehaald, is misschien te zacht. Een doel dat nooit wordt gehaald, vraagt om een besluit, niet om meer uitleg.
Eigenaarschap¶
| Rol | Doet |
|---|---|
| Service owner (kant van de klant) | Is eigenaar van de afspraak en leest de rapporten |
| Teamlead van het platformteam | Levert de service en rapporteert erover |
| Enterprise architecture en security | Levert een standaardtemplate voor service levels voor de hele organisatie, zodat de service levels van het platform en van workloads op elkaar aansluiten |
Heeft je organisatie nog geen standaardtemplate, gebruik dan de tabel onder Wat je moet vastleggen als start en pas die aan wanneer de template er is.