Coding CTO 孙宇聪：评判云服务靠谱程度 —— Coding 安全那些事
CodingNET · 2015-10-06 10:35:36 +08:00 · 3460 次点击这是一个创建于 3328 天前的主题，其中的信息可能已经有所发展或是发生改变。
本文依据孙宇聪在 SegmentFault D-Day 北京场的演讲内容整理，并授权首发于“高效运维”公众号。 10 月 11 日， SegmentFault 将在上海举办 D-Day ，围绕 Docker 主题。 Coding.net WebIDE 项目负责杜万将受邀参与分享《 Docker Container 磁盘容量限制》。了解更多可点击这里
云服务真的靠谱吗？
相信对这个问题每个人心里都有不同的答案。我今天想讲的是如何客观的去回答这个问题, 其中结合了 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 自动化。这就是实践中的一个经验。
可控性
接下来我们看一下可控性。 一提 Access Control 最关键的一点是要 Defense in Depth。就好比你想一下从自己家到公司办公室要经过多少层门，每个门的存在就是一层防御，每个门有不同的开锁方式能挡住不同的人。
云服务也是一样的， Access Control 做得越好，这个云服务越安全。首先从最基础的 Physical Security 开始。 有一句话说的好，任何软件上的花招都抵不过一个螺丝刀。评判一个云服务是否靠谱，先看他们是否做好了 Physical Security ，如果没做， 这个服务就是瞎扯。
如果一个云服务想过这个问题，说明他真正的认识到安全的重要性了。 什么机柜上锁，指纹识别，声纹识别，脸型识别，虹膜识别，姿态识别什么什么的，怎样也不嫌多。（笑）
那么接下来， 我们看一下逻辑上的 Access Control 机制。
第一点：秘密的管理。
任何云服务都有一堆秘密，这个秘密可能是服务器 Root 密码，也可能是交换机的密码什么的，这些东西怎么去保管，怎么去分发，直接体现了一个云服务厂商的靠谱程度。
任何一个云服务厂商正常运转不可能把秘密都寄托在单个人身上，也不可能让全公司人全都知道。 秘密管理怎么来做，这是一个很关键一点。 Coding 使用的是 GPG Multi-recipent 加密，如果另外一个厂商能把这个事情跟你讲清楚，这个云服务才靠谱。
第二点：审核记录.
任何云服务要看他的靠谱程度， 就问他有没有， 如何实现的审核记录系统。 审核记录应该是独立于其他所有业务组件之外一个关键组件，他应该记录了你这个系统里面发生的所有的事情。审核记录是唯一、真实、可靠的数据来源。
第三点：运营系统的权限分级。
任何一个云服务厂商都有这个运营后台，这个运营后台肯定做一个权限分析，哪些人可以看到统计分析，我们网站有多少新用户，趋势是什么样的。有些东西是敏感数据，除了我们运维有限几个人，没有人能够访问用户的数据，再细节的东西，都是严格把控的，公司大部分人都绝对没有任何的 Code Access 。
Access Control 做到这里就行了么？还差得远，想要做的好， 还有以下几点:
第一点： Fine-grained/Rolebased Access Control.
很多云服务，从外面看起来碉堡了，但是只要接入公司网络上就可以随便改数据库（笑）。
如果一个公司认为他内网绝对安全，那么他的服务就是绝对不靠谱。 Accesss Control 首先要做到角色为基础，每个角色给固定的 ACCESS 权限，第二点，必须更细粒度，具体到每一个 HTTP handler, 每一个 RPC 都要权限校验，否则就是正在瞎扯。
第二点： Identity Delegation 。
大部分的云服务的设计都是一堆超级管理员进程，这些超级管理员进程可以改一切数据，做一切事。每个 bug 都会影响到整个服务的数据安全。 Identity Delegation 就是改变了这个事情，在入口处（和用户直接接触处）发了一个令牌，以后所有的操作都带着这个令牌去操作用户数据，没有令牌就改不了。 这样大大降低了某个 bug 影响所有用户数据的可能性。
第三点: Application Level Encryption
其实大家都知道，加密很损耗性能，但是如果哪个云服务厂商没有做数据加密，就说明你对这个数据真的是关心不够，基本属于耍流氓。
第四点：对应用层漏洞的关注度
我在这里介绍一下， OWASP ，是一个开源网站，里面有所有市面上一些常见的网络应用的安全漏洞列表，如何去处理，如何去防范它。这里列出了十大关键问题，如果你不知道这个列表， 那就说明你对安全的关注还不够，赶紧上这个网站去看看。 Coding 跟乌云， FreeBuf 都有合作，体系化，系统化的去解决这个问题。如果哪个厂商不关注这个事情，这个云服务就是不合格的。
灾难恢复
最后讲一讲 Disaster Recovery
一个云服务， 你问他你这个东西好用吗，好用，安全吗？安全。出问题怎么办，不知道，没人跟你说的明白。这是典型的不靠谱。
0 - 15 min ：
如果一个云服务挂了，从故障开始到十五分钟结束还没有恢复，排除大型灾难的可能性 ，基本可以认为他们不靠谱。
零到十五分钟这个时间，是一个很大的关键时间点，他基本上是人力的极限，从出问题收到自动化报警，然后赶紧电脑打开，连上 VPN ，发现问题，处理问题，做到最快 15 分钟基本上可以说是极限了。
就算你的运维团队都是 24 小时不合眼电脑不离身， 15 分钟内恢复服务也需要两个关键点：第一常驻，第二热备。
常驻热备灾难恢复系统，也就是说你必须有一套一模一样的系统随时跑着，生产系统挂了，自动切换到备用系统上。常驻热备，是随时随地可以切换，随时随地可以开始服务，能完全接管不受影响。
你一台机器的电被拔了，硬盘挂了，宇宙射线击中了你的 CPU ，你也可以自动无缝切换。
大家还记得前一段雷击、挖光缆的事情吗，很多人说被雷击了我就挂了这很正常。其实用户管你什么原因， 你挂了就是挂了，为什么没有常驻热备系统？为什么会挂？小服务更应该有这个能力，双系统跨云部署，有了这个才有能力做 Master Slave Automated Failover 。靠谱的云服务厂商才会给你讲到这一点。
15 min - 3 hour ：
这里的 3 个小时是个虚数，根据你的业务重要程度你可以自行定义。 3 个小时是什么的意思呢，不管你什么样的问题，如果你三个小时之内修不好，你的网站就消失了。大家对你这个云服务的厂商的能力的信任程度就基本归 0 了。 想想如果 Coding 突然挂了，突然不能访问了，再回来的时候基本就告别互联网了，对大家的打击、损失是无法承受的。
十五分钟到三个小时，这是我们目前定的一个标准，不管什么灾难，三个小时之内如果恢复不了服务，说明我们工作做得不到位。达到这一点没有捷径，唯一的一点就是要有应急备案，要随时演练。
我们随时假定一个场景，外星人入侵了，搞坏了 XXX(笑), 你们给我模拟恢复一下 Coding 的系统。这是比较高级大的演练。平时也有小的演练，三五个人聚在一起。如果有一台机器重启不起来怎么办？所有的都是 Operational Readiness Drill 平时不断的练，不断的有准备。
要做到这一点： Immutable Infrastruture 。可重现部署。
很多云，包括 Coding 以前也是这样，我开一个新机器以后，一些人装了一些软件。之后辞职了，突然有一天这个机器挂了就没招了。除了把这台机器修好了，什么也做不了。想要灾难恢复，你就要把这个东西做到可重现。要清晰的知道这个机器上，装了什么东西，为什么装这个东西。
做不到这一点的云服务厂商，没有资格说我们是一个靠谱的云服务。
最后再说一下备份系统。备份系统好像是个挺简单的东西，跑起来，平时也不怎么用管，然后他就解决问题了吗？！说的好像备份系统一定备份了你想要的数据， 就算他备份了全部数据，好象就是百分之百不会丢东西的一样。
每一个备份系统都有一个叫 Durability 指标。也就是备份系统的靠谱程度。不管什么媒介，都有可能挂掉，写到硬盘上，硬盘可能坏，写到磁带上，磁带也会坏， 写到纸上，纸都可能烂掉。就算这些都不坏，你也可能宇宙射线来了，打了一下这个硬盘。硬盘受什么强磁场某一个位置就变了，你整个东西还是访问不了。这些东西不考虑，硬说一个备份系统百分之百可靠，这都是自欺欺人。
Coding 原来也没有好的备份系统，我们最近在搞 AWS Glacier ，它有一个大的磁带库，你把东西存进去的话，自动转存到磁盘、磁带上，定期维护。 AWS Glacier 有一个算法，每个硬盘大概多长时间坏一次，每个磁带多长时间坏一次。最后得出来他们的 Durability 可以做到 11 个 9 。
如果一个云厂商连这样一个系统都不舍得去关注的话，你对用户的数据太不在乎了。
有了备份，最最重要的还是恢复。 如果一个备份系统不能随时演习细粒度的恢复，那他就是没用的，关键时刻他一定掉链子，想都不用想。
最后的最后， 很多人说这么多云服务哪家靠谱，哪家安全。我觉得只能和大家共勉啦， Coding 做得还不够多，很多东西都是在探索中，希望跟大家一起多交流，把云服务搞得更靠谱。
关注干货满满的 Coding 微博
 |
