服务宕机了 6 个小时，如果要保证 99.995% 的可靠性，需要至少正常运行多久服务？

[capgrey]

看了一下阿里云的对象存储服务的介绍，https://help.aliyun.com/zh/oss/
说是提供 99.9999999999%（ 12 个 9 ）的数据持久性，99.995%的数据可用性

我问了一下 AI 标题提到的这个问题，回复:

• 要想把一次 6 小时宕机 稀释进一个 99.995% 的长期可用性指标，你需要接下来至少连续运行 约 13.7 年不出问题。
• 相比于 5 个 9 （ 68.5 年），这个目标已经“稍微”容易一些，但仍然不现实作为短期纠正手段。
• 重点是，超过 SLA 容忍值的宕机，通常无法通过“补时”恢复 SLA 级别，需要在服务协议中说明事故归类和例外处理方式。

[msg7086]

没什么稀释，达不到可用性就补偿，最坏的情况就是一个月全额退款。
当然，这次属于不可抗力，补偿都不是必须的。

[qujiqujl]

阿里云赶紧把这句话拿掉吧，搁这儿丢人现眼！脸都不要了！

[kneo]

保证的不是每一台的，而是平均的。知道什么意思吗？

我们先随便假设阿里云有一亿台电脑，每台电脑每年运行 365 * 24 小时，保证运行 99.995%的可用性，一共允许宕机：

100000000 * 365 * 24 * 0.00005 = 43800000 小时

也就说，允许 43800000 / 6 = 7300000 = 730 万台电脑宕机 6 小时。

当然，阿里云可能没有一亿台，那么按照一千万台算，只要宕机的机器少于 73 万台，那也不算个事。

如果是 99.9999999999%呢？

100000000 * 365 * 24 * 0.000000000001 = 0.876

一亿台电脑，只允许一台电脑一年宕机一小时。

当然我没有这个可用性的算法解释权。

[MYDB]

都是随手填的概率

[orioleq]

@kneo 大聪明，用户算可用性管你服务器台数多少，服务器扩容缩容了还重新算可用性么…肯定是整体看啊

[orioleq]

@kneo 哦，你想说产品的整体残次率 0.00005%砸到某个具体消费者身上就是 100%，行吧…

[wind1986]

@MYDB 这个当然不是...

[capgrey]

@kneo 有点搞笑，但是我理解你为啥有这个想法

[Eb7caYE8I5XU0B47]

很多人只关注故障恢复，忽略了 SLA 年均累计停机时长的约束，6 小时确实足以让全年可用性低于 99.995%。

如果业务对高可用要求比较高，其实可以考虑做多云冗余，比如主服务在 AWS 、备服务在 GCP ，或者跨区域容灾。
用 NiceCloud 做多云账号统一管理，快速切换阿里云腾讯云国际、Google Cloud 多平台实例，日常测试也方便些，出问题不容易一锅端。