挂了要不要吭声：目录站的故障状态页和事故公告该怎么搭
挂
做目录站的人对半夜的告警都不陌生。真正难受的不是挂的那几十分钟，是第二天醒来发现：搜「品牌名 打不开」，排在前面的是某个第三方监测工具自动生成的页面，以及一条不知道谁发的论坛帖，而你自己什么都没说。
出声的方式有两种：一个平时就得准备好的状态页，一套临时不会写歪的事故公告模板。这两件事都该在没出事的时候做完。
图片来源：网络，版权归原作者所有，侵权请联系删除
状态页放哪：第一条是不能跟你一起挂
把状态页放在自己的主服务器上是很多人的第一选择，也是最没用的选择——主站挂掉的时候它一定跟着挂。
现实一点的做法是独立托管：可以是第三方状态页服务，也可以是一台放在别的机房、别的网络、甚至别的服务商的小机器。域名 status.example.com 指过去，解析也别和主站绑在同一处。这样即使主站的 DNS、CDN、数据库全线出问题，这个页面还能应答。
组件不要贪多，5 到 10 个就够，而且要用用户能理解的名字：
- 网站访问（前台）
- 条目提交与管理后台
- 图片和静态资源
- 站内搜索
- 开放 API
- 证书与 HTTPS
每个组件三种状态足够：正常、受影响、中断。层级再多就用不起来了，值班的人自己也分不清「部分降级」和「性能下降」有什么区别。
事故公告怎么写：先说用户能感知的那件事
事故公告最常见的毛病是写成了内部通报：先交代数据库主从切换，再解释 CDN 回源失败。用户不关心这些，他只想知道自己现在能不能用。
一个好用的模板，五段，顺序不能换：
- 一句话现状：条目提交功能目前不可用，网站浏览正常。不带形容词，不带猜测。
- 影响范围：写用户能感知的行为，不要写内部模块名。说「无法提交新站点」，而不是「写入队列阻塞」。
- 已经做了什么：已回滚某次变更、已切换到备用节点。动词开头，让人看到在动。
- 下次更新时间：整篇公告里最重要的一句，写具体时间点和时区。
- 时间戳：每条更新都带时间，全文统一用一种时区。
两条纪律：不要猜原因，「怀疑是 DNS 问题」事后被打脸是最伤信任的；收尾必须有一篇复盘，用户接受中断，但不接受没有下文的中断。
要不要让它被搜索引擎收
这个问题躲不掉，因为总有一天用户会拿「你们是不是挂了」去搜。三种做法：
| 做法 | 适合谁 | 代价 |
|---|---|---|
| 整站 noindex | 大多数团队，默认选这个不丢人 | 用户搜品牌词时看不到官方答复 |
| 主状态页可索引，事故详情页 noindex | 想让求助者能找到入口的站 | 历史事故页不会长期挂在结果里 |
| 全部可索引 | 把可靠性当品牌叙事的站 | 旧事故可能长期占据品牌词结果 |
需要提醒的是用 noindex 去「消灾」的想法。业内流传很广的一篇文章叫《给事故页加 noindex 是自己坑自己》，论点很朴素：藏不掉事故，只能藏掉你自己对这个事故的版本。记者照写，用户在社交平台照讨论，第三方追踪站照收，最后排上去的全是别人的转述。更稳的做法一般是中间那档：主状态页正常收录，事故详情页也能访问，但用稳定的 URL 并归一到一个固定的事故列表。
另外几条细节：
- 标题别堆关键词。「产品名 + 服务状态」就够了，重复堆「挂了」「打不开」看着像垃圾页。
- 一个事件一个 URL。按筛选项生成一堆地址，信号就散了。
- 状态页别进主站 sitemap。它和你的主内容是两类东西，混在一起只会干扰。
- 恢复之后别撤表。把它常年挂在页脚或者帮助中心，下次出事时只需要填内容。
和站点本身的关系：三条不能破的纪律
状态页之外，事故期间主站自己的行为也很关键，而这恰恰是最容易临时乱来的地方：
- 不要用状态码撒谎。短暂维护用 503 并带上 Retry-After；不要 301 到首页，不要返回 200 的空壳页。前者让搜索引擎知道这是临时的，后者会把首页地址收进一堆错误结果里。
- 事故期间不上线任何无关变更。叠加变更会让复盘变成猜谜。
- 改 DNS、改 robots、动整站 noindex 这类操作必须走审批。它们的影响范围和「修一下 bug」完全不是一个量级。
没出事时先做的五件事
- 把组件清单写出来，别等到现场发明结构
- 公告模板锁在一个谁都能找到的位置
- 定发布节奏：首报尽快，之后固定间隔更新，哪怕内容只是「仍在排查」
- 指定发布责任人（按角色而不是按人），并且让他有权直接发
- 演练一次：在内部贴一次「测试事故」，走完整个流程
状态页这件事的收益不在平时，而在于某个半夜，你不用现想第一句话该写什么。