| name | reliability-engineering-cloud |
| description | Reliability engineering for cloud systems — SLIs, SLOs, error budgets, SRE practices, runbooks, incident response, on-call rotation, blameless postmortems, chaos engineering, and the NASA Systems Engineering methodology (MCR/SRR/PDR/CDR/ORR phase gates, TAID verification, requirements tracing) adapted to cloud operations. Use when establishing SLOs for a new service, running an incident, writing a runbook, preparing a launch readiness review, or bringing NASA SE discipline to cloud deployments. |
| type | skill |
| category | cloud-systems |
| status | stable |
| origin | tibsfox |
| modified | false |
| first_seen | "2026-04-12T00:00:00.000Z" |
| first_path | examples/skills/cloud-systems/reliability-engineering-cloud/SKILL.md |
| superseded_by | null |
Reliability Engineering for Cloud
Reliability is a property of a system, not of any individual component. A cloud service that meets its availability target is not necessarily built from components that individually meet their target — it is built from a system that absorbs component failures without exposing them to users. This skill covers the SRE toolkit (SLIs, SLOs, error budgets, runbooks, postmortems, chaos engineering) alongside NASA's Systems Engineering methodology for design reviews and verification, because cloud operations at serious scale have to borrow discipline from somewhere, and aerospace is the field that has been figuring this out the longest.
Agent affinity: gray (transaction processing reliability, ACID foundations), hamilton-cloud (SRE economics at AWS scale), lamport (formal safety arguments)
Concept IDs: cloud-se-phase-reviews, cloud-taid-verification, cloud-runbook-structure, cloud-procedure-execution, cloud-communication-loops
Service Level Indicators, Objectives, and Agreements
SLI (Service Level Indicator). A quantitative measure of some aspect of service behavior. Examples: fraction of requests that succeed, fraction of requests served in under 200 ms, bytes delivered, freshness of returned data.
SLO (Service Level Objective). A target for an SLI over a window. "99.9% of requests succeed over a 30-day window." SLOs are set internally by the team that operates the service.
SLA (Service Level Agreement). A contractual commitment, typically looser than the SLO, with financial consequences for violation. SLAs are customer-facing; SLOs are the internal discipline that prevents you from ever needing to pay out on an SLA.
Choosing SLIs
Good SLIs are:
- User-centric. Measure what users experience, not internal plumbing.
- Ratio-based. Expressed as "good events / total events" so they are interpretable across traffic levels.
- Implementable. Can be measured from existing data without instrumenting every code path.
Typical SLIs for a request/response service:
- Availability: fraction of non-5xx responses.
- Latency: fraction of responses under X ms.
- Quality: fraction of responses returning full results (not degraded).
Error Budgets
The error budget is the inverse of the SLO. If the SLO is 99.9% availability, the error budget is 0.1% — about 43 minutes per month of downtime.
Error budgets are the unit of negotiation between "ship features" and "improve reliability." When the error budget is being spent faster than planned, the response is to slow feature velocity and address reliability. When the error budget is being preserved, new features and risk-taking are encouraged. This removes the "SRE says no, developers say yes" political argument and replaces it with a shared metric.
