So what makes for a good SLA? Piece of Cake finds out.


A. Service summary or description
Should detail the names of the provider and the customer, along with the obligations the latter has to fulfil to stay within the bounds of the SLA. You'll typically be asked to provide up-to-date contacts, network topologies, and escalation paths for example.

Should also list the support level - gold or platinum say - you're buying into, i.e. How fast will the service provider respond to service requests? How many requests are you permitted during the weekly or monthly service period?
What's the notification process?

Most importantly of all, what is your general service availability guarantee?


B. Hardware
Whether installed on-site or managed remotely, the SLA should state clearly what hardware is to be provided. Once you're sure of the hardware in use, ask more specific questions about spec, performance, throughput, size, upgrades, and so on.


Software
Most providers use products from name-brand vendors. Others use open-source software. Many use both. In any event it's important to know what software your service is subject to and where, particularly if you have special requirements or stipulations such as bans on unsupported open-source software.

Visibility over the software being used will also give an insight into the provider/software vendor relationship. For example, if your supplier is provisioning your firewall using Cisco PIX but has no qualified CCIEs on staff, you need to know about it.


C. Service Availability
Probably the most important element of the agreement, this section should describe precisely what you're guaranteed under the terms of the SLA, including critical aspects like guaranteed uptime percentage.

This is particularly crucial as, while an uptime figure such as 99.5% looks pretty high at first glance, it would mean your systems could be down for as much as 216 minutes per month without the provider incurring any penalty.

(You should be compensated for any downtime outside this tolerance, which is generally a case of the provider not invoicing for the period in question).

But beware the provider offering 100% availability. Few do, and for good reason; even if it were possible to deliver 100% availability - which is to say the least debatable - it would be prohibitively expensive for both provider and customer.

Also, as Martin Saunders, Group Product Manager at Claranet puts it, 100% SLAs are meaningless and misleading.

In the real world, there are outages; no system is perfect. It is important for customers to be realistic. It is then the responsibility of a good MSP to design a solution that balances the number of 9s in the availability guarantee (99.9%? 99.99%? 99.999%?) to the number of $$$ the customer is prepared to pay. An MSP SLA stating 100% means the customer has no way of knowing what the 'real' performance will be.

D. Defining Downtime
It's vital to have a clear understanding of how the service provider defines downtime
Most don't consider that upgrades constitute service downtime for example, so won't compensate you for them.

Pin down details such as how fast the provider will respond to service requests, how long they'll take to detect, report, and action problems, how long upgrades will take and so on.


E. Service Requests
Most SLAs allow a set number of service and emergency requests during each service period and it's important to understand the difference.

Some providers, for example, class any task performed outside standard business hours as an emergency, which could become an issue if most of your requests fall outside the hours of 9 and 5.

Some providers limit the number of your IT personnel permitted to initiate requests; some define certain tasks as constituting more than one request; some charge extra for certain service requests. So make sure you gen up early.


F. Monitoring & Reporting
Many providers have substantially improved their processes for reporting on metrics such as bandwidth utilisation and uptime in recent years, but capabilities still vary greatly from provider to provider, so ask questions.

Is the most up-to-date configuration available for review online?

How often will you get reports based on firewall, IDS, or VPN logs?
How about ad hoc and custom reporting?


G. Other Components
* Some providers, especially ASPs, source their services from multiple third parties - network providers, infrastructure providers, application management providers - each with their own SLAs that may in turn impact yours. Find out what components of the overall solution are covered under your SLA.

* Ask about guarantees against dropped connections. Some SLAs offer money-back for the time your connection is down.

* Some providers measure network traffic rates based on the packets going in and out but don't allow for dropped packets. Push for a guaranteed packet loss rate in your SLA.


Overall if the provider won't give key guarantees, look for a replacement. But remember, an SLA has to work for both parties and shouldn't be simply a big stick with which to hit the supplier in the event of a problem.

Defining, negotiating, and measuring can be difficult, but it's also vital if you want a meaningful SLA.