Service Level Agreement

SLA requirements

Email: support@testlabs.com.au

How quickly we can respond to and resolve your issues depends on the severity of the issue and the time you report it. During standard support hours, response times and target resolution times are explained in the matrix below.  Outside standard support hours we will provide a best-efforts response to issues.


Severity level

Indicative type of problem

Target response time

Target resolution time **

Critical

Host or production systems unavailable

30 minutes

2 hours

High

Your VM operating system is unresponsive

2 hours

4 hours

Medium

Your VM is running slowly

4 hours

1 business day

Low

You need your VM configuration changed

1 Business day

2 business days

 


  1. Security: A consumer must understand his security requirements and what controls and federation patterns are necessary to meet those requirements. A provider must understand what they must deliver to the consumer to enable the appropriate controls and federation patterns.
  2. Data encryption: Data must be encrypted while it is in motion and while it is at rest. The details of the encryption algorithms and access control policies should be specified.
  3. Privacy: Basic privacy concerns are addressed by requirements such as data encryption, retention, and deletion. An SLA should make it clear how the cloud provider isolates data and applications in a multi-tenant environment.
  4. Data retention, deletion: How does your provider prove they comply with retention laws and deletion policies?
  5. Hardware erasure, destruction: Same as #4.
  6. Regulatory compliance: If regulations must be enforced because of the type of data, the cloud provider must be able to prove his compliance.
  7. Transparency: For critical data and applications, providers must be proactive in notifying consumers when the terms of the SLA are breached. This includes infrastructure issues like outages and performance problems, as well as security incidents.
  8. Certification: The provider should be responsible for proving required certification and keeping it current.
  9. Performance definitions: What does uptime mean? All the servers on every continent are available? Or just one is available? It pays to define those definitions. (The authors of this paper suggest standardizing performance terminology to make it easier.)
  10. Monitoring: For issues of potential breaches, you might want to specify a neutral third-party organization to monitor the performance of the provider.
  11. Auditability: Because the consumer is liable for any breaches that occur with loss of data or availability, it is vital that the consumer be able to audit the provider's systems and procedures. The SLA should make it clear how and when those audits take place. They can be disruptive and costly to the provider.
  12. Metrics: These are the tangible somethings that can be monitored as they happen and audited after the fact. The metrics of an SLA must be objectively and unambiguously defined. Following this list is a list of common metrics.
  13. Providing a machine-readable SLA: This can allow for an automated, dynamic selection of a cloud broker. In other words, if your SLA requires that the broker use the cheapest possible provider for some tasks but the most secure provider for others, this type of automation makes it possible. (This type of service is not readily available yet, but is something to keep in mind when contributing to the cloud SLA standardization discussion.)
  14. Human interaction: On-demand self-service is one of the basic characteristics of cloud computing, but your SLA should take into account that when you need a human being, one is made available to you.

