技术判断：面对未知怎样推进

Google 的《Site Reliability Engineering》记录过一宗 App Engine 排障：一个内部文档应用变慢，团队先怀疑数据存储索引，因为一种相关调用增多。但连不从该存储读取的静态内容也变慢，原假设解释不了这一点。团队先用更多计算资源缓解延迟，继续调查；后来发现，安全扫描触发了应用已有缺陷，产生大量访问白名单对象，每次请求都要检查它们。修复缺陷并清理对象后，性能恢复。¹

这是一份通用软件可靠性案例，不是 FDE 客户案例。它对 FDE 的启发在于判断的顺序：出现相关性时提出假设；遇到反例时放弃假设；需要缓解影响时，不把暂时有效的措施写成已找到根因。技术深度不仅表现为会用某个工具，也表现为知道当前证据还不足以支持哪句话。

先建立一项能站得住的基础

这里没有必要先选出一个全能的自己。更可行的起点，是有一项能站得住的工程基础，再让其他能力围绕真实任务生长。能够读懂程序、跟踪输入输出、定位失败并修改实现，是可以不断迁移的底座。不会的领域可以逐步学习；不知道系统为什么出错，却只能更换提示词碰运气，会限制可以安全承担的工作范围。

怎样知道基础是不是足够扎实？可以选一个自己已经做出的功能，沿着一次请求往下追：用户提交了什么，程序怎样检查，记录保存在哪里，远端服务没有回应时怎么办。然后人为制造一个故障，先解释预期现象，再运行检查。若结果与预期不同，就沿记录继续追，而不是立刻重写全部程序。这是练习建议，目的在于建立可以反复使用的排障方法。

这里的故障练习应在合成数据、隔离环境和明确权限内进行。不能为了学习，在真实客户流程中随意拔掉依赖或改变配置。没有可控环境时，可以先用已有故障记录做推演，把需要实际验证的部分留下，而不是假称已经完成实验。

追踪时，画出本次请求实际经过的少数步骤，标明每步的输入、输出、存储状态和失败信号。不要先画一张包含所有产品名称的架构大图。图中的一条箭头若不能对应到记录、代码或接口约定，就应写成待确认；能画出来不等于发生过。

读陌生代码时，先从入口和一条具体输入走进去，再沿着调用找改变状态的位置。文档帮助理解设计意图，测试展示部分约定，运行记录展示某次行为。三者冲突时，先记录冲突，不自行宣布其中任何一个必然正确。决定当前应该怎样工作，还需要需求和负责人判断。

让检查能够改变自己的想法

一个解释若能包容所有结果，就很难指导下一步。比如“系统不稳定”既能解释慢，也能解释快；“模型随机”既能解释错，也能解释对。应把解释缩到可以观察的条件：是输入缺了字段、某一版本解析错误，还是下游没有收到请求？每一种解释都应有可能被某条证据削弱。

本书建议在调查记录里保留四列：观察到了什么；可能的解释；做什么检查可以区分；检查后还不能确定什么。观察栏只写实际看到的内容，不先放结论。“三条请求返回空值”是观察，“客户数据都不合格”已是远超样本的判断。

选择下一步时，同时考虑信息价值和风险。只读一条已有请求记录，可能比更换整个组件更快区分问题；改变多个参数，即使结果变好，也很难知道哪项改变起作用。必须主动试验时，记录初始配置、预期现象、停止条件和恢复办法。

不要把暂时没有复现当作问题不存在。环境、身份、版本或输入不同，都可能让检查失去比较意义。尤其是用管理员账户成功后，不能据此宣布普通用户的权限问题已经解决。调查者要能指出自己测了哪条路径，也要能承认仍缺哪一条。

一份不要求写新项目的调查题

以下是合成教学材料，不对应 Google 的真实故障。你接到一句反馈：“新版本把申请丢了。”现在有四条观察：

1. 测试环境中，管理员发送带有场次编号的请求，返回“已生成草稿”。
2. 线上反馈来自普通账户；界面截图里没有场次编号，也没有请求编号。
3. 新版本只改过输入解析，但尚未把这次线上输入与旧版本作过同条件比较。
4. 你拥有测试环境权限，可以查询获准查看的日志；没有线上写入或重放权限。

请先列出三个不同假设，再选一个信息量较大、影响较小的下一步。分别写出：检查出现什么结果会支持它，什么结果会使你转向，什么结果仍然无法下结论。

可供比较的假设包括：输入不足，被系统停在澄清步骤；普通账户受到权限限制；解析改动造成回归。仅有这些材料，还不能选出根因。一个合理起点是先向反馈者取得脱敏后的请求定位信息，查看是否有对应记录和返回状态；拿不到定位信息，就先说明观察缺口，不把“没有找到记录”写成“请求没有发生”。

如果要在测试环境复现，应尽可能保持输入、身份能力和配置可比。分别改变一个条件，再比较结果。若只能用管理员账户，应把普通账户这一分支留为未验证，或请求获授权者协助；不得把无法访问的线上环境当作自己已经检查过。

假定后来找到对应记录，显示请求因缺少场次而停在澄清步骤。此时“申请丢失”应改为更具体的结论，但调查还没有自动结束：用户是否看见了澄清提示，界面是否解释下一步，仍需检查。修复可能落在提示，也可能落在数据传递，不能只因后端按规则返回就否定使用者的困难。

评价这份调查，不看你是否猜中预设答案，而看你能否区分观察与解释、保持比较条件、选择不会越权的动作，以及在新证据出现后更新结论。若所有动作都是“升级模型”“扩大权限”“重新部署”，应退回补充为什么这些动作能区分现有假设。

让 AI 帮忙查找，自己保留判断

可以请 AI 找入口、列调用关系、提出可能原因，或生成一份待检查的修改。但应要求答案指向具体文件、接口或记录，再亲自核对关键路径。找不到对应实现的解释只能留在线索栏。即使位置存在，也要确认它属于当前版本，并且在相关输入下真的会执行。

一种有效的学习用法是先预测，再请工具协助运行或解释，最后自己说明差异。不要在看到工具给出的答案后，把它倒填成自己的事前判断。保留原预测很有价值：它能显示你究竟误解了输入、规则，还是运行环境。

对 AI 提出的修复，至少能回答四个问题：修改针对什么已观察的错误；为什么会改变该行为；哪些原来正确的情形可能受影响；不能部署时如何保留可审阅结果。不能回答，就缩小修改范围或寻求复核。审核一份自己无法理解的大改动，不会因为“有测试通过”就自动变得可靠。

工具可以减少查找和试写工作，但不能给出你没有的授权，也不能替领域负责人决定业务规则。关于工具对学习与工作时间的影响，见当Agent也能写代码，FDE会怎样变化；本章不把一次使用经验推广成固定效率倍数。

求助也是一种技术判断

有用的求助包不必很长，但应让接手者知道：影响是什么，哪条输入能复现，当前版本和环境是什么，试过哪些检查，结果是什么，还有哪些假设未排除。附必要的脱敏片段，避免让同事重新走完已经查清的路。

同时给出停止点：哪些生产动作你无权执行，什么现象出现时应由负责者接手，现有缓解能维持到何种条件。这里的边界来自系统和团队约定，不能靠新人的勇气补上。

技术成长可以体现在调查范围逐步扩大，但无需把每次问题都变成一人独立攻克。能把一个模糊抱怨收敛成可复现问题，或用一个反例及时否定昂贵的错误方向，本身就是可以检查的贡献。最终应留下解释和材料，让下一个人不用依赖你的记忆才能继续。