donghyeon.kang/llm-wiki

Fork 0

Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.1 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title

source_type

url

archive_url

related_branches

related_projects

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 의 직접 결정 범위 밖.

같은 저자의 내용이 흡수된 공식 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 요약: (생성 시 추가)

8.1 KiB Raw Permalink Blame History Unescape Escape