Files

T

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

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

9.2 KiB

Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title

source_type

url

archive_url

status

confidence

PagerDuty — Incident Response Documentation / Runbooks

Layer: raw/official-docs/ — PagerDuty Incident Response 공개 문서 (response.pagerduty.com/, Creative Commons) 의 runbook 관련 verbatim 발췌. ca-tmpl Operational Runbook Contract 의 외부 표준 근거.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-operational-runbook-contract	"runbook link 형식 = `runbook://{area}/{scenario}` 또는 repository relative markdown path" + "runbook 은 implementation detail 이 아니라 운영 계약의 일부" 결정의 업계 표준 출처

컨텍스트 / 왜 저장했는지

ca-tmpl 이 결정한 "runbook link 형식 = runbook://{area}/{scenario} 또는 repository relative markdown path" + "runbook 은 implementation detail 이 아니라 운영 계약의 일부" 의 업계 표준 출처. PagerDuty Incident Response 공개 문서가 "alert → runbook 링크 필수" 를 명시한다는 사실을 근거로 박는다.

출처 / Source

원본 URL: https://response.pagerduty.com/
1차 인용 페이지: https://response.pagerduty.com/oncall/alerting_principles/
관련: PagerDuty Runbook Automation product docs (별도 페이지)
아카이브 URL: (미수집)
저자 / 조직: PagerDuty (open source under Creative Commons)
발행일: rolling (Incident Response 공개 문서 — 지속 갱신)
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim, fetched 2026-05-27)

[§Alerting Principles — Actionability] "An alert is something which requires a human to perform an action. Anything else is a notification."

[§Alerting Principles — Alert body requirement] "The body should also include a description of what the actual problem is, and why it's an issue."

[§Alerting Principles — Runbook necessity] "Provide clear steps to resolve the problem, or link to a run book. Alerts with neither of these things are useless."

[§Alerting Principles — Example runbook integration] "Follow the run book here for identifying and resolving disk space issues: https://example.com/runbook/disk. Additionally, you should investigate whether log rotation thresholds are sufficient to prevent this happening again, the following run book has the necessary steps: https://example.com/runbook/log-rotate"

[§Alerting Principles — Alert priority classification (요약)] High = 24/7/365 immediate human action. Medium = business hours, action within 24 hours. Low = 24/7/365 action at some point. Notification = suppressed events, no response required.

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
PD-RB-C1	alert 의 정의는 "사람의 action 을 요구하는 것"; action 이 필요 없으면 notification	[§Alerting Principles] "An alert is something which requires a human to perform an action. Anything else is a notification."	`company-case-study`	PagerDuty 권장 alert design 채택 조직	모든 monitoring 시스템이 이 정의를 따라야 한다는 표준이 아님 — PagerDuty 권장
PD-RB-C2	alert body 는 actual problem 의 description + 왜 issue 인지 포함해야 함	[§Alerting Principles] "The body should also include a description of what the actual problem is, and why it's an issue."	`company-case-study`	alert body 작성 가이드	정확한 markdown/template 형식은 본 인용 범위 밖
PD-RB-C3	alert 는 (a) 해결 단계 직접 제공 또는 (b) runbook 링크 중 하나를 반드시 가져야 함. 둘 다 없으면 "useless"	[§Alerting Principles] "Provide clear steps to resolve the problem, or link to a run book. Alerts with neither of these things are useless."	`company-case-study`	on-call alert 운영	runbook 의 정확한 구조 (purpose / severity / first check / mitigation / escalation) 가 PagerDuty 표준이라는 뜻은 아님 — 본 인용은 "링크해야 한다" 까지만
PD-RB-C4	예시 runbook 링크 형식은 URL 기반 (예: `https://example.com/runbook/disk`) — vendor 중립 URL	[§Alerting Principles — Example] "Follow the run book here for identifying and resolving disk space issues: https://example.com/runbook/disk."	`company-case-study`	runbook 링크 표기 일반	git-hosted markdown 이 PagerDuty 권장이라는 뜻은 아님 — 예시는 https URL 만 표시
PD-RB-C5	PagerDuty 알림 우선순위 분류: High/Medium/Low/Notification 4단계 (각각의 action SLA 정의)	[§Alerting Principles — Priority] High = 24/7/365 immediate human action; Medium = business hours, within 24h; Low = 24/7/365 at some point; Notification = no response required	`company-case-study`	PagerDuty 권장 severity 채택 시	ca-tmpl P1/P2/P3 분류와 1:1 매핑된다는 뜻 아님 — 별도 매핑 필요

