孙宇聪：评判云服务靠谱程度
云服务真的靠谱吗？
相信对这个问题每个人心里都有不同的答案。我今天想讲的是如何客观的去回答这个问题, 其中结合了 Coding 的一些实践和思考。
广义范围的“靠谱” 有几个比较重要的点。
第一个点就是 Availability （可用性），24x7随时可用。一个靠谱的云服务一定是可用性非常高的。
第二点是 Access Control，可控性一定要好，非云服务你可以上个锁，云服务如何能做到可控性很好，很难。
第三点是 灾难恢复，是软件就会有问题。怎么样积极的面对这个问题，这是任何一个云厂商都要诚实面对的问题。
可用性
首先第一点我们看来讲一下可用性，可用性只有一个评判标准，就是 SLA，Service Level Agreement，更多的时候是 SLO, 只是 Objective。 一个东西是不是高可用，那么就问他几个九，敢不敢拿出来说一下。
实实在在的看着这个图说话，3个9基本上是国内云服务的基础线。也就是说**云服务至少要做到3个9才称为基本上可用**，是合格性产品。如果是做不到这个，你的东西就只是玩具，快回去好好把技术内功修炼修炼再出来刷脸。从3个9迈向4个9，也就是99.99%的可用性，每年只有52.6分钟的时间是不可用的。
以前的谷歌搜索可用度大概是全球5个9到6个9之间，每一个小节点都是5个9不到6个9之间。想想吧，这其实是很可怕的一个概念。**因为这里包含了可能发生的一切事故**，不管什么不可抗力，都是扯淡。地震、洪水、台风、大楼震塌了，也是5分钟内恢复服务。
相比之下，大部分国内的IDC机房都是按照99%设计的，一年至少3天是不可用，这3天给你花在元旦一天，春节一天，国庆一天，省点时间给你机动(笑)。这里不可用就是不可用，求爷爷告奶奶也照样不能用。
所以说 SLO 直接反映一个云服务的靠谱程度：
从99%到3个9，是基本可以靠堆人和运气解决的；
从3个9到4个9，考验的是运维自动化的能力，灾备的能力；
从4个9往上基本考验的是服务基础架构、业务设计的能力。
我们也在3个9到4个9之间努力, 这个还是很有难度的。如果一个云服务厂商在注释里加了句“不可抗力排除在外”，这是非常不合适的。
那么如何提升可用性：
Design For Redundancy, 第一是一定要做到所谓的**“无状态微服务”**，去掉单点故障。 首先是“微服务”， 一个服务分解的越简单，出错的面就越小，失败模式就越固定。然后是“无状态”，这样才可以做到无限扩展。 这个很难的， 很多时候最后拆来拆去都发现有一个数据库在最后，这个数据库就做不到无状态，永远只能有一个数据库，一个数据库实例在那摆着，可用性永远上不去。
有了无状态的微服务这种架构，还要做到 N+2。很多时候很多厂商连N都不知道（因为从没有做过压力测试，性能分析），何谈N+2？
Design For Gradual Deployment, 第二就是要**支持灰度发布**。一个服务要前进，任何软件组件都要改，都会改。更新操作会直接提高你系统出问题的可能性。想要提高可用性，**必须将发布的代价降低**。只有能够做到说我上线一个新功能，只给某几个用户用，其他的用户不受这个影响。这样才能提高你整个系统作为一个整体的可用性，
Design for Clustering: 第三点是要**区分 Cluster management 和 App Managment 的概念， 把资源的调配和服务调配分开。**
Design for Automation ，最后一点是**自动化**。一个靠谱的云服务，从设计之初就把人的因素排除在运行之外。整个系统应该是全自动化运行的，不需要你人来干预。云服务初期买了二三台个服务器，服务器放在那，有人天天盯着它才正常运行，这还有可能，上了规模之后显然是不可能的。这是最关键的一点。任何一个云服务到现在内部都是非常复杂的，他就像这个漫画里边这样，每一个人操作它的时候，面前有无数的按钮，无数的可能性。除了问题之后，如果让一个人马上搞清楚弄明白立刻解决，这是不可能的，只能自动化。
而且其实更多的时候都是人的操作带来的问题，更新一个软件，更新一个服务器都不可避免的有人要参与。如果不做自动化，早晚会出问题。
任何的靠谱的云服务厂商至少要做到以下几点：
第一个SLA一定要达到4个9，你达不到这个4个9基本上相当于你这个服务就是一个玩具，根本没有办法依赖你。
第二个是一个数量级，甚至两个数量级以上的预研。
第三就是 Automation 自动化。这就是实践中的一个经验。
