错误分析与根因排查
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @org-02qudk26/error-debugging-error-analysis。
技能介绍
要解决什么问题
生产里反复出现的 5xx、超时、跨服务调用失败,往往只有堆栈片段和零散日志,团队容易在「改配置碰运气」和「加日志再发版」之间循环。本技能把分布式系统调试和生产事故分析收成一条可重复的路径:在能拿到的错误消息、stack trace、结构化日志和追踪上下文里,先界定影响面,再往下挖根因,而不是只贴临时补丁。
技能如何工作
分析范围由你传入的 $ARGUMENTS 决定,可以是具体报错、某个故障服务,或一类错误模式。典型流程包括:
- 收集上下文:时间线、受影响服务、相关日志与追踪片段
- 复现或收窄:用有针对性的实验缩小怀疑面
- 根因验证:用证据链确认原因,避免「看起来合理」的猜测
- 交付物:修复思路、测试建议,以及可观测性与错误处理上的预防项
需要更细的检查清单时,会参考 resources/implementation-playbook.md 里的分析框架。
适用边界与注意点
- 适合:调查生产事故、跨服务 RCA、设计可观测性与错误处理改进
- 不适合:纯功能开发、完全拿不到日志/追踪/错误报告、与可靠性无关的需求
- 安全:未经批准且没有回滚计划,不要动生产;对外共享诊断材料时对密钥和 PII 脱敏
使用场景
- 线上告警后需在多服务日志与追踪里还原时间线并定位首次异常节点
- 同一错误码在网关与下游反复出现,需跨服务收窄调用链与失败条件
- 事故复盘前要把堆栈、日志证据整理成可验证的根因结论与修复项
- 新服务上线后错误率上升,需结合结构化日志设计追踪与错误处理改进
适合人员
- 值班 SRE:事故窗口内要把零散报错收敛成可回滚的修复与验证步骤
- 负责微服务链路的 backend 工程师:反复出现的超时需在无完整复现环境时做跨服务 RCA
- 平台或可观测性工程师:希望把事故分析框架落到日志、追踪与错误处理规范上
- 发布负责人:发版后集中爆发 5xx,需在变更与依赖关系里找根因而非逐个 hotfix