Enterprise customers have long demanded service-level agreements (SLAs) from their telecom and cloud providers....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
These SLAs set the parameters of quality of service (QoS) and network or application dependability. Now that many enterprises are building private or hybrid clouds, they are finding benefits in establishing internal SLAs that set similar accountability rules for the IT team.
External service-level agreements in public cloud computing span the cloud and establish a clear set of expectations between customers, vendors, network service providers and other organizations involved.
In an internal SLA, the IT organization often must establish best practices and rules that stretch across the private and public cloud. For example, an IT organization might put its own private Platform as a Service (PaaS) on top of Infrastructure as a Service (IaaS) that is provided by an external cloud service provider. In that case, the internal SLA must cover all the bases involved.
Elements of internal SLAs
An internal SLA should include the following components:
Description of services: The description of services outlines the types of services provided and the effective dates of agreement between a service provider, such as an IT department within an internal organization, and customers of other departments such as human relations and information security. These services are broken down by application or user group depending on the objectives of the SLA.
Maximum number of end users and application developers: Specifically, the SLA will determine who can concurrently access internal IT services and the maximum number of data requests for each user. If the end users represent more than one department, the specification on the maximum number may differ from one department to another.
Requirements to support QoS: In an internal organization, these include availability, accessibility, scalability and statefulness. There are differences in QoS, and these are determined by how services are broken down between application, network tenant or user group. These differences and details would be outlined in an SLA.
More on service-level agreements
Data center monitoring: Backbone to the cloud service-level agreement
Searching for the right SaaS service-level agreement
How to finesse a data center service-level agreement
Availability of services: Noting that the service is guaranteed to be available all the time or "on schedule" with a certain amount of planned maintenance downtimes or network changes is a key element of the agreement. This availability applies to applications being delivered, whether the services are broken down by application or user group.
It is important to note that only authorized users can access the service. Users who are not authorized to access the service are barred.
Scalability: An SLA should determine how scalable a system can be in order to meet spikes in demand. An example of such a service or situation that would require scalability would be Christmas shopping in a retail setting.
Response time: IT organizations must ensure that an application responds within reasonable threshold and time-to-service time-outs and data requests from a service user. Also included in this consideration is a help desk that will adequately respond to various classes of problems in order to maintain the guaranteed service level of network availability.
Security incident handling: SLAs must address security incident handling. For example, it is crucial to immediately address alerts on system intrusions. They should also define and outline event escalation and remediation services. The SLA must note other security services, such as network vulnerability updates, daily backups, failover plans, a disaster recovery plan and intrusion prevention tools.
Service exceptions: While there are many items to include in an SLA that are crucial to conducting network activity, some service exceptions can also be potentially included in an SLA. Denial of service is one example of service constraints to include in an SLA. This might create exceptions for things like willful misconduct, acts of God and war strikes that render the system useless.
Scheduled maintenance: This covers services that must be made to systems that may hold up functionality and process. Such activities and requirements include software and operating system patch ups and upgrades, as well as periodic malicious intrusion checks.
Service priority: This differs from one department to another within an organization depending on the roles and responsibilities of each user, the priorities of applications and network resources. The higher the priority, the more CPU should be dedicated and the more network resources will be allocated to execute necessary functions.
With so many considerations and factors to include, preparing an internal SLA requires extensive and careful planning ahead of deployment. The collaboration between IT managers and departmental users working together to agree on the terms and conditions of the internal SLA will make for a functional network environment.