debugging-log-analyser

调试日志分析技能

将原始错误日志、堆栈跟踪和崩溃报告解析为结构化诊断，给出可能的根本原因、受影响的代码路径和具体后续步骤——不含糊其辞。

所处位置——诊断步骤

在事件响应主流程中排第二：/slo-error-budget（定框架） → debugging-log-analyser → /incident-postmortem → /oncall-runbook。它接收线上事件的原始 症状，并将根本原因诊断和修复方案交给 /incident-postmortem——这样，事后分析便以诊断为基础，而不是重新推导。 共用术语（根本原因与促成因素、缓解与解决）在 docs/craft/incident-response.md 中统一定义。

流程

如果证据尚不足以支持修复方案就贸然着手，调试便会失败。第 2 阶段就是这项技能——诊断的质量取决于其置信度，而错误的确定感会在最不合时宜的时候把响应人员引向错误方向。

1. 分类并解读证据。 对错误进行分类，沿堆栈跟踪找到实际失败的栈帧（而不是框架产生的噪声），并记录日志展示了什么、没有展示什么。引用日志时，请遮盖机密信息。 完成标准： 已确定失败栈帧，并明确说明证据缺口（日志无法告诉你的内容），而不是用猜测填补。
2. 以诚实的置信度得出根本原因。 指出最可能的根本原因，并标注其置信度（已确认／很可能／不确定）；若尚未确定，也要给出其他可能性。没有置信度标注的诊断，只是穿着白大褂的猜测。 完成标准： 根本原因附有置信度标签；若尚未确认，还要说明下一项可用于确认或排除该原因的观察结果。
3. 分别说明修复方案和缓解措施。 针对根本原因给出具体的代码级修复方案；同时明确说明最快的缓解措施，以便立即停止对用户的影响（回滚、关闭功能标志）。因为止血和疗伤是两种不同的操作，紧迫程度也不同。 完成标准： 既有针对根本原因的具体修复方案，也有立即缓解措施，且两者没有混为一谈。
4. 交接给事后分析。 提供诊断、修复方案和时间信息，让 /incident-postmortem 能依据证据而非记忆梳理时间线和促成因素。 完成标准： 事后分析可以直接依据这份输出开始，无需重新诊断。

必需输入

若用户未提供，请询问以下信息：

• 日志／堆栈跟踪／错误输出（直接粘贴或描述错误）
• 语言和框架（例如 Node.js + Express、Python + Django、Java Spring、Go）
• 上下文（问题开始前发生了什么变化——例如最近部署、配置更改、流量增加、新输入数据；或者“没有变化”也有帮助）
• 发生频率（偶发一次／间歇性／持续发生／特定更改后回归）
• 环境（本地开发／预发布／生产）
• 已尝试的操作（如有）

输出格式

---

调试报告：[服务／应用名称]

1. 错误分类

错误类型： [运行时异常／构建错误／配置错误／网络错误／内存错误／未知] 严重程度： [致命／严重／警告／提示] 复发模式： [偶发一次／间歇性／持续发生／启动时／负载下]

2. 堆栈跟踪分析

从起点开始，逐帧检查堆栈：

• 起始栈帧： [起始位置的文件、行号和函数]
• 传播路径： [错误在调用栈中的传播过程]
• 崩溃点： [最终抛出异常／触发 panic／退出的位置]

对于每个重要栈帧，请注明其属于：

• 用户代码（可在此处修复）
• 框架／库代码（通常是使用不当导致的问题）
• 系统／运行时代码（通常是配置或环境问题）

3. 根因评估

可能的根因： [用 1–2 句话以通俗英语说明] 置信度： [高 / 中 / 低——并说明原因] 需要排除的其他原因： [如果置信度不是高]

4. 受影响的代码路径

入口点： [触发调用的起始位置] 涉及的关键函数： [跟踪记录中提到的具体函数/方法] 触发问题的数据： [如果可以从日志中推断——例如空值、格式错误的 JSON]

5. 建议的修复方案

提供具体的代码级建议：

• 要修改的内容（最小修复）
• 此修改为何能修复根因
• 修复方案的权衡或风险
• 如有帮助，提供一段简短的代码片段

6. 后续调试步骤

如果根因尚不确定，请按顺序列出 3–5 个具体的调试操作：

1. [要检查的具体内容——文件、日志行、配置值]
2. [具体的复现步骤或隔离测试]
3. [具体的工具命令——例如 strace、pprof、--verbose、在 X 处添加日志]

7. 预防

提出一两项具体措施，防止此类错误再次发生：

• 在 [位置] 加强输入验证
• 针对 [条件] 添加监控/告警
• 添加覆盖 [场景] 的测试

---

质量检查

• 根因具体明确（而非“可能存在空指针问题”）
• 至少建议一项具体的代码级修复
• 后续步骤包含可执行的命令，而非模糊的建议
• 建议的修复方案应参考输入中实际使用的语言/框架（而非适用于任何语言的通用修复）
• 置信度说明了理由（而非仅写“高”或“低”，没有解释）
• 预防措施具有主动性（而非仅仅“添加错误处理”）

反面模式

• 根因描述含糊（“某处有个空值”），而非指出具体行/堆栈帧
• 忽略实际堆栈跟踪，给出适用于任何语言的通用修复方案
• 复述错误消息，而不解释其含义
• 将“添加错误处理”作为预防措施，却没有具体的防护措施
• 给出高/低置信度，却没有说明理由

使用示例

• “为什么会崩溃？” + [粘贴日志]
• “你能分析一下这个堆栈跟踪吗？”
• “我遇到了这个错误，这是什么意思？”
• “帮我调试这段日志”
• “这个异常是由什么导致的？”

示例触发短语

• “为什么会崩溃？”
• “阅读这段堆栈跟踪，告诉我问题出在哪里。”
• “诊断这些错误日志。”
• “这些异常是由什么导致的？”