4. 信息收集方法：数据、访谈、观察等技巧
信息收集是解决问题的第一把钥匙。你想想看，问题都说不清楚，后面再牛的分析工具也白搭。
我见过不少团队，上来就拍脑袋做方案，结果翻了车才回头补信息。说白了，信息收集拼的不是工具多高级，而是你有没有把「该问的人、该看的数据、该去现场踩的点」都走一遍。
这一章我把自己摸爬滚打的经验拆成三块：数据怎么挖，访谈怎么问，观察怎么看。每个方法我都会告诉你——什么场景用，怎么用，坑在哪。
4.1 数据收集：让事实自己说话
数据不会骗人——前提是你采的数据得靠谱。我见过有人拿测试环境的日志当生产数据做分析，得出来的结论跟实际差了十万八千里。
4.1.1 数据来源
| 来源类型 | 典型例子 | 优点 | 注意点 |
|---|---|---|---|
| 业务数据库 | MySQL、PostgreSQL、MongoDB | 结构规整，能做SQL聚合 | 要做好脱敏，别把用户隐私拉出来 |
| 日志系统 | ELK、Splunk、CloudWatch | 时序完整，能还原操作轨迹 | 日志量巨大，得先圈定时间窗口 |
| 埋点数据 | 用户点击、页面停留、报错堆栈 | 行为级细粒度 | 埋点要统一规范，否则字段对不上 |
| 第三方API | 监控告警、CI/CD状态、JIRA数据 | 快速拿到上下游信息 | 小心限流和缓存延迟 |
4.1.2 数据清洗要点
原始数据基本都脏。我拿一段日志举例：
2025-03-15 09:12:33.456 ERROR [order-service] [req-abc-123] Order creation failed: timeout waiting for payment
2025-03-15 09:12:33.457 WARN [payment-gw] [req-abc-123] Retry attempt 1/3
2025-03-15 09:12:33.459 INFO [order-service] [req-abc-123] Fallback to local cache
注意看，同一请求ID跨了三个服务，时间戳只差几毫秒。如果不把请求ID串联起来，你根本看不出这是一次完整失败的链路。
清洗原则就三条：去重、补空、对齐时间轴。我个人习惯在Python里用pandas先做一轮数据概览，看null比例和异常值分布，心里有数再动手。
4.2 访谈技巧：问对人，问对话
数据拿不到的地方，得靠人去补。但访谈可不是随便拉个人聊两句就行的。
4.2.1 三类访谈怎么选
| 类型 | 适用场景 | 耗时 | 产出质量 |
|---|---|---|---|
| 结构化 | 需要横向对比多个人的回答 | 较短 | 标准高，但可能丢细节 |
| 半结构化 | 探索未知问题，兼顾深度和广度 | 中等 | 最常用，深度与量化兼得 |
| 非结构化 | 完全开放性，一线员工闲聊式 | 较长 | 容易爆出隐藏问题 |
说说我的经验。做系统故障复盘时，我通常先用非结构化聊一轮，让当事人自由回忆「当时发生了什么」。等关键事件串起来了，再拿半结构化提纲追问细节。但如果是做用户满意度调研，那就得上结构化问卷，不然结果没法对标。
4.2.2 提问技巧
- 多问「什么」和「为什么」：少问「是不是」，多问「具体发生了什么」、「你觉得是什么原因」
- 追问不打断：对方说到一半，就算你猜到了答案，也等他说完再确认
- 录音征得同意：敏感场合我建议只记笔记，别录音，否则对方会紧张
- 最后问「还有什么想补充的吗」：很多关键信息就在这句里
避坑小贴士：千万不要在访谈里评判对方。「你们这里流程不对啊」这种话一出口，对方立刻防御性回答。换成「我注意到这里有个操作顺序，你当时是怎么考虑的？」——信息就出来了。
4.3 现场观察：看比问更真实
你能想象吗？有一次我花了一周分析日志都没找到的Bug，最后坐在运维旁边看了他点两下鼠标就破了。
为什么会这样？因为日志没记录的操作轨迹，在真实场景里就是关键步。说白了，观察是数据与访谈之间的「验证器」。
4.3.1 观察方式对比
| 方式 | 怎么做 | 优点 | 缺点 |
|---|---|---|---|
| 参与式观察 | 你上手操作，边做边记录 | 能亲身感受痛点 | 可能因为你的介入改变流程 |
| 非参与式观察 | 站在旁边看，不干扰对方 | 看到最真实的状态 | 对方可能紧张动作变形 |
| 录像回放 | 录屏或现场录像后逐帧分析 | 可反复看，细节不遗漏 | 隐私合规风险大 |
我个人的建议是：前几次观察用非参与式，等熟悉流程了再上手参与式。录像回放只用于关键操作步骤分析，而且必须告知对方。
4.3.2 观察清单示例
【现场观察检查表——以Web后端部署流程为例】
□ 环境准备：是否先拉了最新代码？有没有遗漏配置文件？
□ 构建过程：有没有报错？日志输出有没有可疑的WARN？
□ 部署方式：手工脚本还是CI/CD？有没有人绕过流程？
□ 验证步骤：部署后是自动跑 smoke test 还是人肉检查？
□ 回滚准备：如果失败，有没有现成的回滚按钮？
□ 沟通环节：出问题时，运维和开发是怎么修通的？
你看，这些细节在文档里根本不会写，只有站在旁边看着人家一步步操作才能发现。比如那个「绕过流程」——我在一个项目里发现运维嫌CI/CD太慢，自己手动scp包上去，结果导致环境不一致，线上Bug复现不出来。要不是观察，这问题永远查不到。
4.3.3 什么时候必须去现场
- 数据与访谈结论对不上时（必去）
- 问题在特定时间/特定环境才复现（必去）
- 涉及人机交互、操作习惯相关的Bug（强烈推荐）
- 远程排查超过2小时没进展（考虑去一下）
嗯，这一章的内容差不多就是这些。信息收集不是一次性动作，而是动态迭代的过程。我建议你下次遇到棘手问题时，别急着分析，先用本章的方法把三方信息都过一遍——数据、访谈、观察，缺哪个补哪个。你会发现，很多问题在收集阶段其实就已经露出了答案的尾巴。