这两天一直有朋友让我分析分析阿里云故障这件事，还有一些数据库原厂的朋友和我探讨是不是数据库出问题导致的本次故障。最近几天这个问题一直很热，从各种各样角度来分析问题的文章很多，也都很有道理。我想我就不从故障分析的角度去猜测阿里云本次故障到底是不是资源访问管理模块（RAM）故障导致的问题了。因为这次的故障十分诡异，是一次跨可用区的故障，什么问题能够跨可用区发生问题呢？某个统一的策略调整触发某个BUG导致问题是可以解释的通的，不过这种跨多个可用域的统一调整对于阿里云这样的平台运营来说属于十分低级的管理错误，发生的可能性也不大。既然没有能力来剖析这只麻雀，那么我就从另外一个角度来谈谈对这个事故的看法的。
“通过技术，云是可以解决所有的可用性问题的”，我听过无数次互联网企业的专家对客户这么忽悠。这种话说多了，可能不光用户信了，云厂商自己的人都信了。所以云不会出问题，也不能出问题。出问题就是不合理的，就一定是有某些内幕的。事实上100%可用性的IT系统似乎还没有出现，四个九可用性的系统允许每年有53分钟的不可用时间，因此云能够保障绝对的高可用肯定是不合理的。全球的公有云都出现过类似阿里这样的不可用故障。就像阿里云这次的故障修复时间来看，两个半小时的恢复时间，对于承诺4个9的客户而言，已经违反了和客户签署的SLA，面临巨额赔偿是必然的事情。而如果放在一个更长的五年、十年周期来看，全球的大多数大型公有云企业还是能够勉强保障四个九的可用性的，可能包括阿里在内（没有仔细计算，不是很确定），这说明公有云总体而言还是能够达到较高的可用性的。这也是云平台追求的目标，用可用性较低的通用软硬件构建一个相对而言更高可用性，甚至能和大型机相媲美的IT基础设施。不过四个九的可用性与100%可用性的距离可能是地球到宇宙边缘那么遥远。
IT系统的可用性是基于成本的。当年国内的大型银行为了高可用性不惜购买昂贵的大型机，这是因为银行账务的可用性十分关键，值得花更多的钱去保障。公有云的可用性也是如此，在获客为王的初期，公有云可以不考虑成本来为用户提供满足SLA的产品，而随着规模的扩大，这种不计成本的支出肯定是不可持久的。因此随着时间的推移，公有云逐步降低成本，获得更多的利润是十分必然的事情。因此阿里云这次的“史诗级的故障”肯定不是最后一次，估计也不是国内公有云厂商的最严重的一次。因为降低成本是公有云获利的最主要途径，临界成本是公有云厂商最佳的平衡点，而在一个极端动态的环境中保持临界平衡是十分困难的。
与公有云不同，私有云的成本完全是自主控制的。与国外的情况不同，国内的大企业自建私有云是主流，大多数企业的系统上云工作至少应持续了六七年了。前两年听一个企业高管说，上云以后，没有了资金巨大的批次招标，取而代之的是小批量的系统扩容。不过系统扩容的频率提高了很多。在小型机时代，三到五年系统才进行一次扩容，而上云后，云平台的扩容基本上是以半年计的。他们自己盘点了一下上云后的IT投资，比起当年使用小型机的时代来看，略低了一些。不过算算小型机和X86服务器的差价，似乎上云后IT成本并没有实质性的节约。
就这个问题，我也有些感觉。在小型机时代，因为小型机很金贵，因此都用得比较狠，CPU使用率，内存使用率往往都超过70%。进入以X86服务器为主的资源池时代，我们当时对资源池设置的入池标准是CPU使用率低于30%，调度标准是CPU 使用率长期超过65%。池中的大多数数据库服务器的CPU使用率都在40%左右。上了云之后，为了确保云平台的总体安全性，云厂商建议平均CPU使用率不要高于30%，而实际上目前云平台中的资源使用率远远低于这个阈值。再加上庞大的云底座的成本，个人感觉上云后的整体基础设施成本应该是大幅增加而不是像IT部门每年向领导汇报那样大大节约的。
再回到业务连续性问题上，我有一个感觉，那就是很多企业IT上云后，容灾、灾备系统的建设放缓了，甚至有些企业的备份系统也不建了。前阵子有个用户误删了一个RDS for MySQL数据库。使用云平台提供的快照+binlog做了恢复，数据库不大，花了几个小时就完成了，这是目前云平台给用户建议的数据库备份的替代方案。虽然在大多数时候可能是有效的，不过总觉得好像有哪个地方不太对劲。
而对于灾备系统，用户总是下不了决心建，主要考虑的还是成本的问题。以前建灾备很容易，需要建灾备的重要系统独立去考虑就行了，花费也不会太大。现在要建灾备就麻烦了，首先得新建一朵云，这个成本还是需要考虑考虑的。再加上云平台这些年用下来也还稳定，这种执念逐渐就淡了。我和客户讨论过云平台出故障的事情，他们普遍的观点是：“云平台本身就是高可用的，不会出现你所说的事情吧”。不知道他们看到了阿里云的事故，会不会脊背发凉。
昨天和一个做关键业务系统的朋友小聚，他说他们不敢用阿里云华为云这样的云平台，而宁可用自己开发的十分简陋的云平台，最大的原因是可控。系统出任何问题，他们都有能力快速解决。而如果用上那些黑匣子，一旦出问题搞不定，那么就是灾难性的。这个问题也挺有意思的，对于关键业务系统，把业务连续性交给自己无法把控的云平台还是尽可能降低复杂性，让自己有能力把控？这已经不是一个经济问题，而是一个理念问题了。对于绝大多数企业来说，关键业务系统没有互联网企业业务系统那么庞大，规模也是在一个可控的范围内慢速发展，云平台的特性是不是企业核心系统所追求的目标？通过前几天的事件，我想很多企业会再做一些思考了。
早上坐在电脑前想写一点东西，不过这个问题太过复杂了，因此写的过程中思绪十分飘忽。上面的杂乱的文字只是记录了我的一点思考，十分不成体系。关于这个问题，未来会有很多具有独到思考的文章会陆续发布。等我学习了这些思想，再来思考一次吧。
