Service-level objective: Difference between revisions

Content deleted Content added
m top: link
No edit summary
 
(42 intermediate revisions by 30 users not shown)
Line 1:
{{short description|Key element of a service-level agreement}}
{{Refimprove|date=December 2013}}
 
A '''service level objective''' (SLO) is a key element of a [[service level agreement]] (SLA) between a [[service provider]] and a [[customer]]. SLOs are agreed as a means of measuring the performance of the Service Provider and are outlined as a way of avoiding disputes between the two parties based on misunderstanding.
 
A '''service-level objective''' ('''SLO'''), as per the O'Reilly Site Reliability Engineering book, is a "target value or range of values for a [[service level]] that is measured by an [[Service Level Indicator|SLI]]."<ref>{{cite web |first1=Chris |last1=Jones |first2=John |last2=Wilkes |first3=Niall |last3=Murphy |editor=Betsy Beyer |title=Site Reliability Engineering: How Google Runs Production Systems |url=https://sre.google/sre-book/service-level-objectives/ |website=Google Site Reliability Engineering |publisher=O'Reilly |access-date=9 June 2023}}</ref> An SLO is a key element of a [[Service-level agreement|service-level agreement (SLA)]] between a [[service provider]] and a [[customer]]. SLOs are agreed upon as a means of measuring the performance of the service provider and are outlined as a way of avoiding disputes between the two parties based on misunderstanding.
There is often confusion in the use of SLA and SLO. The SLA is the entire agreement that specifies what service is to be provided, how it is supported, times, locations, costs, performance, and responsibilities of the parties involved. SLOs are specific measurable characteristics of the SLA such as availability, throughput, frequency, response time, or quality.
 
==Overview==
The SLO may be composed of one or more quality-of-service measurements that are combined to produce the SLO achievement value. As an example, an availability SLO may depend on multiple components, each of which may have a QOS availability measurement. The combination of Quality of Service (QOS) measures into an SLO achievement value will depend on the nature and architecture of the service.
There is often confusion in the use of SLAs and SLOs. The SLA is the entire agreement that specifies what service is to be provided, how it is supported, times, locations, costs, performance, and responsibilities of the parties involved. SLOs are specific measurable characteristics of the SLA such as availability, throughput, frequency, response time, or quality. These SLOs together are meant to define the expected service between the provider and the customer and vary depending on the service's urgency, resources, and budget. SLOs provide a quantitative means to define the level of service a customer can expect from a provider.<ref name=":1">{{Cite journal|last1=Rastegari|first1=Yousef|last2=Shams|first2=Fereidoon|date=2015-12-29|title=Optimal Decomposition of Service Level Objectives into Policy Assertions|journal=The Scientific World Journal|language=en|volume=2015|issue=1 |pages=465074|doi=10.1155/2015/465074|issn=2356-6140|pmc=4709918|pmid=26962544|doi-access=free}}</ref>
 
