24 March 2016 how to – advanced Daniel Örneling 5 min read
Often, when discussing a Service Level Agreement (SLA), the discussion gets stuck at just discussing the number. But, what if I breach the SLA? Shouldn’t there be some kind of ”punishment”, like a fee for breaching the SLA? Shouldn’t there be a statement of what kind of downtime is OK? Shouldn’t I, as a service provider be able to patch or make improvements to the service without breaching the SLA?
In this post, I’ll focus on the rules of the SLA instead. I will show you how your newly created business services will behave by default and also how you can improve it from your end to match your deals.
Checking out the default behavior
Have you already created the service and have you added the components needed for your service to function properly? Once you have done that, there is the Service Level part left to deal with. Through the ”Service Level” tile below you will access the SLA configuration for your service.
In here you can configure the four service level objectives (SLOs) which are created by default, one for every tier (End User, Application and Infrastructure) and one for the complete service. The complete service availability is what we’re interested in here, so let’s make some changes to this one.
Service Level Objectives
As you can see below, I have changed the default 99% value to a higher 99,990% uptime each month. This won’t really give me much time before I eventually breach the SLA, but I think we should aim for a 100% availability instead. After having changed the SLA, I save the service and head into the Operations console (SCOM console).
When checking out the Service Dashboard, we can see that the service is in a healthy state right now, which is quite good for the availability level.
Live Maps Services Overview
Below is an image showing how my service has behaved lately, and as you can see I’ve breached my SLA. Now, I am down to an availability level of 97,6%. This is not really what I’ve signed up for, but then I don’t have any punishments related to SLA breaches in my lab environment, so I’m safe for now.
Live Maps Service Map.
Modifying the default behavior
As you can see in the image above, only a critical state counts as downtime and is affecting the SLA in the default service. What can we do from our end to fine tune these SLAs? Since Live Maps creates its services as distributed applications inside SCOM, all parts are SCOM native parts, meaning that we can change them as long as we know where to find them.
In this case, it’s the SLA rules we’re interested in. So, how can we find these? In the SCOM console, navigate to the Authoring pane and then click ”Service Level Tracking”.
You will now see a complete list of all your SLAs, if you want to search you can bring out the search function with Ctrl+F. Double click your service to open it up.
Service Level Tracking.
In here, you can see the four different service levels created. Let’s check out what we can change to the ”Service Availability” SLA by checking it and clicking edit.
Service Level Tracking.
This is now the default behavior. Only a critical state will count as downtime. If you have a deal which says that you can take down the service for 4 hours every other Sunday night, you shouldn’t be able to just put it into maintenance mode in the middle of some other night and get away with it. For the 4 hours every other Sunday night, you should set the service into a Planned maintenance mode. All other changes affecting the service outside of this service window should be counted as downtime, and you should then use Unplanned maintenance mode instead.
Service Level Objective (Monitor State).
Now, let’s add Unplanned maintenance mode as a thing that will be counted as downtime for the service. You can also add some other states as downtime, but I think this is something worth starting with. Make the changes to all of your services to make sure that you live up to your SLAs and both you and your customer will have a more fair service level availability reporting.
Service Level Objective (Monitor State)
What you’ve seen here is how you can make your business services even better by fine tuning them yourself. Live Maps comes with a lot of features that make business service monitoring in SCOM much easier and more user-friendly. It’s also a lot cleaner, and information is presented in a great way. However, that doesn’t mean we can’t make improvements to our service without the authoring console.
What I’ve shown here is an easy way to fine tune your services to fit your needs even better. Now that you’ve seen this, what will be your next step? Go into your Service Level Agreements in SCOM and have a look for yourself. I hope you like what you see as I really think this is a great addition to the default behavior of our services.
And by the way, this process works just as fine in SCOM 2016 (Technical Preview) as it does in SCOM 2012 that our production environments are still at.
Stay tuned because the newest release of Live Maps v8 will be available next week! The new release comes fully loaded with powerful new features, such as: BMC Remedy integration, Read-only Dashboards, Service Notes, and many more out-of-box services!
About Daniel Orneling
Daniel Örneling is a specialist consultant working for Approved Consulting. He focuses on SCOM, OMS and those parts of Azure that come along with it. Follow his blog if you want to learn more about his tips and fixes for System Center Operations Manager, Operations Management Suite and much more.