客户事故通报
先讲影响与恢复，再讲原因和补偿
把下面这次事故写成给客户的通报。结构：1）什么时间、哪些功能、影响了谁；2）现在是否恢复、我们做了什么；3）只写已确认的原因，未确认的标“仍在排查”；4）未来72小时的改进动作和负责人；5）补偿方案和下次同步时间。不要甩锅，不要用“个别用户”“系统波动”这类模糊词，全文不超过400字。 [事故时间线] [影响范围] [已确认原因]
使用建议
客户先想知道“现在还能不能用、我的数据有没有事”，原因可以晚一点，但影响范围不能含糊。
适合什么场景
- P0 故障恢复两小时后，客户成功催着要对外说明，销售已经在客户群里被追问。
- 事故只影响部分客户，但涉及账单或数据，必须主动通知而不是等对方发现。
不适合的场景
- 原因还没查清、影响面仍在扩大——这时写“根因”只会反复打脸，应先发已知事实和下次更新时间。
- 涉及安全攻击或执法调查——对外口径需法务和安全审批，不能由业务直接写。
示例
输入
时间线：14:02 部分客户登录失败，14:18 定位为证书过期，14:35 恢复。影响：约 12% 企业客户，登录和 API 鉴权失败，期间重试可能重复计费。已确认原因：证书轮换脚本漏了一个域名。
你会得到
开头写清 14:02–14:35 登录与 API 鉴权失败，约 12% 企业客户受影响，现已恢复。第二段只讲已确认原因——证书轮换脚本漏配一个域名，不展开内部追责，并说明重试可能造成重复计费，会在 3 个工作日内核对退回。最后给 72 小时动作（补齐域名清单、加到期告警、演练，由运维负责人牵头）和下次同步时间。
常见误用
- 把内部复盘原文直接发给客户——里面的“某工程师误操作”“监控缺失”会变成索赔和公关材料。
- 为了显得诚恳反复道歉，却不写影响范围和补偿——客户读完仍不知道自己的数据有没有问题。
可以这样改
- 加“给受影响客户和未受影响客户两个版本”，未受影响的只发简短说明，避免制造不必要的恐慌。
- 加“附一段可直接发在客户群里的三句话版本”，长通报走邮件，群里先稳住。