Incident Response Pro

---
name: incident-response-pro
description: 线上故障应急助手。只要用户的问题涉及线上服务出了状况、或是故障之后要交代，即应触发本技能，无需用户明确指定。无论是半夜被叫起来、告警一直响、群里有人喊线上挂了、用户反馈打不开、接口报 500、5xx 涨了、超时、错误率飙升、响应变慢、抖动、CPU 打满、OOM，还是拿不准、先止损还是先定位、该回滚还是该限流降级、错误从几点开始变多的、几台机器日志格式不一样拼不成时间线、日志刷屏看不出哪条是新错误、影响了哪些接口多少用户多少比例请求、接口没报错但变慢了、故障前谁改了什么、是不是数据库拖的、这块代码谁最熟、修完了怎么确认真恢复，或者老板在群里催进展要发故障简报要对外同步、复盘 postmortem 要怎么写、改进项要挂人挂日期挂验收、这条告警本身就吵或者该响的时候没响要治理，都从这里进。本技能判断所处阶段，给出对应方法并路由到精专子技能。不做：代替人连生产系统执行重启、回滚、改配置等操作，也不做日常性能调优与容量规划。
author: Captain
version: 0.1.2
display_name: "线上故障排查"
display_name_en: "Incident Response Pro"
description_zh: "一个入口覆盖整条应急链路，不必等用户报出技能名：告警分诊、快速止损、日志排查与降噪、时间线重建、影响面评估、变更关联、根因假设排序、恢复确认、故障简报与复盘；按所处阶段路由到精专子技能。"
description_en: "One entry point for the whole incident lifecycle, triggered by the situation rather than by name. Alert triage, fast mitigation, log digging and de-noising, timeline reconstruction, blast-radius sizing, change correlation, ranked root-cause hypotheses, recovery checks, incident briefs and postmortems; routes to focused sub-skills."
tags:
  - "故障排查"
  - "告警响应"
  - "止损"
  - "日志分析"
  - "复盘"
  - "根因定位"
  - "SRE"
  - "oncall"
examples_zh:
  - "线上 5xx 涨到 20%，先止损还是先定位？"
  - "刚恢复，老板要简报，下周还要复盘，先干哪个"
  - "告警一直响，三台机器日志格式还不一样，帮我拼条时间线"
examples_en:
  - "5xx just spiked to 20 percent, mitigate first or diagnose first?"
  - "Service is back, boss wants a brief now and a postmortem next week"
  - "Three hosts, three log formats, build me one timeline"
metadata:
  { "openclaw": { "requires": { "bins": ["python3"] }, "os": ["darwin", "linux", "windows"], "emoji": "🚨" } }
---

# 线上故障应急助手

定位一句话：**故障期间不研究代码，先止损、再定界、后定因，最后交代。**
这是「研发效能」系列里应急场景的入口。何时用：告警响了、有人在群里喊线上挂了、要交故障简报或复盘时，先在下表对号入座。表里的子技能装了就直接调用（自带脚本、纯标准库，一条 `python3` 命令出结果），没装就按本页的精简方法做，并告诉用户可以在 SkillHub 搜对应 slug 安装。

## 应急四拍（顺序不要换）

```
1 止损：能回滚先回滚，不行就限流 / 降级 / 切流量，别边扛边查
2 定界：影响哪些接口、多少比例请求、哪些用户、从几点几分开始
3 定因：列可证伪假设 → 先验最快能验的 → 拿日志、指标、变更记录对齐
4 交代：进行中发简报，结束后做复盘，改进项挂人挂日期挂验收方式
```

## 意图 → 方法 → 子技能

