SRE
205 bites tagged SRE — interview questions with model answers, and 60-second explainers.
Fixing a noisy non-actionable alert
Review the data to see if it is ever actionable, then tune threshold or duration, re-target at user-facing symptoms, or delete it. treating alert noise as a fixable problem, not just muting.
First steps on a p99 latency page
Confirm scope and blast radius, check recent changes and deploys, then look at dependencies and resource saturation. a structured triage instinct, not random poking. diving into code or restarting things before scoping impact.
Symptom-based versus cause-based alerting
Symptom alerts fire on user impact like high error rate or latency; cause alerts fire on internal conditions like high CPU. Page on symptoms, treat causes as diagnostic. understanding why user-facing symptoms make better pages.
Launching a risky feature with no error budget left
Bring burn history, what consumed the budget, blast radius, and rollback safety; offer mitigations like flags and canaries. Using error budgets for negotiation, not dogma. A flat veto or a rubber-stamp yes with no data.
Handling planned maintenance in SLOs and error budgets
Either charge maintenance to the error budget or formally exclude it via a maintenance window; each trades honesty against fairness. Honest accounting of planned downtime.
Defining SLOs for a new critical service
Start from user journeys, pick SLIs, involve product, engineering, and business stakeholders, set realistic targets iteratively. Cross-functional SLO design.
What is an error budget?
Error budget is one minus the SLO, the allowed unreliability; it gates feature velocity versus reliability work. Linking reliability targets to delivery decisions.
Relationship between SLI, SLO, and SLA
SLI is the measured metric, SLO is the internal target for that metric, SLA is the external contract with consequences. Core reliability vocabulary. Treating the terms as synonyms or making the SLO looser than the SLA.
Symptom-based vs cause-based alerting
Symptom alerts fire on user-visible impact, cause alerts on internal conditions; page on symptoms to cut noise and catch unforeseen failures. Alerting philosophy and pager hygiene.
Black-box vs white-box monitoring for legacy apps
Black-box probes from outside, white-box reads internal state; start black-box for fast user-facing signal. Pragmatic monitoring strategy. Choosing white-box first on an uninstrumented system or ignoring black-box blind spots.
What are the Four Golden Signals?
Name latency, traffic, errors, and saturation; explain each briefly; describe measuring latency as a distribution separating success from failure. knowledge of the core user-facing monitoring signals.
SRE vs traditional ops on a recurring alert?
Traditional ops repeatedly handles the alert manually and scales by adding people; SRE treats it as a bug, automates or eliminates the root cause, and scales sublinearly. whether you grasp the software-engineering mindset of SRE.
How do you find and eliminate toil systematically?
Inventory and measure toil via time tracking or ticket analysis, prioritize by frequency times cost versus automation effort, automate highest-ROI items, measure success… a measurable, prioritized approach to reducing operational toil.
How do SRE and DevOps relate?
DevOps is a broad culture of breaking down silos; SRE is one prescriptive way to do it with specific practices. whether you see SRE as a concrete implementation of DevOps principles, not a rival.
What defines toil, with an example?
Define toil as manual, repetitive, automatable, tactical, no-enduring-value, scaling-with-growth work; distinguish it from overhead; give a concrete example. whether you can identify operational work worth automating away.
Hiring for SRE
Hiring for SRE seeks engineers who blend software-development skill with systems and operations depth, plus strong debugging and incident temperament. The hardest part is finding people who can both write automation and reason about failure at scale under…
Review of Reviews (Postmortem Metrics)
A meta-process that audits the quality and follow-through of postmortems themselves, tracking metrics like action-item completion, time-to-close, and recurrence of incidents.
The Second Story of an Incident
The first story blames human error and stops there; the second story asks why the action made sense to the person at the time and what systemic conditions enabled it. Seeking the second story is the heart of blameless, learning-oriented incident analysis.
Counterfactual Reasoning in Incident Analysis
Counterfactual reasoning asks what would have prevented or mitigated an incident: if this alert had existed, if this check had run. Used well it finds systemic gaps, but it is a trap when it implies a single person should have just acted differently in…
Actionable Remediation Items
Actionable remediation items are specific, owned, trackable follow-ups from a postmortem that prevent recurrence or improve response. Good ones are concrete and assigned with a due date; vague items like be more careful are non-actionable and predictably…
Postmortem Report Template
A postmortem template is a standard structure for documenting an incident: summary, impact, timeline, root cause, what went well and poorly, and action items.
Incident Timeline Reconstruction
Timeline reconstruction is the after-the-fact process of merging evidence from logs, metrics, deploys, and chat into one accurate sequence of what happened.
War Room in Incident Response
A war room is a dedicated space, physical or virtual, where responders coordinate during a major incident. It centralizes communication and decision-making under a defined incident commander, cutting confusion and duplicated effort, but should be reserved for…
Runbooks
A runbook is a documented, step-by-step procedure for handling a specific operational task or known failure, such as responding to an alert. It captures expert knowledge so any on-call engineer can act quickly and consistently, reducing reliance on tribal…
Get SRE bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.