孙宇聪：评判云服务靠谱程度

孙宇聪：评判云服务靠谱程度

云服务真的可靠吗？

对于这个问题，相信每个人都有不同的答案。今天要讲的是如何客观的回答这个问题，结合了Coding的一些实践和思考。

关于广泛范围内的“可靠”有几个要点。

第一点是可用性，全天候可用。可靠的云服务必须具有非常高的可用性。

第二点是访问控制。可控性一定要好。您可以锁定非云服务。云服务如何实现良好的可控性是困难的。

第三点是容灾，但是软件会有问题。如何积极面对这个问题，是任何云厂商都应该诚实面对的问题。

可用性

首先说一下可用性。可用性的标准只有一个，即SLA，服务水平协议，更多时候是SLO，只是客观。如果某个东西高可用，那就问他几个9，敢不敢拿出来。

真的看这张图，三个9基本是国内云服务的基本线。也就是说，**云服务至少要有3个9才叫做基本可用**，才是合格的产品。如果你做不到这一点，你的东西就只是玩具。刷脸之前先回去练好内功。从3个9到4个9，即99.99%可用，每年只有52.6分钟不可用。

以前Google在全球的搜索可用性在5个9到6个9之间，每个小节点在5个9到6个9以内。仔细想想，这其实是一个很可怕的概念。**因为里面包含了一切可能的意外**，不管什么不可抗力，都是扯淡。地震、洪水、台风、建筑物倒塌，5分钟内恢复服务。

相比之下，国内大部分IDC机房都是按照99%设计的，一年至少有3天不可用。这3天是让你元旦、春节、国庆过的，留点时间给你机动(笑)。这里用不了，就用不了。如果让爷爷告诉奶奶，就不能用了。

所以SLO直接反映了云服务的可靠性:

从99%到3个9，基本可以靠堆人和运气解决；

从三个9到四个9，考验的是运维自动化和容灾能力；

来自四个9的基本测试是服务基础设施和业务设计的能力。

三个9到四个9之间我们也在努力，这个还是很难的。如果某个云服务商在评论里加了一句“不可抗力除外”，是非常不合适的。

那么如何提高可用性:

冗余设计。首先要做所谓的**“无状态微服务”**摆脱单点故障。首先是“微服务”。服务的分解越简单，错误面就越小，故障模式就越固定。然后就是“无状态”，这样就可以无限扩张。这个很难。很多时候拆了才发现最后还有一个数据库。这个数据库不可能是无状态的。永远只能有一个数据库，并且只有一个数据库实例，所以可用性永远不会提高。

采用无状态微服务的架构，需要达到N+2。很多时候很多厂商连N都不知道(因为没做过压力测试和性能分析)。怎么能谈N+2呢？

设计渐变部署，二是**支持灰度发布**。如果一个服务想要向前发展，任何软件组件都会改变。更新会直接增加你的系统出现问题的可能性。为了提高可用性，**必须降低出版成本**。只有当我们可以说，我推出了一个新功能，它只会被少数用户使用，其他用户不会受此影响。只有这样，你的整个系统的可用性才能从整体上得到提高，

集群设计:第三点是**区分集群管理和应用管理的概念，并将资源分配与服务分配分开。**

为自动化而设计，最后一点是**自动化**。可靠的云服务从设计之初就将人为因素排除在运营之外。整个系统应该是完全自动化的，不需要你的干预。云服务刚开始的时候，买了两三台服务器，服务器放在那里，每天有人盯着，才正常运行。这个还是可以的，但是规模化之后显然是不可能了。这是最关键的一点。到现在，任何云服务内部都是非常复杂的。就像这部漫画。当每个人 *** 作它的时候，面前有无数个按钮和无数种可能。除了问题，一个人是不可能马上想通，马上解决的。只能自动化。

其实更多的时候，问题是人为 *** 作造成的。不可避免的会有人参与更新一个软件或者一个服务器。不做自动化，早晚会出问题。

任何可靠的云服务提供商至少应该做到以下几点:

第一个SLA必须达到四个9。如果你达不到这四个9，基本上就说明这个服务是个玩具，没有办法依靠你。

