We can all agree that bad service availability is equal to bad service quality and bad quality leads to angry customers and loss of revenue. On the other hand, good service quality gives us happy customers and they eagerly act as references to find us more customers.
We, as service providers, love happy customers!
To address service quality, we really need visibility (what components deliver the service), insight into service health and enforcement of Service Level Agreements.
Take a look at our state machine!
This is one of the views we use when we our service is misbehaving in some way. Often, we make changes with the intention of improving service quality. However, change is a tricky thing, and in fact leads to outages in many cases. That is why we monitor change from a service level. The above view can help you quickly determine what change was responsible for loss of availability. Simply clicking on the timeline allows you to load previous states of the service; for instance, you can see that a change led to critical alerts.
Where is my rollback plan, right? In other words, what are we doing about it? SLAs are used to address the "What are we doing about it?" question.
What if you could apply Service Level Management principals to service health monitoring? You can, and it is straightforward.
Many of the business services delivered today are highly complex, built on hybrid infrastructure and ultimately have a small handful of service providers (that should be) working together to ensure service quality. Having visibility and insight is critical as is Service Level Management. ServiceNow is the platform where everyone works together and we use Service Level Management to enforce contractual obligations, commitments and agreements between groups that work together to provide services.
For every service that is mapped, a single corresponding task is automatically created in the em_ci_severity_task table. The severity of the task always matches the current severity of the business service.
The appropriate task is created automatically for you, but you will need to create the SLA definitions for the business services.
In this example, the SLA definition states that when the SLABlog service has a severity of Critical or Major, the Default SLA Workflow will execute. In other words, the workflow will start to send notifications (nag) to the task assignee. If appropriate action is not taken in a certain amount of time, the workflow will then notify (tattle) to management that the assignee is not taking care of business.
This way of working can obviously be applied to the prevention of outages. We don't have to wait until a service has a critical severity before we start working on it. For instance, if a degradation in response time is detected, the system can notify the correct parties so that corrective action can take place before the customer experiences a loss of service.
For our Service Level Manager friends out there, please note that SLA reporting with regards to the state of business services works in the same way as SLA reports for Incident response time — or any other task based SLA in ServiceNow. In other words, once you get the SLA definitions in place, the reporting just works.
It is also possible to have SLAs for CIs in much the same way as we described SLAs for Business Services in this blog. You just need to go into Event Management / SLA Configuration and set conditions so that the engine knows what SLAs to apply to which CIs.
There are many ways that we make ITSM & ITOM work better together and SLAs can be used to get the right people, from multiple groups, to focus on the right things at the right time.
