挂了别装死：vibe 项目的对外状态页与事故沟通实战

本篇讲的是对外事故沟通，与站内三篇是同一事故的两面 / 上下游，不重复：vibe-project-incident-runbook-guide（事故响应 Runbook）讲的是"对内：报警之后一个人怎么灭火"，本篇讲的是"对外：用户面前怎么交代"——灭火和交代同一时间发生，互链 https://vibefix.work/zh/explore/vibe-project-incident-runbook-guide；vibe-project-observability-guide（可观测性）讲的是"装眼睛耳朵发现事故"，本篇讲的是"发现之后向外播报"，互链 https://vibefix.work/zh/explore/vibe-project-observability-guide；vibe-project-changelog-release-communication-guide（Changelog）讲的是"版本发布的喜报沟通"，本篇讲的是"事故的坏消息沟通"，一喜一忧成对，互链 https://vibefix.work/zh/explore/vibe-project-changelog-release-communication-guide。

一、为什么需要状态页：事故沟通的三个受众

凌晨三点，你的服务挂了。你还在睡觉，用户已经在群里 @ 你了。等你爬起来修好，群里已经有三个人在问"这服务是不是跑路了"。修 bug 用了 40 分钟，解释和安抚用了 4 天——这就是没有状态页的一人项目的日常。

事故沟通有三个受众，缺一不可：

• 付费用户：他们花了钱，事故对他们近乎违约。他们要的不是道歉，是交代——发生了什么、影响我多久、我的数据有没有事。
• 免费用户：他们没花钱，但花了信任。一次"悄悄挂掉、悄悄修好"的经历，足够让他们换竞品。他们要的是"这个人靠谱"的证据。
• 你自己：状态页是你的事故台账。每一次翻黄、翻红、翻绿，都是一条带时间戳的公开记录。三个月后有人问"你们稳定性怎么样"，你甩出状态页的历史记录，比说一万句"我们很稳定"都有用。

核心的判断题是这个：用户先发现，还是你先公告？这是两种完全不同的信任结局。用户先在群里喊"挂了"，你半小时后姗姗来迟说"我们已知晓"——用户记住的不是故障，是"被蒙在鼓里"。反过来，你在用户察觉之前就把状态页翻黄、发出第一条公告——故障还是那个故障，但"隐瞒"这个扣分项被你亲手拆掉了。

所以状态页的本质不是技术设施，是信任基础设施。它回答的不是"系统怎么样"，而是"这个人值不值得继续信任"。一人团队尤其需要它：你没有客服团队，没有 PR 部门，状态页就是你 7×24 小时在线的发言人。

记住下面这张双泳道图：灭火（内部响应）和交代（对外播报）是两条并行的泳道，同一时间发生，互不阻塞。你不需要等修好了才说话——事实上，你越早说话，修 bug 的压力越小，因为用户已经知道你在处理了。

深色风格的网站服务状态页仪表盘截图，显示各组件运行状态

二、状态页信息架构：组件拆分与四种状态

按用户感知边界拆组件，别按你的代码模块拆

新手的状态页常常长这样：一盏大灯，写着"All systems operational"。然后登录挂了，灯还是绿的——因为"网站能打开"。这种状态页不如没有，它消耗的是你仅剩的那点信任。

拆分的原则只有一条：按用户能感知到的边界拆，而不是按你的代码模块拆。用户不关心你的微服务拓扑，他关心的是"我能不能登录""能不能付款""App 会不会闪退"。建议的最小拆分：

• 网站前端：用户第一眼看到的地方；
• API 服务：核心链路，挂了等于全挂；
• 移动端 App：发版引入的 bug 只影响这一端时，别让整站跟着背锅；
• 第三方依赖：支付、邮件、云服务商，单独列出来。Stripe 挂了不是你的错，但用户只认你——点名写出来，既是诚实，也是甩锅的正确姿势。

每个组件独立亮灯，用户一眼就知道"哦，只是邮件通知延迟了，核心功能没事"，而不是对着一盏绿灯猜谜。

四种状态的判定线，事故前就要写下来

operational / degraded / partial outage / major outage，这四个词每个状态页都在用，但"黄和红的边界在哪"，十个团队有十个答案。你必须在事故发生之前把判定线写下来，因为事故进行中时，你是没有余力开会讨论"这算黄还是红"的。参考线：

• operational：全部组件正常，错误率在基线内；
• degraded：非核心组件异常，或 P95 响应时间翻倍——能用，但体验打折；
• partial outage：核心组件部分用户受影响——比如某个地区的用户登录失败；
• major outage：核心组件完全不可用——所有人、全部功能。