The SLO are formed by setting goals for metrics (commonly called [[service level indicator]]s, SLIs). As an example, an availability SLO may be defined as the expected measured value of an availability SLI over a prescribed duration (e.g. four weeks). The availability SLI used will vary based on the nature and architecture of the service. For example, a simple web service might use the ratio of successful responses served vs the total number of valid requests received. (total_success / total_valid) <ref name="Hidalgo20">{{cite book |last1=Hidalgo |first1=Alex |title=Implementing Service Level Objectives |date=August 2020 |publisher=O'Reilly Media, Inc. |isbn=9781492076766 |edition=1}}</ref>
In <ref>Rick Sturm, Wayne Morris "Foundations of Service Level Management", April 2000, Pearson.</ref> the authors argue that SLOs must be:
 
==Examples==
 
InSturm and Morris argue <ref>Rick Sturm, Wayne Morris "Foundations of Service Level Management", April 2000, Pearson.</ref> the authors argue that SLOs must be:
 
* Attainable
Line 17 ⟶ 21:
* Affordable
* Mutually acceptable
In <ref>Alexander Keller, Heiko Ludwig "The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services", Journal of Network and Systems Management, Vol 11, n. 1, March 2003.</ref> the authors define a SLO as a "commitment to maintain a particular state of the service in a given period" with respect to the state of the SLA parameters.
 
InWhile <refAndrieux name=":0"et /> the authorsal. define the SLO as "the quality of service aspect of the agreement. Syntactically, it is an assertion over the terms of the agreement as well as such qualities as date and time".<ref name=":0" /> Keller and Ludwig more concisely define an SLO as "commitment to maintain a particular state of the service in a given period" with respect to the state of the SLA parameters.<ref>Alexander Keller, Heiko Ludwig "The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services", Journal of Network and Systems Management, Vol 11, n. 1, March 2003.</ref> Keller and Ludwig go on to state that while service providers will most often be the lead entity in taking on SLOs there is no firm definition as such and any entity can be responsible for an SLO. Along with this an SLO can be broken down into a number of different components.
 
* Obliged - The entity that is required to deliver the SLO.
SLOs should generally be specified in terms of an achievement value or service level, a target measurement, a measurement period, and where and how measured. As an example, "90% of calls to the helpdesk should be answered in less than 20 seconds measured over a one-month period as reported by the [[Automatic call distributor|ACD system]]". Results can be reported by the percent of time that the target answer time was achieved compared to the desired service level (90%).
* Validity Period - The time in which the SLO will be delivered.
* Expression - This is the actual language that defines what the SLO will be.
 
Optionally an EvaluationEvent maybe assigned to the SLO, an EvaluationEvent is defined as the measure by which the SLO will be checked to see if it's meeting the Expression.
The use of the term ''SLO'' is deprecated in [[ITIL]] V3 to Service Level Target, not to be confused with [[service level requirement|Service Level Requirement]] defined in the [[service design]]. However the SLO term is found in various scientific papers, for instance in the reference architecture of the SLA@SOI project,<ref>Jens Happe, Wolfgang Theilmann, Andrew Edmonds, and Keven T. Kearney "A Reference Architecture for Multi-Level SLA Management" in "Service Level Agreements for Cloud Computing", eds. Wieder, Philipp and Butler, Joe M. and Theilmann, Wolfgang and Yahyapour, Ramin, Springer New York, 2011, DOI:10.1007/978-1-4614-1614-2_2</ref> and it is used in the Open Grid Forum document on WS-Agreement.<ref name=":0">Alain Andrieux, Karl Czajkowski, Asit Dan, Kate Keahey, Heiko Ludwig, Toshiyuki Nakata, Jim Pruyne, John Rofrano, Steve Tuecke, Ming Xu "Web Services Agreement Specification (WS-Agreement)", GFD-R-P.107, March 2007, Open Grid Forum.</ref>
 
SLOs should generally be specified in terms of an achievement value or service level, a target measurement, a measurement period, and where and how they are measured.<ref name=":1" /> As an example, "90% of calls to the helpdesk should be answered in less than 20 seconds measured over a one-month period as reported by the [[Automatic call distributor|ACD system]]". Results can be reported byas thea percent of time that the target answer time was achieved and then compared to the desired service level (90%).
 
{| class="wikitable"
!Type of Measure
!Example SLO Requirement
!Measurement Period
|-
|Availability
|The application will be available 99.95% of the time
|Over a year
|-
|Service Desk Response
|75% of help desk calls will be answered in less than a minute
85% of help desk calls will be answered within two minutes
 
100% of help desk calls will be answered within three minutes
|Over a month
|-
|Incident Response Time
|99% of severity 1 tickets will be resolved within three hours
98% of severity 2 tickets will be resolved within eight hours
 
98% of severity 3 tickets will be resolved within three business days
 
98% of severity 4 tickets will be resolved within five business days
|Over a quarter
|-
|Response Time
|85% of TCP replies within 1.5 seconds of receiving a request
99.5% of TCP replies within 4 seconds of receiving a request
|Over a month
|}
 
==Term usage==
The use of the term ''SLO'' is deprecated in [[ITIL]] V3 to Service Level Target, not to be confused with [[service level requirement|Service Level Requirement]] defined in the [[service design]]. However the SLO term is found in various scientific papers, for instance in the reference architecture of the SLA@SOI project,<ref>Jens Happe, Wolfgang Theilmann, Andrew Edmonds, and Keven T. Kearney "A Reference Architecture for Multi-Level SLA Management" in "Service Level Agreements for Cloud Computing", eds. Wieder, Philipp and Butler, Joe M. and Theilmann, Wolfgang and Yahyapour, Ramin, Springer New York, 2011, DOI:10.1007/978-1-4614-1614-2_2</ref> and it is used in the Open Grid Forum document on WS-Agreement.<ref name=":0">Alain Andrieux, Karl Czajkowski, Asit Dan, [[Kate Keahey]], Heiko Ludwig, Toshiyuki Nakata, Jim Pruyne, John Rofrano, Steve Tuecke, Ming Xu "Web Services Agreement Specification (WS-Agreement)", GFD-R-P.107, March 2007, Open Grid Forum.</ref>
 
==References==
 
{{reflist}}
 
==External links==
* [https://sre.google/sre-book/service-level-objectives/ Service Level Objectives]
* [https://www.dynatrace.com/news/blog/what-are-slos/ What are SLOs? How service-level objectives work with SLIs to deliver on SLAs]
* [https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli SLA vs. SLO vs. SLI: What’s the difference?]
 
{{DEFAULTSORT:Service Level Objectives}}
[[Category:IT service management]]
[[Category:Outsourcing]]