如何创建 status page

状态页只有在事故期间会自动更新，并且客户需要时能找到，才值得拥有。这些步骤会从一开始就构建一个由真实监控驱动的状态页，同时提供足够的人为说明来减少支持噪音。

1. 1

   决定要展示哪些组件

   列出客户能识别、并且会分别关心的产品部分：主站或应用、如果别人会集成则包括 API、如果会独立失败则包括结账或计费，以及任何停止后客户会注意到的关键后台服务。列表要短而有意义；三到六个可识别组件，比二十个团队外没人懂的内部标签更好。

2. 2

   把每个组件绑定到真实 monitor

   把页面上的每个组件连接到已经检查它的监控，也就是日常监控网站的同一个由外向内检查或 heartbeat。这正是页面能自动更新的原因：底层检查失败时组件变红，恢复时又变绿，中间不需要人工操作。如果某个组件背后没有监控，要么添加一个，要么不要把它放到公开页面上。

3. 3

   发布，并放到人们会找的地方

   把状态页链接放在事故期间真的会被找到的地方：网站页脚、文档、支持自动回复、入门邮件和 API 文档都是常见位置。技术上已经上线但没有任何地方链接的状态页，并不能减少支持工单。如果客户有合同或 SLA，确保这就是故障期间你会引用的页面。

上线之后

真实事故期间，只要知道有问题，就发布一条简短更新，即使还不知道原因也一样。“我们已经知晓并正在调查”比沉默更好。有更多信息时再更新，修复后发布解决说明。自动组件状态处理“可用或不可用”；简短的人为说明处理影响、范围、临时方案和下次更新时间。事故期间两者都重要。

第二步该加什么

页面上线并正确连接到真实监控后，添加能减少重复问题的内容：可用率历史徽章、RSS 或邮件订阅，以及团队在压力下可以复用的简短事故模板。如果底层监控包含 TLS 或域名过期检查，决定它们是否值得作为客户可见组件，还是更适合作为主站状态的一部分来表达。即将过期的证书是真实风险，但未必需要自己占一条公开状态。

常见错误

列出每个内部组件。一个包含十几个客户不认识的组件的页面，比一个只有三四个真正重要组件的页面更难一眼读懂。如果团队需要详细拆分，把它留给内部视图。

没有连接到任何东西。没有接到真实监控的状态页，只是一个需要有人记得更新的静态页面，而这恰好会在大家最忙的时候失败。真实来源应该是已经在检测问题的监控。

发布后没有任何链接。和第 3 步一样，如果状态页上线了，却没有从网站、文档或支持流程链接，关键时刻没人会找到它。像测试告警一样测试可发现性：问问客户第一时间会去哪里看。