Mastering SLA, SLO, and SLI: Practical Strategies for Reliable Services

1. Service Quality Terminology

If you cannot measure the importance and correctness of system behaviors, you cannot operate the system reliably. Both external services and internal APIs need clear service quality goals.

We define Service Level Indicator (SLI), Service Level Objective (SLO), and Service Level Agreement (SLA) based on historical experience, subjective judgment, and service understanding.

1) Service Level Indicator (SLI)

Definition: a specific quantitative metric of a service’s quality.

Common SLIs include:

Availability (percentage of successful responses)

Request latency 99th percentile (TP99)

Throughput (requests per second)

Durability (data retention time, often for storage systems)

2) Service Level Objective (SLO)

Definition: the target value or range for a specific SLI.

Benefits of setting SLOs:

Provides predictable service quality for clients, simplifying system design.

Helps providers define standards, manage resources, and balance cost/benefit.

Improves risk control and enables faster, correct responses during incidents.

Choosing an appropriate SLO is complex; often a concrete value cannot be determined. For external APIs, you may set a TP99 target (e.g., TP99 < 20 ms ) to encourage performance optimization.

3) Service Level Agreement (SLA)

Definition: a formal (or informal) agreement between service and user describing consequences of meeting or missing SLOs, which may be financial or otherwise.

A simple way to differentiate SLO from SLA: ask “What happens if the SLO is not met?” If no explicit consequence is defined, it is an SLO, not an SLA.

4) Cloud Service Level Agreement (CSLA)

See Chapter 3 for details.

2. SLO Practice Cases

1) Service Grading & Core Interface Grading

Grading rules:

Applications are graded 0‑3 based on business impact.

Within an application, interfaces are further graded 0/1; many historical interfaces are non‑core.

Purpose:

Core services must follow stricter standards (code review, release process, change control, high‑traffic governance).

Alerting is based on service grade.

Different grades have different SLO requirements (e.g., circuit‑breaker capability).

Key issues and solutions:

Inconsistent full‑link grading: Promote downstream updates to align grades.

Inconsistent interface grading: Trace from user perspective to assess impact.

Inaccurate interface availability: Ensure errors are not swallowed; implement true availability monitoring.

2) SLI Practice Application

Select APIs representing core business functions, grade them, and define 3‑5 representative metrics such as TP50/TP90/TP99, availability, and call volume.

Only metrics that truly reflect user‑perceived quality should become SLIs; too many metrics dilute focus.

3) SLO Practice Application

Start from what users care about, not just what can be measured. Define SLOs with clear measurement methods and conditions, e.g., “99% of requests complete within 200 ms over a 1‑minute window.”

Guidelines:

Do not aim for perfection initially; set a relaxed target and tighten over time.

Leave a safety buffer: use stricter internal SLOs and slightly looser external SLOs.

4) SLA Practice Application

R&D teams coordinate with product owners to reach internal agreements via email; external cloud providers use contractual SLAs with compensation clauses.

3. Cloud Service Agreements (optional)

National standards and various cloud vendor SLAs (JD Cloud, Alibaba Cloud, AWS, Google Cloud, Huawei Cloud, Tencent Cloud) are listed with reference images.

4. API Gateway Service Agreements

Examples of SLA definitions from JD Cloud, Alibaba Cloud, and Amazon API Gateway are shown.

5. SLO‑Based Alert Governance

SLOs are key for reliability decisions. Alerts should be filtered to focus on events that consume error budget.

Alert configuration principles:

Set thresholds based on critical SLI values (e.g., availability < 99.95% for 3 consecutive minutes triggers a critical alert).

Use a “tight‑then‑loose” approach: start with strict thresholds, then relax as stability improves.

Tailor alerts to business scenarios and system characteristics.

1) API Alert Configuration

Combine availability, TP99, and call volume to evaluate alerts. Example thresholds:

Critical: availability < 99.95% (3 consecutive breaches) or TP99 ≥ 200 ms.

Warning: availability < 99.99% (30‑minute window) or TP99 ≥ 100 ms.

Call‑volume alert when calls exceed a defined limit for 3 consecutive minutes.

2) MQ Alert Configuration

Monitor producer‑to‑MQ latency, consumer backlog, and processing logic. Define thresholds based on total processing time formula T(3) > T(1)+T(2.1)+T(2.2) and validate via stress testing.

3) Scheduled‑Task Alert Configuration

Ensure monitoring windows match task schedules; trigger alerts when tasks do not execute as expected.

6. Q&A

1) Relationship between SLA, TP99, and timeout

TP99 is observed via monitoring; SLA may promise TP99 ≤ 20 ms with a 6 ms buffer. Timeout should be set above TP99 (e.g., TP99 200 ms → timeout 300‑400 ms).

2) How departmental availability is calculated

Aggregate individual service downtimes weighted by business impact: availability = 1 – (total weighted downtime / total period).

3) Cloud host & API gateway availability calculation

Calculate based on incident duration and impact factor; discuss acceptable reliability levels and business implications.

7. Technical vs Business Metrics

Technical metrics (availability, TP99) affect business metrics (data correctness, completeness). Failures in technical metrics inevitably cause business metric failures, but not vice‑versa.

8. Using SLA to Prepare for 11.11 Promotion

Steps include defining clear service goals, creating a battle‑plan, conducting full‑link stress tests, establishing monitoring & alerting, prioritizing incidents, fostering cross‑team collaboration, and performing post‑event reviews.

Appendix

1) Sample SLO Document

Overview of services (API, MQ), measurement notes, and warnings about metric limitations.

2) Cloud Service Level Indicators

Reference diagram of common cloud SLA metrics.

For any inaccuracies, readers are encouraged to provide feedback.