公有云事故频发，吃瓜群众怎么看

有人说 ，上公有云就像租房，屋内基础设施一应俱全，租户拎包即可入住，不仅自由灵活，而且便宜易扩展，于是很多企业对公有云趋之若鹜。

然而，有的租户发现，住进去第一天，现金和银行卡没了，第二天，电脑飞了，第三天直接被告知“您的住所正在燃烧”……

这些租户无辜蒙受损失，四处讨说法，结果认识了很多“同道中人”——出租屋失窃遭火被水淹，大家各有各的遭遇。

公有云为何事故频发？

重大损失背后责任归属如何划分？

各供应商和租户应该注意什么问题？

敬请阅读本期走进IT之解密公有云事故现场

今年，某公有云的一个用户向媒体“状告”其重大损失，引爆了IT界吃瓜群众广的朋友圈，为什么近年来公有云故障的事件时有发生？今天我就以一名普通吃瓜群众的视角，来谈一谈公有云面临的四大关键问题以及问题分析，以飨读者。

吃瓜群众如何看事故？

某公有云厂商的故障事件大致如下：

上午 11:57 运维人员收到仓库Ⅰ空间使用率过高告警，准备发起搬迁扩容；

下午 14:05 运维人员从仓库Ⅰ选择了一批云盘搬迁至新仓库Ⅱ，为了加速搬迁，手动关闭了迁移过程中的数据校验；

晚上 20:27 搬迁完成之后，运维人员将客户的云盘访问切至仓库Ⅱ，同时为了释放空间，对仓库Ⅰ中的源数据发起了回收操作；

晚上 20:30 监控发现仓库Ⅱ部分云盘出现IO异常。

事后，复盘发现该故障缘起于单副本数据错误，再加上数据迁移过程中的两次不规范的操作，导致云盘的三副本安全机制失效，并最终导致客户数据完整性受损。

我们知道，运维的过程实际上就是人员、流程、工具三者之间的协同过程。本事件中，CSP(内容安全策略)在人员、流程和工具三个方面都有一些细节问题值得我们去进一步推敲：

• 人的问题：通过事件复盘，我对现场工程师的评价只有一个字—急！所有的操作都是为了快，不顾风险地关闭传输过程校验，不确认一致性就回收空间……可能有人觉得此工程师是不是也被无限期休假了。

这里，我要为现场的工程师说两句：首先，我不相信能够进入到大公司一线运维团队的人是碌碌无为之辈，他的经验肯定是丰富的，他对所有动作有可能带来的后续风险肯定也是心知肚明的。否则，该公司在用人方面就糟糕透了。那他为什么还要犯下这种低级错误呢？

这个问题该问下给该工程师下达数据迁移任务的人，对该工程师提出了什么样的时间要求？作为管理者设定任务完成时限时，有没有考虑到可行性和执行风险？合格的团队在出现问题时首先应该拷问的是管理者，不能只让干活的人挨板子！当然，作为一线操作者，他的问题是没有勇于说不。明显有很大风险的不合理任务，就该直接拒绝，这才是真正的负责。

• 流程问题：流程的设计首先要保证高效，其次更要做到闭环。纵观此次变更，虽然公开的复盘描述中未体现从事件发生到产生工单启动变更流程的过程，但可以看出一线人员的操作权限没有受到任何流程管控。可不经授权直接关闭数据校验，迁移完成后可未经一致性校验直接回收空间。整个变更流程从始至终没能针对数据可用性形成完整的闭环，这是运维管理团队最大的问题。

可能有人会说互联网时代追求的是敏态，要快速地迭代，快速地完成变更，进而才能在竞争中立于不败之地……但我必须告诉你，敏态不等于无序。不负责任地突破底线单纯追求所谓的效率，那是“乱态”，要承担严重的后果的混乱状态。人与系统之间的交互和人与人之间的交互有一个最大的共同点，你对TA负责，TA才会让你放心。

• 工具问题：“敏态运维”的一个必要条件是依靠强大的自动化工具高效完成任务的同时，最大程度地减少人工操作过程的不可控失误。从这个事件看，公有云服务商缺乏有效的容量预测手段，因而只能在超出警戒值进行被动响应，而且后续的操作也多依赖人工操作。在主动式、自动化运维领域，公有云服务商还有很大的提升空间。

