Introduction
Every service you run will eventually fail some request. Reliability engineering makes you answer, in advance, not whether that happens but how much of it is acceptable, and what happens the moment it isn't. Cogitave's reliability standard is one org's written answer to exactly that, and this module uses it as the worked example.
Reliability is a budgeted feature, not an absolute
The thesis: 100% is the wrong target for everything. It is unaffordable, it makes change impossible, and a user cannot tell the difference between 100% and the nines their experience actually needs. So the job of SRE is not to prevent every failure - it is to spend a measured, agreed amount of unreliability on the velocity that ships value, and to stop spending the instant the budget runs out. The SLO is the number that makes that trade explicit; the error budget is the currency; the error-budget policy is the law that the currency buys real decisions, not just a dashboard.
IMPORTANT
This is why SRE is an engineering discipline, not a renamed ops rota. A service that stays up only because a human watches it around the clock is not reliable - it is unfunded debt. Cogitave, for instance, is a small remote team with no 24/7 wall-of-screens shift, so automation, not headcount, is the only sustainable model.
What a reliability discipline sits on top of
A reliability discipline does not redefine measurement or incident response - it consumes them. In Cogitave's estate, SLIs and telemetry come from observability; a burn-rate page runs as an incident under ops/incident-response; disaster scenarios and DR game-days come from ops/business-continuity. What it adds is the error-budget policy itself, sustainable on-call, the toil cap, capacity planning, and chaos engineering - the subject of this module.
What you will get from this module
A working ability to set a service's SLO, compute the error budget it buys, and say exactly what happens - to velocity, to on-call, to the roadmap - once that budget is spent.