作为一个外行，请问 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]

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

[xyooyx]

有，我做过的一个项目我们花了好几个月就是专门按照 SLA 进行相关压力、稳定性测试。暴力拉闸、多中心切换

[xyooyx]

微博瘫痪本质上不是技术架构问题，是成本问题，为了未知的舆情而长期维持大规模集群成本太高了

[ming1455]

很多人，包括你的客户都不想听真话
你骗他，即使他知道，这个事情也会继续下去，大不了出了问题找你负责就是了
但如果你连骗都不骗，他会找个能说出他想听的话的人，即使是假的

[nekoneko]

5 个 9, 也就是 0.99999 也就是 99.999%, 365*24*0.00001=0.0876, 也就是说一年最多不可用时间为 0.0876*60=5.256 分钟. 可靠性算是非常高了.
弹性扩容这是最基本的.
秒级恢复是放屁.
异地容灾, 首先得买这个服务, 而且异地容灾不可能不丢失小部分数据.

[Hopetree]

灾备秒级恢复，我想知道这是什么简单系统，除非是没有数据存储的纯逻辑服务，那做到秒级没啥问题，自动切换我都信，但是但凡一个完整的系统，包含各种数据库，数据同步这一块，就很难做到灾备秒级，别说秒级吧，半个小时都算顶级

[Rickkkkkkk]

你没发现微博最近两年都不会再因为热搜瘫痪了吗，这肯定是做了优化的。

[wzy44944]

不算骗吧，就是达不到可用性，就按照差值赔付，对客户有确定的赔付计算方法，是有好处的。当然实际执行中，会因为完全不可用还是部分可用扯皮，按照云厂商的降级处理，用户感知到一个小时不可用，可能在云厂商侧只有几分钟。比如很多故障切换都是通过 dns 替换掉故障 ip ，但是客户端上的缓存时长配置的很长导致没恢复。

[jciba5n4y6u]

作为运营商内部人士，告诉你网运部对可用性的执念绝对超出你的想象，哪怕所在区域的领导骂娘也要顶住他犯浑。想搞点创新比登天还难，必须从网运部最高处去突破，基层单位一点折扣也不讲

移动核心网的容灾备份，在 ITU 标准的基础上做了好多优化。郑州地铁发水那次，核心网机房进水，就差点停服，后来一直在优化。

投入老大了。

[OBNtHBZY3N3lxGVT]

@Hopetree 哥，可能我描述错了，我记忆力偏差了，可能是秒级切换备份？

[cnsdytedison]

1 、真的有这些技术在真实业务中使用了吗？
是的，而且一般售前的资料还会稍微落后于技术。
2 、ppt 上的的内容，在实际情况发生的时候，真的顶上用处了吗？
90%用上了。但是这玩意本质还是看人有没有人在干。
3 、PPT 内容和实际业务发生的情况不一致是因为什么？
其实是一致的。本质是对需要的资源的预估不到位。或者说击穿的原因并不完全是主业务人多。原因很多，不能从一而论。
4 、其 PPT 的技术吹嘘言过其实，是为了骗领导、骗客户、骗投资人吗？
客户不合理的要求+售前瞎吹也不会让他背锅。 所以自然而然会出现这样的情况。
5 、未来的技术（硬件技术或者软件技术）能达到 PPT 吹嘘的水准吗？
不会，ai 也是人写的，架构也是人设计的。 除非通信技术大突破，不然还是会出现击穿，瘫痪的情况。

[OBNtHBZY3N3lxGVT]

@wzy44944 哦哦，对哦，我没想过这个，也许是云服务秒级恢复，但客户的程序启动、环境还原没那么快，所以用户侧感知就是很久很久

[ne6rd]

基本都是真的，但是这些应该都只是某类云服务自身的属性。
但是实际的一个系统比如微博或者微信它不单单是一个云服务，是一系列云服务组成的。
比如 CDN,路由，微服务，缓存，持久存储。如果某个节点有短板，水桶效应。

[Ketteiron]

@wph95 #19 金融支付平台一般都是 5 个 9 ，但遇到故障家常便饭。

[midsolo]

实际上只有 50 分，在内部被吹到了 80 分，去外面给客户吹到了 100 分

[tcper]

5 个 9 可靠性，一年只允许 down 十几分钟，目前看没有任何一个云厂商能够做到（包括 aws,g)

但是基本每个云厂商都会宣传自己能够做到（其实都做不到），不过仔细看他们条款，都在玩文字游戏

1. 如何定义 down ？你在他们那里的主机 down 了，他们可说我们几万台的集群就你一个 vm down 了，不算数
2. down 了是否造成损失？比如半夜 down 了，他们就可以不承认
3. 什么服务 down 了？充值 down 可能立刻发现，几台图片静态服务 down ，根本无人发现

不过从另一个方面讲又不能说这几个云没有技术，微博瘫痪、微信瘫痪，最后基本没有丢失什么数据
如果是国企、奇葩小公司试试，绝对丢数据
机房路由表修改失误，导致大范围 down ，最后也没丢太多数据，如果是国企、奇葩小公司试试

所以说现在的情况就是，大厂都自称 5 个 9 的 SLA ，有些套壳国企也自称 5 个 9
不这么自称，别人还以为你技术差

[zhangeric]

记住了,全世界都遍布草台班子,无非是有些草台班子还能从问题中总结经验,逐步改进,但是还是不改草台班子的底色.

[yukiir]

在 ppt 右下角用超级小的字写：“数据为设计目标”

[Ketteiron]

@tcper #35 大厂的大部分服务可用性自称是 3.5 个 9 (99.95%)，5 个 9 的服务没几个，听销售说的，但不知为何到处都在说 5 个 9
关于赔付，基本要经过多次扯皮才能拿到全额代金券。
如果是真正赚钱的核心业务，这点赔偿九牛一毛。
只上一个云不能保证不出问题，但多云运维不是小公司玩得起的，大多数小厂还是绑定在其中一家，出了问题自认倒霉。
可用性说实话没啥用，跟保险差不多，只是赔的没有保险多。绝大部分公司的故障基本与 SLA 无关，是自己的破烂代码出问题，是某个云服务配置出错，真的有秒级恢复也得等他们定位到错误代码在哪，这一般都是几十分钟到几十小时，1 秒恢复和 10 秒恢复没有任何区别。

[defunct9]

都是骗人的，真信就惨了。

[burby]

像是方便面包装上写着：图案仅供参考。

[NotLongNil]

1. 有的
2. 真的有用
3. 要达理想的效果，要付出很大的人力物力，公司不一定会为此付出这么多的资源，反正能用就行
4. 是的
5. 现在就能达到了，他们吹嘘的东西也是网上抄的

[tunggt]

你说的 5 个 9 ，实际应用中基本不可能。因为要考虑成本收益比。
秒级恢复，就是文字游戏。1s 是秒级。一亿秒不也是秒！
技术有，也能顶用。

至于 PPT 和实际解决方案，这个难道你没写过 PPT 吗？真假如何，写过你就知道了。

[kneo]

当然是真的，五个 9 相当于告诉你每年都得出点问题。

[mytsing520]

理论上，不是不能有，但你得付出相应代价

[bbbblue]

想起了之前公司做集群迁移。。。
实现了阿里云和腾讯云双边的服务集群 emmmm 然后哪边出故障整个集群都会挂。。。（你简单理解就是 A 服务在阿里云 B 服务在腾讯云 靠专线互联。。。

办完庆功会负责人升迁 剩下的迁移就剩下其他人自己折腾了。。。