SRE On-Call Practices & Runbooks 5 — Questions and Answers
Question 1: What does 'alert fatigue' describe in an on-call context?
- Engineers becoming too comfortable with alerting tools
- Desensitization to alerts caused by excessive noisy or false-positive pages (Correct answer)
- Running out of alert quota in a monitoring system
- Alerts that trigger too slowly to be useful
Correct answer: Desensitization to alerts caused by excessive noisy or false-positive pages
Alert fatigue occurs when engineers receive so many low-quality or false-positive alerts that they begin ignoring or dismissing pages, risking missed real incidents.
Question 2: Which element should every runbook include to help engineers confirm a remediation worked?
- The name of the engineer who authored the runbook
- Expected system behavior or metrics after the fix is applied (Correct answer)
- A full architecture diagram of the service
- Links to competitor documentation
Correct answer: Expected system behavior or metrics after the fix is applied
Verification steps tell the engineer what to check after a remediation to confirm the issue is resolved, preventing premature incident closure.
Question 3: A service has been paging on-call engineers 15 times per shift on average. According to SRE principles, what should be done?
- Increase the on-call team size to share the load
- Investigate and eliminate the sources of noise through alert tuning or automation (Correct answer)
- Accept the high page volume as a sign of a critical service
- Reduce monitoring coverage to lower page count
Correct answer: Investigate and eliminate the sources of noise through alert tuning or automation
High page volume indicates poor alert hygiene; SRE practice calls for eliminating noise through tuning thresholds, improving automation, and fixing root causes.
Question 4: What is the main risk of having a single 'super-engineer' who is always on-call for critical systems?
- The engineer gains too much system knowledge
- Single-person on-call creates a bus factor risk and leads to unsustainable burnout (Correct answer)
- Incident response becomes too fast
- The engineer skips runbooks and improvises instead
Correct answer: Single-person on-call creates a bus factor risk and leads to unsustainable burnout
Depending on one person creates a single point of failure — if that person is unavailable or leaves, response capability collapses, and the workload causes burnout.
Question 5: What distinguishes a 'playbook' from a 'runbook' in some SRE organizations?
- Playbooks are automated; runbooks are always manual
- Playbooks provide high-level strategy and decision trees; runbooks provide specific step-by-step procedures (Correct answer)
- Playbooks are for developers; runbooks are for operators
- There is no meaningful distinction between the two terms
Correct answer: Playbooks provide high-level strategy and decision trees; runbooks provide specific step-by-step procedures
Some teams use 'playbook' to mean a higher-level guide with decision logic, while 'runbook' refers to a specific ordered set of executable steps for a known failure mode.
Question 6: Which of the following best describes a 'severity level' in incident management?
- The number of engineers responding to an incident
- A classification that describes the impact of an incident on users and business operations (Correct answer)
- The time of day when an incident occurs
- The number of alerts fired during an incident
Correct answer: A classification that describes the impact of an incident on users and business operations
Severity levels (e.g., SEV1–SEV4) categorize incidents by their scope of user impact and business consequence, guiding response urgency and escalation.
Question 7: Why is it important for runbooks to include links to relevant dashboards and logs?
- To comply with SOC 2 audit requirements
- To save the on-call engineer time locating diagnostic data during a time-sensitive incident (Correct answer)
- To demonstrate to stakeholders that monitoring exists
- To allow automated systems to self-heal
Correct answer: To save the on-call engineer time locating diagnostic data during a time-sensitive incident
Direct links to dashboards and log queries eliminate the time an on-call engineer spends searching for the right views during an incident, accelerating diagnosis.
SRE On-Call Practices & Runbooks 5
What does 'alert fatigue' describe in an on-call context?