我们能别再谈正常运行时间百分比了吗？

原文 ↗ Hacker News 讨论 ↗

像“四个九”正常运行时间和光鲜的状态页这类服务可靠性指标，正受到批评：它们往往不透明，甚至具有误导性，尤其当它们掩盖了频繁发生、发生在工作时间、并真正阻断工作的故障时。评论者认为，正常运行时间百分比无法体现故障何时发生、如何在互联系统中级联、以及它们对生产力和收入造成的代价。许多人呼吁更透明、以用户为中心的报告方式——例如实际中断小时数、事件频率和发生时间，以及标准化的可靠性指标——同时指出提供商有动机去低报或美化故障。

关于正常运行时间百分比和“几个九”的争论

  • 许多人指出，“几个九”主要是营销/合同工具，而不是用户影响指标。
  • 一些人认为，普通人和高管并不真正理解 99%、99.9% 和 99.99% 之间到底有多大差别。
  • 也有人说，百分比仍然有用，至少可以作为一个简单的代理指标，尤其是在组合独立系统时（概率相乘）。
  • 一些行业（交易、应急服务、电信、电力）确实需要 5–6 个九；对许多 SaaS 场景来说，2–3 个九在经济上可能已经足够。

展示可靠性的替代方式

  • 很多人支持把它表述为 时间（例如每月停机多少小时），而不是只给百分比；这样更具体（“1% 约等于 3.5 天”）。
  • 反方观点：“受影响 12 小时”仍然含糊不清——一次长故障和多次短故障，体验完全不同。
  • 还有人希望看到更丰富的视图：随时间变化的图表、“平均两次中断之间的时间”，以及面向用户的指标，比如：
    • 按地区划分的工作时间内正常运行时间。
    • 基于实际请求成功率的加权正常运行时间。
    • 按时间窗口统计的用户正常运行时间，以及类似电力行业的指标（SAIDI/SAIFI/CAIDI）。

停机的时间点与影响

  • 反复强调的是，什么时候 出故障比总共少了多少分钟更重要。
  • 工作时间和高负载时段的故障，远比凌晨 3 点的维护更具破坏性。
  • 有人指出，在全球服务中，“糟糕时段”总会影响到某些人，而且故障往往与高负载相关。
  • 对某些工作流（例如较长的 CI 运行）来说，即使很短的中断也可能浪费数小时的人力时间。

SLA、合同与激励机制

  • 讨论了激进的 SLA（例如 6 个九）在某些领域是现实的，在另一些领域则荒谬。
  • 销售部门往往未经工程团队同意就承诺高位数的“几个九”；退款通常很少，更像是退出权而不是真正的赔偿。
  • 供应商有时会把底层云故障排除在外，从而削弱保证。

状态页、信任与透明度

  • 很多人觉得官方状态页会低报或淡化问题；第三方监测被认为更诚实。
  • 有人怀疑大型提供商公布的正常运行时间（例如最近 GitHub/Microsoft 的问题）与实际观察到的可靠性并不一致。
  • 也有人呼吁状态页直接绑定外部监测，自动报告所有事件，哪怕再小。

多高的可靠性才算“足够”？

  • 一种观点是：大多数组织为边际性的“几个九”支付了过高成本，但这些投入并不会实质改善结果；不如把资源投到别处。
  • 另一种观点认为：即便短暂且罕见的故障，也会引发级联的运营、合规和声誉成本；企业看重可靠性胜过花哨手段。