4 个可直接套用的事件通报模板（状态页文案）
故障发生时没空斟酌文案？这里给你 4 套可直接复制的事件通报模板：计划内维护、小故障、重大故障、全站宕机，每套含预告/进行中/已恢复三阶段文案，并附通报写作要点。
故障发生时，状态页上一个红绿图标远远不够——用户想知道影响什么、多久能好。但故障当前，值班人没心思现场写作文。提前备好模板，到时候填空即可，压力骤减。以下 4 套模板按场景分类，可直接取用或按需调整。
使用通则
- 通报要快，比"写得漂亮"重要得多。第一条消息不求细节，只求承认问题；
- 给时间预期要谨慎：你可以写"30 分钟后同步进展"，但用户会当真。做不到宁可不写具体时长；
- 维护预告要提前发：维护窗口越大、服务越关键，通知越要早——从提前 3 天到数周不等。
模板一：计划内维护
适用：数据库迁移、版本升级等计划内操作，需要用户提前知情。
预告（提前数天发布）
【公司名】将于 6 月 10 日 14:00（UTC+8）起进行例行维护。期间【网站/服务名】可能短时无法访问。我们将尽快完成维护，最大限度减少对你的影响。
进行中
计划内维护正在进行中。如有进展变化，我们会及时同步。
完成
本次维护已完成，服务恢复正常。感谢你的理解与耐心等待！
模板二：小故障（Minor Incident）
适用：某个次要功能异常，或仅影响少量用户。
排查中
我们发现【受影响服务】出现异常，正在全力修复。稍后会同步最新进展。
已恢复
服务已恢复！【受影响服务】目前运行正常，感谢耐心等待。
小故障模板的关键是克制：不要过度渲染影响面，也别轻易承诺精确修复时间。
模板三：重大故障（Major Incident）
适用：核心功能不可用，或大量用户受影响。
排查中
我们正在调查【受影响服务】的故障，该问题已影响部分用户。团队正全力抢修，稍后同步最新进展。
已恢复
服务已恢复！【受影响服务】目前运行正常。对此次故障造成的不便，我们深表歉意，感谢你的理解与耐心。
与模板二的差别：明确写出"影响用户"这一事实，恢复通报中加上致歉。重大故障恢复后，建议后续补发一篇复盘说明（时间线、根因、改进措施）。
模板四：全站宕机（Complete Downtime）
适用：整个服务不可用、全体用户受影响——最高级别事件。
排查中
【服务名】当前对多数用户不可用。我们已启动最高优先级响应，正在全力抢修，将持续同步进展。
已恢复
服务已全面恢复！【服务名】目前运行正常。我们对此次中断造成的影响深表歉意，详细复盘说明将在稍后公布，感谢你的理解与包容。
全站宕机的通报要点：频率更高（每 30 分钟至少一条，哪怕只说"仍在排查"）、语气更郑重、恢复后必有复盘。
让模板真正生效的两个配套动作
- 把模板存进值班手册（Runbook）：放在值班人抬手可及的地方，而不是某个没人记得的文档目录深处；
- 演练时真用：每季度做一次故障演练，要求值班人用模板在 10 分钟内发出第一条通报。模板只有被用过才是活的。
配合观测云的告警与事件时间线，值班人拿到告警确认故障后，可以直接按级别取对应模板发布，把时间花在修问题上而不是写公告上。 1
常见问题（FAQ）
Q：通报里要不要写技术原因？
进行中通报不必写（你往往也还没查清），写清楚"影响什么、我们在修、下次更新时间"即可。根因留给复盘报告，那时再讲技术细节。
Q：多久发一次进展更新？
全站宕机每 30 分钟，重大故障每 30-60 分钟，小故障可视情况放宽。关键是承诺了就要兑现，说了"30 分钟后更新"就必须更新，哪怕内容没有实质变化。
Q：模板语气可以活泼一点吗？
看品牌调性，但故障通报建议保持平实专业。幽默文案留在一切正常的日子里，用户服务中断时没有心情欣赏俏皮话。
Q：计划维护要不要也发"已恢复"消息？
要。维护完成通知是重置用户预期的信号，缺少它，谨慎的用户会持续以为服务处于不稳定状态。
