"Being live" is not an SLO. An SLO is a numerical commitment to the user, with a window and consequence. Without it, every reliability discussion becomes opinion.

This chapter closes the operations section: what to promise, how to measure, when to wake someone up, and how to learn without hunting for blame.

Course seal: applied in an environment with a monthly SLO of 99.5%.

SLI, SLO and SLA

Term	Definition	Example
SLI	measured indicator	% of requests with status < 500 and latency < 500 ms
SLO	target for the SLI	99.5% in 30 days
SLA	contract with consequence	99.5% with credit/penalty
Error budget	error margin	0.5% = ~3h36min per month

SLO is internal and guides decisions. SLA is external and involves money. Never promise an SLA higher than the SLO you measure.

Choosing the SLI

Few and good. For a portal:

1. Availability: proportion of successful requests.
2. Latency: proportion of requests below the limit (not the average).
3. Data quality (when critical): jobs that processed without error.

Avoid:

• pod uptime as an SLI (the user doesn't see pods);
• average latency;
• a metric that nobody can measure this quarter.

Defining the SLO

slo: disponibilidade-api
target: 99.5
window: 30d
sli:
  good: http_requests_total{status!~"5.."}
  total: http_requests_total

PromQL calculation:

sum(rate(http_requests_total{job="portal-backend",status!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="portal-backend"}[5m]))

Burned error budget:

1 - (
  sum(rate(http_requests_total{job="portal-backend",status!~"5.."}[30d]))
  /
  sum(rate(http_requests_total{job="portal-backend"}[30d]))
) / 0.005

99.5% in 30 days = 3h36min of equivalent total downtime.

Burn rate: an alert worth waking someone up for

Alerting on "1 error" generates fatigue. A good alert looks at the consumption speed of the budget:

Burn rate	Window	Action
14.4x	1h	page (wakes up)
6x	6h	urgent ticket
1x	3d	backlog

(
  sum(rate(http_requests_total{job="portal-backend",status=~"5.."}[1h]))
  /
  sum(rate(http_requests_total{job="portal-backend"}[1h]))
) > (14.4 * 0.005)

This reduces noise: 0.1% error in 5 minutes doesn't wake anyone; 5% for an hour does.

On-call that works

• Weekly rotation, with written handoff.
• Runbook per alert: what to check, what to do, how to escalate.
• Ready access: VPN, kubectl, dashboards, logs — tested before the shift.
• One alert, one action. An alert without an action is noise.
• Page only for user symptoms, not for isolated high CPU.

Handoff checklist:

- Open incidents and status
- Deploys in the window
- Silenced alerts and why
- Known risks (disk, capacity, certificate)

Blameless postmortem

Premise: people act with the information they have. The goal is to fix the system, not the person.

Structure:

1. Summary (5 lines).
2. Impact: users, duration, burned SLO.
3. Timeline (minute by minute).
4. Root cause and contributing factors.
5. What worked (detection, rollback, communication).
6. What failed.
7. Actions with owner and deadline.

Rules:

• Written within 72 hours, with those who participated.
• No "human error" as the final cause. The question is: why did the system allow it?
• An action without an owner and date does not exist.
• Shared with the whole team.

Example of a poorly written cause: "the operator deleted the wrong PVC". Useful version: "there was no protection against deletion of production PVC; the command was destructive and without confirmation; there was no recent backup of the volume".

Linking SLO to decisions

• Budget surplus: can accelerate changes.
• Budget burning: prioritize reliability, freeze risky feature.
• Budget exceeded: architecture review, not "work harder".

This turns reliability into a product conversation — and takes SRE out of the eternal firefighter role.

Laboratory

1. Instrument the API with a request counter by status.
2. Create the SLI rules and an SLO dashboard in Grafana.
3. Calculate the remaining budget for the month.
4. Configure a burn rate alert of 14.4x/1h.
5. Inject 500 errors for 10 minutes and see the alert fire.
6. Write a simulated postmortem with a timeline and three actions.
7. Do an on-call handoff in 10 lines.

Common mistakes

Symptom	Cause
Ignored alert	threshold without burn rate
SLO never met	target copied from a larger company
Postmortem becomes blame	focus on person, not system
Action not executed	missing owner/deadline
SLI doesn't measure user	internal metric (pod up)
Infinite budget in practice	nobody looks at the dashboard
On-call without runbook	knowledge only in one person's head

Checklist

• [ ] SLI defined from the user experience.
• [ ] SLO with explicit window and target.
• [ ] Error budget calculated and visible.
• [ ] Alerts by burn rate, not by isolated event.
• [ ] Runbook per critical alert.
• [ ] Rotation and handoff documented.
• [ ] Postmortem within 72h, blameless, with tracked actions.
• [ ] Monthly review of SLO and budget.

Glossary

• SLI: measured indicator.
• SLO: target for the indicator.
• SLA: contract with consequence.
• error budget: allowed failure margin.
• burn rate: speed of budget consumption.
• blameless: analysis without individual blame.
• handoff: shift handover.

Next

Last chapter: DR and capstone. RPO/RTO in practice, restore drills, and the course wrap-up with what to take to production.

Next: Kubernetes Course 28 — DR and capstone