能承诺的不是解决时间，是下次汇报的时间

一句话总结

FDE 的故障响应不是在系统恢复时结束，而是在报告完成时结束。即使技术上修复得无可挑剔，只要报告迟缓或表述含糊，客户记住的也只会是不安。

为什么需要这些知识

在八个技术领域中，只有客户沟通本身不属于技术。然而，它是把其他七个领域的成果交付给客户的通道；一旦这里受阻，即使诊断正确，项目仍会失败。

最常见的失败源于预期管理。而这种失败通常是因为承诺的单位选错了。

尚不知道原因时，说“下午之前解决”并不是承诺，而是赌博。能够承诺的不是解决时间，而是下一次汇报时间。“一小时后，我会整理并汇报目前已知和未知的事项”，这是始终可以兑现的承诺；每兑现一次，信任就会积累一层。

20 分钟没有消息，会让客户在想象中把故障扩大一倍。因此，故障期间的第一条消息就必须包含汇报频率：“恢复之前，我们每 30 分钟汇报一次。”

它是如何运作的

故障报告的结构顺序与日常文档不同。日常文档从背景写起，故障报告则要从影响写起。

영향     : 결제 API 5xx 비율 평시 0.1% → 최대 7% (14:10–15:40)
현재 상태: 완화 조치 적용 완료, 오류율 평시 범위로 복귀 확인
잠정 원인: 14:05 설정 배포에서 DB 커넥션 풀 크기 축소
다음 단계: 원복 완료. 재발 방지로 배포 전 설정 diff 점검 절차를 제안 예정

读者最先需要知道的是“目前谁无法做什么”和“现在是否已经恢复正常”。原因分析即使令人关心，也要排在后面。从原因写起的报告，需要读完三个段落才能知道当前状态；而在给管理层阅读的文档里，这三个段落往往根本不会被读到。

此外，还有三条规则。

用数字表述。 不要写“很多用户受到了影响”，而要写“500 响应从平时的 33 次上升到一分钟内 70 次”。形容词会被不同读者作出不同解释，这种差异日后会演变成争议。

不要以人为句子的主语。 不要写“负责人错误修改了配置，导致……”，而应写“配置变更之后……”。如果客户报告点名某位具体负责人，下次发生故障时，这个人就会隐瞒信息。无责备的报告并非道德姿态，而是为下一次诊断提速所作的投资。

翻译专业术语。 不要写“Pod 陷入重启循环”，而应写“服务器反复关闭并重新启动，导致连接中断”。状态码也是如此。数字 500 只对工程师有意义，客户需要看到的是“支付失败”。

在实际工作中会是什么样

面对同一种情况，有些表达会消耗信任，另一些表达则会积累信任。

原因尚不明确时，说“看起来不像是我们这边的问题”是在自我防御。说“目前已经确认网络和认证正常，正在检查数据层。30 分钟后会分享阶段性结果”，则是在描述同样状态的同时建立信任。

区别在于三个要素：已经确认的事实、当前正在做的事、下一次汇报时间。 只要包含这三项，即使仍不知道原因，也能形成一份有效的汇报。

最后是升级处理。这并不是承认失败。预先给自己定下“30 分钟内没有进展就升级”的规则，升级决定就会成为流程，而非情绪反应。在客户看来，“我们已调集专业人员”表达的是积极响应，而不是能力不足。

故障结束后的沟通

恢复完成后，对话的性质会发生变化。故障期间的问题是“现在进展如何”，结束后的问题则变成**“为什么会发生，是否还会重演”。** 回答这个问题的文档必须不同于故障期间的汇报，并且应在几天内完成。超过一周后，人们的记忆会彼此分化，连核实事实本身都变得困难。

文档需要包含四项内容：按时间顺序记录事件、原因、为何发现得晚，以及准备改变什么。 第三项最常被遗漏，但最有价值的改进往往正是从这里产生。如果问题原本 30 分钟就能修好，却用了两小时才察觉，那么需要改进的不是修复流程，而是发现问题的机制。

写改进事项时，必须同时注明由谁负责、何时完成。 没有负责人和期限的改进清单，会在下一份故障报告中原样再次出现。如果清单上有十项，结果往往一项也做不成；更诚实的做法是只保留真正效果显著的两三项，其余项目可以记录下来，但明确决定不实施。

这里有必要明确 FDE 的位置：实际执行改进通常是客户的职责，我们负责提供依据。 因此，比起“你们必须这样做”，“这个指标呈现出这样的结果；如果据此设置告警，下次就能在 30 分钟内发现”更容易被接受。提供判断材料，让客户自行决定，最终反而能让更多改进真正落地。

最后，也要记录做得好的地方。 如果回滚在 5 分钟内完成，那是因为有人事先建立了这套流程；如果这个事实没有被记录，下次就失去了提前做这类准备的理由。当故障报告变成只收集坏消息的文档时，人们就会厌恶写它，随后连记录本身都会消失。

下一次实操要做什么

你将以前三个课程中找出的数据为材料，制作一页故障报告：包含所有必备章节和具体数字，不点名个人，并用不含技术术语的语言撰写面向客户的摘要。评分不评价文笔好坏，只检查这些条件是否全部满足。