SRE On-Call Practices & Runbooks 3 — Questions and Answers
Question 1: What is the recommended maximum sustainable on-call burden according to Google SRE best practices?
- No more than 50% of work hours spent on operational work
- No more than 25% of work hours spent on operational work (Correct answer)
- No more than 10% of work hours spent on on-call duties
- On-call burden has no defined limit
Correct answer: No more than 25% of work hours spent on operational work
Google SRE guidelines recommend limiting operational work including on-call to no more than 25% of an engineer's time to preserve capacity for engineering work.
Question 2: Which runbook section helps an on-call engineer determine whether an alert represents a real user-impacting issue?
- Rollback procedures
- Impact assessment / severity criteria (Correct answer)
- Change history
- On-call contact list
Correct answer: Impact assessment / severity criteria
Impact assessment sections define thresholds and signals that distinguish genuine user impact from benign anomalies, guiding severity classification.
Question 3: An on-call rotation has only two engineers sharing duty. What is the primary risk?
- Over-automation of incident response
- Burnout due to insufficient rotation depth (Correct answer)
- Alerts firing too infrequently
- Excessive escalation paths
Correct answer: Burnout due to insufficient rotation depth
Two-person rotations mean each engineer is on-call 50% of the time, which leads to fatigue and burnout without adequate relief.
Question 4: What is a 'war room' in the context of incident response?
- A physical or virtual space where all responders coordinate during a major incident (Correct answer)
- A database of past incident reports
- A monitoring dashboard showing real-time metrics
- A policy document for escalation decisions
Correct answer: A physical or virtual space where all responders coordinate during a major incident
A war room is a centralized coordination space (physical or virtual, such as a dedicated chat channel) where incident responders collaborate in real time.
Question 5: Which of the following is a key characteristic of a well-structured runbook step?
- It requires deep system expertise to interpret
- It is actionable, specific, and includes expected outcomes (Correct answer)
- It lists all possible system states exhaustively
- It references source code directly
Correct answer: It is actionable, specific, and includes expected outcomes
Good runbook steps are written so an on-call engineer can execute them confidently, with clear actions and expected results to verify success.
Question 6: What is the role of an Incident Commander (IC) during a major outage?
- To write the post-mortem report after resolution
- To coordinate responders, manage communications, and make prioritization decisions (Correct answer)
- To execute all technical remediation steps personally
- To disable alerting until the incident is resolved
Correct answer: To coordinate responders, manage communications, and make prioritization decisions
The Incident Commander coordinates the response, delegates tasks to specialists, and manages stakeholder communications without necessarily doing hands-on technical work.
Question 7: Why should runbooks avoid using vague language like 'check if the service looks healthy'?
- Vague language is acceptable if the team is experienced
- It slows page load times in runbook portals
- Vague steps create ambiguity, leading to inconsistent actions under pressure (Correct answer)
- Regulators prohibit informal language in technical documents
Correct answer: Vague steps create ambiguity, leading to inconsistent actions under pressure
Ambiguous runbook language forces on-call engineers to interpret instructions during high-stress incidents, increasing the chance of error or delay.
What is the recommended maximum sustainable on-call burden according to Google SRE best practices?