把「太慢了」翻译成工程问题 — FDE 的客户沟通

• 客户的话是疼痛报告，不是缺陷报告
• 翻译提问法 — 五条轴
• 坏回答，好回答
• 期望管理 — 换掉承诺的单位
• 故障正酣时的沟通
• 亲手练习

客户的话是疼痛报告，不是缺陷报告

工程师之间会说「p95 翻倍了」，客户只会说「太慢了」。把这个差距当成客户的错的那一刻，FDE 的工作就拧了。客户没有义务精确描述症状，报告了疼痛就已经尽到了他的本分。把它变成可测量的问题，完完全全是你的工作。

本博客 FDE 工程师养成 RPG 的任务标题正是这个形状：「太慢了」「连不上」「有时登录不上」。因为真实现场的报告，大都以这种形式抵达。本文讲的就是把这些句子搬进工程学的手艺。下文出现的对话，全部是为说明而构造的示例。

翻译提问法 — 五条轴

沿五条轴切开，「太慢了」就变成可测量的问题。按顺序逐条问会变成审讯，更好的方式是把问题织进对话，同时在脑子里核对五个格子是否填满。

• 从什么时候开始 — 有了起始时间，就能与那个时刻的部署、配置变更、流量变化交叉比对。「一直如此，还是某天开始」是第一个岔路。
• 谁，在哪里 — 是所有人还是部分人，办公室内还是外，只有某种权限的用户吗？范围直接收窄嫌疑层级。
• 做什么的时候 — 登录时、搜索时、还是保存时？这是复现路径的原材料。
• 慢到什么程度 — 几秒？十次里几次？把形容词换成数字的格子。
• 和什么相比 — 比昨天慢，还是比预期慢？没有基线，连修没修好都无法判定。

五个格子填满后，「太慢了」就变成了：从上周二开始，只有从总部外部接入的用户，在导出报表时，平时 3 秒变成 30 秒，再前一周还正常。这句话已经是诊断计划的一半，可以直接接进故障诊断手册的复现步骤。

坏回答，好回答

同一场景下，有的句子消耗信任，有的句子积累信任。三个场面，逐一对照。全部是构造的示例。

模式很明显。坏回答的共同点是防御：先划清责任边界，用没有根据的乐观脱身，把客户的假设拒之门外。好回答的共同点是三要素：已确认的事实、正在做的事、下次汇报的时刻。第三个场面尤其关键。客户的假设即使是错的，也要当作待验证对象而非当场驳回——这样下次客户才会继续把观察讲给你听。

期望管理 — 换掉承诺的单位

期望管理的失败，多半源于承诺的单位选错了。在原因未明的阶段说「下午之前解决」，那不是承诺，是赌博。能承诺的不是修复时刻，而是下次汇报的时刻。「一小时后，我把已知和未知整理后向您汇报」永远做得到，而每兑现一次，信任就复利一次。

用区间说话是同一个原理。不确定的日程不要给单点时刻，而给乐观到保守的区间，区间收窄一步就更新一步。还有：消息越坏，越要早说。拖到截止前才通知延期，损失的信任比延期本身更多。提前两天送达坏消息的 FDE，被记住的身份不是拖延日程的人，而是管理日程的人。

故障正酣时的沟通

故障期间，平时的规则会反转。平时汇报的是完成的分析；故障中，未完成但准点的汇报优先于精致但迟到的汇报。规则四行写完。

• 先固定节奏。「恢复之前每 30 分钟汇报一次」应该写进第一条消息。杳无音讯的 20 分钟，会让故障在客户的想象里翻倍。
• 先讲影响。原因分析再有意思也先忍住。现在谁做不了什么、有没有绕行方案，这个在前。
• 翻译术语。不说「Pod 进入重启循环了」，说「服务器反复关了又开，所以连接会断」。
• 不拿人当主语。不说「有人把配置改错了」，说「配置变更之后」。无责的语言，是故障期间保住信息流动的安全装置。

还有，升级求援不是失败自白。事先给自己定一条规则——30 分钟没有进展就上报——升级的决定就从情绪变成了程序。在客户面前，「我们调来了专家」读作响应的信号，而不是无能的信号。

亲手练习

沟通不是背句子背出来的，是在压力之下开口练出来的。

• FDE 工程师养成 RPG — 8 个领域里客户沟通等级太低时，即使诊断正确任务也会失败。游戏里选择何时汇报的选项，就是本文内容的可玩版。
• FDE 课程路线图 — 查看客户沟通领域的自检标准。

FDE 完全指南系列

• 上一篇: FDE 故障诊断手册 — 从访问权限到报告的六个步骤
• 下一篇: PoC 为什么到不了生产环境 — 成功标准、安全评审、交接