上周那场被认为是“史诗般”的IT系统中断事故发生后，国内的IT圈子很热闹，第二天各种分析文章、带货文章都出来了。我也早就想写一写，不过因为最近要写的东西太多了，所以今天才有空写一写。既然写在后面了，分析或者预测原因那套就用不着了，那么我就换个 角度来讨论这个事件吧。

　　最终的结果实际上很简单，中断是由美国一家大型网络安全公司CrowdStrike在周五早上向其企业客户推送的更新引起的，该更新与Windows操作系统相冲突，导致设备无法正常运行。幸运的是，解决问题不难，世界很快就恢复了正常。不过事情依然令人反思，如果一家科技公司的一个错误就可能造成如此大的破坏，那么我们的IT世界是不是过于脆弱呢？

　　事实上，不像一些自嗨的国人认为的是老外的WINDOWS不够安全引发了这个问题，任何操作系统系统都有可能因为组件升级也出现严重的问题，导致业务中断。因此我天朝幸免于难的原因不是XC，而是另有原因。

　　这种因为某个软件的某个存在问题的更新而导致的问题并不少见，当年Oracle SCN HEADROOM问题刚刚发生的时候，O记刚开始出来的补丁不但没有解决这个问题 ，反而让问题更严重了。后来的那场灾难并不比前几天的蓝屏故障差多少。只不过是大量的DBA通过自己无休无眠的工作，让关键民生服务系统维持了表面上的正常而已。

　　社会服务类的IT系统应该属于高SLA要求的系统，因此其业务连续性要求有更高的要求。我国早期的信息化建设过程中，金融、证券、通讯、公共交通、能源等领域都对核心业务系统的业务连续性提出了相当高的要求。90年代中后期开始，银行的核心系统的业务连续性更多的是依赖于IT基础设施的可靠性 ，因此大型机、小型机、两地三中心架构等都成了标配。

　　关键业务系统追求业务连续性，当时的理念是要确保技术栈的全栈可控，一方面IT系统对于IT运营部门来说必须是白盒，IT运营部门也要对核心业务系统的全栈都确保有能力覆盖，能够解决任何异常。在IT基础设施层面 ，也充分考虑到硬件不可能百分之百可靠 的问题，除了消除单点故障外，还要尽可能降低故障发生的可能性。

　　一个极端的例子是，90年代我参加一个银行的系统集成项目，在配置核心系统的存储磁盘组的时候，RAID 0+1的磁盘组，每一对磁盘尽可能选择不同批次的磁盘。可能有朋友觉得这样是不是过于矫情了，不过这也是有惨痛的教训的。2015年的时候，我处置过一个故障，当时一套国产一体机里的90多块SSD盘突然都出问题了。后来发现是这批SSD盘的驱动存在BUG，当负载较高，SSD盘温度较高的时候，会出现IO故障。幸运的是，升级了盘的微码后，系统恢复了，否则丢失数十TB数据的悲剧就要上演了，这样也导致了这套系统宕机超过2天。

　　在PRE-云的时代里，对于公共服务类的关键业务系统的业务连续性解决方案是不怕花钱，就怕考虑不周全。主备系统最好不是同构的；灾备和备份不能在同一机房里；补丁出来后至少半年以上才在自己的核心系统中部署；主备系统的升级不能同时做，要隔一段时间，避免升级软件存在BUG导致问题，等等等等。这些措施可能在很多企业的预案里都有。

　　云时代下，要确保系统在白盒里运行已经不可能了。云平台就是最大的黑盒。云的精神是易用、可靠、弹性、和省钱。易用和弹性是没话说的，可靠的问题谁也说不清楚，上云以后确实用不可靠的X86服务器构建了媲美小型机甚至大型机的可靠IT基础设施。虽然如此，云也不是100%可靠的，遇到一些隐藏很深的BUG或者云底座关键组件升级的 时候，是比较容易出问题的。另外一个比较大的问题就是云出了问题比较难搞定。

　　上云后大家最为关注的问题是成本，无论是公有云还是私有云用户。这回海外出问题的用户很多使用了公有云服务，这次蓝屏事件让我感到震惊的 是国外的那么多社会服务类IT系统居然都在使用公有云，这是和我们的国情完全不同的。按照公有云承诺的SLA，似乎已经达到了以前我们通过两地三中心追求的SLA目标，那么我们是否还需要构建双活系统？依赖于公有云的双活服务是否靠谱？这些问题似乎不大说得清楚。如果按照公共服务的高品质要求，似乎双活或者高可用还是必须要建设的，但是这意味着成本。构建了双活系统后，多数据中心的IT基础设施维护是自己干还是完全交给云厂商？如果自己干，又违背了上云从而降低IT运营费用的初衷；如果不自己干，云厂商标准的软件升级策略能否达到自己的IT运营管理要求呢？这些都是不太好解决的。

　　对于私有云用户来说，似乎解决这些问题要简单多了。事实上也不是那么回事。当初上云的时候主要还是考虑成本的问题，上云可以大幅削减IT运营成本，用更低的成本来达成更高的SLA目标，这是很多企业领导选择上云的最重要的因素。

　　事实真的如此吗？几年前曾经和一个企业的IT高管聊过关于云与成本的问题。他觉得以前小机时代确实是花了不少冤枉钱，一台几百万的小机经常负载不到10%，反而是高端的小机可以做虚拟化，使用率更高一些。到了资源池时代，他们是明显感受到省钱的，服务器的综合资源使用率都在50%以上，也没有因为省钱而降低业务连续性。而到了云时代，感受反而不明显了。以前的容量管理模型不管用了，被废弃了。反正各个应用申请资源，够用就分配，不够用就压缩点。第二年根据前一年的使用情况，加个系数申请资源扩容需求就可以了。自己初步估算估算，这些年花的钱比资源池时代要高了数倍。

　　大多数企业的IT人员都认为云时代构建两地三中心高业务连续性系统也是刚需 。不过想要落地，问题还是落到了成本上。物理机和资源池时代，为某些关键业务系统构建一套多活系统很容易，而在云时代就不同了。首先你必须在同城和异地机房建设另外一套云，这可不是弄两台服务器就可以搞定的，是一个不小的投资。两套云的运维运营又是不小的成本，大量的资金已经投入到云平台上了，再建一朵云对于很多企业来说有点力不从心了。前几年我帮一个企业搞ERP的双活系统，数据库是可以做到同城双活了，但是应用还只是在一个机房部署，这种双活系统，从本质上讲，还只是一个数据级双活系统。

　　我国对于公共服务类系统的业务连续性要求是十分高的，也许这场蓝屏风波，能够给我们的一些IT部门领导敲响警钟吧。是时候重新评估一下这些系统是否能够满足企业的对外业务承诺吧。