@llryiop/avatar-boot-cli 1.0.0

package/templates/.claude/skills/incident-analysis/SKILL.md

@@ -0,0 +1,241 @@
+---
+name: incident-analysis
+description: |
+  故障分析与复盘技能。当用户提到以下关键词时触发：
+  incident, 故障分析, postmortem, 复盘, 事故, 故障报告,
+  线上故障, 生产事故, 事后分析, 故障复盘
+
+  本技能提供故障事件的时间线重建、影响评估、5-Why 根因分析、
+  修复跟踪、预防措施制定和事故报告模板等完整指导。
+---
+
+# 故障分析与复盘技能
+
+> **与 troubleshooting 的区别**：本 Skill 用于**已解决故障的事后复盘**（时间线、根因、报告、预防）。如需**正在发生的问题的实时排查和修复**，请使用 [troubleshooting](../troubleshooting/) Skill。
+
+## 适用场景
+
+- 线上故障的事后分析
+- 故障复盘会议准备
+- 编写事故报告
+- 制定预防改进措施
+- 故障响应流程优化
+
+## 时间线重建模板
+
+故障时间线是复盘的基础，必须精确到分钟：
+
+```
+时间线记录格式:
+
+[HH:MM] 事件描述 | 操作人/系统 | 依据（监控/日志/通知）
+
+示例:
+[09:15] 监控告警：用户服务 API 响应时间超过 5s     | Prometheus 告警  | Grafana 面板
+[09:17] 值班人员收到告警通知                       | 张三（值班）      | 企业微信通知
+[09:20] 确认问题：用户查询接口超时                  | 张三             | 日志排查
+[09:25] 定位原因：数据库连接池耗尽                  | 张三             | HikariCP 监控
+[09:30] 发现根因：凌晨上线的批量导出功能未加分页      | 张三、李四        | 代码审查
+[09:35] 执行修复：重启服务 + 临时增大连接池           | 李四             | 运维操作
+[09:40] 服务恢复正常                               | 监控系统          | Grafana 面板
+[10:00] 发布热修复版本：添加分页和超时控制            | 李四             | Git 提交记录
+```
+
+## 影响评估
+
+### 评估维度
+
+```
+1. 影响范围
+   ├── 受影响的服务/模块
+   ├── 受影响的功能
+   └── 是否有级联影响
+
+2. 影响时长
+   ├── 故障开始时间
+   ├── 发现时间（TTD: Time To Detect）
+   ├── 响应时间（TTR: Time To Respond）
+   ├── 修复时间（TTF: Time To Fix）
+   └── 恢复时间（MTTR: Mean Time To Recover）
+
+3. 影响用户
+   ├── 受影响用户数量
+   ├── 受影响请求数量
+   ├── 错误率变化
+   └── 是否有数据丢失
+
+4. 业务影响
+   ├── 是否影响核心业务流程
+   ├── 是否造成经济损失
+   ├── 是否违反 SLA 承诺
+   └── 是否影响客户信任
+```
+
+### 故障等级定义
+
+| 等级   | 定义                             | 响应时间   | 示例                         |
+|--------|----------------------------------|-----------|------------------------------|
+| P0     | 核心服务完全不可用                 | 5 分钟内   | 全站不可访问、数据丢失         |
+| P1     | 核心功能严重受损                   | 15 分钟内  | 登录失败、支付异常             |
+| P2     | 非核心功能异常                     | 30 分钟内  | 报表延迟、搜索降级             |
+| P3     | 轻微影响，用户可绕过               | 2 小时内   | 页面样式问题、非关键提示错误    |
+
+## 5-Why 根因分析
+
+### 分析方法
+
+从表面现象出发，连续追问"为什么"，直到找到根本原因：
+
+```
+示例：用户服务 API 响应超时
+
+Why 1: 为什么 API 响应超时？
+  → 因为数据库查询耗时过长
+
+Why 2: 为什么数据库查询耗时过长？
+  → 因为数据库连接池已满，新请求排队等待
+
+Why 3: 为什么连接池已满？
+  → 因为有大量慢查询占用连接不释放
+
+Why 4: 为什么有大量慢查询？
+  → 因为凌晨上线的批量导出功能对全表执行无分页查询
+
+Why 5: 为什么无分页查询能上线？
+  → 因为代码审查未覆盖 SQL 性能检查，且缺少慢查询告警
+
+根本原因: 代码审查流程缺少 SQL 性能检查环节
+直接原因: 批量导出功能未做分页查询
+```
+
+### 分析要点
+
+1. **不停留在表象** — "服务挂了"不是根因，要追问为什么挂
+2. **不归咎于人** — 分析系统和流程的问题，而非个人失误
+3. **可操作的结论** — 根因必须对应可落地的改进措施
+4. **多因素分析** — 一个故障可能有多条因果链
+
+## 修复实施跟踪
+
+### 修复任务分类
+
+```
+紧急修复（Hotfix）:
+  - 目标：立即止血，恢复服务
+  - 时间：故障发生后立即执行
+  - 方式：回滚、重启、临时配置调整
+
+短期修复（Short-term Fix）:
+  - 目标：修复根本问题
+  - 时间：1-3 个工作日
+  - 方式：代码修复 + 测试 + 发布
+
+长期改进（Long-term Improvement）:
+  - 目标：防止同类问题再次发生
+  - 时间：1-4 周
+  - 方式：架构优化、流程改进、工具建设
+```
+
+### 跟踪表格
+
+```
+| 编号  | 类型     | 任务描述                    | 负责人 | 截止日期     | 状态     |
+|------|---------|---------------------------|--------|------------|---------|
+| F-01 | 紧急修复 | 重启服务恢复可用             | 李四   | 2024-01-15 | 已完成   |
+| F-02 | 短期修复 | 批量导出接口添加分页          | 王五   | 2024-01-17 | 进行中   |
+| F-03 | 长期改进 | 建立 SQL 审查自动化检测       | 张三   | 2024-02-01 | 待开始   |
+| F-04 | 长期改进 | 完善数据库连接池监控告警       | 赵六   | 2024-01-25 | 待开始   |
+```
+
+## 预防措施
+
+### 技术层面
+
+1. **监控完善** — 补充关键指标告警（响应时间、错误率、连接池使用率）
+2. **熔断降级** — 关键服务添加熔断和降级策略
+3. **限流防护** — 接口添加限流保护
+4. **灰度发布** — 新功能分批发布，降低影响范围
+5. **自动化测试** — 补充集成测试和性能测试
+
+### 流程层面
+
+1. **代码审查** — 加强 SQL 性能和安全相关的审查
+2. **变更管理** — 明确上线审批和回滚流程
+3. **值班机制** — 确保告警能及时触达责任人
+4. **演练机制** — 定期进行故障演练
+5. **知识沉淀** — 故障复盘结论同步到团队知识库
+
+## 事故报告模板
+
+```markdown
+# 故障报告
+
+## 基本信息
+- 故障标题: [一句话描述]
+- 故障等级: P0 / P1 / P2 / P3
+- 发生时间: YYYY-MM-DD HH:MM
+- 恢复时间: YYYY-MM-DD HH:MM
+- 持续时长: XX 分钟
+- 影响范围: [受影响的服务/功能/用户数]
+- 报告人: [姓名]
+- 参与处理人: [姓名列表]
+
+## 故障概要
+[2-3 句话描述故障现象和影响]
+
+## 时间线
+| 时间  | 事件          | 操作人 | 备注     |
+|------|--------------|--------|---------|
+| HH:MM | [事件描述]   | [人员]  | [说明]   |
+
+## 根因分析
+### 直接原因
+[描述直接导致故障的原因]
+
+### 根本原因（5-Why 分析）
+Why 1: ...
+Why 2: ...
+Why 3: ...
+Why 4: ...
+Why 5: ...
+
+### 触发因素
+[描述触发故障的操作或事件]
+
+## 影响评估
+- 受影响用户数: [数量]
+- 受影响请求数: [数量]
+- 错误率峰值: [百分比]
+- 是否有数据丢失: 是 / 否
+- 经济损失估算: [金额]
+
+## 修复措施
+### 紧急修复
+- [已执行的紧急措施]
+
+### 后续改进
+| 编号 | 任务         | 负责人 | 截止日期   | 优先级 |
+|-----|-------------|--------|-----------|-------|
+| 1   | [任务描述]   | [人员]  | YYYY-MM-DD | 高    |
+
+## 经验教训
+1. [总结1]
+2. [总结2]
+3. [总结3]
+
+## 附录
+- 相关日志截图
+- 监控面板截图
+- 相关代码变更链接
+```
+
+## 最佳实践
+
+1. **无责文化** — 复盘聚焦于系统和流程，而非追究个人责任
+2. **及时复盘** — 故障恢复后 48 小时内完成复盘
+3. **全员参与** — 相关方都参加复盘会议，确保信息完整
+4. **数据驱动** — 用监控数据和日志支撑分析，避免凭记忆推测
+5. **闭环跟踪** — 改进措施必须有负责人和截止日期，定期检查进度
+6. **知识共享** — 典型故障案例沉淀为团队知识库
+7. **预防为主** — 从故障中提炼通用的预防模式，应用到其他服务
+8. **持续改进** — 定期回顾历史故障，评估改进措施的效果