|
Reporting for SLM by Rick Sturm A key element of Service Level Management (SLM) or Service Level Agreements (SLAs) is the reporting given by the service provider to the client. Unfortunately, from the viewpoint of the client, most of today's reporting is worthless gibberish. Typical reports contain such details as physical memory utilization, paging, swapping, disk I/O faults, buffer miss ratio, latency, packet loss, and so on. That is not to say that such technical data has no value; it does. However, it is not valuable to the end user. Instead, the data is useful internally, helping the service provider ensure that the various components involved in delivering a service are functioning properly and efficiently. So, what should reports intended for users contain? Before answering that, it is necessary 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 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 denote this status check with an icon similar to a stop light, with red, amber and green lights, with the obvious meanings. The next step in real-time reporting is to advise clients of any problems that currently exist. Of course, in most cases, this will simply be a confirmation of something that they already know or at least suspect. However, if you are a service provider, advising the client about problems does provide them with positive confirmation that you are aware of the problem. To maintain truly positive relations with your customers, you need to proactively advise clients when you see a potential problem arising. You need to let clients know how likely it is that the problem will occur, when it might happen and what might be the impact of the problem. This additional information allows your customers to anticipate and plan for possible difficulties. When a problem does occur, reporting should shift into what can be characterized as "Help Desk" mode. The client needs to know the nature of the problem, its scope, and its impact. As with other reporting, it is risky to provide a level of detail will not be helpful or understandable. A simple, concise description should be sufficient. Yet if it's doubtful that your customer is not going to understand a technical explanation, is any explanation of the cause necessary? The answer is, "Yes!" It is human nature to want to know what is happening, even if we don't really understand it. Let's assume that we are planning to fly from Frankfurt, Germany to London. We board the plane, but don't depart on schedule. As we sit there, the question that is most frequently asked is, "Why are we delayed?" Only after learning the cause of the delay will most passengers progress to the next questions: "How long will we have to wait?" and "When will we arrive at our destination?" The airlines recognize this and that typically provide this information to passengers in this order. Notice this the next time that you are on a flight that is delayed. Like the airline passengers, when there is a problem, end users want to have a sense of the nature of the problem. Next, they want to be assured that the service provider is taking the appropriate steps to resolve the problem. They also want to know when to expect the problem to resolved. Be as specific as possible when answering your customer's questions. Vague responses such as, "I don't know, we are working on it," are not helpful or acceptable. If you really don't know, then tell the client, but also explain why you don't know and when you may be able to provide an estimate of the time to resolution. If the outage is extended, give them progress reports. Also, in the case of an extended outage, don't forget to escalate awareness of the problem within both your own organization and your customer's. Periodic Reporting The other category of service-level reporting is periodic reporting. Periodic reports are the ones that occupy the attention of service providers. Typically, these are the reports that are specified in SLAs and are primarily, although not exclusively, historical in nature. Periodic reports contrast the actual performance with the objectives that have been specified previously. Those objectives need to have meaning and value for the customer. Typically, the reports will need to show some aspect of availability and speed (e.g., response time, service [not component] availability, and transaction volume). A detailed discussion about the definition of objectives and the appropriate levels for those objectives is a topic for another article. When Service Level Objectives (SLO) have not been met, the periodic reports should include an explanation of why the objectives were not met and what steps have been taken to ensure that they will be met in the future. In some cases, the missed SLOs will be due to circumstances for which the client is responsible - such as excessive traffic, mix of transactions. In such cases, service providers should seek a dialog with their clients. And it may be necessary to rewrite the SLA to reflect changing circumstances. Periodic reports should also include any information about future changes, anticipated problems, and so on - in short, anything that might forseeably impact the level of service delivered to the client. In looking to the future, it is also good to consider any changes in resource requirements that may be anticipated. Finally, service providers should deliver information in the periodic reports in a meeting instead of "throwing them over the wall" (i.e., shipping the reports). The meeting can be by conference call or in person. However, the dialog in that meeting will go a long way toward maintaining a good relationship between the client and the service provider. Rick Sturm is the founder and president of Enterprise Management Associates, the first technology analyst firm to specialize exclusively in management software and services. |
||
| Copyright (c) 2000-2003, nextslm.org. All Rights Reserved. Legal Statement. | ||