I’m frequently asked about SLO’s when I do consulting work and I realised that many people may not full understand how SLO’s work and the key pieces that have to be in place to not only get these to work as we expect but to do it efficiently so they do not adversely impact performance on our SCSM environment.
What is an SLO?
An SLO within ITIL is a contract or agreement negotiated between you as a service provider and your customer(s). An SLA describes the service and specifies your responsibilities that you will deliver to the customer. You might use a single SLA across several services or even customers, depending on your business model.
A simple example of an SLA might be that we agree to resolve a priority 1 rated incident in 4 hours.
A more complicated example might be that we agree to provide a 99.99% up time for a service.
What Components Make Up an SLO within SCSM?
To create an SLO within SCSM we need four components:
- A metric to measure
- A Queue to apply it to
- A calendar that defines our “Work Hours”
- A time set against the metric
Creating a Metric in SCSM
A metric, within SCSM, is defining any two properties that can have time difference between them.
For example: The Creation time and Resolution time of an Incident or Service Request.
The Metric is used as the point of measure for the workflow to use when displaying or reacting to a warning or breach event.
Out of all the SLO’s I’ve seen, the most common two are IR First Contact and IR Resolution.
Creating a Queue in SCSM
Not all SLO’s apply to all Work Items.
To limit what SLO’s apply to what Work Items, we need to group together a bunch of Work Items that we want to apply the SLO to.
Creating a Queue is a way of being about to group together a given type of work item based on a criteria that you choose.
Common examples used for Queues are:
- Priority based queues (P1, P2, P3 etc.)
- Category based queues (Server, Desktop, Network etc.)
The most critical thing to watch when creating Queues is to ensure you select a class that has the minimum number o relationships your required to achieve your goal. Selecting the “Incident (Advanced)” combination class for all Incident based Queues is the leading cause of SCSM slowdowns that I have seen.
Creating a Calendar in SCSM
The calendar is used to ensure that the SLO is only calculated when support staff are at work and not over weekend or overnight. (If you don’t work in a 24×7 organization)
You can have multiple calendars if you have different support groups working different hours, but for most organizations there is a single support schedule that the entire team works to.
Creating an SLO in SCSM
To create an SLO you have to have all of the perquisites created and available.
The SLO is then just a case of selecting the time to set against the metric type and applying it to a given queue.
Within the SLO creation wizard you will be asked for both a warning time and breach time.
Warning time triggers an event at a given time before the SLO breaches allowing you to have an e-mail sent to the relevant parties to give them fair warning that the Work Item needs to be worked on.
Breach time triggers an event at the time of the breach and can be used to notify management or an escalation team if required.
How to (and how not to) Use SLO’s in Day-to-Day Operations?
In this authors opinion, for MOST organizations, SLO’s are not required and provide nothing more than a false sense of security in reports and a great source of anxiety for support staff.
I only advise customers to implement SLO’s if they have strict, contractually binding service levels that they must achieve under penalty of contract breach or financial fine.
If your organization wishes to use the SLO’s purely as a reporting measure after the fact, then I suggest you use some advance reporting features to tease this information out of the data after the fact rather than placing the stress of the SLO clock on the support staff.
In a future post I will also offer an opinion on why I believe SLO’s for most organizations are terrible and should be killed with fire…… But that’s another post 😉
After working with SCSM for 6 years now, I thought that there was pretty much no new surprises left for me within this product that, lets face it, gets new features about as often as politicians do something right.
So it was with much celebration and rejoicing that I was informed of a hidden trick with in the SCSM Console that we all love to hate.
A good friend and fellow SCSM tragic Shayne Ray contacted me today to share what he found.
While doing some work jumping from the SCSM Console to the Cireson Service Manager portal, Shayne hit Ctrl+F5 to refresh the browser however, the focus at the time was on the SCSM console and he found something remarkable. A quick search around the interwebs finds a few mentions of it from others but nothing official from Microsoft, so I thought I’d do a quick write up of it all.
While in the console, any location, if the analyst hits any of the following combination of keys, the following actions are invoked:
- Ctrl+F1 – Opens a new default Incident form
- Ctrl+F2 – Opens a new Incident from a template
- Ctrl+F3 – Opens a new Request Offering from a template
- Ctrl+F4 – Opens a new Service Request from a template
- Ctrl+F5 – Opens a new Change Request from a template
- Ctrl+T – Hides or shows Tasks pane
- Ctrl+F – Opens the Advanced Search window
- Ctrl+D – Hides or Shows the Details Pane
- Ctrl+1 – Selects the Administration Workspace
- Ctrl+2 – Selects the Library Workspace
- Ctrl+3 – Selects the Work Items Workspace
- Ctrl+4 – Selects the Configuration Items Workspace
- Ctrl+5 – Selects the Data Warehouse Workspace
- Ctrl+6 – Selects the Reporting Workspace
- Alt+F1 – Hides or Shows the Navigation pane
You learn something new every day! 🙂