Site Reliability Engineering Practice

• · SR1 — Every production service has defined SLIs and SLOs for its critical user journeys, not just "we'll know if it's down."
• · SR2 — Alerts fire on symptoms affecting users (error rate, latency SLO breach), not on every resource-utilization fluctuation.
• · SR3 — An error budget is tracked; when exhausted, feature velocity yields to stability work until it recovers.
• · SR4 — Every page-worthy alert is actionable — if a human receiving it at 3am can't do anything useful, it shouldn't page.
• · SR5 — Postmortems are blameless, focus on systemic causes, and produce concrete follow-up actions with owners.

• · An alert that's fired 20 times this month, dismissed 19 times as noise → either fix the underlying issue or delete the alert; it's training the on-call to ignore pages.
• · No SLO defined for a critical service → symptom of "we'll notice if it's really broken" reactive operations; define one before the next incident, not after.
• · A postmortem naming a specific person as the cause → rewrite toward the process/system gap that allowed the mistake to have impact.
• · The same manual operational task performed weekly by a human → toil; script/automate it.
• · An incident resolved by "someone remembered what to do" rather than a runbook → write the runbook now, while it's fresh.

• · Alert fatigue — dozens of low-signal alerts firing constantly, training the on-call to ignore pages, until a real one is missed among the noise.
• · Cause-based paging — paging on "CPU > 80%" instead of "users are seeing errors," waking someone for a non-issue while missing user-impacting problems that don't correlate with the watched metric.
• · Blame-first postmortems — incident reviews that identify "who broke it" instead of "what systemic gap allowed this," discouraging honest reporting of near-misses.
• · No SLO, reactive-only operations — reliability work only happens after an outage, with no proactive target or budget guiding investment.
• · Tribal-knowledge incident response — resolving incidents relies on one specific engineer's memory, with no runbook, creating a single point of failure in the response process itself.

• [ ] SLIs/SLOs defined for critical user journeys. (SR-E1)
• [ ] Paging alerts are symptom-based with documented rationale. (SR-E2)
• [ ] Every alert links to a runbook. (SR-E3)
• [ ] Postmortems blameless, with tracked follow-up actions. (SR-E4)
• [ ] Error budget status reviewed on a regular cadence. (SR-E5)
• [ ] Recurring manual toil tracked and prioritized for automation. (SR-E6)

• Site Reliability Engineering: How Google Runs Production Systems

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• bookSite Reliability Engineering: How Google Runs Production SystemsGoogle (Beyer, Jones, Petoff, Murphy, eds.). O'Reilly
• webThe Site Reliability WorkbookGoogle