[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] The essential elements of an SLA [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
A service-level agreement (SLA) is a contract that codifies the requirements and expectations of all parties, both supplier and customer, for delivery of a class of service. It should specify the class of service tier required, detail the costs of providing that tier of service and can include penalties for failing to deliver the service. In general, SLAs include the following sections:

1. Preamble, prologue or summary: Identifies and describes the document and governing policy
2. Service: Codifies the terms of the agreement by identifying the class of service to be delivered
3. Responsibilities: Outlines the requirements for implementation and identifies the division of labor
4. Operations: Specifies support level, including provisioning, monitoring, escalation paths and response time
5. Compliance and reporting: Identifies the method and frequency of reporting
6. Appendix: Contains supplemental material, including any servers specifically excluded or with nonstandard backup windows, as well as other requirements

Transforming backup into a service
No discussion of SLAs can begin until the bigger issue of "service" is settled. You'll find that once IT is transformed into a real service provider, constructing SLAs becomes simple (see "The four parts of a service provider model"). The pieces of the contract naturally fall together once all parties agree on what should be included. But before you can agree to a service level for backup, you must transform backup into a service.

This is more easily said than done because backup is unusual among IT disciplines in that it's not in the critical path of operations. This means backup can fail day after day with no impact on the app's availability or performance, at least not until a restore request is made. This unusual aspect is shared with archiving, capacity planning and a few other disciplines, but it sets backup apart from the availability- and performance-obsessed data storage and server disciplines.

Today, ownership of backup responsibilities at most companies falls to either the storage or server groups. Bundling backup into storage seems to be the most prevalent direction, but that isn't necessarily any more appropriate than leaving backup responsibilities in the server group.

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   6  |   NEXT PAGE  >