本页目录
看案例时，先抓转折点
第 16 章不是故事收尾，也不是给前面内容找几个例子。
它真正值钱的地方，是让你看到一条证据链到底怎么推进：
- 起点症状是什么
- 第一反应为什么会猜错
- 哪个证据让方向改了
- 为什么最后能收敛到这个解释
如果这些没抓住，案例就很容易被读成“别人查到了答案”。
别只记工具，不记判断怎么转向
最常见的错法有四种：
- 只记最后结论，不记中间转折
- 只看用了什么工具，不看为什么那时切工具
- 觉得案例和自己环境不一样，就直接跳过
- 把案例读成故事，不把它拆成可复用动作
这些错法都会把案例的工程价值抹掉。
还要再防一种更隐蔽的删减：只保留“最后查出来了什么”，把那些走错的路都删掉。真实排障最有价值的地方，往往不是答案本身，而是哪些假设曾经看起来合理，后来又被哪条证据推翻。
看案例时，至少要把这条链抄出来
以后读一个案例，至少按这个顺序抄一遍：
- 起点症状
- 首轮假设
- 哪条证据先把首轮假设推翻
- 为什么要换层、换工具或换方向
- 最终解释靠什么证据站住
这条链抄不出来，就说明案例还没读透。
一个最典型的错法：工具记住了，转折没记住
很多人读完案例以后，只能记住“这里用了 perf”“那里用了 trace”“最后查到了某个根因”。
但真正能迁回自己现场的，不是这串工具名，而是：
- 为什么一开始没先上那个工具
- 为什么到了那个时刻才切过去
- 哪条证据说明旧方向该停了
案例最值钱的不是结果，是这些转折点。
先把案例里的转折和复用动作抄出来
先把案例回放成 5 栏
以后每读完一个案例，都压成这 5 栏：
- 起点症状
- 首轮误判
- 关键证据
- 转向动作
- 最终解释
先找“哪条证据让方向改了”
如果只能留一句话，就留这句：
哪条证据让团队不再沿着原方向继续挖。
这是案例里最值得反复看的地方。
同样别放过“好得不真实”的性能结果。一次案例里如果突然出现无法解释的性能飙升，也要像查故障一样追根因；很多所谓的优化红利，最后只是测试环境偶然没邻居干扰，或者恰好独占了缓存，上线后根本复现不出来。
再用同样结构回放自己的一个故障
读完案例以后，不要停在书里。用同样 5 栏，回放你自己团队的一个真实故障。能回放出来，才算真的带走了方法。
复盘时最好把错路也带上时间戳留下来。只有把“什么时候怀疑过 A、为什么放弃 A、又是什么时间点转去 B”都保住，案例才不会被改写成一条事后诸葛亮式的直线。
最后把方法、层次和工具收成一条完整链
第 16 章解决的是“整条证据链怎么走”。读完整本书以后，真正的收口不是记住作者用了哪些工具，而是下次你也能按类似顺序，把问题越查越小。