服务宕机了 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 级别，需要在服务协议中说明事故归类和例外处理方式。

[fffq]

你咋还当真了咧，哪个厂能做这样的保证[doge]

[totoro625]

如果这个概率指的是时间，把 6 个小时的宕机排除在外就行了，赔个代金券就当没看见

还有一种可能这个概率指的是数据在不在，事故发生之后数据还在，就不算不可靠/不可用

[Perry]

理性点来讲，宕机只影响数据可用性吧，你丢数据才是数据持久性

[Gilfoyle26]

这是广告，不是疗效！你咋还当真了。。。。。

[sampeng]

99.995% 的可靠性。是 7*24*365*0.005%=3.066.。业界通用算法是这个。AI 说的啥啊。。。谁说这是连续运行时间。。

[xmdbb]

>数据持久性
指是否丢失数据

>数据可用性
指数据访问是否正常

昨晚的事故不涉及第一点，但涉及第二点，而第二点牵扯到计算方式不是按年，是按月指标，所以无法稀释。
但是如果你有看阿里的协议，其中免责部分有提及到：任何阿里云所属设备以外的网络、设备故障或配置调整引起的
所以根本不用稀释。

[capgrey]

@xmdbb 这下看懂了，那就一个月内不超过 2.16 分钟不能使用。否则根据 SLA 会补偿。应该是这个意思吧？

[opengps]

理论数值仅限于理论推导，实际就算成绩更好也没人做得到保证

[zqqian]

你可以假设宕机的概率是一个泊松分布，然后用统计学的假设检验来算一下

[xmdbb]

@capgrey 计算是这样计算，但是还是要看免责部分的；
比如阿里 oss 的免责中明确说明排除“任何阿里云所属设备以外的网络、设备故障或配置调整引起的”
那这次故障根本不算入 SLA 范围内。

[fredcc]

https://terms.aliyun.com/legal-agreement/terms/suit_bu1_ali_cloud/suit_bu1_ali_cloud201803021527_93160.html?spm=a2c4g.11186623.0.0.26a12cc1iNnvZm

数据持久性，数据可用性，服务可用性区分下

[xmdbb]

@capgrey 不过我也只是看了下 V 站说才知道，因为我没用 ali 的服务。
但公平来说，就算 aws 的 sla ，也有排除部分的，所以这个 sla 仅供参考。

而这次具体原因我不清楚，就看了下 V 站里面提到的，说上游根服务器那边改了解析，类似这种我觉得会推到去第三方的原因从而避免扣除 SLA 可用度。

不过就算扣除 SLA ，假设这个月不会再有任何故障出现，那这个月 SLA 也是降低到 99.17%​，对应协议中的赔偿就是 OSS​月度服务费的 50%​​

说难听点根本不算什么，之前国补那一堆一样赔，只是估计更加在意声誉受损

[decken]

类似 百年一遇的洪水

[sn0wdr1am]

都是不长记性的人啊。

当年各个号称无限容量的免费邮箱，免费相册，后来都怎么了？

阿里云盘还号称永久免费，不限速呢？

结果呢？

别看他们怎么承诺的，要看他们怎么兑现承诺的。

[JoeDH]

广告谁都会吹，之前很多公司都吹什么两地三中心、异地多活，实际只停在 PPT 里面
并且实际停机那么点时间，真会产生那么大影响么？用户该用还不是得用

[ykb8121]

只要前面定语加的够多、够好、够足，什么服务都能整好几个 9

[dcsuibian]

@sampeng 多乘了个 7 吧

[COW]

相比赔偿，云厂商可能更在乎信誉，你这明显是没看清楚规则。公有云 SLA 基本都是按月计的，不是你这么算的，你这个超长期可用性保证，哪家能保证啊？云厂商有免责声明，比如什么用户自身配置错误、API 使用错误、不可抗力、不可预知的因素啥的，另外你还要证明确实是云厂商服务的问题，另外，就算能赔偿吧，也是按可用性分等级的，所以也别想着能赔多少。

[coolcoffee]

唉！某些厂商是根据故障时段费用的百倍赔偿。比如宕机一小时，x100 也只是相当于抵扣了 4 天的费用罢了。

[ryd994]

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 多平台实例，日常测试也方便些，出问题不容易一锅端。