What I understand SRE to require
Also in Chinese: 中文版
From tool inventories to problem classes
There are two ways to slice SRE skill. The first is by tools: Kubernetes, Terraform, Prometheus, a cloud provider. That is the entry-level view, and its weakness is immediate — kubectl apply is a commodity. The second slice is by problem classes: which categories of failure can I close, end to end, under time pressure. That is the view this site’s radar is built on.
The test I use for mastery is specific: when the abstraction leaks, can you drill down? Deploying a service is entry level. Tracing a pod stuck in Pending through scheduling constraints, allocatable arithmetic, and node conditions — or tracing an OOM into a memory buffer the engine does not even track — is mastery. Every capability claim on this site should be read against that criterion, which is also why every claim links to an artifact: mastery asserted without a drill-down record is just confidence.
Why these nine axes
The radar’s nine domains are not a taxonomy I found; they are a derivation from what the job is — keeping a system delivering its contract.
Four steady-state delivery domains — Observability, Release & Change, Platform & Automation, Infra & Capacity — together constitute “operating a system”: can you see it, change it without breaking it, automate what repeats, and size it for what is coming. These are the domains with the most mature industry practice, which makes them necessary but not differentiating.
Distributed systems is the intellectual core rather than an operating domain: understanding why systems break in the specific ways they do. Partial failure, overload as arrival rate exceeding service rate, retry amplification, cascading timeouts. Availability itself decomposes into P(no fault) + P(fault) × P(detected fast) × P(recovered or degraded fast) — and that one decomposition quietly justifies half the radar: detection is observability’s term in the product, recovery is incident response’s, and the often-forgotten middle factor is why monitoring can never be a nice-to-have.
Incident response is the time dimension of the whole loop. Everything the delivery domains prepare over weeks gets consumed in minutes, by one person, with incomplete information.
Security is the implicit second contract. Availability promises the system serves; security promises it is not breached. Different threat model, different failure model, and a failure that no rollback undoes — it earns its own axis even on a reliability-centric map.
Data & state is where irreversibility lives. Moving data fails completely differently from moving machines: a bad deploy rolls back, a lost byte does not, and load-time behavior can depend on the accumulated size of the table rather than the size of the batch. Applying stateless reflexes to stateful systems is, in my book, a named anti-pattern.
Influence is the hard gate above senior. Root-cause and prevention work is structurally under-visible, so the capability that unlocks organizational investment is translation: stating technical debt in the organization’s own cost language, with evidence. Engineers who cannot do this cap out at personal excellence regardless of how tall their other axes are.
Why incident response is the moat
Deployment, capacity planning, and toil automation all have mature patterns you can copy — reference architectures, vendor blueprints, other people’s postmortems. What cannot be copied or outsourced is: the service is down at three in the morning, and the question is whether you can localize and recover within twenty minutes. That capability is a compound of every other axis executed under time pressure, which is exactly why it gets its own axis instead of dissolving into the others — the compound is the thing employers are actually buying.
The SRE subset of database operations
Operating stateful engines looks like DBA work but has a clean boundary: the DBA owns the engine’s internals; the SRE owns the service that runs the engine. “Why is this query slow” is DBA territory. “Why is this cluster down, and why won’t it hold the load” is SRE territory.
The SRE side reduces to a five-part skeleton that is deliberately engine-agnostic: (1) deployment topology — what dies when a node dies; (2) failure modes and recovery — the core of the core; (3) the capacity and resource model — where the bottleneck is and what scaling costs; (4) backup with rehearsed restore — an unrehearsed backup is a hypothesis, not a backup; (5) observability — replication lag, queue depth, memory and disk watermarks wired to alerts. Master these five answers for one engine and the next engine is a checklist, not a career change.
There is one grey zone I deliberately claim for SRE: query-level resource governance — memory isolation, queueing, per-query limits. It looks like query tuning, but its purpose is stability (prevent one query from taking down the service), not optimization (make that query faster). Stability mechanisms belong to whoever owns the pager.
Operating monitoring versus building monitoring
The last split corrects a common mislabeling of monitoring as optional infrastructure work. Building the monitoring platform — federation, ingestion pipelines, custom exporters — is a specialist item; it is fine to not master it. Operating monitoring — reading metrics under pressure, writing the query that localizes the fault, designing SLIs, SLOs, and alerts that page on symptoms — is core, full stop. An SRE who cannot read their own telemetry is blind at exactly the moment sight matters most.
One design conviction inside that core: keep four concepts separate — the SLI (what you measure), the histogram (how the distribution is recorded), the quantile (one view into it), and the SLO (the target over a window). I prefer SLI = requests-under-threshold / valid-requests; a bare “P99 ≤ X ms” is a useful observation lens, not the SLI itself.
This framework is what the radar’s nine axes mean. The next two pages apply it: where the evidence says I actually stand, and what I know I cannot do yet.