| Like car insurance or self-assessment, it's easy to see | | | | 100% SLAs are meaningless and misleading. "In the |
| the Service Level Agreement (SLA) as a bit of a | | | | real world there are outage; no system is perfect. It |
| black art; but they're vital in ensuring IT service | | | | is important for customers to be realistic. It is then the |
| providers deliver availability, responsiveness, quality and | | | | responsibility of a good MSP to design a solution that |
| communication. Also, with managed services climbing | | | | balances the number of 9s in the availability guarantee |
| the IT agenda and other disciplines like Software as a | | | | (99.9%? 99.99%? 99.999%?) to the number of |
| Service gaining serious momentum, a watertight SLA | | | | £££ the customer is prepared to pay. An MSP |
| can make the difference between the success and | | | | SLA stating 100% means the customer has no way of |
| failure of your critical business systems and even the | | | | knowing what the ‘real' performance will be." |
| business itself. | | | | 5. Defining Downtime |
| So, what makes for a good SLA? | | | | It's vital to have a clear understanding of how the |
| 1. Service Summary or Description | | | | service provider defines ‘downtime'. Most don't |
| Should detail the names of the provider and the | | | | consider that upgrades constitute service downtime |
| customer, along with the obligations the latter has to | | | | for example, so won't compensate you for them. Pin |
| fulfil to stay within the bounds of the SLA. You'll | | | | down details such as how fast the provider will |
| typically be asked to provide up-to-date contacts, | | | | respond to service requests, how long they'll take to |
| network topologies and escalation paths for example. | | | | detect, report and action problems, how long upgrades |
| Should also list the support level – gold or platinum | | | | will take and so on. |
| say – you're buying into ie. How fast will the service | | | | 6. Service Requests |
| provider respond to service requests? How many | | | | Most SLAs allow a set number of service and |
| requests are you permitted during the weekly or | | | | emergency requests during each service period and |
| monthly service period? What's the notification | | | | it's important to understand the difference. Some |
| process? | | | | providers, for example, class any task performed |
| Most importantly of all, what is your general service | | | | outside standard business hours as an emergency, |
| availability guarantee? | | | | which could become an issue if most of your requests |
| 2. Hardware | | | | fall outside the hours of 9 and 5. Some providers limit |
| Whether installed onsite or managed remotely, the | | | | the number of your IT personnel permitted to initiate |
| SLA should state clearly what hardware is to be | | | | requests; some define certain tasks as constituting |
| provided. Once you're sure of the hardware in use, | | | | more than one request; some charge extra for certain |
| ask more specific questions about spec, performance, | | | | service requests. |
| throughput, size, upgrades, and so on. | | | | 7. Monitoring & Reporting |
| 3. Software | | | | Many providers have substantially improved their |
| Most providers use products from name-brand | | | | processes for reporting on metrics such as bandwidth |
| vendors. Others use open-source software. Many | | | | utilisation and uptime in recent years, but capabilities still |
| use both. In any event it's important to know what | | | | vary greatly from provider to provider, so ask |
| software your service is subject to and where, | | | | questions. Is the most up-to-date configuration |
| particularly if you have special requirements or | | | | available for review online? How often will you get |
| stipulations such as bans on unsupported software. | | | | reports based on firewall, IDS or VPN logs? How |
| Visibility over the software being used will also give an | | | | about ad hoc and custom reporting? |
| insight into the provider/software vendor relationship. | | | | 8. Other Components |
| For example, if your supplier is provisioning your firewall | | | | - Some providers, especially ASPs, source their |
| using Cisco PIX but has no qualified CCIEs on staff, | | | | services from multiple third parties – network |
| you need to know about it. | | | | providers, infrastructure providers, application |
| 4. Service Availability | | | | management providers – each with their own SLAs |
| Probably the most important element of the | | | | that may in turn impact yours. Find out what |
| agreement, this section should describe precisely what | | | | components of the overall solution are covered under |
| you're guaranteed under the terms of the SLA, | | | | your SLA. |
| including critical aspects like guaranteed uptime | | | | - Ask about guarantees against dropped |
| percentage. This is particularly crucial as, while an | | | | connections. Some SLAs offer money-back for the |
| uptime figure such as 99.5% looks pretty high at first | | | | time your connection is down. |
| glance, it would mean your systems could be down for | | | | - Some providers measure network traffic rates |
| as much as 216 minutes per month without the | | | | based on the packets going in and out but don't allow |
| provider incurring any penalty. (You should be | | | | for dropped packets. Push for a guaranteed packet |
| compensated for any downtime outside this tolerance, | | | | loss rate in your SLA. |
| which is generally a case of the provider not invoicing | | | | Overall if the provider won't give key guarantees, look |
| for the period in question.) | | | | for a replacement. But remember, an SLA has to |
| But beware the provider offering 100% availability. | | | | work for both parties and shouldn't be simply a big |
| Few do and for good reason; even if it were possible | | | | stick with which to hit the supplier in the event of a |
| to deliver 100% availability – which is to say the | | | | problem. |
| least debatable – it would be prohibitively expensive | | | | Defining, negotiating and measuring can be difficult, but |
| for both provider and customer. Also, as Martin | | | | it's also vital if you want a meaningful SLA. |
| Saunders, Group Product Manager at Claranet puts it, | | | | |