服务状态公示页

状态页的第一件事不是画图，是定义什么叫正常。口径不清楚，故障时会和用户在评论区吵起来。

服务清单（按用户视角列，不按你的架构）：

• 网站访问
• API 接口
• 图片 / 下载
• 后台管理

三种状态定义（写进页面说明里）：

• 正常：核心功能可用
• 降级：能用但慢或部分功能不可用（如图片加载慢）
• 故障：核心功能不可用

别列太多：5 个以内。列 20 个内部微服务，用户看不懂，出事时反而要解释更多。

顺手定义 SLA 口径：可用性怎么算（按分钟？按请求成功率？）、统计周期多长（30 天）。写在页面底部，既是承诺也是边界——承诺 99.9% 就要能测出 99.9%，测不出来的别写。

状态页和监控面板的区别：监控是给你看的，状态页是给用户看的，所以数据来源要更「官方」——用用户视角的探测，不是服务器内部指标。

探测脚本做的事：

1. 对每个服务做一次真实请求（HTTP GET / 接口调用）
2. 记录：状态码、响应耗时、时间戳
3. 判定状态（连续 N 次失败才判故障，避免抖动误报）
4. 写入 data/status.json

{
  "updated": "2026-09-27T08:00:00Z",
  "overall": "ok",
  "services": [
    { "name": "网站访问", "status": "ok", "latency_ms": 180 }
  ],
  "incidents": [ { "date": "2026-09-20", "title": "...", "status": "resolved" } ]
}

关键设计：状态页必须独立于被监控的服务（别放在同一台机器上），否则服务挂了状态页也打不开，这是最尴尬的故障。

托管建议：状态页放 GitHub Pages / Vercel 或另一台机器，探测脚本放你的服务器上。

用户打开状态页只想知道两件事：现在好没好、最近是不是老坏。

页面三块：

1. 顶部大状态条：一句话 + 颜色（正常绿 / 降级黄 / 故障红），带更新时间
2. 服务列表：每项一行，状态点 + 名称 + 90 天可用率小条形图
3. 历史事故：按时间倒序列最近 10 条，每条写「时间 · 影响范围 · 原因 · 已解决」

90 天小条形图：每天一格，绿色正常、黄色降级、红色故障。这一块最能建立信任——敢把历史摆出来，比任何「我们很稳定」都有说服力。

事故文案怎么写（模板）：
09-20 14:05 检测到图片加载失败 → 14:22 定位为 CDN 节点异常 → 14:40 切换备用节点恢复。影响：约 35 分钟，图片加载失败。原因：上游 CDN 节点故障。

别写：「因不可控因素导致服务异常」——这种话只会让人更不信任。

订阅方式：放一个「订阅状态变更」的入口（RSS 或邮件，见 Newsletter 场景），让用户不用反复刷页面。

上线：独立托管（别和被监控服务同机）+ HTTPS + sitemap 可收录（用户会搜「XX 状态页」）。

故障时的动作顺序（写进你的运维手册）：

1. 探测告警触发 → 确认是真故障（自己访问一次）
2. 先把状态页改成「故障」（哪怕原因还没查清）——用户最怕的是「坏了但没人说」
3. 排查修复
4. 恢复后改回「正常」，并补一条事故记录

关键原则：先公示，后定责。 一句「已确认故障，正在处理，预计 X 点前恢复」比沉默两小时强一百倍。

复盘留档：每次事故写清时间线、根因、修复动作、下次怎么避免。这些记录积累起来就是你最好的工程资产，也是给用户的交代。

观测指标：给状态页本身埋 pv + status_view，故障时 PV 会飙升——这个数字能反过来验证你的用户规模，也是「有多少人在意」的真实反馈。

演练：每季度手动触发一次假故障（改 status.json），确认告警能到、状态页能改、团队知道流程。没演练过的流程不算流程。