1 、真实业务当中是在使用的 2 、顶上了用处的 3 、PPT 内容和实际业务不一致的原因是很多，有的是客户业务没有做好策略，有的是外部原因例如着火，有的是外部原因例如配置错误设备异常 4 、是不是骗这个不好说 5 、可以的现在云厂商基本都实现了，但是需要客户也就是实际使用方做好业务层面的灾备和动态扩容策略 总结，动态扩容可以实现手动或者自动监控然后自动开通拉起虚拟机加入到业务处理上。灾备秒级恢复分为业务层面和多地域层面，业务层面要做好监控和动态负载迁移，多地域需要在不同的数据中心或者地区部署业务系统，达到某地挂掉自动剔除然后业务流量动态迁移到正常地域。若干个 9 就是通过以上一系列的举措实现的。当然这只是简单写写，实际用的东西非常多。 实际上你现在能看到的故障大新闻都是很少见的,抢红包微博瘫痪都是比较少见的当时业务侧应该没有做应急预案或者预估的最大流量预估不准小了导致实际业务量远大于预估业务量然后就过载了。现在很少有这种情况了，常见的都不会报出来已经通过以上技术规避了。

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

目前编出比这更好的了

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

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

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

不吹不黑，其实是有用的。如果作为云厂商，达不到是要赔钱的 当然也都是有代价的，多副本是有成本的。而且数据统计是有一些定语的，有些情况不统计进去

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

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

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 分钟，没则么见云厂商提供这么高的, 估计就金融会有这种玩意