Some of the common performance metrics (for consideration #12) include

  • Throughput: System response speed.
  • Reliability: System availability.
  • Load balancing: When elasticity kicks in.
  • Durability: How likely to lose data.
  • Elasticity: How much a resource can grow.
  • Linearity: System performance as the load increases.
  • Agility: How quickly the provider responds to load changes.
  • Automation: Percent of requests handled without human interaction.
  • Customer service response times.

A few rules of thumb on reliability

The authors provide a concise treatise on a working definition of reliability when it comes to cloud performance. It goes something like this:

  • The rule of nines. A common metric concerning reliability is the number of nines a provider delivers (like, if the service is available 99.99999 percent of the time, five nines, then the total systems outages are like 5 minutes every 12 months). Problem is, what's an outage? (It can be a really bad situation if the provider gets to decide what an outage is.)
  • Layers of clouds. Many cloud offerings are built atop other cloud offerings — this is great for flexibility and power but each additional provider makes the system less reliable. (Like if each rates themselves to five nines, then the system overall is less than five nines.)
  • Distance between your app and its data. Again, as the number of providers increase, other factors that affect reliability take hold. Not only are you affected whenever one of the systems goes down, you're also affected if the network between them goes down.

 

1. Agreement Overview

This Agreement represents a Service Level Agreement ("SLA" or "Agreement") between Testlabs Australia and Customer for the provisioning of IT services required to support and sustain the product or service.

This Agreement remains valid until superseded by a revised agreement mutually endorsed by the stakeholders.

This Agreement outlines the parameters of all IT services covered as they are mutually understood by the primary stakeholders. This Agreement does not supersede current processes and procedures unless explicitly stated herein.

2. Goals & Objectives

The purpose of this Agreement is to ensure that the proper elements and commitments are in place to provide consistent IT service support and delivery to the Customer(s) by the Service Provider(s).

The goal of this Agreement is to obtain mutual agreement for IT service provision between the Service Provider(s) and Customer(s).

The objectives of this Agreement are to:

  • o Provide clear reference to service ownership, accountability, roles and/or responsibilities.
  • o Present a clear, concise and measurable description of service provision to the customer.
  • o Match perceptions of expected service provision with actual service support & delivery.

3. Stakeholders

The following Service Provider(s) and Customer(s) will be used as the basis of the Agreement and represent the primary stakeholders associated with this SLA:

 

IT Service Provider(s): Company name. ("Provider")

IT Customer(s): Customer ("Customer")


4. Periodic Review

This Agreement is valid from the Effective Date outlined herein and is valid until further notice. This Agreement should be reviewed at a minimum once per fiscal year; however, in lieu of a review during any period specified, the current Agreement will remain in effect.

 

The Business Relationship Manager ("Document Owner") is responsible for facilitating regular reviews of this document. Contents of this document may be amended as required, provided mutual agreement is obtained from the primary stakeholders and communicated to all affected parties. The Document Owner will incorporate all subsequent revisions and obtain mutual agreements / approvals as required.

 

Business Relationship Manager: Company name

Review Period: Bi-Yearly (6 months)

Previous Review Date: January 3, 2013

Next Review Date: February 12, 2013

5. Service Agreement

The following detailed service parameters are the responsibility of the Service Provider in the ongoing support of this Agreement.

5.1. Service Scope

The following Services are covered by this Agreement;

  • o Manned telephone support
  • o Monitored email support
  • o Remote assistance using Remote Desktop and a Virtual Private Network where available
  • o Planned or Emergency Onsite assistance (extra costs apply)
  • o Monthly system health check

5.2.Customer Requirements

Customer responsibilities and/or requirements in support of this Agreement include:

  • o Payment for all support costs at the agreed interval.
  • o Reasonable availability of customer representative(s) when resolving a service related incident or request.

5.3. Service Provider Requirements

Service Provider responsibilities and/or requirements in support of this Agreement include:

  • o Meeting response times associated with service related incidents.
  • o Appropriate notification to Customer for all scheduled maintenance.

5.4.Service Assumptions

Assumptions related to in-scope services and/or components include:

  • o Changes to services will be communicated and documented to all stakeholders.

6. Service Management

Effective support of in-scope services is a result of maintaining consistent service levels. The following sections provide relevant details on service availability, monitoring of in-scope services and related components.

6.1. Service Availability

Coverage parameters specific to the service(s) covered in this Agreement are as follows:

  • o Telephone support : 9:00 A.M. to 5:00 P.M. Monday - Friday
  • o Calls received out of office hours will be forwarded to a mobile phone and best efforts will be made to answer / action the call, however there will be a backup answer phone service
  • o Email support: Monitored 9:00 A.M. to 5:00 P.M. Monday - Friday
  • o Emails received outside of office hours will be collected, however no action can be guaranteed until the next working day
  • o Onsite assistance guaranteed within 72 hours during the business week

6.2.Service Requests

In support of services outlined in this Agreement, the Service Provider will respond to service related incidents and/or requests submitted by the Customer within the following time frames:

Severity level

Indicative type of problem

Target response time

Target resolution time **

Critical

Host or production systems unavailable

30 minutes

2 hours

High

Your VM operating system is unresponsive

2 hours

4 hours

Medium

Your VM is running slowly

4 hours

1 business day

Low

You need your VM configuration changed

1 Business day

2 business days