Service Level Management¶
Service level management means agreeing what the platform team delivers, measuring it, and talking about the result. This page is a framework. It contains no fixed numbers: the targets depend on your operating model and on your contract or internal agreement. Fill in the placeholders, or keep the values in your onboarding document.
- Managed service (XMMS): the targets are part of the contract. The platform team reports against them, and the customer's service owner reviews the report.
- Self-managed: your own platform team defines the targets (often called objectives, SLOs) with its stakeholders, and reports in the same way.
For a first set of example values (severities, response times, an availability target for the hub), see Operating responsibilities.
Scope: what the service level covers¶
| Covered by the platform's service level | Not covered |
|---|---|
| Hub components: firewall, Virtual WAN and hub, gateways, DNS, Application Gateway, Bastion | The workload team's application, including its availability and performance (Responsibilities) |
| Pipelines and runners of the platform | Resources a workload team deploys in its own spoke |
| The spoke baseline and standard changes | Faults inside Azure itself. These are handled by escalation to the cloud provider (Incident management), but the platform team still reports on them |
| Monitoring of the platform and its alerts |
Workload teams have their own service level for their application, with their own business owners. The platform's level is the foundation for it, so tell workload teams what it is.
What to define¶
Write one table in your onboarding document, with these items.
| Item | What to agree | Value |
|---|---|---|
| Service hours | When requests and incidents are handled. Is the hub covered outside office hours, and if so which alerts? | <hours> |
| Intake | Where requests and incidents are logged | <support channel> |
| Severity definitions | See Incident management | <table> |
| Response time per severity | Time from registration to the first reaction by an engineer | <minutes / hours> |
| Resolution target per severity | Optional. Time to restore service | <hours> |
| Standard change lead time | Time from complete request to done, per type of change | <working days> |
| Availability of hub components | Percentage per month and a limit on a single disruption | <percentage>, <minutes> |
| Planned maintenance | Announcement lead time, windows, how many per period | <n days>, see Maintenance calendar |
| Exclusions | What does not count (see below) | |
| Reporting | What is reported, how often, to whom | Monthly health check |
| Review | How often the service level itself is reviewed | <quarterly / yearly> |
Measuring¶
Measure only what you can read from a system, so that the numbers are not argued over each month.
| Service level | Source | Note |
|---|---|---|
| Availability of the Application Gateway | Availability metric per gateway | Monthly percentage, as in the health check |
| Availability of the firewall | Firewall health metric | Monthly average |
| Connections to on-premises | Traffic on the connection, as well as its state | State alone can say connected during an outage (Post-mortems) |
| Response time | Ticket system: registration time and the time of the first reply by an engineer | Define whether office hours count |
| Resolve time of incidents and standard changes | Ticket system: registration time to resolution time | Report the average and the individual items. A few long items distort an average |
Exclusions¶
Decide beforehand which time does not count against the platform team. Common choices:
- planned maintenance that was announced in time;
- time spent waiting for the customer, for example for approval or information;
- time spent waiting for a platform release that the customer agreed to wait for. Report it with a comment, so that it is visible without distorting the averages;
- faults in Azure itself, in the availability figures. The incident is still handled and reported.
Reporting and review¶
- Put the figures in the monthly health check and discuss them in the tactical meeting.
- When a target is missed, say why, and decide on an action: an improvement, a changed target, or an accepted risk.
- Review the service level at the agreed interval. A target that is always met may be too soft. A target that is never met needs a decision, not more explanation.
Ownership¶
| Role | Does |
|---|---|
| Service owner (customer side) | Owns the agreement and reads the reports |
| Platform team lead | Delivers the service and reports on it |
| Enterprise architecture and security | Provides a standard service level template for the whole organisation, so that platform and workload service levels fit together |
If your organisation does not have a standard template yet, use the table under What to define as a start, and change it when the template arrives.