What do SLAs typically cover?
It is very important to keep the SLA simple, measurable and realistic. SLAs typically cover:
- Description of overall services
- Service performance metrics
- Financial aspects of service delivery
- Responsibilities of service provider and customer
- Disaster recovery process
- Review process and frequency of review
- Termination of agreement process
The specific performance metrics that manage the compliance of service delivery are called Service Level Objectives (SLOs). In the context of web services, SLOs would cover availability, uptime and response time for the service; probably accessibility by geography and problem resolution metrics such as mean time to answer and/or mean time to repair.
Is a service really available if the customer cannot use it? A well-constructed SLA should include a unit of measurement that defines availability to align with the customer’s critical business process, and not just the availability of the servers URL/URI or log in process.
SLAs often refer to monthly downtime or availability in order to calculate service credits to match monthly billing cycles. This table shows the translation from a given availability percentage to the corresponding amount of time a system or service would be unavailable.
Ex. If you have an e-commerce site with yearly revenue of $500 Million, 99% availability will cost you 3.65 days worth of revenue, nearly $5M lost to downtimes and unavailability. This is assuming that every day of the year contributes to the revenue equally, which is nigh impossible considering the seasonal nature of e-commerce business. Imagine a retailer facing downtime during the busy season of Black Friday to Cyber Monday. Right SLA's can help you save such disasters.
What are SLAs and why do we have them?
Consider the following analogy. You ask a friend to ‘check’ on your dog while you’re away. Obliging, your friend goes to your house, rings the doorbell to listen for a bark and then returns to their car. However, when you made the request you really wanted your friend to go into the house for a bit, make sure there were no issues and immediately notify you if something was wrong.
Using our doorbell analogy in web services context, a poorly negotiated SLA will ring the doorbell equivalent of looking for the 200 OK from the server. The 200 code, like the dog’s bark, will just tell you that someone is home and not the actual condition i.e. health of the service. Checking a website or authenticating without validating the business process you rely on, exposes you to downtime without financial leverage.
What can you, the service provider, do to get most out of SLAs?
Let’s say you are providing a marketing automation system to an enterprise that will run its global web activities over your system. You have promised them 95% availability and suitable performance from the east coast and west coast of USA, UK, Germany, and India.
Step one: Measure what you have
Before you commit to an exact performance target, hopefully you have measured what you have now. You need to baseline the performance of your service in order to understand what you can offer. It doesn’t make sense to offer 95% availability in India if your system typically only is available 80% of the time in India. However, when it comes to SLAs, under committing can lead to lost business opportunities and lost revenue. You can use your SLA as a competitive advantage, only if you know what you can and cannot deliver. Baselining performance will help you commit not too much, not too little but just right!
Using a synthetic performance monitoring tool like AlertSite, you can baseline your services. AlertSite allows you to proactively monitor websites, web applications, mobile applications and APIs. Ex. Let’s say you to measure performance of a user log in activity from UK during business hours. You can use the web recorder to record this multi-step user transaction and use that script to create a monitor. Next, you can create an SLA for that monitor by setting desired response time and availability objective. A quality synthetic tool will not only see if the service is up and running but also measures the response times and functional correctness from its global monitoring nodes; assuring SLA compliance by comparing the actual performance with SLA objectives.
Most vendors in the monitoring space cannot monitor to a set frequency, creating situations where some parts of an hour are over monitored while others have no monitoring at all. Unlike these vendors, AlertSite can perform consistent testing at set frequency. By observing your monitors real time in AlertSite, as well as from the SLA summary, you get the realistic and complete picture of your performance.
Step Two: Include what applies to your customer, exclude the rest
If your agreement states that you will provide a certain level of service for east coast, west coast, UK, Germany and India, don’t provide the data regarding the Netherlands and Africa. You also need to account for operational time for you, clearly mention the descriptions of your maintenance windows and/or upgrades. When building the service-level-agreement, keep in mind the operating periods as well as both ongoing and onetime events.
AlertSite lets you add exclusions to negate the effect of scheduled downtime and/or planned activities. On top of that, the reporting engine can isolate the locations for your SLA validation out of your larger monitoring pool without limiting your geographic monitoring coverage.
Customers are getting used to the multi tenancy nature of service providers. So be open to SLA negotiations, however calculate the cost associated with customization and make sure it aligns with your aggregate business interest in that customer. Many a times the customer can also be found in over/under demanding situations. Baselining customer’s performance requirements will lead to more realistic SLAs and a win-win situation for both parties.
Step Three: Monitor Aggressively
In order to make realistic availability and performance goals and keep them, you have to take enough measurements so that a single failure doesn’t skew the overall results.
The law of large numbers
I want to talk a little bit about the law of large numbers: which is a principle of probability and statistics. The law of large numbers states that as a sample size grows, its mean will get closer and closer to the average of the whole population.
This is an important context for monitoring and setting SLAs. If you run an availability test from 5 locations once an hour, one time, and one of those tests fails. Your availability is down to 80 percent. If you run tests from 10 locations every 5 minutes for an hour that is 50 tests – and if 1 fails then your availability is now 98%! Less aggressive monitoring leaves you vulnerable to an SLA violation for a brief outage.
By using AlertSite’s 350 real browser monitoring nodes across 81 global locations, you can monitor the transaction performance across selected geographies and on diverse internet service providers. Take advantage of the Law of large numbers to limit a brief outage from putting you out of your availability target.
In conclusion, service level agreements are valuable for you and your customers. Our three steps will help you look at SLAs as an opportunity than a restriction.
- Make the right agreement based on baseline performance
- Measure the correct things with the correct frequency
- Take enough measurements to smooth out variability