1
welsmann 2015-10-06 11:06:33 +08:00  3
Coding 谈 SLA ，这该怎么吐槽？在线等，挺急的..
|
 |
2
Yamade 2015-10-06 11:10:27 +08:00 1
我赵日天表示不服。
|
 |
3
Actrace 2015-10-06 11:28:31 +08:00 1
你若有实力玩,我良辰愿意奉陪到底.
|
 |
4
DreamCMS 2015-10-06 11:29:25 +08:00 1
叶良成：呵呵
|
 |
5
onlyxuyang 2015-10-06 11:30:32 +08:00 via Android 1
说的天花乱坠…… 他家服务没用过 不置可否 说得好不如做得好
|
 |
6
CodingNET OP hi @welsmann @Yamade @Actrace @DreamCMS @onlyxuyang ,
Coding 做得确实还不够，很多东西都是在探索中，希望跟大家一起多交流，把云服务搞得更靠谱。良辰在此多谢了：） |
 |
7
TakWolf 2015-10-06 11:39:08 +08:00 3
若大家能给云计算一点宽容，良辰日后必有重谢！
|
 |
8
adslxyz 2015-10-06 11:44:19 +08:00 1
Coding 换的抱枕质量不错～好评 :)
|
 |
10
bdbai 2015-10-06 12:16:18 +08:00 via iPhone 1
@onlyxuyang 推荐你用用 妹子挺喜欢那件衬衫的
|
 |
