SLM reporting done right

A key aspect of service-level management or service-level agreements is that service providers regularly report to the client. Unfortunately, to an end user – say, a line-of-business manager – most of that reporting is worthless gibberish.

Typical reports look at physical memory utilization, paging, swapping, disk I/O faults, buffer miss ratio, latency, packet loss and so forth. I’m not saying such data has no value. It does. However, that value is not in communicating with an end user. That data is useful internally for the service provider to ensure that the various components involved in delivering a service are functioning properly and efficiently.

The natural question is: What should reports intended for users contain? Before answering that, we need to take a step back and look at the issue of reporting from a broader perspective. Reporting can be broadly divided into two categories: real-time and periodic.

Real-time reporting should be the first priority in service-level reporting. On a real-time basis, clients need to know the status (i.e., health) of the service. A simple, positive confirmation that the service is believed to be functioning normally is often sufficient. Some companies with SLM tools characterize this simple status check with an icon similar to a stoplight, with red, amber and green lights, with the obvious meanings.

The next step in real-time reporting is for service providers to advise clients of any current problems. Of course, in most cases, this will simply confirm something that the clients already know or at least suspect. However, advising clients about problems does let them know that the service provider is aware of the problem. To maintain truly positive relations with clients, service providers should be proactive, telling clients when they see the potential for a problem to occur, how likely it is, when it might happen and what the impact might be. This additional information lets users anticipate and plan for possible problems.

The other half of service-level reporting is the periodic reports. Typically, these are the reports specified in SLAs. They are primarily, although not exclusively, historical in nature and contrast actual performance with the objectives that have been specified previously. Those objectives need to be meaningful to the user. Typically, the reports will need to reflect some aspect of availability and speed – for example, response time, service (not component) availability, transaction volume and so forth. A detailed discussion about the definitions of objectives and the appropriate levels for those objectives is a topic for another article.

When service-level objectives (SLO) are missed, the periodic reports should include an explanation of the reason that the objective was not met and what steps have been taken to insure that the objective will be met in the future. In some cases, the missed SLO will be the responsibility of the user – such as excessive traffic, mix of transactions and so forth. This should lead to a discussion with the user, and it may be necessary to rewrite the SLA to reflect changing circumstances.

Finally, the information in the periodic reports should be delivered in a meeting, rather than by “throwing them over the wall” (i.e., shipping the reports). The meeting can be by conference call or in person, but the dialog in that meeting is important for maintaining a good relationship between the client and the service provider.