In IT, we live and die by our SLAs, but those sometimes dusty contracts aren’t always a good reflection of today’s reality. Service-level agreements are drafted at the time of subscription to a new service, then often filed away and not revisited again until there’s a problem—maybe years later.
We all know that an SLA defines the percentage of time an application, server or database will be up and available, and how much time IT has to restore service when it goes down. But even though your SLA may allow three hours to get the app, server or database back up, what happens if the CEO and CFO start breathing down your neck after 30 minutes? You’ve got a problem, that’s what.
A service-level agreement formally binds a company and its IT department to a given time period for recovery when an outage occurs, but the more important recovery barometer should be the service-level expectation. You can put down your IT dictionary. You won’t find the term in there. Though not an “official” IT term, an SLE nonetheless refers to the level of service a company expects in the event of an outage. So while you won’t see any language spelling out the provisions of an SLE, if company leadership has expectations that are more demanding than what’s spelled out in your SLA, the priority is pretty clear.
There is a big gap between SLAs (contractual language that defines availability and sets a limit on downtime) and SLEs, the informal knowledge of true expectations for availability that generates the healthy relationship you want to have with company leadership. We see two main reasons for this gap: The first is the rapid rate of change in the way we produce and classify data. More and more data is mission-critical today, which means the reliance of the business on this ever-growing data is becoming increasingly important. So, if your SLA was written in 2009, it’s not likely to reflect business needs in 2012.
Secondly, you’re dealing with people. The consumerization of IT basically means that people expect things to work and be easy. Who cares what the legal contract (SLA) says if the people who use the service don’t think it’s reliable? Who cares if your performance review shows five nines if your stakeholders think you’re doing a bad job?
#!
You can maintain a healthy, positive relationship with your stakeholders by focusing on their service-level expectations rather than dusty 5-year-old SLAs. At the end of the day, this means your backup and recovery strategy, as well as your selected recovery technologies, should be based on SLEs, not SLAs. If you’re building your strategy based on a dated SLA, you might be asking for trouble.
A strategy based on an SLE, however, will push you to different tactics and more cutting-edge technologies that are better suited to meeting modern data-recovery challenges. With that in mind, here are three tips to ensure your recovery strategy and technologies align with your SLEs:
Have frequent, recurring conversations with business leadership to gain a better understanding of ever-changing business needs. This means regular conversations about the amount of downtime the business can realistically withstand for critical applications. This type of communication isn’t contractually defined or written down, but rather is a means of getting feedback on whether or not they like what you are doing. It’s asking, “How do you think it’s going?” and “Is it there when you need it?”
Use application-aware data protection technology. Use backup and recovery products that fully integrate with your mission-critical applications and databases (like Microsoft Exchange, SQL Server, Active Directory, SharePoint or Oracle) that the business can’t do without. Make sure your backup program is deeply integrated with your applications so you can recover and restore them directly. For example, if the CEO loses a critical e-mail in Exchange, the more granular you can get with your recovery, the quicker you can recover that single e-mail. For that type of granular recovery, you need application-aware recovery technologies.
Align your recovery strategy—and map recovery technologies—to the criticality of the data. Get away from a one-size-fits-all approach to data protection, and instead institute a tiered-recovery strategy by which you mix and match your technology implementations according to the criticality of the applications and data you’re protecting. Pair your most critical data to cutting-edge technology like replication and continuous data protection CDP, so you can get applications up and running very quickly after an outage. Use tape for static data that you need to retain for compliance and other reasons but don’t need to recover immediately. And consider cloud backup solutions, especially cloud gateways, that allow off-site backup with the speed of on-premise caching and recovery.
It goes without saying that SLAs are required in this world of hyper data growth. It’s SLEs, however, that capture what users really want from their critical applications and databases. If they are unhappy with the speed of recovery, this will reflect poorly on the provider.
If you are fully acquainted with the service-level expectation of business leadership, not only will you keep IT in good standing with the business, you will also be much better prepared to withstand the firestorm of expectations that will erupt when a critical application goes down.
Walter Angerer is senior vice president and general manager of data protection products for Quest Software.