| 用户在说什么 | 先做什么 | 子技能（SkillHub slug） |
|---|---|---|
| 告警刚响、线上挂了，先干什么 | 按四拍走；同时开一份时间线，把告警时间、症状、已做动作、执行人逐条记下来 | 线上排查简报 `incident-brief-sre` |
| 错误是什么时候开始变多的 | 日志或指标按分钟聚合，滑动基线 3σ 标出异常起点、峰值与恢复点，再与变更时间对齐 | 日志突变检测 `log-anomaly-3sigma` |
| 几台机器、几个服务的日志对不上 | 多格式多时区时间戳归一后合成一条排序时间线，标注来源、级别与错误爆发点 | 日志时间线重建 `log-timeline` |
| 日志刷屏，看不出哪条是新错误 | 变量位抽象成模板后计数——最常见的是噪音，最少见的往往才是这次的新错误 | 日志模板聚类 `log-pattern-cluster` |
| 影响面有多大、哪些接口受影响 | 访问日志出接口级报表：请求量、错误率、5xx、P95/P99、高峰时段、Top IP | 访问日志统计 `access-log-stats` |
| 是不是数据库拖的 | 慢查询日志按指纹聚合出 Top SQL，附扫描行数与缺索引、无 WHERE 等改法 | 慢查询摘要 `sql-slow-query-digest` |
| 故障前谁改了什么（变更关联） | 本仓库暂无对应技能，按方法做：取异常起点前 30 分钟到 2 小时的窗口，把发布、配置开关、数据库迁移、依赖升级、基础设施调整、上游公告列成一张表，逐条写「能否解释这个症状」的正反证据，按可疑度排序 | —— |
| 这块代码谁最熟、改动最频繁 | git 历史找高频大改文件、单人维护目录（bus factor）与总是一起改的隐性耦合 | 代码热点 `git-hotspots` |
| 修完了怎么确认真恢复 | 并发巡检一批 URL 的状态码、耗时、关键字与证书剩余天数，作恢复验证与冒烟 | HTTP 健康巡检 `http-health-check` |
| 要发故障简报、对外同步 | 时间线 + 可疑变更排序 + 假设与反证 + 已做动作 + 未知项，不写没证据的根因 | 线上排查简报 `incident-brief-sre` |
| 复盘、postmortem | 影响范围 / 时间线 / 根因（5 Why）/ 做对与做错 / 改进项（负责人 + 截止日 + 验收方式） | 线上排查简报 `incident-brief-sre` |
| 这个告警本身就有毛病 | 规则体检：缺 for、for 过短、缺 severity、rate 窗口与抓取间隔不匹配、缺聚合导致告警风暴 | 告警规则体检 `prometheus-rule-check` |

## 输出契约

1. **每条结论附证据**：日志原文行、时间戳、commit 短 hash、变更单号、指标出处。拿不到就写「待确认」。
2. **不下根因结论**：只给按可疑度排序的假设，每条附验证方法与反证，定性由人做。
3. **时间线先于分析**：任何一份产出的第一节都是时间线，缺失的时间点明写「未知」。
4. **人还在故障里就先止损**：先给动作清单与风险提示，深度分析可以晚十分钟。

## 典型组合流程

- **接到告警到发出简报**：日志突变检测定异常起点 → 访问日志统计定影响面 → 变更关联列可疑变更 → 日志时间线重建把多机日志拼成一条 → 线上排查简报出稿 → HTTP 健康巡检确认恢复。
- **日志太多无从下手**：日志模板聚类先降噪，专看最少见的模式 → 挑出新错误关键字 → 日志时间线重建看这类错误的爆发点 → 日志突变检测确认起点是否与某次发布对齐。
- **复盘周**：线上排查简报补齐时间线与改进项 → 代码热点验证出事文件是不是长期高频大改、是不是只有一个人在维护 → 把「补测试 / 拆文件 / 加监控 / 改告警」写成带负责人与截止日的改进项 → 告警规则体检把这次漏报或风暴的规则一并修掉。

## 不做什么

- 不代替人连生产系统执行操作：重启、回滚、改配置、清缓存都由人来按，本技能只给动作清单与风险提示。
- 没有证据就不给根因，也不给「已恢复，可以收工」这类结论。
- 不接触任何未脱敏的内部系统信息；示例一律用 example.com 与 GitHub / GitLab / Jira。
- 不做日常性能调优与容量规划，那是压测与部署类技能的事。

---
本系列全部开源（正文 CC BY 4.0，代码 MIT）：https://github.com/po-et/workbuddy-skills