别再拿Uptime百分比糊弄用户了

Can we stop with the uptime percentages?

别再拿Uptime百分比糊弄用户了

最近我发现GitHub、CI、AI和Slack等服务频繁宕机,访问状态页时总被一堆99.72%、99.09%这样的数字轰炸。这些看似接近满分的数值,在基础设施专家眼中差异巨大,就像地震里6.2级和7.8级的区别。但普通用户根本看不懂这种非线性指标。Jason Gorman曾指出,从90%到99%的可靠性提升难度,与从99%到99.9%一样大。状态页作为服务可靠性的公开接口,不该只服务于懂行的工程师。与其展示晦涩的百分比,不如直接告诉用户:过去30天里,GitHub Actions有12小时受影响。这种表达方式更直观,也更容易被大众理解。

  1. proxysna

    更广泛的受众开始使用状态页面,是因为服务的不可靠性变得比以前更加明显,而不是反过来。我从未不得不为 bear blog 或 protonmail 使用状态页面,因为我从未遇到过问题,或者只是从未注意到。

    我现在被要求去查阅 GitHub、CircleCI 或微软服务等状态页面,因为我需要知道为什么构建无法通过,为什么无法打开仓库,为什么我的工作停滞不前。

    百分比很重要,只是当涉及到像 GitHub 这样互联网的关键组成部分时,它们为何重要就变得显而易见了。我高度怀疑过去一个月里 12 小时这个数字。微软一直淡化他们与 GitHub 性能相关的问题已经有一段时间了,我认为现在还不是开始相信他们的时候。维护这些基础设施既是责任也是负担。

    总的来说,我对“接近 100% 的数字的非线性重要性”持谨慎态度。我们说的是 GitHub 今年的可用性已经进入 90% 以上,而基础设施人员经常被提醒的一个数字是

  2. hdgvhicv

    我曾在一些系统中工作过,这些系统在最坏的情况下多年来也只有三个 9 的可用性,但我也曾在一些系统中工作过,那里五个 9 都被视为失败。

    这种现代技术声称 98% 就不错的态度,在旧技术的接受度中根本行不通。我们当时各个组件经常故障。上周我们还在处理一个分支办公室因停电加上糟糕的配电布线导致的 230 毫秒中断。

    现代软件人员不把 230 毫秒视为中断。幸好他们不在电力行业工作。

    (我们遇到的故障仅发生在我们保证 99.1% 可用性的服务上,这是我们最低的 SLA。之后还有 99.95% 和 99.999%。

    (实际上,我们在最低级别上每年都达到五个 9,但存在一些重大担忧,比如“数据中心有大炸弹”,这可能导致我们一些不太关键的单元每年中断时间远超 5 分钟。)

  3. teraflop

    除了你如何呈现这个数字之外,在分布式系统的背景下,“正常运行时间”作为一个单一数字的概念本身就有点模糊,因为不同的组件对不同的用户可能有不同的可用性。

    此外,以每月 45 分钟中断形式出现的 0.1% 停机时间,与请求在短暂爆发中失败的 0.1% 截然不同。你经常看到停机时间被报告为“错误率增加”,这模糊得毫无意义。

    Google 的“窗口化用户正常运行时间”试图更好地处理这个问题,通过展示数据的不同视图,而不是试图将正常运行时间压缩成一个单一数字:https://www.usenix.org/system/files/nsdi20-paper-hauer.pdf

  4. hx8

    > 我们这样说:

    > GitHub Actions:过去 30 天受影响 12 小时(正常运行时间 98.31%)。

    这是在尽力将恶化的情况描绘得尽可能有利。这并不能抹去这样一个事实:大多数企业在停机期间都有可衡量的收入损失。去别处购物的客户、从未展示的广告、逐渐冷却的潜在客户。12 小时的 GitHub 停机导致数百万美元的开发生产力损失,而微软将这些成本外部化给了其他公司。

    我们不应该试图将停机时间粉饰为“每月只有几个小时”。这几个小时是实实在在的真金白银。

  5. runjake

    我也不太在乎百分比。但对于某些行业来说,“两个 9”和“五个 9”之间的差异可能价值数百万美元,所以他们就是以这种方式向客户发布的。

  6. PaulKeeble

    与本地部署的正常运行时间相比,我认为关于正常运行时间百分比被忽视的一点是停机发生的时间。如果停机发生在工作日中间或购物高峰期,其影响要大得多。一家商店在黑色星期五中间或圣诞节前夕离线,比在周日晚上/周一凌晨 3 点停机受到的伤害要大得多。

    我注意到的一点是,很多 AWS、Azure 等等的停机都发生在大家的工作时间中间,数百万人受到影响。GitHub 也是如此,它阻碍了工作。而当我们用自己的设备托管服务时,停机通常发生在非主要工作时间。在很多方面,百分比是衡量停机时间的错误指标,因为小时对企业的冲击力并不相等。

  7. procflora

    这些服务状态页面还有太多其他问题,我实在无法对这篇文章的观点感到兴奋。作为服务的用户,我根本不关心额外的 0.09% 正常运行时间是否比额外的 0.9% 更难实现,即使你用时间分数来描述。我只在乎两件事:服务当前的状态是什么,以及你的服务可靠性对我长期的影响(别拿你那 30 天的垃圾数据来糊弄我)。

    在电力公用事业领域,我们有几个 IEEE 标准化的指标(带有适当的 IEEE 风格缩写)来跟踪服务可靠性,我更喜欢这些指标,并且总是希望在查看状态页面时能看到它们。这确实是天方夜谭,没人愿意在没有监管机构要求的情况下进行这种分析并发布结果,但这就是生活。

    SAIDI - 系统平均停电持续时间指数。平均客户一年经历多少分钟的停电。在我看来,这是服务状态页面上最应该看到的指标。对于电网,我们将任何超过 5 分钟的中断都视为停电(“非瞬时停电”)。

    SAIFI - 系统平均停电频率指数。平均客户一年经历多少次停电。

    CAIDI - 客户平均停电持续时间指数。当发生中断时,平均客户恢复服务需要多长时间。

    对于美国,这些数字看起来是这样的 […]

  8. blakeashleyjr

    公司也会操纵这些数字。我主要的主机商之一发生过一次中断,导致我所有环境都宕机,用户超时等等。我去查看状态页面:“部分中断,影响特定区域的部分客户”(显示为橙色,而不是红色)。好消息是,这不计入他们的正常运行时间百分比,所以我们仍然是 99.99%!我会把这个消息转达给我的客户,他们因此无法工作。

同日更多故事

2026-09-16