{
  "uid": "cogitave.learn.reliability-and-sre.introduction",
  "kind": "moduleUnit",
  "href": "/modules/reliability-and-sre/introduction/",
  "title": "Introduction",
  "summary": "",
  "type": null,
  "products": [],
  "roles": [],
  "levels": [],
  "subjects": [],
  "headings": [
    "Reliability is a budgeted feature, not an absolute",
    "What this standard sits on top of",
    "What you will get from this module"
  ],
  "source": "Every service Cogitave runs will eventually fail some request. The question the\n[reliability standard](../../../../standards/docs/standards/reliability.md) makes\nyou answer in advance is not *whether* that happens, but **how much of it is\nacceptable, and what happens the moment it isn't**.\n\n## Reliability is a budgeted feature, not an absolute\n\nThe standard's thesis: 100% is the wrong target for everything. It is\nunaffordable, it makes change impossible, and a user cannot tell the difference\nbetween 100% and the nines their experience actually needs. So the job of SRE is\nnot to prevent every failure - it is to **spend a measured, agreed amount of\nunreliability** on the velocity that ships value, and to **stop spending** the\ninstant the budget runs out. The **SLO** is the number that makes that trade\nexplicit; the **error budget** is the currency; the **error-budget policy** is the\nlaw that the currency buys real decisions, not just a dashboard.\n\n> [!IMPORTANT]\n> This is why SRE is an **engineering discipline**, not a renamed ops rota. A\n> service that stays up only because a human watches it around the clock is\n> **not** reliable - it is unfunded debt. Cogitave is a small remote team with no\n> 24/7 wall-of-screens shift, so automation, not headcount, is the only\n> sustainable model.\n\n## What this standard sits on top of\n\nThe reliability standard does not redefine measurement or incident response - it\n**consumes** them. SLIs and telemetry come from\n[observability](../../../../standards/docs/standards/observability.md); a\nburn-rate page runs as an incident under\n[ops/incident-response](../../../../ops/incident-response/docs/incident-response-plan.md);\ndisaster scenarios and DR game-days come from\n[ops/business-continuity](../../../../ops/business-continuity/README.md). What it\n**adds** is the error-budget policy itself, sustainable on-call, the toil cap,\ncapacity planning, and chaos engineering - the subject of this module.\n\n## What you will get from this module\n\nA working ability to set a service's SLO, compute the error budget it buys, and\nsay exactly what happens - to velocity, to on-call, to the roadmap - once that\nbudget is spent.\n",
  "partOf": "cogitave.learn.reliability-and-sre",
  "durationInMinutes": 4,
  "quiz": null
}