Enterprises and organisations are increasingly adopting cloud to run their workloads and apps. With multi-cloud and hybrid coming into the picture, crafting cloud SLA is becoming all the more complex and important in the service provider cloud market.
While service providers offer hundreds of tools and practices to manage multi-cloud workloads, the challenge, however, lies in laying down and adhering to SLAs. On one hand, organisations are adapting moving their mission-critical apps to run in a hybrid cloud environment. Service providers, on the other hand, act as single window of operations and offerings to their enterprise customers. Thus, planning and crafting SLA for the hybrid and multi-cloud environments is a challenge because of the involvement of different service providers, platforms and systems.
The Importance of SLA
Service Level Agreements are important because they help clear the expectations of the service quality between the cloud service provider and the cloud consumer. Each cloud entity engaged by the enterprise needs to have clearly written and drafted SLAs, including but not limited to public cloud providers, managed service providers and even cloud brokers.
SLAs formally document the service quality expectations, responsibilities and the limits of the service between the cloud service provider and the cloud service buyers. A formally documented SLA defines the availability, performance and process of serviceability, operations, billing and the penalties in cases where the cloud service provider is not able to meet SLA commitments. In addition, a well-drafted SLA can not only thwart any potential disputes but also has provisions for resolutions in case any dispute materialises.
Steps to Craft Complete Cloud SLAs
Before signing up or drafting any SLA for the cloud, consumers must chart out a detailed analysis of their business use case and strategy for the cloud environment. This includes identifying the apps to be deployed, with a clear roadmap of their criticalness to the business. Before negotiating the terms and conditions, executives need to understand the services that are going to be deployed. This helps understand the resources required and also set and negotiate terms with the providers.
1. Understand the Needs
The first step to drafting an SLA is to understand business needs and use cases and define what the consumer wants to achieve with cloud. Analysis should include how business needs will be achieved and what potential problems and challenges the provider could encounter. Furthermore, there should be clear distinctions between what constitute a SLA and what defines service level objectives (SLO).
2. Roles and Responsibilities
A good SLA defines what the consumer is getting, how the solution is going to be delivered. In doing so, the SLA should clearly outline roles and responsibilities of the consumer, using simple language that is easy to understand and interpret. The definitions might include, for example, the persons responsible for the oversight of security, audit, compliance or management. Further, key terms such as initiation date, maintenance dates and performance are essential to define.
Availability is a key aspect of any SLA as it lets the customer have a glimpse of the service provider’s responsiveness in the hour of need. More importantly, this helps set clear and honest expectations. It lets a customer know how often the service and personnel will be available. Customers should have a clear picture into support timings and average response times in case of raising a ticket.
It is also essential to clearly mention any exceptions to the service when it comes to IT support. For example, if there are any limitations to the service, they should be quantifiable and defined.
Metrics help compare and measure the performance of the service with respect to benchmarks. Defining measurable and trackable metrics is a Herculean task when it comes to cloud. But, at the same time, it is also very crucial. Metrics such as ‘time taken to respond to tickets’ or ‘time taken to install key security patches on the virtual machines’ are fairly standard and help manage consumers’ expectations regarding service levels.
Alongside, it is also extremely important to mention when the performance metrics cannot be applied or tracked, such as during a scheduled maintenance or updates.
5. Classification of Requests
Not every request can be addressed with the same terms in the SLA, and this should be clearly communicated. A fairly standard way of doing this is by classifying requests into high, medium and low priorities and so on. It is standard practice to exclude feature requests from SLA targets. It is also standard practice to have OEM-level escalations (L3+) as having an SLO rather than an SLA.
A service provider is responsible for providing and hosting the environment on which consumers run their mission-critical workloads. The service provider commits to provide the consumer with availability and resources over 99% of the time. Not meeting service levels could potentially result in business losses for the consumer in many cases. A well-written SLA needs to clearly define the penalties the service provider will undertake for incidents causing such business losses.
Lastly, the SLA needs to be proactive. It is of paramount importance for the provider to define reports and deliver them on a platform that is easy to interpret for the consumer. The SLA should essentially include all mechanics of reporting – what, when, how etc. Once put on schedule, these reports become a template for monthly or weekly reviews of all support operations.
Here’s a cheatsheet with the above 7 ingredients.
This post is part one of a multi-post series on cloud service level agreements.