donghyeon.kang/llm-wiki

Fork 0

Files

T

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

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

6.8 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

Google SRE Workbook — On-Call Chapter (alert↔playbook + monitoring console coupling)

Layer: raw/official-docs/ — 외부 자료(공식 문서)의 원문 발췌·출처 기록. 검증된 요약은 /ingest 후 wiki/concepts/에 source-summary-template 형식으로 별도 작성. 원본은 raw에 영구 보관.

Parent / 활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-metrics-alerting-contract	D10 — alert payload 가 monitoring console(dashboard) 링크를 포함해야 하고, 각 alert 에 playbook/runbook entry 가 있어야 한다는 Google SRE 공식 근거

출처 / Source

원본 URL: https://sre.google/workbook/on-call/
아카이브 URL: (미등록 — 추가 필요)
저자 / 조직: Google SRE (The Site Reliability Workbook)
발행일: (정확한 날짜 미명시 — Google SRE Workbook 공개 이후)
마지막 확인일: 2026-06-14

왜 저장했는지 / Why archived

Google SRE Workbook 의 On-Call 챕터는 alert 페이지가 monitoring console 링크를 포함해야 한다는 것과 모든 alert 에 playbook entry 가 대응해야 한다는 것을 공식으로 명시한다. D10(alert payload = dashboard/log/runbook 링크 포함)이 UNSUPPORTED_DECISION에서 벗어나기 위한 1차 근거 출처로 저장한다.

핵심 인용 / Key quotes (verbatim, 3~5문장)

[§Identification delay] "Ensure pages link to relevant monitoring consoles, and that consoles highlight where the system is operating out of specification."

[§Identification delay] "Make sure playbooks are up to date with advice on responding to each type of alert."

[§Playbooks] "In SRE, whenever an alert is created, a corresponding playbook entry is usually created. These guides reduce stress, the mean time to repair (MTTR), and the risk of human error."

[§Alerting] "Each alert should have a corresponding playbook entry."

Claims Extracted / 추출된 주장

이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
SRE-ONCALL-C1	alert 페이지(page)는 관련 monitoring console 링크를 포함해야 하며, console 은 시스템이 사양(specification) 밖에서 동작하는 위치를 강조(highlight)해야 한다	[§Identification delay] "Ensure pages link to relevant monitoring consoles, and that consoles highlight where the system is operating out of specification."	`official-vendor-doc`	SRE on-call 운영 — alert 가 page 형태로 전달되는 모든 운영 환경	특정 alert 도구(Alertmanager, PagerDuty 등)의 구현 방법을 규정하지 않음. "console" 이 Grafana 인지 Cloud Console 인지 미특정
SRE-ONCALL-C2	playbook 은 각 alert 유형에 대한 대응 조언을 포함해 최신 상태로 유지해야 한다	[§Identification delay] "Make sure playbooks are up to date with advice on responding to each type of alert."	`official-vendor-doc`	alert 유형별 runbook/playbook 을 가진 모든 on-call 팀	playbook 의 구체적 형식(Wiki 페이지, PDF, Notion 등)을 지정하지 않음. 최신 상태 유지 주기를 수치로 명시하지 않음
SRE-ONCALL-C3	SRE 에서는 alert 생성 시 대응하는 playbook entry 도 함께 생성하는 것이 일반적(usual) 관행이다	[§Playbooks] "In SRE, whenever an alert is created, a corresponding playbook entry is usually created. These guides reduce stress, the mean time to repair (MTTR), and the risk of human error."	`official-vendor-doc`	SRE 관행을 따르는 팀의 alert 작성 프로세스	"usually" — 필수 강제 규범이 아닌 일반적 관행 기술. playbook entry 없는 alert 가 SRE 원칙 위반이라는 뜻은 아님
SRE-ONCALL-C4	각 alert 에는 대응하는 playbook entry 가 있어야 한다	[§Alerting] "Each alert should have a corresponding playbook entry."	`official-vendor-doc`	alert 설계 — SRE Workbook 권고를 준수하는 모든 팀	"should" — MUST 수준의 강제 규범이 아닌 강력 권고. playbook entry 의 최소 내용(무엇을 포함해야 하는지)을 상세 명시하지 않음

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- SRE-ONCALL-C1: alert 가 페이지(page)로 전달될 때 monitoring console 링크 포함이 Google SRE 공식 권장사항임
- SRE-ONCALL-C2: alert 유형별 최신 playbook 유지가 Google SRE 공식 권장사항임
- SRE-ONCALL-C3: alert 생성 시 playbook entry 동시 생성이 SRE 일반 관행임 (descriptive)
- SRE-ONCALL-C4: 각 alert 에 playbook entry 대응이 Google SRE 강력 권고(should)임
이 자료가 증명하지 않는 것:
- ca-tmpl 의 Alertmanager annotation 필드(runbook_url, dashboard_url)가 이 권고를 충족하는 유일한 구현 방법이라는 것
- playbook entry 의 최소 내용 구성(어떤 섹션이 있어야 하는지)
- dashboard/log/runbook 세 링크를 동시에 포함해야 한다는 3-링크 조합 (이 자료는 "monitoring console"과 "playbook"만 언급)
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl Alertmanager alert 설계에서 annotations.runbook_url + annotations.dashboard_url 이 이 권고를 실제로 충족하는지 — 구현 검증 필요
- "log 링크" 포함 요건은 이 자료에서 직접 명시되지 않음 — D10 의 "log 링크" 부분은 별도 근거 필요

메모 / Notes

SRE-ONCALL-C3 의 "usually" 는 descriptive(기술적) 표현 — SRE 팀들이 실제로 그렇게 한다는 관찰이며, normative(규범적) 강제 요건이 아님. SRE-ONCALL-C4 의 "should" 가 규범 역할을 함.
D10 의 "alert payload = dashboard / log / runbook 링크 동시 포함" 중 monitoring console + runbook 은 본 자료로 공식 근거 확보됨. "log 링크" 부분은 이 자료에서 직접 다루지 않음 — toss techblog 재확인 또는 별도 근거 필요.
추가로 봐야 할 동일 출처 페이지: https://sre.google/workbook/alerting-on-slos/ (SLO 기반 alerting 상세)

같은 주제 다른 official-doc: raw/official-docs/metric-google-sre-slo-burn-rate (SLO burn-rate alert — D3, D5 근거)
같은 프로젝트 branch: raw/branch-notes/feature-metrics-alerting-contract
이 자료를 인용한 wiki 요약: (생성 시 추가)

6.8 KiB Raw Permalink Blame History