二是一个数量级甚至两个数量级以上的预研。

第三是自动化。这是实践中的经验。

可控性

接下来，我们来看可控性。门禁的重点是纵深防御。比如，你想想从你家到公司办公室要经过多少道门，每道门的存在都是一层防御，每道门都有不同的开锁方式来阻挡不同的人。

云服务也是如此。访问控制越好，云服务就越安全。从**最基本的人身安全**开始。俗话说，没有一个软件的招数能比得上一把螺丝刀。判断一个云服务是否可靠，先看他们有没有做物理安全。如果没有，这个服务就是扯淡。

如果一个云服务思考过这个问题，说明他真的意识到了安全的重要性。柜子锁不能太多，指纹识别，声纹识别，人脸识别，虹膜识别，姿态识别等等。(笑)

接下来，我们来看看逻辑访问控制机制。

第一点:秘密管理。

任何云服务都有一堆秘密。该密码可能是服务器的根密码或交换机的密码。如何保管和分发这些东西，直接体现了一个云服务厂商的可靠程度。

任何一个云服务商都不可能把所有的秘密都寄托在一个人身上，也不可能让全公司的人都知道。如何做好秘密管理是一个重点。编码使用GPG多重收件人加密，只有在另一个供应商能够向你解释清楚的情况下，这个云服务才是可靠的。

第二点:审计记录。

任何云服务都要看他的可靠性，就问他有没有审计记录制度，怎么实施。审计记录应该是独立于所有其他业务组件的关键组件，它应该记录系统中发生的所有事情。审计记录是唯一真实可靠的数据来源。

第三点: *** 作系统的权限分级。

任何云服务厂商都有这个运营后台，这个运营后台必须做一个权限分析。谁能看到统计分析，我们网站有多少新用户，趋势是什么。有些东西是敏感数据，除了少数有限运维的人，没有人能接触到用户的数据。无论什么细节都是**严格控制的**，而且公司里大多数人绝对没有任何代码权限。

门禁够吗？还有很长的路要走。我想做好。有以下几点:

第一点:细粒度/基于角色的访问控制。

很多云服务从外面看像碉堡，但只要连上公司网络，就可以随意更改数据库(笑)。

如果一个公司认为自己的内网绝对安全，那么它的服务绝对不可靠。ACCESSs控制首先必须基于角色，**每个角色赋予固定的访问权限**，其次必须**更细粒度**，具体到每个HTTP处理程序，每个RPC都必须有权限验证，否则就是扯淡。

第二点:身份委托。

大部分云服务都是设计成一堆超级管理员进程，可以改变所有数据，做所有事情。每一个bug都会影响整个服务的数据安全。身份委托只是改变了这个东西，在入口处(与用户直接接触的地方)发送一个令牌。**以后所有的 *** 作都要拿这个令牌来 *** 作用户数据**，没有令牌是无法更改的。这大大降低了错误影响所有用户数据的可能性。

第三点:应用级加密

其实大家都知道，加密是性能的损失，但是如果哪个云服务商不做数据加密，说明你真的对这些数据不够关心，基本属于流氓行为。

第四点:关注应用层漏洞

我要介绍一下OWASP，一个开源的网站，里面罗列了市面上一些常见的网络应用的安全漏洞，如何应对，如何防范。这里列出了十个关键问题。如果你不知道这个列表，说明你对安全不够重视。去这个网站看看吧。编码已经和乌云、FreeBuf合作，系统地解决了这个问题。如果哪个厂商不重视这个事情，这个云服务就是不合格的。

灾难恢复

最后，谈谈灾难恢复

云服务。你问他你这个东西好不好用。好用又安全吗？安全。出了问题怎么办？我不知道。没人跟你说清楚。这通常是不可靠的。

0-15分钟:

如果一个云服务出现故障，从故障开始到十五分钟结束还没有恢复，排除大灾可能性的情况下，基本可以认为是不可靠的。

