调查模式 (investigate)

调查模式（investigate）

概述

investigate 是 GStack 中用于深度调查的技能。当遇到复杂问题、不确定问题所在、或需要根本原因分析时，使用这个技能。

它的核心是：不猜测，用实验和数据找到真相。

为什么需要 investigate

作为一个程序员，你一定遇到过：

“这个 bug 很奇怪，我试了很多办法都没修好”
“不知道问题在哪，看代码完全没问题”
“总觉得是某个地方的问题，但又不敢确定”

investigate 就是解决这些的。

核心方法论

1. 假设驱动

❌ 乱试：这个不对，试试那个
✅ 假设驱动：提出假设 → 设计实验 → 验证

2. 二分查找

❌ 整个代码库乱找
✅ 二分查找：一半一半排除

3. 控制变量

❌ 同时改很多地方
✅ 一次只改一个变量

工作流程

第一步：定义问题

问题描述：用户提交表单后显示"服务器错误"

不是：
- "有个 bug"

应该是：
- 什么操作触发的？
- 错误信息是什么？
- 100% 复现还是偶发？
- 是所有用户还是部分用户？

第二步：收集信息

# 1. 查看错误日志
tail -f logs/error.log

# 2. 查看请求
curl -v form/submit

# 3. 查看数据库
SELECT * FROM submissions WHERE id = ?

# 4. 查看监控

第三步：形成假设

基于收集的信息，提出假设：
- 假设1：数据库连接池满了
- 假设2：API 超时
- 假设3：数据验证失败

第四步：设计实验

验证假设1：
- 检查连接池使用情况
- 如果 > 80%，假设成立

第五步：验证和迭代

实验结果支持假设 → 修复
实验结果不支持假设 → 形成新假设 → 重复

实践案例

案例 1：间歇性 500 错误

背景：用户偶尔报告 500 错误，但日志里看不到

1. 定义问题
   - 间歇性，不是 100%
   - 只有部分用户
   - 无规律

2. 收集信息
   - 查看 APM
   - 统计错误时间分布
   - 对比成功请求

3. 形成假设
   - 假设：某个 API 超时

4. 设计实验
   - 加长超时时间
   - 观察是否还出现

5. 验证
   - 错误消失 → 假设成立
   - 修复超时配置

案例 2：内存持续增长

背景：服务运行一段时间后内存越来越高

1. 定义问题
   - 每次请求后内存增长
   - 不请求时稳定

2. 收集信息
   - heap snapshot
   - memory timeline

3. 形成假设
   - 假设：缓存没有清理
   - 假设：事件监听器累积

4. 设计实验
   - 用 Chrome DevTools 追踪
   - 看哪个对象在增长

5. 验证
   - 发现事件监听器累积
   - 修复unload逻辑

案例 3：数据库查询慢

背景：某个查询突然变慢

1. 定义问题
   - 之前不慢
   - 现在 5 秒

2. 收集信息
   - EXPLAIN 查询
   - 查看索引
   - 查看表大小

3. 形成假设
   - 假设：索引失效
   - 假设：数据量变大

4. 设计实验
   - REINDEX
   - 添加更合适的索引

5. 验证
   - 查询时间 5s → 50ms

常用命令

日志分析

# 实时查看错误
tail -f app.log | grep ERROR

# 统计错误次数
grep ERROR app.log | wc -l

# 查看某个时间段的日志
sed -n '/10:00/,/10:30/p' app.log

性能分析

# Node.js
node --inspect app.js
# Chrome DevTools > Memory

# Python
python -m cProfile app.py

# 数据库
EXPLAIN ANALYZE SELECT * FROM ...

网络分析

# curl 详细输出
curl -v http://api/example

# 抓包
tcpdump -i eth0 port 3000

速查卡片

核心方法

假设驱动
二分查找
控制变量

工作流

定义问题
收集信息
形成假设
设计实验
验证迭代

不要

不要乱试
不要猜测
不要同时改多个地方

与其他技能

systematic-debugging - 更结构化的调试流程
audit - 代码质量审查
investigate - 探索性调查

查看源文件: GitHub原始文件