核心用法
Deep Debugging 是一套面向生产级、高风险、反复出现或原因不明的软件故障的系统性调试方法论。其核心流程遵循 7 阶段工作流：
- Phase 0 — 事故门控：优先评估用户/生产影响，高严重性事件需先考虑回滚或功能开关，再进行诊断
- Phase 1 — 快速分诊：排查重启、环境变量、依赖安装、缓存等明显 setup/runtime 问题
- Phase 2 — 证据收集：精确定位错误信息、复现路径、影响范围、最后变更点
- Phase 3 — 假设验证：每次仅提出一个可证伪的假设，明确证明/证伪方式
- Phase 4 — 二分收窄：沿「请求→应用→服务→数据库/外部 API→响应」链条逐层隔离故障点
- Phase 5 — 最小修复：仅修改最小必要表面，禁止顺带重构，优先可逆变更
- Phase 6 — 验证闭环：提供包含根因、证据、修复、验证的完整调试报告
- Phase 7 — 预防复发：针对生产级、反复性、安全相关或耗时故障，强制添加回归测试、监控改进、运维手册或知识沉淀
显著优点
- 风险控制严格：默认只读权限，生产写入/回滚/凭证变更需显式用户授权；禁止打印密钥、令牌、客户数据
- 方法论成熟：借鉴 SRE 事故响应与科学调试方法，避免「随机修复-祈祷-上线」的无效循环
- 适用场景精准：明确区分适用边界（401/403/500、部署失败、集成故障）与禁用场景（明显拼写错误、缺失安装）
- 输出模板化：INCIDENT SNAPSHOT、DEBUG REPORT 等结构化输出，提升团队协作与事后复盘效率
潜在缺点与局限性
- 启动成本较高：对于简单 bug（如拼写错误、依赖未安装）强制走 7 阶段流程反而低效
- 假设依赖经验：Phase 3 假设质量高度依赖调试者对系统架构的熟悉程度
- 生产环境受限：read-only-by-default 设计可能阻碍某些需要临时写操作才能复现的故障诊断
- 工具链依赖：部分能力（如
scripts/incident_snapshot.sh、stack-specific checklists）需要预置基础设施支持
适合人群
- SRE / 运维工程师处理生产事故
- 后端开发者排查复杂集成或认证问题
- 技术负责人建立团队级调试规范与事故响应机制
常规风险
- 证据污染：调试过程中重启服务或重新部署可能破坏故障现场，需在 Phase 0 优先决策是否保留现场
- 假设偏见：调试者可能过早锁定假设而忽略反证，需强制「一次一假设」规则约束
- 修复漂移：即使要求最小修复，人为因素仍可能导致范围蔓延，需通过「3 次失败重启」机制强制反思
- 敏感信息泄露：虽然禁止打印 secrets，但日志审查时仍需人工二次确认 redaction 完整性