判定线越具体，翻页时手越不抖。"P95 翻倍"比"感觉有点慢"好执行一百倍。把这条线写进你的 Runbook，翻页就变成一道判断题，而不是作文题。

深色风格的网站服务状态页仪表盘截图，显示各组件运行状态

三、轻量方案选型：买、租还是白嫖

一人团队选状态页方案，只看四个维度：成本、搭建时间、自动化程度、能不能让用户订阅。下面三个是截至 2026-10-16 亲核过官网的靠谱选项：

• Better Stack（买服务）：免费计划就含状态页，可以发布到自定义子域名；自带每 30 秒的多地 uptime 检测，宕机时状态页自动翻页，不用你半夜爬起来手动点；事故管理是联动的——监控报警、on-call、Slack 频道、状态页更新是一条链。免费版够一人团队起步；要自定义设计、邮件和 API 订阅、密码保护的私有页，付费从每月 30 美元起，额外页面约 12 美元一页起。
• UptimeRobot（买服务）：免费计划也有公共状态页，给你一个唯一链接，也支持 CNAME 绑自己的域名；每个状态页能生成 SVG 徽章，嵌进 GitHub README 或文档页脚，不用打开状态页就知道你挂没挂；还有第三方依赖监控（比如 Stripe、AWS 的组件状态），"到底是我挂了还是上游挂了"一目了然；SLA 徽章和邮件报告适合要给客户交 SLA 的小团队。
• Upptime（白嫖自建）：开源模板，玩法很妙——用 GitHub Actions 每 5 分钟 ping 你的接口，用 GitHub Issues 的自动开 / 关来记录事故，用 GitHub Pages 托管状态页。零服务器成本，数据全在 git 里，自带审计链。仓库 1.7 万多 star，MIT 协议，截至 2026-10-16 当天仍有提交在跑，10 月中旬刚发了上游包的新版本，活跃得很。适合已经在用 GitHub、愿意花半小时按模板搭的人。

决策建议：先有再好。今天就能上线的方案，就是最好的方案。一人团队从 Better Stack 免费版或 Upptime 起步，半天内让状态页上线，之后再谈品牌定制。只有一条铁律：别自研状态页，更别把它和你的服务部署在同一台机器上。服务挂了的时候状态页也跟着挂，这种黑色幽默，用户看一次就记一辈子。

什么时候从免费版升级？三个信号：订阅用户超过免费额度了、需要密码保护的私有状态页给大客户看、想要去掉服务商 branding。这三个信号出现任意一个，说明你的项目已经大到配得上付费版了——这是好消息，不是成本。

四、监控联动：让状态自己翻

所有状态页事故里最丢人的一种：服务挂了两小时，状态页还全绿，配文"All systems operational"。用户截图发到群里，你连反驳的余地都没有——你的状态页在撒谎。

解法只有一条：状态翻转必须和监控联动，不能靠人肉。人肉翻页的问题不是懒，是人总有睡着的时候。规则设计参考：

• 心跳检测连续失败 N 次（比如 3 次，约等于 15 分钟），自动把对应组件标为 degraded；
• 确认是核心链路且大面积失败，自动升级为 partial / major outage；
• 恢复后连续成功 M 次，自动翻绿，并追加一条"已恢复"的时间线记录。

N 和 M 的取值，是误报和漏报的权衡：N 太小，网络抖动一次就翻黄，用户被"狼来了"搞疲了；N 太大，真实事故半小时没动静。从 3 次起步，按你的误报率调。

三个方案的联动方式各不相同，但思路一致：Upptime 靠 Actions 检测到宕机自动开 issue、恢复自动关 issue，issue 的开合就是事故的开合；Better Stack 的监控检测到宕机直接更新状态页，顺带触发 on-call 和 Slack 频道；UptimeRobot 的监控和状态页是同一套数据，翻页不需要二次录入。

手动翻页可以作为兜底保留——比如第三方依赖出问题，但你的监控没覆盖到——但它不能是唯一路径。验收标准很简单：你在睡觉的时候，状态页也要会自己变黄。

五、事故公告写作：三段式模板

事故公告不需要文采，需要结构。记住三段式，照着填就行：

一句话说清事实，不带情绪、不带术语。
哪些用户、哪些功能、从什么时候开始。
我们正在做什么，预计什么时候有下一条更新。

看一个改写对照。反面教材（真实世界里很常见）：

由于上游 Redis 集群主从切换异常导致部分 API 网关超时，
我们正在紧急处理，请稍后再试。

用户看完只知道一件事：你很忙。他不知道"我有没有被影响""我的数据丢没丢""我要等多久"。改写后：

14:20 起，登录和下单接口响应变慢，部分请求会超时。
所有需要登录的用户；已登录用户的使用不受影响，
历史订单和数据不受影响。
我们正在切换备用链路，预计 15:00 前发出下一条更新，
届时会说明是否恢复。

