The Business Case for Storage Networks [Electronic resources] نسخه متنی

Service Level Management

Next to ILM, service level management (SLM) is one of the most buzz-worthy storage terms in use today. As a concept, SLM is not new; many application and hosting environments have had service level agreements (SLAs) in place with their clients for some time. SLAs allow for the monitoring and measurement of performance and solution delivery over time. Without an SLA to fall back on, there is no concrete benchmark against which the implemented solution can be graded.

In many instances, application environments already have SLAs with their clients outlining application performance and availability. Likewise, many hosting organizations have SLAs outlining host availability and performance. Some environments might even have SLAs governing the storage attached to the hosts, but few are likely to have storage-specific SLAs for services other than availability.

Storage-specific SLAs are rapidly gaining acceptance as organizations seek to build and implement the storage utility model. Simply put, SLAs are the most critical piece of the infrastructure required to support the storage utility model.

The difficulty of building the processes required to support SLAs depends entirely on the overall IT infrastructure of your organization. Large organizations with many different services and client groups will find building an SLA framework from scratch difficult and time-consuming. The effort, however, will be rewarded. When an SLA framework is completed, execution becomes almost a formality. All new products and services must merely meet the values set forth in an SLA.

Defining the Storage Vision

Defining the storage visionthe goal of providing storage as a utility-like servicehelps to secure the support of executive sponsors and outlines a basic roadmap for achieving the consolidated utility model. By now, this concept should be familiar to most IT professionals and many of the benefits of such a model should be obvious: cost containment, cost reduction, and improved service to name a few.

The view of the storage support team as internal service provider however, can be distasteful to some, and the astute client recognizes the next step after creating and implementing the utility model is billing (cost recovery or chargeback). This is a key concern of many application owners and consumers of storage, especially those who benefited from the obfuscation and chaos of the late 1990s when monitoring consumption rates and TCO was unheard of.

One concept that can be used to help navigate the implementation of the storage utility model in your environment is that of remuneration. When the cost-recovery concept is initially broached, if end users understand that, just as they can expect to be billed for their usage, they have recourse to financial recompense if the service does not meet the expectations defined and documented in the SLA, tensions are likely to be eased. It is a rare species that shies away from a money-back guarantee.

Note

Financial impact and remuneration can be calculated solely on a TCO basis or, for external facing systems, as a percentage of revenue impacted (dollars per minute of downtime). It would be wise to ensure that the vendor providing services to meet your own SLAs is also bound by the same financial penalties as those facing the storage support team.

Another tactic to consider using to mitigate the impact of implementing the storage utility model is to create SLAs for a pilot project or service. This demonstrates to application owners and end users exactly what to expect when the model is fully implemented. A pilot project can help ease fears about your ability to support an SLA for storage as a utility as well as relieve clients' concerns over what the final product will look like.

If there is intense pushback against the storage utility model, it is also possible to implement the SLA framework and utility model without a charge-back mechanism. The SLA framework and utility model provide ample data for the purposes of measuring storage costs and storage performance. After the framework is in place, the ability to control costs and quality is at your disposal.

It is hard to overstate the importance of securing executive sponsorship for implementing an SLA framework for storage services and support. Without executive sponsorship, any program designed to implement SLAs fails. Without SLAs, the storage utility model will be hampered by indistinct and unclear objectives and any push towards measuring client usage and recovering costs are met with resistance.

The clients should believe that having SLAs protects their best interests as much as the storage team does. Just as it is critical for the storage support team to have an SLA defined with their clients, they must also have a clearly defined SLA with the storage vendors (if you use a fully outsourced models you probably already have an SLA in place with at least one party in the storage value chain). Indeed, each of the values should match so that the appropriate service levels are met for all parties and so that the storage team is not left in the middle without recourse to resolution between vendors and clients.

Defining the Services

After the appropriate executive backing is in place and clients have agreed to an SLA framework, it is important to clearly define each service that will be measured within the framework. It is not critical that every one of the following services are tracked and monitored, but it is likely that at least some of these are of interest to the end users and clients:

AvailabilityTotal uptime.

PerformanceAgreed upon unit of measurement (response time, IO/sec).

Break-fixHardware and software troubleshooting and repair.

ProvisioningAllocation and de-allocation of storage devices.

Capacity planningProjecting for storage growth.

Financial analysisCost accounting and billing for storage services.

Data integrityBackup and restore.

Other services can be built around disaster recovery and business continuance as needed.

It is quite likely that many environments will tend to build SLAs only around the first four of these services, especially if dedicated resources are already assigned to capacity planning and financial analysis. Obviously, availability and performance are two metrics that are easily obtained and are most often already covered in an SLA with the application groups and their clients. SLAs for these services will undoubtedly be requested by your application groups and should likewise be required from your storage vendors. It is also essential that storage, host, and application SLA values match.

How break-fix and provisioning services are handled depends on your choice of storage support models (virtual team, dedicated team, and outsourced services). If these services are performed by a separate entity (as in an outsourced services model), you should ensure that there is some type of contractual obligation guiding and measuring the delivery of these services, especially if you have agreed to financial remuneration for missed SLAs.

Note

The most commonly recognized authority on IT service frameworks is the Information Technology Infrastructure Library (ITIL).

Finalizing the Framework Repository

When the services are defined and the SLAs are finalized, it is important that the resulting documentation be stored securely and centrally for easy access. In the event of an outage it will be necessary for the end users and service providers to revisit the documented availability and recovery times originally agreed upon.

If the overall outage window has been exceeded or the availability number has not been met, a postmortem required to determine what, if any, recourse the clients and end users might have as part of recovering from the outage. If there is financial impact to consider, what portion of that is financially recoverable from the storage