| ||
An SLA in this context is an agreement between the IT staff and the user community about the services being provided, the manner in which they are delivered, the responsibilities of the IT support staff, and the responsibilities of the users. An SLA serves many important functions, including setting the expectations of the users about the scope of services being delivered and providing accountability and a baseline of measurement for the IT staff. The established SLAs in your organization also provide the framework for the SME. After all, if you don't first figure out what you are managing and how you will manage it, what good will a tool do you? In addition to incorporating the three P s, a service level agreement should address the following three areas of responsibility:
– Availability This section should explain when the services are provided, the frequency (if appropriate), and the nature of the services.
– Performance This section describes how the service is to be performed and any underlying processes related to the delivery of the service.
– Usability This section should show how to measure whether the service is being used effectively. For example, a measure of success could be infrequent help desk calls.
Table 9-1 shows a sample SLA for an enterprise backup service.
Volumes To Back Up |
|
Availability |
|
Performance |
|
Usability |
|
Ideally, the SLA is an extension of the overall business goals. Defining a group of SLAs for an organization that has never used them can be a daunting task. The following tips will help you with the effort:
– Start by deciding which parts of your infrastructure go directly to supporting your business goals, and define exactly how that happens.
– Do not define an SLA in terms of your current support capability. Think "outside the box" regarding how a particular service should be delivered. The result will be your goal for the SLA. Now work backward and figure out what has to be done to reach the ideal SLA.
– Rather than starting at the ground level with individual SLAs for particular services, try laying down some universal rules for a so-called Master SLA. After all, some things will apply to nearly every service you deliver. A good place to start is with the help desk, where all user calls are taken. Decide how the help desk will handle, prioritize, and assign calls. The problem response time, for example, will be a standard time for all nonpriority calls. Once that is established, you can think about whether different services may need different handling for priority calls. Decide what the mission and goals are of the IT staff overall and how they support the business. Work backward from that to how the service management function must be defined to align with those goals.
Establishing a viable SLA for the user community (whether corporate users or fee-for-service (ASP) users) mandates equivalent SLAs with your providers. For example, most WAN providers (Qwest, Sprint, AT&T) will guarantee various parameters (availability, bandwidth, latency) that impact your ability to deliver service to users. Ensure internal SLAs do not invoke more stringent quality and reliability guarantees than external SLAs.
The subject of defining and working with SLAs is adequate material for a book all its own. Our intention here is to get you started in framing your network management services in terms of SLAs. You will find them to be not only a great help in sorting through the "noise" of information collected, but also an invaluable communication tool for users, IT staff, and management alike.