122 lines
9.2 KiB
Markdown
122 lines
9.2 KiB
Markdown
---
|
|
title: PagerDuty — Incident Response Documentation / Runbooks
|
|
source_type: official-doc
|
|
url: https://response.pagerduty.com/
|
|
archive_url:
|
|
status: raw
|
|
confidence: medium
|
|
tags: [ca-operational-runbook, pagerduty, incident-response, runbook]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
related_branches: [feature-operational-runbook-contract]
|
|
created: 2026-05-22
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# 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 **문서** 형식만 정의.
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 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: (미작성)
|