用户不怕你说坏了，怕的是你什么都不说。
一、沉默了四十分钟
支付回调挂掉的那天，桑禾的第一反应是修。四十分钟里，他重启服务、翻日志、换密钥，手机在桌上亮了七次，都是用户在问「付了钱没到账」。
四十分钟后服务恢复。他发了一封道歉邮件，只有一句话：「已经修复。」当天有三个用户申请退款，其中一个在退款理由里写：「不知道你们还在不在。」
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
沉默会被填满。 用户看不到你的后台，只能用自己的想象补；想象通常比事实更糟。
沟通是运维的一部分。 它和技术处置并行，不占用修复的时间；一个人也要留出这十五分钟。
沟通不解决技术问题，但决定用户是否留下。 修得快而说得晚，和修得慢但一直说，用户的判断完全不同。
二、五种状态与一条时间线
状态页不需要复杂，五个状态、一条时间线就够。
| 状态 | 含义 | 用户该做什么 | 什么时候用 |
|---|---|---|---|
| 正常 | 所有核心路径可用 | 无需动作 | 默认状态 |
| 维护 | 计划内不可用 | 按公告时间避开 | 提前至少 48 小时公告 |
| 降级 | 核心路径可用但变慢 | 重试或稍后再试 | 延迟高于基线 2 倍 |
| 部分故障 | 某些功能不可用 | 换一条路径完成 | 单一功能或单一区域 |
| 重大故障 | 核心路径不可用 | 停止操作，等待更新 | 登录、支付或数据写入失败 |
状态要按功能列，不按服务器列。 用户关心「导出能不能用」，不关心「worker-2 是否健康」。
状态要能自动更新一半。 探针结果自动映射到状态，人工只负责写文字；纯手动更新的状态页，忙起来就会停在「正常」。
时间线从发现开始写。 第一条公告写「我们已发现」，不写「我们正在调查」；调查是内部动作，用户要知道的是你知道了。
维护要提前 48 小时。 临时维护也要发，哪怕只有十分钟；没公告的维护会被当成故障。
降级也要标。 只在内部知道「今天慢」，用户会以为是自己的网络问题。
恢复不等于结束。 恢复公告要写清「已恢复」与「是否补数据」，这两件事用户最关心。
| 时间点 | 写什么 | 渠道 |
|---|---|---|
| 发现后 15 分钟内 | 什么功能、影响谁、下次更新时间 | 状态页 + 邮件 |
| 每 30 分钟 | 进展、预期、用户要不要动手 | 状态页 |
| 恢复后 30 分钟内 | 恢复时间、影响范围、是否需要操作 | 状态页 + 邮件 |
三、三条公告模板
模板的价值是在慌乱时不用组织语言。
首次公告（发现后 15 分钟内）。 写三件事：什么功能、影响谁、下次更新什么时候。例：「14:03 起，支付回调处理失败，已付款订单可能延迟到账。影响约 34 个账户。我们正在处理，15:30 前更新。」
更新公告（每 30 分钟）。 写进展与预期，不写内部细节。例：「已定位为回调验签失败，正在回滚 14:00 的版本。已延迟的 12 笔订单会在恢复后自动补处理，无需重新付款。15:45 再更新。」
恢复公告（恢复后 30 分钟内）。 写三件事：恢复时间、影响范围、要不要用户动手。例：「15:22 全部恢复。14:03–15:22 之间的 12 笔订单已补处理完成，无需操作。如仍有异常，请回复这封邮件。」
不要写「请耐心等待」。 它没有信息量，还会让用户觉得自己被敷衍。
三条模板配一张节奏表。 什么时间点写什么、发在哪里，事先定好，出事时只填内容不排流程。
不要写「小问题」。 对你小，对正在付款的用户不小；形容词一律换成事实。
给出下一次更新时间。 这是最重要的一句；它把不确定变成了可等待。
别承诺没验证过的原因。 「疑似数据库问题」可以说，但要说「疑似」，并在下次更新里纠正。
四、受影响面与沟通成本
受影响面要算，不要估。
账户总数 = 120
本次受影响 = 34 → 占比 28.3%
受影响订单 = 12 笔 → 占当日订单约 2.1%
公告条数 = 3 条（首次、更新、恢复）
每条撰写与发布 ≈ 12 分钟 → 单次事故 36 分钟
一年 4 次事故 → 144 分钟 = 2.4 小时/年
按 4 小时/月预算计，占全年 48 小时的 5%
受影响面按账户算，不按请求算。 一个账户重试十次，仍然是一个账户受影响；按请求算会把影响夸大到十倍。
沟通成本很低。 一年 2.4 小时，比一次退款纠纷的处理时间还短；不沟通省下的不是时间，是信任。
状态页可以是一张静态页。 一人产品不需要复杂系统；一个静态页加手动更新，足够覆盖 4 次/年的事故。
状态页要独立于主站。 主站挂了，状态页得还活着；放在同一台机器上，等于没有。
公告要能被订阅。 邮件或 RSS 都行；让用户自己决定要不要第一时间知道。
五、行动清单与复算验收
先把模板写出来，再谈状态页工具。
- 列出五个状态，并为每个状态写一句用户可读的定义。
- 把核心功能拆成 3 到 5 项，作为状态页的行。
- 写好首次、更新、恢复三条模板，填好占位符。
- 规定首发时限 15 分钟、更新间隔 30 分钟。
- 把状态页部署到独立域名或独立托管。
- 加一个邮件或 RSS 订阅入口。
- 维护窗口提前 48 小时公告，写清起止时间。
- 每次事故后记录沟通耗时与用户反馈。
验收标准：故障发生时，你能在 15 分钟内发出包含功能、影响面与下次更新时间的公告；做不到，说明你的沟通还依赖临场发挥。
使用边界与实操验收
本文处理的是对外沟通，不涉及事故的技术处置。
技术处置不归本文。 止损、回滚与数据修复在事故响应一篇里讲；本文只解决「说什么」。
法律与赔偿不归本文。 违约与退款条款走合同与合规口径，公告里不要自行承诺赔偿。
不要用公告代替修复。 一直更新但没有进展，用户会更快失去耐心。
别把状态页做成营销页。 它唯一的用途是告知状态；放满功能宣传，会让人找不到关键信息。
公告要留档。 每次事故的公告原文存下来，下次复盘与合同争议都用得上。
语气要一致。 首次公告简短、更新公告具体、恢复公告明确；三封都保持同一个说话的人。
别在公告里甩锅。 「云厂商故障」可以写在原因里，但不能成为唯一解释；用户买的是你的产品。
关键参考与核验范围
核验日期：2026-10-25。以下链接用于核对状态页与故障沟通的一般做法，本文未逐条引用其内容。
- Atlassian Statuspage：事故沟通 ：用于核对事故沟通的阶段与模板结构。
- Google SRE：管理事故 ：用于核对事故期间的角色与信息流。
引用口径。 本文只借用「分阶段公告 + 固定更新节奏」这一一般做法；34、12、36 与 2.4 全部是教学假设，与上述材料无关。
核验范围。 核验的是「三条模板能否覆盖一人产品的常见故障」，不是比对某家状态页服务的功能。
如何自行复核。 取上一次故障，看首次公告与发现时间相差多少分钟；超过 15 分钟，就把模板提前填好。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。