作为一个外行，请问 5 个 9 的可靠性、弹性扩容、秒级恢复等话术是不是就是骗领导、骗客户的？

[OBNtHBZY3N3lxGVT]

各位老师好，作为一个外行，我不是做数据中心或者运维的，我能理解提升数据的安全性、稳定性的必要，也理解数据、服务的维护业务难度。

我心里一直有个疑问，我经常能看到某某互联网大厂、某某云服务吹自己的业务有“动态扩容”、“灾备秒级恢复”、“若干个 9 的业务可靠性”之类的 ppt 。
但实际情况就是：
·有明星爆绯闻，微博瘫痪。
·早些年抢红包，微信瘫痪。
·某某云机房新加坡火灾，导致客户数据丢失。
·某某云机房香港设备异常，导致客户业务中断好长时间。

请问一下
1 、真的有这些技术在真实业务中使用了吗？
2 、ppt 上的的内容，在实际情况发生的时候，真的顶上用处了吗？
3 、PPT 内容和实际业务发生的情况不一致是因为什么？
4 、其 PPT 的技术吹嘘言过其实，是为了骗领导、骗客户、骗投资人吗？
5 、未来的技术（硬件技术或者软件技术）能达到 PPT 吹嘘的水准吗？

望各位技术大佬指点迷津，谢谢了🙏

[zzq825924]

描述的这么好，完全可以先问 AI 。5 个 9 是一种评价体系，有了体系就有了进步方向，员工的绩效也有了锚点

[RightHand]

99.999%的概率是的

[shuiduoduo]

5 个 9 那些什么云没给客户少丢数据吧

[clemente]

99.999%的概率是的

[winzkh]

其实不然，超出时间可是要赔钱的

[opengps]

我能做到，但你得给足支持

[Vraw5]

你把它当成保险就好。
5 个 9 内的免赔，超过 5 个 9 的时间给你赔偿，SLA 的费用就是保费。
丢数据、服务不可用造成的损失用赔偿金额覆盖比例，这是客户考虑的问题。

[Ketteiron]

1. 有
2. 确实有用
3. 编得太离谱
4. 一定程度上是的
5. 不知道

其实这些都是细枝末节，代码写得好，100%。
在追求锦上添花的东西之前，先把简单的代码写好，就像 v2 的“好好说话”那样，程序员要做的仅仅是"好好写代码"，这就够了。
我说个实际情况，提供 5 个 9 服务的云厂商，自己的业务达不到 5 个 9 。

[mooyo]

我很中肯的告诉你，在当前降本增效的浪潮下，即使有 99999 的设计可靠性，部署上也做不到。

所以你可以认为都是假的。

[thereone]

1 、真实业务当中是在使用的
2 、顶上了用处的
3 、PPT 内容和实际业务不一致的原因是很多，有的是客户业务没有做好策略，有的是外部原因例如着火，有的是外部原因例如配置错误设备异常
4 、是不是骗这个不好说
5 、可以的现在云厂商基本都实现了，但是需要客户也就是实际使用方做好业务层面的灾备和动态扩容策略

总结，动态扩容可以实现手动或者自动监控然后自动开通拉起虚拟机加入到业务处理上。灾备秒级恢复分为业务层面和多地域层面，业务层面要做好监控和动态负载迁移，多地域需要在不同的数据中心或者地区部署业务系统，达到某地挂掉自动剔除然后业务流量动态迁移到正常地域。若干个 9 就是通过以上一系列的举措实现的。当然这只是简单写写，实际用的东西非常多。

实际上你现在能看到的故障大新闻都是很少见的,抢红包微博瘫痪都是比较少见的当时业务侧应该没有做应急预案或者预估的最大流量预估不准小了导致实际业务量远大于预估业务量然后就过载了。现在很少有这种情况了，常见的都不会报出来已经通过以上技术规避了。

[Junzh]

你说的这些其实是国内厂商对标 AWS 的话语。因为这些几个 9 的描述是 AWS 常见的。虽然 AWS 也出过不少问题，甚至也有扯皮的。但它依然是行业 NO.1 。

[Sekai]

目前编出比这更好的了

[pingdog]

评审过的技术方案，T3 不是水逼，5 个 9 不是问题
严重事故 T3 光指挥不上马，4 个 9 都难，毕竟 T2 也就 T2 ，某些权限不足

[thereone]

想了解详细一点的可以看看网易云的方案，虽然这个当时也搞出了事故但是写的整体没什么问题。
https://juejin.cn/post/7389952004791894016

[Kirkcong]

这东西叫 SLA,是会写在合同里的，如果服务商没有达标，是要赔钱的

[iyaozhen]

不吹不黑，其实是有用的。如果作为云厂商，达不到是要赔钱的

当然也都是有代价的，多副本是有成本的。而且数据统计是有一些定语的，有些情况不统计进去

[acorngyl]

看见过个阵列的解释：如果某阵列恢复时间是 3600 秒，保证故障周期在 10 年以上，平均到每天的恢复时间就不到 1 秒。要不就是某个硬盘，设计寿命多少小时，如果在这个时间内坏的概率是 P ，几块硬盘放一起，同时坏的概率就是（ 1-P ）^n ，就是多少千小时故障率达到几个 9.反正都是数学游戏。

[blackbookbj277]

这个可以是售前介绍，真写合同和违约条款里就不一样了。

[wph95]

1. 有
2. 有
3. 方案设计是 N 个 9 ，实施过程中会因为成本减配/太菜了没按计划实现/链路里有短板，实际可用性会低于设计值
4. 如果是架构师写的 ppt ，更多是一种交差/向上管理
5. 技术从来都够，只要钱足够的前提。


SLA 只是理论值，跟真实体验没关系，出了问题只会是 0%，100%。 当然，云厂商的 SLA 是和客户约定赔偿的黄金指标。

比如，kafka 推荐是 3AZ 部署。sla 能追到 99.95/99.99 这个级别。但是如果是 aws ，跨 AZ 的网络流量成本能占总成本的 1/3, 1/2.
很多为了省钱，就单 AZ 了，sla 就降到 99.5/99 了。成为链路的薄弱环节。



同时，例如机房火灾这种，都是免责条款里的，例如 AWS 的 SLA 免责条款：

(i) caused by factors outside of our reasonable control, including any force majeure event or Internet access or related problems beyond the demarcation point of Amazon RDS;


// 5 个 9 可靠性, 一年只能 downtime 5 分钟，没则么见云厂商提供这么高的, 估计就金融会有这种玩意

[Steaven]

都是骗投资人、客户、老板的话术