Within the context of a storage system outage, a service-level objective is the understanding between IT planners and application owners for how much time can elapse before a given application must be returned to full operation. George Crump, president of Storage Switzerland, explained that the service-level objective, a relatively new concept, includes several elements:
- Recovery point objective: How much data a company can afford to lose
- Recovery time objective: How long a company can go without a specific application
- Version retention objective: How many copies of data a company should keep and for how long
- Geographic recovery objective: Ensures the DR site is far enough away from the main site
According to Crump, in approximately 10 years of existence, 60% of service-level objectives are accepted at face value, 25% require some modification and 15% need some major work.
George Crump, president of Storage Switzerland
It's important that service-level objectives be realistic, he noted. Decide what's important and what your capabilities are, but don't set impossible goals.
Service-level objectives differ from service-level agreements. A service-level agreement is a contract between a service provider and its internal or external customers that documents what services the provider will furnish. The basic problem with a service-level agreement is that if you go to your users and say, "What's acceptable down time?" or "How much data can you afford to lose?" the answer is typically "none," Crump said.
The service-level agreement includes language describing the overall service, financial aspects of service delivery and specific performance metrics governing compliant service delivery. These individual performance metrics make up the service-level objective. Crump said he prefers using the word objective versus agreement because when you start using the word agreement, that means the other side agrees, and there are times when you can't get users to agree to things.
In this video, Crump discussed his criteria for a service-level objective and explained why companies should have one.
Transcript - The importance of a service-level objective
Editor's note: The following is a transcript of the video clip from George Crump's presentation, "Beyond Backup."
Now, service-level objectives essentially give you control back. You guys are the knowledge base as it comes to IT. You know what's possible, so you set what used to be called the SLA [service-level agreement]. You tell those guys, and I don't want to make it an "us vs. them" thing, but let's be honest, it is. You tell those guys what you can do.
The problem with that is that we generally, when we first start talking about that to people, we get a lot of resistance to it. Generally IT people aren't very kind of "go out there and get in your face" and all that kind of stuff. We'd rather just make things break on your computer, silently. But this does work very, very well.
It's based on your intrinsic understanding of what's important and what your capabilities are. As we do these data protection workshops, I've probably spoken to over 1,000 people now, easy. One of the first things I always do is I say, "OK, write down three applications that if they went down this morning and you couldn't get them back up and running tomorrow, you'd be fired." I have yet to have a single person not be able to write three applications down. Because I like to kind of play around a little bit, I act surprised. "Well, how did you do that?" First of all, can everybody here come up with three applications? A little head nod? OK. It's early, maybe two, I get it.
So then I ask, "Well, how did you do that? You didn't pay EMC $20,000 to come in and tell you it. You're not able to think. What are you doing? Stop it." Well, it's because you have this intrinsic understanding. I'm not picking on EMC by the way, it's anybody. You have this intrinsic understanding of what your capabilities are, right? You know what your important applications are. Nobody has to tell you.
So we set these service-level objectives and they have some puzzle pieces to them, if you will. There's a recovery point objective, recovery time objective, you've probably heard of those too. We kind of cast it in a little bit different light. There is a version retention objective. You probably haven't heard of that. That's because I made it up, because I needed three-letter acronyms and archive just didn't sound all that cool to me, so it's kind of [an] archive.
And then there's a geographic recovery objective [GRO]. Probably haven't heard of that one either. Again, made it up. I'm an analyst, so if I don't have good facts, I just pull some up. But GRO is disaster recovery, but I want people to think geographically. The No. 1 problem we see with disaster recovery plans today [is that] they're not far enough away.
I just was meeting with a guy two weeks ago whose disaster recovery site was 14 miles away from his primary site in the exact same flood plain. They were in a 100-year flood plain. It had flooded twice in the last 10 years. So, bit of a problem. We want you to start thinking much, much further than generally we see people do today.
If you go up to FEMA's website, [for] example, they have these [sorts of] regions -- we want you to be two regions away.