Topics in this domain
- IT Service Management
- Hardware Components and Architecture
- Operating Systems
- OSI Model
- TCP/IP and Common Protocols
- Network Devices: Switches, Routers, Gateways
- LAN/WAN Topologies
- Database Models and DBMS
- Database Controls and Normalization
- Asset Management
- Configuration Management
- Job Scheduling and Batch Processing
- Incident Management
- Problem Management
- Change Management
- Release and Patch Management
- Service Level Management
- Capacity and Performance Monitoring
- End-User Computing
- BCP Lifecycle
- Business Impact Analysis
- RTO, RPO, MTD, SDO
- Recovery Strategies
- Alternate Sites: Hot, Warm, Cold
- Backup Types: Full, Incremental, Differential
- Backup Storage and Rotation
- DRP Contents
- Testing BCP/DRP
- High Availability, RAID, Insurance
- Auditing BCP
Service Level Management
Agreeing what “good” means
A delivery company promises “next day by noon”. That promise is only real if it can be measured, if the warehouse, the drivers and the planes all commit to their part, and if someone checks the actual delivery times.
Service level management does this for IT. It:
- defines the services IT offers in a service catalogue
- agrees measurable SLAs with business customers
- makes sure internal teams (OLAs) and suppliers (underpinning contracts) can support them
- monitors and reports performance
- reviews services and drives improvement
The three agreements
| Agreement | Between | Purpose |
|---|---|---|
| Service level agreement (SLA) | IT and the business customer | Measurable service targets |
| Operational level agreement (OLA) | IT teams internally (network, database, service desk) | Internal commitments that support the SLA |
| Underpinning contract (UC) | IT and an external supplier | Supplier commitments that support the SLA |
The SLA is only as strong as what’s underneath it. If the SLA promises a four-hour fix but the hardware supplier’s contract allows next-business-day replacement, the SLA can’t be met. Checking that alignment is a common audit point.
What an SLA contains
- the services covered and the service hours
- measurable targets: availability, response and resolution times, throughput, capacity
- how performance is measured, and from what data
- reporting frequency and review meetings
- responsibilities of both sides
- escalation and consequences, including service credits
- how the SLA is reviewed and changed
A target that can’t be measured can’t be managed.
Checking the numbers
Reports should come from reliable, ideally automated, measurement. The auditor asks how the figures are produced:
- Is availability measured as users experience it, or only for one component?
- Are exclusions such as planned maintenance reasonable and agreed? Excluding lots of “planned” downtime can hide poor service.
- Could the provider manipulate the data, for example by reclassifying incidents?
Performance reported by the provider itself should be validated.
Example. The hosting provider reports 99.95% availability for the e-commerce site. Users experienced three long outages. The provider measures only server uptime, not whether the site actually responded. The auditor recommends end-to-end availability monitoring run by the organisation itself.
Improvement
Breaches should trigger root cause analysis and a service improvement plan. Service credits compensate the customer, but they don’t fix the service.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Internal agreement supporting an SLA | Operational level agreement |
| Supplier contract supporting an SLA | Underpinning contract |
| Most important characteristic of SLA targets | Measurable and agreed with the business |
| Provider’s performance reports | Validate the data independently |
| Repeated SLA breaches | Root cause analysis and service improvement plan |
In short
- Service level management agrees, monitors and reports on service levels with customers, and drives improvement.
- A service catalogue lists the services IT provides; SLAs set measurable targets for them.
- Operational level agreements (OLAs) are internal agreements between IT teams; underpinning contracts are with external suppliers. Both must support the SLA.
- SLA targets should be measurable, agreed with the business, and reported regularly.
- The auditor checks that reported performance is accurate and based on reliable data.
- Repeated SLA breaches should lead to service improvement plans, not just penalty payments.
Exam traps
- An SLA target that can't be measured can't be managed.
- If OLAs and supplier contracts don't support the SLA, the SLA will be breached.
- Self-reported performance by the provider should be validated.
- Availability measured excluding 'planned' downtime can hide poor service.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Agreeing what 'good' means
A delivery company promises 'next day by noon'. That promise is only real if it's measurable, if the warehouse, drivers and planes all commit to their part, and if someone checks the actual delivery times.
Service level management does this for IT: agree measurable targets with the business, make sure everyone behind them can deliver, and report honestly.
The three agreements