12
Anteiku 2015-10-06 12:30:36 +08:00 via Android 1
目前使用感觉还好，小项目和作业什么的每天 push 一下……
|
 |
13
aprikyblue 2015-10-06 18:20:11 +08:00 1
自己先做好再来说。。
|
 |
14
wdhwg001 2015-10-06 21:04:13 +08:00 via iPhone
|
 |
15
Vanilla 2015-10-06 22:58:54 +08:00 1
抱枕和 T 都有 老被同事鄙视用 coding ... 就冲着自己用着舒服老给同事安利 coding 毕竟不是哪家的私有仓库都免费的
不过 coding 真的有一些不爽的地方，比如之前的 N 多次服务器故障（尼玛 push 不了代码知道有多着急吗），仓库地址默认是 https 还不能换成 ssh ，仓库的权限分配必须每创建一个分配一次，不能团队成员自动划分，像水桶那样？ 虽然还是听到同事的朋友说 coding 和 shi 一样 ... 但是我还是会继续用下去，给云计算一些宽容 最后，喜欢能倾听用户意见并迅速做出回应的产品。 |
 |
16
twor2 2015-10-07 01:33:55 +08:00 1
|
 |
17
cz5424 2021-09-17 15:32:41 +08:00
几年后回来挖坟，并没有改善，举例 2021 年 8 月 5 日
|
Select Language