A set of principles for designing how systems behave under failure.
Reliability Engineering treats failure as a design problem: what can break, what the user sees when it does, and how the system degrades.
A Reliability Engineer applies these principles to decide this in advance, not during incidents.
The question is not "what happens to the server", but "what does the user see and lose". Reliability is defined not by internal metrics, but by whether a person can do their job.
Every critical component has a designed failure scenario. Not "what might break", but "what will happen when it breaks and how the system will behave".
A system that works worse is more useful than a system that doesn't work at all. Degradation is not a bug — it's a designed state. It has levels, defined behavior, and communication with the user.
If something isn't working, the user should know. No searching, no status pages, no guessing. Feedback about problems is available where the user already is. Part of the resolution can be delegated to the user — if you explain honestly what's going on.
Default settings are the most tested. Every deviation is a new failure surface, a new component that needs to be understood, maintained, and have its own failure scenario. Deviate deliberately, document the deviation, assign an owner.
A reliability knowledge base is not essays or a 50-page Confluence. It's short, specific specifications: what to do, what not to do, what to expect. Write like a spec for an engineer, not an article for a blog. One component — one document — two screens maximum.
New code, AI-generated code, hypotheses — all of it lives in an isolated sandbox. Code in the sandbox has an expiration date. Production only gets what has been verified and understood. Chaos is contained to its territory; production stays predictable.
Small teams. Startups and small products with no dedicated SRE, no budget for a platform team — but with users who will leave if the service lets them down.