简单总结了CSP的问题后，我们还得说说租户自身的问题。作为旁观者，总结租户问题时，我的心情是沉重的。真！的！很！痛！啊！但痛定思痛，我们还是要分析一下租户自身哪些方面做得不到位，才造成了要承担如此严重后果的局面。

首先，租户最大的问题可用一句话来总结：“把所有鸡蛋放在了一个篮子里”！结合前面的分析我们可以看到，CSP对租户所申请的资源的“带外”维护，从租户这一侧都是无感知的，租户不知道CSP在做什么进而无法及时采取一些应对举措。

篮子破了鸡蛋碎了，卖篮子的可能根据合同依法赔偿你三倍、五倍甚至十倍的鸡蛋。但你说你这篮子鸡蛋要孵小鸡，小鸡长大后再生蛋再孵鸡最后你要开养鸡厂，所以让篮子的赔你个养鸡厂？没有任何法律支持这样的诉求。所有服务器、存储提供方均不会对因设备或服务故障所带来的关联损失进行赔偿。

其次，灾备！灾备！灾备！无论云服务商所宣传的服务可靠性是几个9，这都指的是通常状态下的数值。所谓通常状态，就是未考虑相关的人员、环境等外围风险因素的评估结果。即便是你把数据放在9个9可靠性的三副本的云存储上，它也无法保证数据的绝对安全、可靠。

多副本不能替代数据的备份保护，也不能防范灾难的风险。误操作、逻辑故障、灾难事件都能带来数据的破坏，所以自家数据的容灾及备份还是要自己注意，“公有云服务的数据安全”永远是租户首要考虑的。

租户在该公有云上的数据一直在“裸奔”， 如此重大的安全风险存在这么长的时间都没有人认识到且提出应对举措，真的是太不应该了。

从公有云事故总结的经验教训

教训一：

不能把鸡蛋放到一个篮子里。这是在传统IT时代即是老生常谈，云时代也一样。

对于大、中型企业，更适合选择自建私有云+公有云的方式实现多云（multi-cloud）架构，并在多云环境中通过异地备份、容灾手段保证数据安全性和业务连续性。

对于小企业和初创公司，可以考虑采用公有云服务，以较低初始成本快速开展业务，但务必考虑应用和数据的保护与恢复。随着企业规模壮大，需要再次评估“云战略”是否需要调整。

教训二：

核心数据要尽可能放在自己手中。针对本次事件我们不做任何阴谋论假设，也不对其他阴谋论观点予以评述。但任何企业都会有对自身业务极其重要的核心机密数据存在，选择公有云服务时需要特别考虑这些数据的安全性，因为租户对公有云服务商在后台对资源进行的任何操作都是无感知的。所以从防止数据泄漏的角度，核心数据应尽量选择私有云或自有设备进行存储。

教训三：

提升风险意识。所有企业在经营过程中均会面临市场、信用、合规、法律、会计、流动性等多个方面的风险。针对可能的风险，有效识别是采取规避手段的前提，识别风险后，根据风险的财务损失等级采取相应的规避措施是至关重要的。本次数据丢失事件的发生无疑对企业的市场和财务均造成了致命的影响，如能早期识别并采取规避措施，也许今天不会那样的“痛”。

下图是部分公有云服务商的SLA示例，可以看出，“数据备份”都是用户自己的责任，这意味着如果发生数据丢失，租户自己才是第一责任人，服务商只有“协助”义务。这里吃瓜群众真诚提醒各位公有云用户再次评估一下，运行在公有云上的业务应用及数据的保护与恢复是否能满足企业的要求。

企业上云需要考虑的问题：

目前，越来越多的企业已经制定或正在制定自己的“云战略”，公有云服务及私有云、混合云技术得到了广泛的应用。无论您企业的“云之旅”到了哪个阶段，都请试着回答下面我们为您精心整理的问题☟

如果您回答上面的问题有困难，请来咨询戴尔易安信。我们的咨询团队、技术专家都可以帮您解答，随时为您提供全方位的“云解决方案”。

点击▼“了解更多”查看数字化转型方案详情