几条语言纪律，写进模板旁边贴着：

• 承认，不解释过度："是我们的问题"一句话就够，用户不欠你一篇架构科普；
• 不甩锅给用户：永远别写"请检查你的网络"，除非你 100% 确定；
• 不给做不到的 ETA："预计 15:00 恢复"做不到，就写"15:00 前发出下一条更新"——承诺更新时间，比承诺恢复时间安全得多；
• "正在调查"也是一条有效更新：每 30 分钟更新一次，哪怕内容是"仍在排查，已排除 A 和 B"。沉默是最差的更新。

公告的受众是非技术用户，写完自己读一遍：我妈能看懂吗？看不懂就重写。

六、订阅与通知：让用户自己订阅

状态页立好了，别指望用户事故时自己想起来去刷。正确姿势是让用户提前订阅，事故时通知自动找上门。三个通道按优先级排：

• 邮件订阅：覆盖面最广，不需要用户装任何东西；事故公告、恢复通知自动推送；
• RSS：被严重低估的通道。零成本、去中心化，技术型用户用自己的阅读器订阅，稳定得不像话；
• Webhook：给重度用户和你自己——把状态变更接到 Slack / Discord / 自己的 on-call 通道，顺带给自己也发一份，防止"状态页翻了但我不知道"。

订阅入口要放在用户找得到的地方：网站页脚、帮助中心、报错页面。最蠢的藏法是"状态页有个 URL 但没人知道"。上线第一周，在更新日志里写一条"我们上线了状态页，欢迎订阅"，把第一批订阅者攒起来——事故发生时，这批人是你的缓冲垫，不是火药桶。

顺带把状态页的域名定下来：status.你的域名.com。别用服务商的默认二级域名凑合——事故时用户在地址栏看到的是你自己的域名，信任感完全不一样。CNAME 过去 10 分钟的事，别在这上面省。

七、复盘公开到什么颗粒度

事故结束 24 小时内，写复盘。写两版：内部版和公开版。内部版给自己看，越细越好；公开版发在状态页的时间线上，给所有人看。颗粒度的分界线：

• 公开写：完整时间线（几点几分发生了什么）、影响范围（多少用户、多长时间）、技术层面的根因、已经做了的补救和防止复发的措施；
• 不公开写：具体到人的指责（"都是小王的错"）、还没修复的安全细节（等于给攻击者发邀请函）、真实的商业数据（损失了多少单）。

我的判断是：公开复盘是最高级的信任广告。用户对"不出事故"的服务没有概念（也没人信），但对"出了事故、说清楚了、改明白了"的服务印象极深。一篇写得好的 postmortem，比十条发版公告更涨粉。Cloudflare、AWS 这些大厂每次大事故都公开写长文，不是因为他们闲，是因为他们算过这笔账。

一人团队的优势在这里反而明显：你不需要过法务、过 PR，一篇诚恳的复盘两小时就能发出去。大公司的流程走下来，用户早忘了。

八、演练清单：上线前先"假装挂了"一次

状态页、监控联动、公告模板、订阅通道——这四样配齐了还不算完。上线前，做一次"假装挂了"的全链路演练，5 步：

• 第一步：挑一个非核心组件（比如邮件通知），故意让它挂掉，或者直接模拟一次检测失败；
• 第二步：计时——监控多久报警？状态页多久自动翻黄？把分钟数记下来；
• 第三步：按三段式模板发一条测试公告，看看写一条合格的公告你要花几分钟；
• 第四步：检查订阅通道——测试邮箱收到邮件了吗？RSS 更新了吗？Webhook 触发了吗？
• 第五步：复盘演练本身。哪个环节卡住了？翻页规则要不要调？模板要不要改？

验收标准：全链路跑通一次，各环节耗时记录在案。演练中发现的每一个断点，都是真实事故里会让你多慌 10 分钟的坑。演练不丢人，真实事故里手忙脚乱才丢人。

结语：坏消息也要好好说

Changelog 是喜报，状态页是病危通知书。喜报人人会写，坏消息才见功力。一人团队没有品牌部替你说话，你的每一次事故沟通，都是用户在心里给你打分。

把这篇的 checklist 收拢一下：状态页上线（今天）、组件拆好（按用户感知）、判定线写死（事故前）、监控联动（自动翻页）、模板备好（三段式）、订阅入口放出来、演练跑一遍。从第一条做到第七条，一个周末够了。

灭火的手艺，见 《事故响应 Runbook》；喜报的写法，见 《Changelog 与版本发布沟通》。灭火、交代、报喜，三件套齐了，你的项目才算有了对外沟通的完整闭环。