Service-Level Objective (SLO)

A Service-Level Objective (SLO) is an measurable objective of an IT system on a service-level indicator measure.

• AKA: SLO, Service Level Objective, Service Reliability Target.
• Context:
  • It can typically specify Service-Level Performance Targets through service-level performance thresholds.
  • It can typically define Service-Level Reliability Goals through service-level reliability measurements.
  • It can typically establish Service-Level Quality Standards through service-level quality metrics.
  • It can typically enable Service-Level Performance Monitoring through service-level performance trackings.
  • It can typically quantify Service-Level Customer Expectations through service-level performance evaluations.
  • ...
  • It can often serve as Service-Level Agreement Components within service-level contractual frameworks.
  • It can often guide Service-Level Engineering Prioritys through service-level reliability budgets.
  • It can often facilitate Service-Level Performance Measurement through service-level indicator combinations.
  • It can often avoid Service-Level Misunderstandings through service-level performance clarity.
  • It can often help Service-Level Providers manage service-level customer expectations through service-level performance transparency.
  • ...
  • It can range from being a Simple Service-Level Objective (SLO) to being a Complex Service-Level Objective (SLO), depending on its service-level objective complexity.
  • It can range from being a Attainable Service-Level Objective (SLO) to being a Aspirational Service-Level Objective (SLO), depending on its service-level objective achievability.
  • It can range from being a Short-Term Service-Level Objective (SLO) to being a Long-Term Service-Level Objective (SLO), depending on its service-level objective timeframe.
  • It can range from being a Single-Metric Service-Level Objective (SLO) to being a Composite Service-Level Objective (SLO), depending on its service-level objective measurement composition.
  • It can range from being a Internal-Facing Service-Level Objective (SLO) to being a Customer-Facing Service-Level Objective (SLO), depending on its service-level objective stakeholder visibility.
  • ...
  • It can integrate with Service-Level Monitoring Systems for service-level objective tracking.
  • It can connect to Service-Level Alerting Systems for service-level objective violation notification.
  • It can support Service-Level Reporting Systems for service-level objective compliance assessment.
  • ...
• Examples:
  • Service-Level Availability Objectives, such as:
    • Service-Level Uptime Objectives, such as:
      • 99.9% Service-Level Uptime Objective (SLO) for service-level three-nines availability measured over service-level monthly periods.
      • 99.99% Service-Level Uptime Objective (SLO) for service-level four-nines availability measured over service-level quarterly periods.
    • Service-Level Downtime Objectives, such as:
      • Maximum Monthly Service-Level Downtime Objective (SLO) for service-level downtime allowance.
      • Mean Time Between Failures Service-Level Objective (SLO) for service-level failure frequency.
  • Service-Level Performance Objectives, such as:
    • Service-Level Response Time Objectives, such as:
      • 95% Service-Level Response Time Objective (SLO) where service-level customer service calls are answered within service-level 20-second thresholds.
      • Sub-200ms Service-Level Response Time Objective (SLO) for service-level latency requirements.
    • Service-Level Throughput Objectives, such as:
      • Requests-per-Second Service-Level Throughput Objective (SLO) for service-level capacity requirements.
      • Transaction Volume Service-Level Objective (SLO) for service-level processing capacity.
  • Service-Level Quality Objectives, such as:
    • Service-Level Error Rate Objectives, such as:
      • Maximum 0.1% Service-Level Error Rate Objective (SLO) for service-level error tolerance.
      • Service-Level Success Rate Objective (SLO) for service-level operation reliability.
    • Service-Level Application Responsiveness Objectives, such as:
      • Service-Level User Satisfaction Objective (SLO) for service-level experience quality.
      • Service-Level Data Consistency Objective (SLO) for service-level data accuracy.
  • Service-Level Capacity Objectives, such as:
    • Service-Level Concurrent User Objectives, such as:
      • 10,000 Concurrent Users Service-Level Capacity Objective (SLO) for service-level user scalability.
      • 1 Million Daily Active Users Service-Level Capacity Objective (SLO) for service-level platform capacity.
    • Service-Level Storage Capacity Objectives, such as:
      • 99.9% Service-Level Storage Availability Objective (SLO) for service-level data accessibility.
      • Petabyte-Scale Service-Level Storage Objective (SLO) for service-level data capacity.
  • ...
• Counter-Examples:
  • Service-Level Indicator (SLI)s, which measure actual service-level performance values rather than defining service-level target values.
  • Service-Level Agreement (SLA)s, which encompass broader service-level contractual commitments rather than specific service-level measurement targets.
  • OKR Objectives, which track general organizational goals rather than specific service-level performance standards.
  • Key Performance Indicator (KPI)s, which monitor general business performance metrics rather than specific service-level reliability targets.
• See: Service-Level Indicator (SLI), Service-Level Agreement (SLA), Error Budget, Site Reliability Engineering (SRE), Performance Metric, Service Reliability, Quality of Service (QoS), SMART Objective Criteria.

---

---

References

2022

• (Wikipedia, 2022) ⇒ https://en.wikipedia.org/wiki/Service-level_objective Retrieved:2022-6-6.
  • 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 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.

2021

• (Wikipedia, 2021) ⇒ https://en.wikipedia.org/wiki/Service-level_objective#Overview Retrieved:2021-2-22.
  • 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.

    The SLO may be composed of one or more quality of service (QoS) measurements (service level indicators, SLIs) 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 QoS measures into an SLO achievement value will depend on the nature and architecture of the service.

2020

• (Wikipedia, 2020) ⇒ https://en.wikipedia.org/wiki/Service-level_objective#Examples Retrieved:2020-8-5.
  • Sturm and Morris argue that SLOs must be:
    • Attainable
    • Repeatable
    • Measurable
    • Understandable
    • Meaningful
    • Controllable
    • Affordable
    • Mutually acceptable
  • While Andrieux et. al. 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". 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. 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.
    • 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.

    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. 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 ACD system". Results can be reported as a percent of time that the target answer time was achieved and then compared to the desired service level (90%).

---