llm-wiki/raw/official-docs/metric-google-ewaschuk-philosophy-on-alerting.md

---
title: "My Philosophy on Alerting — Rob Ewaschuk (Google SRE)"
source_type: official-doc
url: https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/
archive_url: https://gist.github.com/msgodf/86a3fc7fcd3ce663ff37
related_branches: [feature-metrics-alerting-contract]
related_projects: []
tags: [official-doc, ca-skeleton, observability, alerting, sre]
created: 2026-06-14
---

# My Philosophy on Alerting — Rob Ewaschuk (Google SRE)

> Layer: `raw/` — 외부 자료(공식 문서 / Google SRE 개인 저술)의 **원문 발췌·출처 기록**.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/` 에 별도 작성. 원본은 raw 에 영구 보관.
>
> **Archive 출처 주의**: 원본은 Google Docs 문서(개인 공유 링크)로 직접 fetch 불가. 본 파일의 인용은 커뮤니티 gist mirror (`archive_url` 참조)에서 추출·self-grep 검증. 내용은 Rob Ewaschuk 의 동일 저술이며, 이후 Google SRE Book ("Practical Alerting") 에 흡수됨. Strength 는 개인 저술 원문 기준 `official-reference` 로 분류.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-metrics-alerting-contract]] | D10 — alert 는 actionable 해야 하고, 각 alert / alert family 에 runbook(playbook) entry 가 있어야 한다는 원칙의 근거. |

## 출처 / Source

- 원본 URL: https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/
- 아카이브 URL: https://gist.github.com/msgodf/86a3fc7fcd3ce663ff37 (커뮤니티 gist mirror — 본 인용의 실제 fetch 출처)
- 저자 / 조직: Rob Ewaschuk, Google SRE
- 발행일: 2013년경 (Google Docs 원본 발행, 정확한 날짜 미확인); Google SRE Book 에 흡수 시기 불명
- 마지막 확인일: 2026-06-14

## 왜 저장했는지 / Why archived

`feature-metrics-alerting-contract` 의 D10 결정 — "alert payload 에 runbook 링크 포함" — 의 근거 자료. Google SRE 현장 경험에서 도출된 playbook/runbook 원칙, actionable alert 기준, 그리고 summary 4원칙("urgent, important, actionable, real")을 verbatim 으로 보존.

## 핵심 인용 / Key quotes (verbatim, self-grep 통과)

> [§Playbooks, line 71] "Playbooks (or runbooks) are an important part of an alerting system; it's best to have an entry for each alert or family of alerts that catch a symptom, which can further explain what the alert means and how it might be addressed."

> [§Introduction, line 3] "Every page should be actionable; simply noting "this paged again" is not an action. Every page should require intelligence to deal with: no robotic, scriptable responses."

> [§Summary, line 91] "Pages should be urgent, important, actionable, and real. They should represent either ongoing or imminent problems with your service."

> [§Summary, line 97] "Symptoms are a better way to capture more problems more comprehensively and robustly with less effort."

> [§Summary, line 93] "Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SRE-PHIL-C1 | 각 alert 또는 alert family 마다 playbook(runbook) entry 가 있어야 하며, alert 의 의미와 대처 방법을 설명해야 한다 | [§Playbooks] "Playbooks (or runbooks) are an important part of an alerting system; it's best to have an entry for each alert or family of alerts that catch a symptom, which can further explain what the alert means and how it might be addressed." | `official-reference` | alert 기반 운영 시스템 전반. SRE 실무 맥락 | playbook 의 구체적 형식(wiki/문서/링크)을 강제한다는 뜻 아님; 자동화 runbook 의 구현 방식을 명시하지 않음 |
| SRE-PHIL-C2 | 모든 page 는 actionable 해야 하며, "이 alert 또다시 울렸다" 라고만 기록하는 것은 action 이 아니다 | [§Introduction] "Every page should be actionable; simply noting \"this paged again\" is not an action." | `official-reference` | alert/paging rule 설계 전반 | alert payload 에 어떤 링크를 포함해야 하는지를 직접 명시하지 않음; 링크 포맷·도구 선택은 이 원칙에서 추론되는 적용 |
| SRE-PHIL-C3 | page 는 urgent, important, actionable, real 의 4원칙을 모두 만족해야 한다 | [§Summary] "Pages should be urgent, important, actionable, and real. They should represent either ongoing or imminent problems with your service." | `official-reference` | paging rule 감사 및 신규 alert 설계 | 4원칙 각각의 정량 기준(예: "urgent" 의 response time SLA)을 이 문서가 정의하지 않음 |
| SRE-PHIL-C4 | symptom 기반 alert 가 cause 기반 alert 보다 더 많은 문제를 포괄적으로 robust 하게 더 적은 노력으로 잡는다 | [§Summary] "Symptoms are a better way to capture more problems more comprehensively and robustly with less effort." | `official-reference` | monitoring strategy 설계 전반 | 모든 서비스에서 symptom-only 접근이 항상 최선이라는 뜻 아님 — 본 문서 §"You're being naïve!" 섹션에서 예외 경우를 직접 열거 |
| SRE-PHIL-C5 | noisy alert 는 제거하는 방향으로 err 해야 한다 — over-monitoring 은 under-monitoring 보다 해결하기 어려운 문제다 | [§Summary] "Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring." | `official-reference` | alert rule 유지·관리 정책 | 특정 noise threshold(예: "50% 미만 정확도" 는 §Tracking & Accountability 에 있으나 이 claim 과 별도 인용)를 이 summary 줄이 직접 수치로 명시하지 않음 |

## Usage Boundaries / 적용 경계

- 이 자료가 직접 증명하는 것:
  - `SRE-PHIL-C1`: 각 alert/alert family 에 playbook entry 가 필요하다는 원칙.
  - `SRE-PHIL-C2`: page 는 actionable 해야 한다는 원칙.
  - `SRE-PHIL-C3`: urgent/important/actionable/real 4원칙.
  - `SRE-PHIL-C4`: symptom 기반이 cause 기반보다 우수한 이유.
  - `SRE-PHIL-C5`: noisy alert 제거 우선 정책.
- 이 자료가 증명하지 않는 것:
  - alert payload 에 dashboard URL / log link / runbook URL 을 구체적으로 함께 포함해야 한다는 것 (이는 `SRE-PHIL-C1` + `SRE-PHIL-C2` 의 적용 추론이며, 별도 source `raw/official-docs/metric-google-sre-workbook-on-call.md` 가 보완).
  - P1/P2/P3 정량 threshold 값.
  - playbook 의 구체적 포맷(wiki, Confluence, URL 링크 등).
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  - ca-tmpl 의 alert payload 구조(dashboard link + runbook link 동시 포함)는 `SRE-PHIL-C1` + `SRE-PHIL-C2` 에서 추론된 적용. 별도 SRE Workbook(`metric-google-sre-workbook-on-call.md`) 과 교차 검증 권장.
  - "각 alert family 마다 runbook entry" 의 실제 구현 범위(자동화 여부, 도구 선택)는 ca-tmpl 운영 결정.

## 메모 / Notes

- 본 문서는 Rob Ewaschuk 의 개인 저술이나, Google SRE 현장 7년 경험에서 도출된 내용으로 Google SRE Book 에 흡수되어 사실상 SRE 업계 표준 참조 자료로 통용됨.
- Strength 를 `official-vendor-doc` 이 아닌 `official-reference` 로 분류한 이유: Google 사의 공식 제품 문서가 아니라 개인 저술 + community archive 경로이기 때문.
- `SRE-PHIL-C1` 이 D10 의 직접 근거. `feature-metrics-alerting-contract` D10 은 이 source 추가로 `UNSUPPORTED_DECISION` 에서 해소됨.
- playbook 의 길이에 관한 조언 ("long detailed flow chart → too much documenting, too little fixing") 은 Claims 로 추출하지 않음 — ca-tmpl branch 의 직접 결정 범위 밖.

## Related / 관련

- 같은 저자의 내용이 흡수된 공식 SRE Book 챕터: [[raw/official-docs/metric-google-sre-workbook-on-call]] (SRE Workbook on-call 챕터 — alert payload dashboard/runbook link 포함 원칙)
- 번 레이트 경보 근거: [[raw/official-docs/metric-google-sre-slo-burn-rate]]
- 이 자료를 인용한 wiki 요약: (생성 시 추가)