Status page：它们的用途

status page 真正用来做什么

故障期间，客户不知道问题来自自己的连接、账号，还是你的服务。没有 status page，这种不确定会变成支持请求、社交媒体消息和反复出现的“只有我这样吗？”问题，全部在团队最忙着修复实际问题时落到你们身上。

status page 吸收这部分压力。一个链接，一个查看地点，随着事故发生而更新。它不会修复故障，但能移除每次故障在原问题之上制造的第二个问题：困惑的客户。

页面上应该有什么

至少应该有客户真正关心的组件：主站或应用、客户会集成的 API，以及其他有独立故障模式、值得分开跟踪的部分。每个组件应显示当前状态（operational、degraded、down）和滚动 uptime 数字。

除此之外，事故更新也重要：出问题时的一句简短说明、有更多信息时的更新，以及修复后的解决说明，会把页面从静态仪表盘变成真正的沟通渠道。可选地，可嵌入 uptime 徽章是低成本方式，让页面能从 README 或文档站点被发现。

为什么应该由真实 monitor 驱动，而不是手动更新

需要人在事故期间手动把 status page 切到“红色”的页面有明显缺陷：它依赖人注意到并记得更新，而那个人正好在最忙的时候。它也容易在实际已经坏掉很久后，仍停留在“all systems operational”。

绑定到已经监控网站的同一批 monitor 后，检查失败时 status page 会自动更新，恢复时也会自动恢复；事故期间不需要任何人记得去碰它，这正是最重要的时候。

让 status page 失效的错误

手动维护且陈旧。如果页面比现实慢几个小时，客户会学会不信任它，然后回到提交工单。

没有事故历史。只显示当前状态、没有历史事故或 uptime 记录的页面，无法回答“它实际上可靠到什么程度”，而这往往是潜在客户真正想知道的问题。

埋在没人能找到的位置。没有从产品、文档或页脚链接出去的 status page，在故障期间帮不上任何人。

写好事故更新

status page 的自动部分，也就是组件变红或变绿，只告诉人们有东西变了。它不会说明发生了什么或下一步会怎样，这正是简短人工说明的作用。“我们已知悉影响 [component] 的问题并正在调查”即使没有更多细节，也比沉默好；第二次更新说明已知信息，修复后再发布解决说明，通常就足够处理真实事故。

没有时间戳或下一步的模糊安抚（“我们正在查看”）如果之后不再更新，几乎不比什么都不说好。标准不是文采，而是及时发布，然后跟进。

公开与内部 status page

公开 status page 面向客户和任何集成你 API 的人；它需要简单、准确，并且不泄露内部细节（不需要说具体哪个数据库表失败）。内部 status page 只对团队共享，可以包含更多细节和更多组件，因为受众已经理解相关系统。很多团队最后会需要两者：给客户看的干净公开页面，以及给值班人员看的更详细内部视图。

Holter 如何处理

Holter 的 status page 由检查网站的同一批 monitor 驱动；组件变红是因为真实检查失败，恢复变绿也是因为它恢复，中间没有手动步骤。页面带有 uptime 历史、事故说明和可嵌入徽章，并且每个页面都可以从 Free 计划开始，配合 5 个 monitor、5 分钟检查，无需信用卡。