零点到十五分钟的时间是一个很大的关键时间点。他基本上是人力的极限。在收到出错时的自动报警后，他迅速打开电脑，连接VPN，找到问题，并进行处理。基本可以说最快15分钟就是极限了。

即使你的运维团队24小时不闭眼不离开电脑，15分钟内恢复服务也需要两个关键点:**第一常驻，第二热备。**

常驻热备容灾系统，也就是说你必须有一个完全相同的系统随时运行。如果生产系统出现故障，它会自动切换到备用系统。常驻热备是指**随时随地可以切换，随时随地可以启动服务。完全可以不受影响的接手。**

你的一台机器的电源被拔掉，硬盘挂起，宇宙射线击中了你的CPU。还可以自动无缝切换。

还记得之前的雷击和挖光缆吗？很多人说我被雷劈挂了很正常。其实用户在乎的是你做什么。如果你挂了，你就挂了。为什么没有常驻热备系统？你为什么挂电话？小服务要有这个能力，双系统跨云部署。只有这样，我们才有能力进行主从式自动故障转移。可靠的云服务提供商会告诉你这些。

15分钟-3小时:

这里的3小时是一个虚数，你可以根据自己业务的重要程度自己定义。3小时是什么意思？无论你有什么样的问题，如果你不能在3小时内修复，你的网站就会消失。大家对你这个云服务商能力的信任度基本为零。想想吧。如果编码突然挂机，突然不能访问，等他回来，基本上就告别互联网了。对大家的打击和损失是无法承受的。

十五分钟到三个小时，这是我们目前设定的一个标准。无论什么灾难，如果三个小时内不能恢复服务，说明我们的工作不到位。这一点没有捷径可走。唯一的就是要有应急记录，随时演练。

我们随时假设一个场景，外星人入侵，攻破XXX(笑)。你可以帮我模拟和还原Coding的系统。这是比较高级的演练。还有小演练，三五个人聚在一起。一台机器无法重启怎么办？都是战备演练，不断练习，不断准备。

要做到这一点:不变的基础设施。**可重复的部署**。

很多云，包括编码，以前都是这样的。我入手一台新机后，有人安装了一些软件。之后，我辞职了。突然有一天，机器挂了，我没有表白。除了修理这台机器，什么也做不了。如果你想要灾难恢复，你必须让这个东西可复制。**清楚知道这台机器上安装了什么，为什么要安装。**

做不到这一点的云服务提供商，没有资格说我们是可靠的云服务。

最后说一句**备份系统**。备份系统似乎是一件非常简单的事情。它运行的时候一般不会管，然后解决问题了吗？！看来备份系统一定备份了你要的数据。即使他备份了所有的数据，似乎也永远不会丢失什么。

每个备份系统耐久性指标。也就是备份系统的可靠性。不管什么介质，都有可能挂机，写在硬盘上，硬盘可能会坏，写在磁带上，磁带会坏，写在纸上，纸可能会烂。就算这些不差，你也可能是用宇宙射线打了这个硬盘。硬盘的某个位置被任何强磁场改变，你仍然无法访问整个东西。不考虑这些，就硬说一个备份系统100%可靠，是自欺欺人。

编码也没有一个好的备份系统。最近在搞AWSGlacier，有一个很大的磁带库。如果你在里面放了东西，它会自动转移到磁盘和磁带上进行定期维护。AWSGlacier有一个算法，关于每个硬盘坏的频率和每个磁带坏的频率。最后得出结论，其耐久性可以达到119秒。

如果一个云厂商不愿意关注这样的系统，你就不太在乎用户的数据。

有了备份，最重要的是还原[/s2/]。如果一个备份系统不能在任何时候进行细粒度的恢复，那么它是没有用的。关键时刻，他必须掉链子，想都别想。

最后，很多人说，这样的阴天，哪个服务可靠，哪个安全。我想我只能和你分享。编码做的还不够。很多东西都在探索。希望和大家多交流，让云服务更可靠。

注:本文根据孙在SegmentFaultD-Day北京市场演讲内容整理，授权发布于“高效运维”微信官方账号。10月11日，SegmentFault将在上海举办D-Day，以Docker为主题。