SRE Practitioner common mistakes
SRE Practitioner · Understand the traps and how to avoid them.
When asked how a team should reduce toil, the candidate answers with a tool purchase or 'hire more on-call engineers' rather than describing a toil measurement and reduction process.
Scenarios about culture and toil read like operational problems, so candidates reach for the familiar reflex of adding monitoring or headcount instead of addressing the underlying manual, repetitive work.
What to do instead
Answer with the mechanism: define toil (manual, repetitive, automatable, tactical, no enduring value), measure it as a percentage of each SRE's week, set an explicit ceiling (commonly 50%), then rank automation candidates by frequency x time cost x scalability and track the toil budget over time.
The candidate frames the error budget policy as a punitive, org-wide consequence - for example 'if the budget is burned, freeze every team's releases' - and assigns blame to the owning engineer.
Error budgets are easy to remember as a club to swing, and candidates conflate the policy's enforcement step with a performance-management tool rather than a pre-agreed trade-off between reliability and feature velocity.
What to do instead
Describe the policy as negotiated in advance and signed off by product and engineering leadership, with consequences scoped to the affected service's release pipeline, and reliability work prioritized above new features for that service until the budget recovers. Postmortems stay blameless; accountability attaches to actions and systems, not individuals.
The candidate answers organizational-adoption questions ('how do we get buy-in', 'who should own SLOs') with a technical deliverable such as building a dashboard or publishing a runbook.
Most candidates are practitioners who have solved reliability problems technically; org questions feel vague, so they convert them into the artifact they know how to produce.
What to do instead
Name the stakeholders and the artifacts of governance: a product owner who co-owns the SLO, a recurring SLO review cadence, a documented error budget policy, an explicit engagement model (embedded, consulting, or enablement) and a stated sequence of which critical user journeys are onboarded first. State the incentive change, not the tool.
The candidate proposes standing up a centralized SRE team that owns reliability for every service at once, or recommends a top-down reorganization as the first step of adoption.
Centralized SRE is the most widely known model, so it becomes the default answer even when the scenario describes a large, heterogeneous estate with low organizational trust.
What to do instead
Recommend a phased model tied to criticality: start with a small number of high-value user journeys, establish SLIs, SLOs and error budgets there, then scale through enablement, documentation and platform-provided defaults, letting teams with high reliability maturity self-serve. Address staffing ratios and on-call rotation design explicitly.
When defining SLIs, the candidate picks an infrastructure signal such as CPU utilization, pod restarts or a single service's internal error count, and sets the SLO target at 100%.
These are the metrics that appear on traditional host dashboards, and a 100% target feels like the obviously correct aspiration; the user-journey framing of SLIs is easy to state in the abstract but hard to apply under time pressure.
What to do instead
Define the SLI as a ratio of good events to total valid events measured as close to the user as possible (e.g. successful, sufficiently fast requests served, over all valid requests), state the measurement point and the threshold for 'good', and set the target below 100% so a non-zero error budget exists to spend on releases and risk.
The candidate designs error budget alerting as a single static threshold, such as paging when the monthly budget reaches 100% consumed or when the SLO is missed for a day.
Static threshold alerting is the reflex carried over from infrastructure monitoring, and burn-rate math is one of the least intuitive parts of the SLO toolkit, so candidates substitute the alerting model they already know.
What to do instead
Describe multi-window, multi-burn-rate alerting: a fast-burn page that detects consuming a large fraction of the budget within an hour or so using a short and a long window together, plus a slower ticket-level alert for sustained low-grade burn. Explain that the window pair controls both detection latency and false positives.
Answering zero-trust design questions with perimeter controls - 'put it behind the VPN and the WAF', 'the internal network is trusted' - and treating zero trust as a product to be purchased.
Perimeter security is the dominant historical mental model, and the phrase 'zero trust' is heavily marketed as an appliance or a vendor category rather than an architectural principle.
What to do instead
Answer with identity-based controls per request: authenticated and authorized every call regardless of network location, least privilege and short-lived credentials, workload identity with mutual TLS between services, assume-breach segmentation, and reliability practices (SLOs, canarying, chaos experiments) applied to the security controls themselves so they fail safe and are tested.
The candidate proposes to instrument later - 'add logging once it's in production' - and answers observability questions only with metrics dashboards, showing no plan for trace context propagation, sampling strategy or high-cardinality structured events.
Observability is often learned as an operations afterthought and as a metrics-and-dashboards discipline; time pressure in a scenario makes candidates skip the developmental side.
What to do instead
Treat instrumentation as part of the definition of done: propagate trace context across service and queue boundaries, emit structured events rather than free text, choose a sampling strategy that preserves all errors and slow traces (tail-based), and agree the SLIs and dashboards before launch so new code is observable by construction.
Diagnosing distributed latency from averages or from a single aggregate error rate, without breaking the request down per hop or per percentile, and without correlating traces to logs and metrics.
Host-centric monitoring traditions report means and aggregate counts; averages hide tail latency, and candidates default to the single graph they are used to reading.
What to do instead
Use percentiles (p50/p95/p99) against the SLI threshold, use span-level breakdowns to locate the slow or failing hop, and pivot from an exemplar on a metric or a slow trace into the correlated logs via trace ID. State explicitly which sampling policy keeps the interesting traces.
The candidate proposes ML-driven anomaly detection or fully automated remediation as a replacement for SLO-based alerting, with no discussion of data quality, label cardinality, retention or the cost of false positives.
AIOps is presented commercially as a plug-in intelligence layer, so candidates skip the unglamorous prerequisite that predictive systems are only as good as the curated telemetry pipelines feeding them.
What to do instead
Sequence the answer: fix the data first (consistent labels and schemas, controlled cardinality, retention, join-ability across metrics, logs and traces), tie any prediction or anomaly signal back to user-visible SLO impact, keep a human in the loop, and expand automation gradually only after measuring precision, recall and the operational cost of false positives.
Describing a golden-path platform as a mandate - 'all teams must use the standard pipeline' - with no product ownership, no self-service, and no measurement of developer adoption or lead time.
Platform engineering is often framed as standardization and compliance, so candidates emphasize enforcement and forget that internal platforms succeed or fail as products with voluntary adoption.
What to do instead
Treat developers as customers: define the paved road with sensible defaults, provide escape hatches, deliver self-service with guardrails rather than tickets, embed reliability and observability defaults into templates, and measure adoption, time-to-first-deploy, change lead time and platform SLOs as the platform's own success criteria.
Proposing chaos engineering as 'break something in production and see what happens', with no hypothesis, no defined steady state, no blast-radius control and no abort condition.
Chaos engineering is memorable for the dramatic demonstrations and easy to reduce to a stunt; the experimental discipline behind it is the part candidates skip.
What to do instead
Describe the experiment formally: a hypothesis about steady state expressed in SLIs, a minimal blast radius (small percentage of traffic or a single instance), a controlled start in a non-production or limited environment, pre-agreed abort conditions, and a progression from known failure modes (instance death, latency injection) toward more complex ones, with findings fed back into SLOs and runbooks.
In a major incident scenario, the candidate has the incident commander debugging the system hands-on, or omits a communication cadence and a timeline, and later describes the postmortem as finished once the document is written.
Strong engineers default to fixing, and the role separation and comms structure of incident command are process knowledge that is rarely practiced outside formal programs.
What to do instead
Separate roles explicitly - incident commander, communications lead, operations lead, scribe - with severity levels that determine escalation and update cadence. The commander coordinates and decides, not debugs; a stakeholder update goes out on a fixed interval; the timeline is captured live; and the postmortem is complete only when each action item has an owner, a due date and tracking to closure.