菜单
Design and operate an effective on-call rotation. Outputs rotation schedule, escalation policies, alert routing rules, on-call handbook, and well-being guidelines.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/kalilurrahman/kr-claudiator-skills --skill on-call-management命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | on-call-management |
| description | Design and operate an effective on-call rotation. Outputs rotation schedule, escalation policies, alert routing rules, on-call handbook, and well-being guidelines. |
| argument-hint | ["team size","service criticality","time zones","current pain points","alerting tool"] |
| allowed-tools | Read, Write |
Effective on-call management ensures services are monitored 24/7 without burning out the people doing it. The goal is actionable alerts, clear escalation paths, appropriate response SLAs, and a culture where on-call is manageable — not traumatic.
# PagerDuty schedule (Terraform)
resource "pagerduty_schedule" "primary" {
name = "Engineering Primary On-Call"
time_zone = "UTC"
layer {
name = "Weekly Rotation"
start = "2024-01-01T00:00:00Z"
[
,
,
,
,
]
{
}
}
}
{
{
{
}
}
{
{
}
}
{
{
}
}
}
# Only actionable alerts page on-call
# Severity matrix:
# P1 - Page immediately (24/7)
# Service down, data loss risk, security breach, SLO critical burn
alerts:
- name: ServiceDown
severity: P1
notify: [pagerduty_primary]
response_sla: 5min
- name: SLOCriticalBurnRate
severity: P1
notify: [pagerduty_primary]
response_sla: 5min
# P2 - Page during business hours; Slack at night
- name: HighErrorRate
severity: P2
notify:
business_hours: [pagerduty_primary]
off_hours: [slack_oncall_channel]
response_sla: 30min
# P3 - Slack only, next business day
- name: DiskUsageHigh
severity: P3
notify: [slack_oncall_channel]
response_sla: next_business_day
# NEVER PAGE for:
# - Informational metrics
# - Metrics that auto-resolve in <5 min
# - Anything that has never needed human action
# On-Call Handbook
## Before Your Shift
- [ ] Ensure laptop charged and internet reliable
- [ ] Test PagerDuty app works and alerts come through
- [ ] Know who your backup is (and their phone number)
- [ ] Review last 7 days of incidents for context
- [ ] Know your shift handoff time and who you're handing to
## During An Incident
1. **Acknowledge** the alert within 5 minutes (stops escalation)
2. **Assess** — is this a real incident or a flaky alert?
- Check Grafana dashboard first (link in alert)
- Check recent deployments (kubectl rollout history)
3. **Communicate** in #incidents-live: "Investigating [alert name] — [initial finding]"
4. **Decide**: rollback vs fix forward
- If deployed in last 30 min → rollback first, investigate second
5. **Update** #incidents-live every 15 minutes
6. **Escalate** if not resolved in 30 min — never try to fix alone in the dark
## After An Incident
- Write incident summary in #incidents within 1 hour
- Create postmortem ticket if P1 or repeated issue
- Add runbook entry if one didn't exist
## Escalation
1. Can't reproduce → wait 2 cycles; if re-fires, escalate
2. Can reproduce but don't know fix → escalate to domain expert
3. Need access you don't have → escalate to senior on-call
4. Customer impact confirmed → loop in CS team
## Your Rights as On-Call
- You may not be contactable during a medical appointment, meal, or family emergency
- Incidents during off-hours are compensated (check HR policy)
- You may request a swap for personal commitments — slack #on-call-swaps
- More than 2 P1 incidents in a shift → flag to manager; reduce load or add rotation
# Track these monthly to prevent burnout
metrics = {
"pages_per_person_per_week": {
"healthy": "< 2",
"action_required": "> 5",
"note": "High page rate → reduce alerts or increase rotation size"
},
"pct_actionable_alerts": {
"healthy": "> 80%",
"action_required": "< 50%",
"note": "Low actionability → audit and remove noise alerts"
},
"incidents_per_month": {
"healthy": "< 5 P1",
"action_required": "> 10 P1",
"note": "High incident rate → invest in reliability"
},
"avg_time_to_acknowledge": {
"healthy": "< 5 min",
"action_required": "> 15 min",
"note": "Slow ACK → alert fatigue or staffing issue"
},
"mean_time_to_resolve": {
"target_p1": "< 1 hour",
"target_p2": "< 4 hours",
}
}
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Always-firing low-severity alerts | Alert fatigue; real issues ignored | Alert only when human action required |
| Same person always on-call | Burnout; bus factor | Mandatory rotation; no opt-outs |
| No runbooks | Every incident solved by experience, not documentation | Runbook required for every alert |
| No postmortems | Same incidents repeat | Blameless postmortem for every P1 |
| Paging for metrics not user-impacting | Engineer woken for non-emergency | Tie every alert to user impact |