状态页全绿时，客服正在替它解释故障

如果监控已经报警、客服连续收到登录失败工单，状态页仍显示“所有系统正常”，绿色图标会把客户推回客服、销售和社交平台。此时先检查组件、公开事件和通知是否接在同一条事故沟通路径上。

这套事故沟通要同时完成两件事：状态页准确反映客户正在经历什么；产品、邮件与客服在客户准备报障之前，把同一条进展送到他常用的触点。

全绿先看组件和事件有没有接上

状态页顶部的绿色结论来自页面里的组件与活动事件。Atlassian 的 Statuspage 文档写得很明确：页面没有配置组件时，只要没有活动事件，顶层状态始终会显示 All Systems Operational。组件建了以后，它的状态仍由人工、API 或监控集成更新。监控报警和页面变色之间，没有天然的同步关系。官方对顶层状态的说明也因此值得在上线前读一遍。

这里还有一个容易遗漏的区别：单独修改组件状态不会给订阅者发送通知，创建或更新事件才会触发通知。于是，一家公司可能已经把“登录服务”从绿色切成黄色，订阅客户仍收不到消息；也可能工程师已经在内部事故群里处理，公开页面因为没人创建事件而一直全绿。

排查时顺着事故沟通路径检查：哪类监控信号触发事故，谁决定公开，哪些客户功能受到影响，哪一步创建事件并发送通知。只看页面能不能打开，找不到信息在哪一步中断。

客户按任务判断影响，组件也要用他们认识的名字

工程团队习惯按数据库、消息队列、集群和区域看系统，客户只关心自己还能不能登录、上传文件、调用 API、导出报表。状态页如果原样搬出内部架构，客户仍然无法确认眼前的失败是否属于已知事故。

Atlassian 建议从用户依赖最深、过去出现过故障的产品能力中选择组件，并给复杂组件补上说明。实际整理时，先从最近三个月的客服工单和事故记录里找高频任务，再把内部服务映射到这些任务。一个队列故障同时影响“报表导出”和“邮件发送”，页面就应呈现客户能识别的两个影响面，工程团队在后台继续保留同一个技术根因。

要把组件分组、状态定义、事件模板、订阅入口和独立托管整理在一起，服务状态页策划工具可输出页面结构与事件更新格式。完成后再做一次演练：模拟登录变慢，观察客户能否只凭组件名称找到对应状态，并准确判断受影响的功能。

第一次更新不必交出根因，但要说清客户看到什么

事故刚出现时，团队常想等工程师找到根因再公开。等待期间，客户看到的只有失败和一片绿色，客服只能逐个解释“还在查”。

Atlassian 的事故响应手册先问客户影响：客户看到了什么、多少客户受影响、从什么时候开始、已经产生多少支持请求。确认事故存在以后，首次外部沟通的任务很简单——告诉客户团队已经知晓并正在处理。这套响应流程并不要求第一条消息交出完整根因。

一条可用的首次更新至少包含四项：受影响的客户动作、已知影响范围、团队正在进行的处理、下一次更新时间。恢复时间还无法确定时，直接说明当前不能给出时间，并约定何时再更新。客户此时最关心的是接下来的工作怎样安排；沉默会让他不断刷新、重试和询问。

状态页统一信息，产品和客户渠道负责送达

状态页适合保存唯一的一条事件时间线，客户不会因此自动发现它。Front 的做法是把状态信息通过弹窗放进产品，客户在提交工单前就能看到当前事件；事故结束后，团队再用邮件发布复盘并提醒客户订阅。Signiant 则在新客户引导和技术支持通话中持续介绍状态页，让客户平时就知道去哪里找。

对于 API 产品，产品文档与帮助中心工具可先规划排错内容和文档导航，再把状态页入口放到开发者处理错误时最容易看见的位置。

触达方式要跟事故影响相配。客户还能登录时，产品内横幅最接近问题发生的位置；产品无法访问时，邮件、短信、客服自动回复和公开社交渠道要把人带到独立托管的状态页。组件订阅还能让 API 客户只接收 API 事件，减少无关提醒带来的退订。

因此，状态页负责统一内容，其他渠道负责送达。每个渠道只写简短影响和状态页链接，进展继续在同一事件里更新，客服和销售也引用这条记录，避免几套说法同时流通。

Atlassian 已经发了状态更新，沟通仍然出现空档

Atlassian 对 2022 年 4 月事故的复盘，把这种空档写得很具体。4 月 5 日 7:46 UTC 出现第一张支持工单，团队在 9:03 发布首条状态页更新，11:13 说明已经确认根因并着手修复。首次面向社交平台的公开说明直到 4 月 7 日 00:56 才发出。

问题随后扩展到联系人和协作方式。部分受影响客户的联系人资料已经过期，事故又破坏了站点管理员信息；客户升级请求同时从邮件、电话、CEO 通道、LinkedIn 和支持工单进入，不同工具让团队难以掌握整体情况。Atlassian 在公开事故复盘中承认，团队应该更早开展广泛沟通，更早说明暂时无法准确给出恢复时间，并建立更完整的跨团队沟通职责。

这段经历说明，发出一条状态更新只能完成公开沟通的一部分。联系人是否有效、客户是否知道状态页、哪些渠道承担提醒、谁持续更新，都会影响客户最终收到什么。

访问量之外，更该看客户有没有少走一次客服

FiveStars 在一次严重生产事故中，把电话等候中的客户引导到公开状态页。Atlassian 披露，这个页面两天获得 10,000 次访问，电话量随后降到客服可处理的水平，客服服务水平翻倍，并解决了 98% 的来电问题。这个结果的价值在于，状态页进入了客户正在求助的地方，访问与客服分流发生在同一场事故里。

团队复盘自己的状态页，也要把页面数据和事故、客服数据放在一起看：从确认事故到首次公开用了多久，两次更新之间最长隔了多久，受影响组件的订阅客户中有多少收到消息，同一问题的重复工单是否在更新后下降，事故结束后还有多少客户继续追问。页面访问量很高，只能说明很多人来过；重复报障减少，才说明客户从页面得到了能安排工作的答案。

事故发生时，状态页仍然全绿，先检查组件是否覆盖客户任务，再确认公开事件是否已经创建、订阅通知是否已经发出，最后查看产品、邮件和客服有没有把客户带到同一条时间线。三处都接通以后，再用重复工单和更新间隔衡量页面有没有真正替客服分流。