Strength 근거

모두 company-case-study — PagerDuty 는 incident response 도구 vendor 이며 본 문서는 PagerDuty 의 권장 운영 방식. 업계 표준 (RFC / 공식 사양) 이 아니므로 "공식 best practice" 로 단정하지 말 것. Creative Commons 공개 문서이지만 source_type 은 vendor 권장.

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- PD-RB-C1 ~ C3: alert / notification 의 정의, alert body 의무 항목, runbook 링크 의무 (PagerDuty 권장)
- PD-RB-C4: 예시 runbook 링크 형식 (URL 기반)
- PD-RB-C5: PagerDuty 4단계 priority 분류
이 자료가 증명하지 않는 것:
- "runbook 은 (1) Purpose (2) Severity & SLO impact (3) First checks (4) Mitigation (5) Escalation 의 5섹션 구조" — 이는 ca-tmpl 측 해석/요약. PagerDuty alerting_principles 페이지 verbatim 에 5섹션 구조 정의 없음. (별도 PagerDuty 페이지 또는 Google SRE Workbook 등에서 확인 필요)
- "Runbooks should be version-controlled (git) and live next to code" — PagerDuty 페이지 verbatim 인용 미확보. 본 자료에서는 ca-tmpl 측 해석으로만 표기
- "A runbook is a compilation of routine procedures and operations that responders carry out" — 이전 raw 노트의 인용 문장. 본 fetch (2026-05-27) 시점 alerting_principles 페이지에서 verbatim 매칭 안 됨. PagerDuty 의 다른 페이지 (Runbook Automation product docs 등) 출처 가능성 — 별도 확인 필요
- PagerDuty Runbook Automation 의 정확한 동작 (별도 product docs)
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl runbook://{area}/{scenario} 스킴이 PagerDuty / Opsgenie 등 on-call tool 에서 렌더링되는지 (보통 https/file URL 만 클릭 가능)
- ca-tmpl P1/P2/P3 와 PagerDuty High/Medium/Low 의 정확한 매핑
- link-check smoke 가 어떤 도구로 구현되는지 (별도 branch / contract)

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

PagerDuty 권장 vs ca-tmpl Runbook Link Contract 매핑 (해석):

PagerDuty (인용 기반)	ca-tmpl (해석 매핑)
alert body 의 problem description	runbook header / context
alert priority (High/Medium/Low)	severity (P1/P2/P3) — 매핑은 별도
"resolve steps 또는 runbook 링크" 의무	runbook scheme 의무 + link-check smoke
예시 URL 형식	`docs/runbooks/*.md` (git-relative) 또는 `runbook://{area}/{scenario}`

link 형식 비교 (ca-tmpl 측 해석):
- PagerDuty: URL (vendor SaaS) or git-hosted markdown.
- ca-tmpl: runbook://{area}/{scenario} (custom scheme, abstract) 또는 docs/runbooks/*.md (git-relative).
- ca-tmpl 이 더 strict — placeholder/TBD/empty link 모두 forbidden.
장점 (ca-tmpl 접근, 해석):
- git-hosted = version control + PR review.
- link-check smoke 로 검증 자동화 가능.
- vendor lock 없음.
단점 (해석):
- on-call tool (PagerDuty/Opsgenie) 이 markdown rendering 못 하면 link 만 클릭.
- 누가 update 할지 명확한 ownership 필요.
automation 차이 (해석):
- PagerDuty Runbook Automation = 일부 mitigation 을 자동 실행.
- ca-tmpl 은 automation 안 함 (out-of-scope), runbook 문서 형식만 정의.

같은 주제 다른 official-doc:
- (PagerDuty Runbook Automation product docs — 별도 fetch 예정)
- (Google SRE Workbook — Incident Response — 별도 fetch 예정)
적용 branch-note: raw/branch-notes/feature-operational-runbook-contract
canonical contract: raw/project-notes/ca-skeleton-operational-contract (§18 Control Plane Contract — Operational Runbook)
대안 그룹: Group G-A — Operational runbook
본 source 위치: ca-tmpl 채택안 — git-hosted runbook + scheme + link-check (PagerDuty 권장과 정합)
인용하는 wiki: (미작성)

9.2 KiB Raw Blame History