{
  "uid": "cogitave.learn.observability-and-reliability.reliability-and-slos",
  "kind": "moduleUnit",
  "href": "/modules/observability-and-reliability/reliability-and-slos/",
  "title": "Reliability and SLOs",
  "summary": "",
  "type": null,
  "products": [],
  "roles": [],
  "levels": [],
  "subjects": [],
  "headings": [
    "The thesis: reliability is a budgeted feature",
    "SLO, error budget, burn rate",
    "Alert on the burn, page on the symptom",
    "The error-budget policy: the rule with teeth"
  ],
  "source": "Measurement tells you how the system is doing. **Reliability engineering** is what\nyou do about it. The\n[reliability standard](../../../../standards/docs/standards/reliability.md)\nconsumes the SLIs and telemetry from observability and adds the engineering\ndiscipline on top.\n\n## The thesis: reliability is a budgeted feature\n\nThe standard's core claim is that **reliability is a feature with a budget, not\nan absolute**. 100% is the wrong target: it is unaffordable, it makes change\nimpossible, and users cannot tell the difference between 100% and the nines their\nexperience actually needs. So the job is not to prevent every failure - it is to\n**spend a measured, agreed amount of unreliability** on the velocity that ships\nvalue, and to **stop spending** the moment the budget is gone.\n\nThis is why SRE is an **engineering discipline, not a renamed ops rota**. A\nservice that stays up only because a human watches it 24/7 is not reliable; it is\nunfunded debt.\n\n## SLO, error budget, burn rate\n\nThree definitions do the work:\n\n- An **SLO (Service Level Objective)** is a target for an SLI, set from the\n  **critical user journey** - the thing a customer would open a ticket about -\n  expressed as `good events / valid events` over a rolling window. Each service\n  ships with three minimum: availability, latency (p99 of the journey), and\n  correctness/error-rate.\n- The **error budget** is the math: `(1 - SLO) x valid events in the window`,\n  tracked as budget remaining. At **99.9% over 30 days** the budget is 0.1% -\n  about **43 minutes** of allowed downtime.\n- The **burn rate** is how fast you are spending it: rate `1.0` spends the whole\n  window's budget exactly over the window; rate `14.4` spends it in about 50 hours.\n\nThe inherited tier targets are **Tier-1 99.9%** (~43 min/month), **Tier-2 99.5%**,\nand **Tier-3 99.0%** or an explicit no-SLO note. Any other value is a design-class\ndeviation that needs an Accepted RFC.\n\n## Alert on the burn, page on the symptom\n\nSLO alerts are **burn-rate** alerts, not static thresholds, and use **paired\nlong+short windows**: the long window sets severity, the short window must also\nbe firing so a spike that already recovered does not page. You **page** for fast\nburns only; slow burns become **tickets**. The anti-fatigue rule is strict: a\nservice **must not page on a metric that is not in a user's SLO** - the pager is\nreserved for symptoms the user feels.\n\n## The error-budget policy: the rule with teeth\n\nAn SLO with no consequence is a dashboard. The **error-budget policy** is the\nload-bearing rule, agreed in advance so the decision at breach is mechanical, not\npolitical:\n\n> **Budget healthy** -> normal velocity, ship freely behind the deployment gates.\n> **Budget exhausted** (or projected to exhaust before the window closes) ->\n> **per-service feature freeze**: only reliability fixes, rollbacks, and\n> security/critical patches deploy, and reliability work goes to the top of the\n> backlog until the budget recovers.\n\nThe freeze is **enforced in the pipeline**, not by good intentions, and one named\n**reliability champion** owns the weekly freeze/thaw call. [ADR-0020](../../../../standards/docs/decisions/0020-reliability-and-secure-sdlc.md)\nrecords the decision that the error budget gates release velocity. Two rules in\nthe standard are **non-deviable** - they may be strengthened, never relaxed: the\nfreeze on an exhausted budget, and the rule that a **published SLA is always\nstrictly looser than the SLO** that backs it. That gap is the operating margin\nthat lets the team react to a burn before the customer-facing promise breaks.\n\n> [!NOTE]\n> The freeze is **per-service**: one service's blown budget does not freeze\n> unrelated services, and a security or critical-severity fix is always exempt -\n> a freeze never blocks a change that improves safety.\n",
  "partOf": "cogitave.learn.observability-and-reliability",
  "durationInMinutes": 8,
  "quiz": null
}