你的 Slack 无法加载。问题出在你自己、你的虚拟专用网络、办公室的无线局域网，还是 Slack？你打开 Slack 的状态页面，显示一切正常。当你明显遇到服务中断时，它往往仍显示正常，因为公司只有在确认事故之后才会更新其状态页面——而不是在你感受到故障的那一刻。
在过去的几个月里，我构建了 OutageDeck，它读取 96 家云计算和软件即服务提供商的官方状态源，并将它们整合到一个地方。我原本以为最难的部分是前端开发。事实并非如此。困难之处在于，“官方状态”是一片泥沼。以下是我在其中发现的问题。
简而言之：
- 没有统一的状态格式。Statuspage 很常见，但长尾部分则是定制的——谷歌、Slack、Heroku、通过 RSS 提供的微软 Azure，以及使用 UTF-16 编码的亚马逊云科技。
- 提供商自己的时间戳存在滞后，有时甚至长达数天，因此你无法据此计算正常运行时间。
- 一些官方订阅源是过时的遗留物，或者建模了数千个实例，因此“它是否在线？”没有单一的答案。
- 官方状态具有权威性但滞后——这正是众包“是否宕机？”网站存在的全部原因。
- 所有这些因素促使我采用一个刻意精简的后端架构：一个 Next.js 应用程序和一个 PostgreSQL 数据库，无消息队列，每月成本约 55 美元。
没有统一标准
Atlassian Statuspage 是最接近通用语言的东西。在我的 96 家提供商中，约有 89 家暴露了类似 Statuspage 的 summary.json 和 incidents.json，一个适配器即可读取所有这些数据。有些提供商甚至没有运行 Statuspage，但仍复制了其结构——incident.io 在每个客户自己的域名上提供兼容 Statuspage 的端点，因此 Notion 和 Linear 可以使用完全相同的代码进行解析。
然后是长尾部分。谷歌以其自有格式发布 incidents.json（在 Cloud、Workspace 和 Firebase 之间共享）。Slack 拥有定制的 API。Heroku 则处于其自有格式的第四个版本。Azure 仅提供 RSS。亚马逊云科技提供的事件订阅源采用带字节顺序标记的 UTF-16编码，这会静默破坏任何假设使用 UTF-8 的解析器。“只需读取状态页面”变成了六个适配器和一堆编码检查工作。
时间戳不可信
我最初的正常运行时间数据毫无意义，我花了一段时间才弄清楚原因：我是根据每个提供商自己的 captured_at 时间戳来计算的，而这些时间戳存在滞后。有一家提供商的时间戳一度滞后数天。如果订阅源显示某个状态是“三天前捕获的”，你就无法判断服务是中断了三天，还是时间戳只是过时了。
解决办法是完全不再信任上游时间。每次观察都打上我的检查时间戳，正常运行时间是根据我看到状态的时间计算的，而不是根据提供商声称发生的时间。由此产生的推论也很重要：如果我自己的轮询器出现间隙——例如部署期间——我不会将其回填为“正常”。任何超过 30 分钟的间隙都被记录为无数据，因为虚构绿色正常状态比承认我没有监测更糟糕。
一些官方来源是化石
少数提供商在技术上拥有机器可读的状态端点，但你仍然无法使用。Stripe 的遗留状态 JSON 自 2024 年以来实际上已冻结；它将永远愉快地报告一切正常。Salesforce 的状态 API 建模了近 3,900 个单独的实例，因此“Salesforce 是否在线？”完全取决于你的组织位于哪个集群节点上。
对于此类来源，诚实的做法是在我有值得自己信任的数据之前，不发布它们。这就是为什么它们仍然缺失于列表中的原因。我宁愿解释数据缺口，也不愿伪造绿色正常信号。
订阅源对后端的影响
这些订阅源的两个特性 s
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
