SRE
205 bites tagged SRE — interview questions with model answers, and 60-second explainers.
Distinguishing toil from necessary ops work
Toil is manual, repetitive, automatable, tactical, and scales with growth; engineering and judgment-heavy work is not toil. Defining toil precisely. calling all ops work toil, or thinking toil means unimportant work.
Automating a recurring manual cache clear
Recognize the repetitive manual task, document the runbook, then automate it into the deploy pipeline as a post-deploy hook with monitoring. Eliminating toil.
Reviewing a large-scale cascading outage
Dedicated facilitator, cross-team timeline reconciliation, map cascade chains and multiple contributing factors, layered action items. Scaling the review to a complex outage.
Measuring post-incident review effectiveness
Track action-item completion and age, repeat-incident rate, time-to-publish, and MTTR trend. Treating the review process as a measurable system.
Fixing an unmanaged post-mortem action backlog
Generate fewer, higher-leverage items targeting systemic risk; assign owners and dates; integrate into normal planning with explicit prioritization. Making action items actually land.
Proximate cause versus root cause
Proximate cause is the immediate trigger, root cause is the systemic condition that allowed it; fix the root to prevent recurrence. Distinguishing trigger from underlying cause.
Resolving post-mortem disagreement with data
Anchor the debate in the timeline, deploy events, traces, and metrics; correlate cause and onset; allow multiple contributing factors. Fact-based facilitation. resolving by seniority or opinion instead of evidence.
Why 'human error' is not a root cause
Human error is a starting symptom; ask why the system allowed it, find missing guardrails. Systems thinking over blame. accepting human error as the conclusion and prescribing be more careful.
Why blameless culture matters for reviews
Blame causes people to hide facts, so reviews miss systemic causes; blamelessness surfaces honest detail. Link between culture and signal quality. dismissing it as soft or thinking fear improves accountability.
The 5 Whys root cause technique
Repeatedly ask why to move from symptom to systemic cause, stop at an actionable systemic fix. Iterative root-cause analysis. stopping at a surface symptom or treating five as a rigid count, landing on human error.
Essential sections of a post-mortem
Summary, impact, timeline, root cause, lessons, and owned action items, each with a clear purpose. Post-mortem structure. a narrative with no timeline or no concrete, tracked follow-ups.
Designing a safe chaos engineering exercise
Form a hypothesis, define steady state and blast radius, inject failure, observe response, with abort and rollback safeguards. Disciplined chaos experiments.
Architecting a single source of truth for incidents
One curated view overlaying golden metrics, deploy/change events, and active alerts on a shared timeline, fed by standardized telemetry. Consolidating incident signal. a wall of vanity panels nobody can read under pressure.
Technical investments to reduce MTTR
Cut detection, diagnosis, and recovery time via observability, runbooks/automation, fast rollback, and resilient architecture. Systemic MTTR reduction. only buying more alerting without addressing diagnosis or recovery speed.
Conducting a blameless post-mortem in practice
Focus on systems not individuals, assume good intent, use neutral language and facilitation, end with owned action items. Operationalizing blamelessness. blameless as a slogan with no facilitation or follow-through.
Fast rollback versus targeted fix in an incident
Weigh time-to-recovery and blast radius against rollback side effects; prefer restoring service fast, gated by data like deploy diff and migration risk. Mitigation decision-making under pressure.
Designing a SEV1-SEV4 severity matrix
Tie levels to user impact, scope, and SLO burn with concrete thresholds; map each to response and escalation. Measurable severity definitions. subjective severity with no metrics, causing under or over reaction.
Primary goal and sections of a post-mortem
Goal is organizational learning and prevention, not blame; include summary, timeline, impact, root cause, action items. Purpose of post-mortems. framing it as finding who to blame or a paperwork ritual.
Triaging a 5xx error spike
Confirm impact and scope, declare and assign roles, check recent changes, stop the bleeding before root cause. Calm, structured incident triage. diving into code fixes before assessing blast radius or mitigating.
Alert silencing versus alert inhibition
Silencing mutes by matcher for a window, inhibition suppresses lower alerts when a higher one fires, dependency-aware. Alertmanager noise control. treating them as synonyms or over-silencing real signals.
Measuring on-call health quantitatively
Track pages per shift especially off-hours, actionability rate, time-to-resolve, and load distribution; use trends to prioritize reliability work and protect against burnout. turning on-call pain into data that justifies investment.
Designing an escalation policy
Define timeout-based escalation tiers, multiple notification channels, secondary and management layers, coverage across time zones, and severity-based routing. ensuring critical alerts always reach someone.
Anatomy of an effective runbook
Alert meaning and impact, diagnostic steps with dashboard and query links, concrete remediation with rollback, and escalation contacts. knowing what makes a runbook usable under stress.
SLO-based alerting and error budgets
Define SLI/SLO, derive an error budget, alert on how fast you burn it using multi-window multi-burn-rate rules so fast burns page and slow burns ticket. alerting on budget burn rate, not static thresholds.
Get SRE bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.