Implement "Pause SLO Clock" Solution

Adrian_Paech

Heya,

Just a quick question, does anyone recommendations around implementing the "Pause SLO Clock" Solution one way or another?
The best article I have found is this: http://blog.scsmsolutions.com/2013/02/sla-in-scsm-2012-part-3-hidden-features/

Anyone have any other thoughts, recommendations or tips on this before I attempt to implement it?

Thanks!

Adrian

Robert_Brentley

Hi Adrian,

That link does describe how to implement 'Stop the clock' on SLOs if you were to follow it.

However I personally discourage pausing the SLOs for two main reason.

Technically this process isn't supported by the product and you'll notice if you modify the SLO elements from the GUI console afterwards that your management pack will lose some of the code you are using to stop the clock which means the trigger event is going to happen against any change to the incident for example description update, classification change etc.

So if you do use this method do note it has a high chance of breaking if people adjust the SLO elements POST implementation and requires you to re-enable it each time you modify your SLOs.

The second reason I'm personally not keen on it is that it masks the service level agreement success rates for your organisation if you can simply pause the clock. If you have underpinning contracts which means you rely on third parties to assist in the incident resolution which is pushing you past your SLAs (typically the reason for wanting 'Stop the clock') then it might mean you need to think about an adjustment to your targets in your OLAs or a new design solution and criteria within the program that can handle this delay while the incident is waiting to be resolved.

Also remember an incident should be resolved when the interruption to the service has been restored and that a problem record should be raised to identify the root cause, sometimes I find people leaving incident open even after restoring the service until they find the root cause which is not the correct process.

Just my thoughts on it anyway.

Regards,

Rob.

Robert_Brentley

Hi Adrian,

That link does describe how to implement 'Stop the clock' on SLOs if you were to follow it.

However I personally discourage pausing the SLOs for two main reason.

Technically this process isn't supported by the product and you'll notice if you modify the SLO elements from the GUI console afterwards that your management pack will lose some of the code you are using to stop the clock which means the trigger event is going to happen against any change to the incident for example description update, classification change etc.

So if you do use this method do note it has a high chance of breaking if people adjust the SLO elements POST implementation and requires you to re-enable it each time you modify your SLOs.

The second reason I'm personally not keen on it is that it masks the service level agreement success rates for your organisation if you can simply pause the clock. If you have underpinning contracts which means you rely on third parties to assist in the incident resolution which is pushing you past your SLAs (typically the reason for wanting 'Stop the clock') then it might mean you need to think about an adjustment to your targets in your OLAs or a new design solution and criteria within the program that can handle this delay while the incident is waiting to be resolved.

Also remember an incident should be resolved when the interruption to the service has been restored and that a problem record should be raised to identify the root cause, sometimes I find people leaving incident open even after restoring the service until they find the root cause which is not the correct process.

Just my thoughts on it anyway.

Regards,

Rob.

Adrian_Paech

Good tips, thanks for that.
in our scenario, we often have a situation where we have a job in "pending user" or "pending date" state, where we are waiting on an end user to do something for us. Or the incident cannot be resolved until a certain date. We don't really want the Ali clock running at this time.
thos also applies to SRs where we cannot fulfill the SR until a specific date.
for example, we are on-boarding a new user, but they must not have their user account created and password sms'ed until 3 days before they commence. So the SR goes into a pause state until this date.
we don't really want to have the slo clock running in these scenarios.
As you mentioned, we wouldn't plan stopping the slo clock while the incident is waiting on a vendor for the same reasons you mentioned.

Saying all that I will keep in mind what you mentioned about the risks of implementing the stop slo clock solution.

thanks again!
Adrian