"S.L.O." Your S.L.A.

“S.L.O.” your Roll with your SLA’s

We all know the acronym SLA (Service Level Agreement) and we have all used it quite generically I suspect. So let’s get more specific and take a look at SLA and SLO (Service Level Objective) and define, compare and contrast the two.

Whether you are a vendor or a customer, you have probably said something like, “…in order to meet SLA’s…” and went no further, thought nothing more about it. I know I have done this many, many times.  I have found through my many years on this rock, that I can provide better value-add to our customers by drilling a bit deeper into this.  I hope that you can increase your value-add to your business stake holders by doing the same.  So let’s attack the SLA first. 

What is an SLA?

A Service Level Agreement is an agreement; a document that is produced for all parties that defines several things including, but not necessarily limited to:

  • What service is to be provided (backup, recovery, etc.)
  • The cost of the service
  • What support will be provided
  • Logistics including times, locations, and others as they relate to the service
  • Responsibilities of all parties
  • Penalties/consequences for non-compliance

This definition is pretty straightforward at a high level. But when you begin peeling that onion called your SLA, you should understand what Service Level Objectives are defined deep inside this document. 

What is an SLO?

A Service Level Objective is a key element within your SLA and is a means of measuring the performance of the service provider (which may or may not be you.) You could even consider an SLO as a Quality of Service (QoS) metric. In a paper published by Rick Sturm and Wayne Morris (“Foundations of Service Level Management”, April 2000), an SLO should be (my comments are in orange):

  • Attainable – Make sure you can do what you say you can do.
  • Repeatable – Especially in terms of backup/recovery!
  • Measurable – Make sure you have the tools needed to demonstrate you are meeting your requirements.
  • Understandable – Kind of obvious, but make sure all details are understood by all parties. Avoid generic terms that can be interpreted in different ways.
  • Meaningful – Enough said. SLOs should be meaningful and targeted to one specific metric.
  • Controllable – If you have no control over your environment, you probably shouldn’t guarantee anything…Remember Murphy?
  • Affordable – Both parties must feel the agreement is worth the costs involved. As you determine affordability, think beyond pure dollars and cents. Remember to factor in resource costs (people, infrastructure, etc) when you look at affordability.
  • Mutually acceptable – Don’t agree to something just because it’s the easy way. This must be a win-win agreement.

So, we understand that an SLO is a critical component in any SLA. Let’s talk about some common SLOs as they pertain to backup/recovery.

While there may be many in any given backup/recovery SLA, there are four SLOs that consistently bubble to the top.   Most vendors focus on only two of these, Recovery Time Objective (RTO) and Recovery Point Objective (RPO).  I would like to add Version Retention Objective (VRO) and Geographic Redundancy Objective (GRO) to round out the top four.

Defining these four goes something like this:

  • Recovery Time Objectives
    • How much down time can they afford before coming back “live”
  • Recovery Point Objectives
    • How much data can they afford to lose? 
  • Version Retention Objectives
    • How many copies of a given version of a file/application data set will be maintained and how long that copy will be maintained
  • Geographic Redundancy Objectives
    • What data needs to be replicated off-site, how often should replication occur, and what is the distance required between sites.

As you look at these, you may be thinking…”Gosh, all our business units have different requirements for each of these SLOs.”  That may be true.  And what does that mean to you?  Well, either you create different SLAs to meet the different needs across the business…or change to a more global backup/recovery policy.  Sounds simple, right?  Unfortunately it isn't always that way.  In either case you will need buy-in from management and the business stakeholders, as well as products that can be flexible enough to handle YOUR requirements. 

Now the great news! When you are developing your SLAs and associated SLOs, or looking for alternatives to your legacy backup, Quest has an outstanding portfolio of products to help you meet your specific SLOs.  Our suite of products provides RTOs as small as minutes (think in terms of the time it takes to power up a virtual machine) and RPOs down to 5 minutes for your mission-critical needs.  When you leverage the retention policies built into our portfolio, rest assured you can protect data “forever”, meeting all your VROs.  Finally, you can leverage our replication technologies to protect your data on-premise, at your disaster recovery site, or to the cloud, thus ensuring you meet the most stringent GROs. 

My father used to tell me that you should never let a day go by without learning something new. Here’s hoping that if you abide by the same wisdom, this blog proved valuable to you.  Please reach out to us if you would like to discuss our suite of Backup & Recovery products and how we can help you meet your specific SLAs….er.…I mean SLOs. 

About the Author
Joel.Jensen
Joel Jensen works as a Systems Engineer with Quest Software, specializing in data protection.