生产事故响应工具包

这个 pack 包含什么

凌晨 2:47。PagerDuty 把你叫醒。SLO 错误预算还有 14 分钟烧光。这个 pack 就是上个季度你后悔没装的那套支架 — 不是 50 个工具的 observability 购物清单，而是正在救火的工程师真正会伸手去抓的那十个，按事故真实发生的顺序排好。

每一个都是开源或有开源核心、可以跑在自己基础设施上、在你这周最难熬的十分钟里值得占一个快捷键。顺序不是字母序 — 是按生命周期走的：告警进来 → 分诊 → 查日志/链路 → 执行 runbook → 对外通信 → 写复盘。

推荐安装顺序

1. Oncall-Guide — Incident Response Subagent — 从这里开始。Claude Code subagent，自动走完 on-call 检查清单（部署关联、错误尖刺分诊、回滚决策），灵感来自 Boris Cherny 的 oncall playbook。这是后面所有工具的大脑。
2. Claude Code Agent: Devops Incident Responder — 负责事故头 90 秒的 triage agent：拉最近部署、检查 dashboard、标出可疑 commit。绑到编辑器的 slash command，MTTA 直接砍半。
3. Claude Code Agent: PagerDuty Incident Responder — 把 agent 接进 PagerDuty 本身。自动 ack、升级、往事故频道发更新。消灭头五分钟「有人在看吗？」的 Slack 噪音。
4. SigNoz MCP Server — Query Traces, Logs & Alerts — 给 agent 一个统一的 MCP 工具，同时 grep 分布式链路和日志。当 agent 说「p99 延迟尖刺和 cart-service 的 abc123 部署相关」，数据就是从这儿来的。
5. Monoscope — LLM Query for Logs/Traces/Metrics — 跨技术栈的自然语言日志查询。「过去 15 分钟从新 pod 出来的 /checkout 5xx」一句话就能查，不用开三个 Kibana dashboard。agent 用它，agent 错的时候人也用它。
6. Graylog — Centralized Log Management — 如果你还没有日志底座就装这个。SigNoz 和 Monoscope 从它读，runbook 往它写，postmortem agent 从它引用。自托管，没有按 GB 收费的陷阱。
7. Prometheus Alertmanager — Alert Routing and Notification Hub — 决定谁被 page、什么时候静音、抖动信号如何聚合的路由大脑。先调它再加 dashboard。大部分 pager 疲劳是 Alertmanager 配置问题，不是 dashboard 问题。
8. Rundeck — Open Source Runbook Automation — runbook 变成按钮的地方。「重启 worker 池」「清缓存」「轮换只读副本」变成 on-call 点一下的 job，不用现场回忆命令。agent 也能通过权限闸门触发。
9. OpenStatus — Open-Source Monitoring and Status Page — 面向客户的状态页，从同一套告警自动更新。让 on-call 不用同时兼任公关。客户在发推骂你之前先看到黄色 banner。
10. Claude Code Agent: Incident Responder — 写复盘的 agent。缓解措施一上线，它就抓 Slack 频道、PagerDuty 时间线、部署历史、SigNoz 查询，拼出一份 five-whys 草稿，你只需要改不需要写。和 #1 同类型 agent，不同 prompt。

它们怎么协同

PagerDuty 告警
   │
   ▼
PagerDuty Responder agent  ──── ack + 第一条 triage 帖
   │
   ▼
Devops Incident Responder  ──── 拉部署/dashboard/可疑 commit
   │
   ├──► SigNoz MCP   ──► 链路 + 日志关联
   ├──► Monoscope    ──► 自然语言查日志
   └──► Graylog      ──► 原始日志底座
   │
   ▼
Alertmanager  ──── 静音抖动信号、重新聚合
   │
   ▼
Rundeck  ──── 执行 runbook（重启 / 清缓存 / failover）
   │
   ▼
OpenStatus  ──── 公开状态页自动更新
   │
   ▼
Incident Responder agent  ──── 复盘草稿（five-whys + 时间线）

闭环完成的标志：postmortem agent 找到那个如果上周就上线就能阻止这次 page 的 action item。开 ticket。睡觉。

你会遇到的取舍

• SigNoz vs Datadog — Datadog 是闭源 SaaS 霸主。SigNoz 是当你的账单从 4K 涨到 40K/月有人问起时的开源退路。MCP server 是让两个里随便哪个都能从 agent 用起来的桥梁。
• Monoscope vs grep + jq — 3 人小团队 grep + jq 够用。过了 50 个服务，你需要自然语言搜索，因为凌晨 3 点没人记得每个服务的日志 schema。
• Rundeck vs 仓库里的 shell 脚本 — 裸脚本一直能用，直到写它的 on-call 休年假。Rundeck 加了认证、审计、点击运行 UI，你未来的自己会感谢你。
• 一个 postmortem agent vs 自己写 — agent 第一稿能到 70%。剩下 30%（上下文、意图、blameless 表述）才是文档真正有用的部分。别把 agent 草稿不改就发出去。

常见踩坑

• triage agent 没设速率限制 — 第一次出事 agent 30 秒打 200 次 SigNoz 查询，给正在着火的系统又加了一层压。每次事故设查询预算。
• 跳过 Alertmanager 分组规则 — 没分组的话一个上游小抖动 page 五个团队。group_by 配置就是「有用的 page」和「on-call 六周烧光」之间的分水岭。
• 状态页骗人，因为 OpenStatus 用的是同一套已经挂了的监控 — 状态页放在独立基础设施上。不同云、不同 DNS、不同 paging 链路。
• LLM 写完不改就发的 postmortem — 复盘文档是改变文化的产物。没改的 LLM 草稿会侵蚀大家对这套实践的信任。终稿必须有人在 loop 里。
• Runbook 写在没人看的 wiki 里 — Rundeck 只有 runbook 被告警链接到才值回票价。Alertmanager → Rundeck 那条链路是承重的。