扯个淡：云数据99.99%安全？有时候0%

顶级巨头2019年6月以来停电或宕机事件

• 6月2日，谷歌云停运，一个错误诶之导致该问题在整个Google服务器中级联，导致整个云端的网络锁定超过三个小时。

• 6月24日，由于网络路由泄漏，Cloudflare在长达数小时的停机期间下降了15%的全球流量。亚马逊，Linode和依赖Cloudflare基础设施的其他主要公司也陷入停顿。

• 7月2日，Cloudflare遭遇了第二次中断 - 这次是由于内部代码推送造成的。

• 7月2日，谷歌遭遇了另一次停电。这次中断持续了大约6个小时，尽管谷歌表示，通过其他数据中心路由流量可以缓解大部分中断。Facebook及其整个服务组合 - 包括WhatsApp和Instagram - 在7月3日，发生停电故障达8个小时，因为它的共享内容交付网络受到停机时间的影响。大约在同一时间，Twitter音乐GG，在推文中承认消息系统发生故障。

• 7月4日，轮到苹果了。iCloud遭遇了全国范围的三小时停电，几乎影响了其基于云的服务的每一部分 - 来自App Store，Apple ID，Apple Pay和Apple TV。

• 7月11日欧盟的全球导航卫星系统伽利略发生了神秘的停电，“伽利略”中断服务接近5天后恢复，原预计48小时解决。

• 7月13日，由于服务中断问题引发全球性中断，Twitter已经关闭
  

• 7月31日，Microsoft 365全球范围遇到登陆问题，Outlook服务器临时关闭

• 8月20日，谷歌的免费Gmail电子邮件服务中国时间昨天夜里经历了全球范围内停运，它阻止用户登录，在他们尝试登录自己的帐户时显示“出错”错误。
  

• 8月22日，GitHub Git存储库托管平台经历了广泛而重大的全球性服务中断

• 9月1日，Reddit用户在访问该网站时遇到了问题。连接问题的原因是Amazon Web Services（AWS）上发生的事件，该事件是Reddit的托管服务提供商亚马逊问题。

亚马逊AWS数据工厂最近的停电中断以及由此导致的一些客户数据丢失表明，将数据存储在云中并不意味着您不需要备份。

在作者/程序员Andy Hunt发布推文之后，他发现人们硬件故障可能发生在任何地方并且云端托管数据不会十分可靠和安全。

来自Andy Hunt的推文

2019年8月31日，位于北弗吉尼亚州的亚马逊AWS US-EAST-1数据中心在凌晨4:33 经历了电源故障，导致数据中心的备用发电机启动。不幸的是，这些发电机在大约上午6点开始失效，导致7.5％的EC2实例和EBS卷变得不可用。

我们将继续努力恢复所有受影响的实例和卷，并将通过Personal Health仪表板与剩余的受影响客户进行通信。为了立即恢复，我们建议尽可能更换任何剩余的受影响实例或卷。“

电源恢复后，亚马逊确定某些EC2实例和EBS卷遭受硬件损坏，并且存储在其上的数据不再可恢复。

Amazon Elastic Block Store是一项亚马逊服务，允许您创建块级存储卷，然后可以将其作为存储附加到Amazon EC2虚拟机实例。

在受到这次停电的影响之后，Hunt告诉BleepingComputer他发现整个体验令人沮丧，因为他在试图获得状态更新时“不断从亚马逊那里得到废话”。

“我们的工程师目前正在调查受影响的实例，例如你的实例，所以这将需要一些人来调查所有实例受此事件影响的持续问题。请随时向我们发送更新信息。但是，由于没有ETA目前，请记住，在工程师完成调查之前我们不会收到任何信息，这可能需要一段时间。如果您有任何进一步的问题或疑虑，请告诉我们。“

终于在9月3日，亨特被告知他的数据无法恢复。

不存在0%，但是对亨特来说，数据变成了0%。

“由于电力事件造成的损害，这些卷下的EBS服务器尚未恢复。在进一步尝试恢复这些卷之后，它们被确定为无法恢复。”

对于Hunt来说，这种数据丢失并不是灾难性的，因为他有可以恢复的工作备份，但对于其他可能依赖亚马逊的EBS广告冗余和持久性功能的人来说，数据丢失可能意味着很大的问题。 

无论数据存储在何处，始终执行备份

Hunt的经验对于在云端托管数据的任何人来说都是一个很好的教训。

无论服务宣传哪些功能，为您的数据合并辅助备份策略始终都很重要。

例如，亚马逊EBS宣称自己“旨在通过在可用区（AZ）内复制来防止故障，提供99.999％的可用性和年度失败率（AFR）在0.1％-0.2％之间。”

广告亚马逊EBS功能

即使有这些广告功能，亚马逊也会通过明确声明他们只会因服务可用性损失而发放信用额并且不对数据丢失负责，从而保护自己。

“作为使用Amazon EC2的一部分，您同意您的Amazon EC2资源可能因失败，退休或其他AWS要求而被终止或替换。对于任何损害，责任，损失（包括任何腐败，我们）不承担任何责任。删除，破坏或丢失数据，应用程序或利润），或由此产生的任何其他后果。“

亚马逊并不孤单。例如，DropBox表示他们为所有计划提供“120天的文件恢复”，包括免费计划。对于大多数用户而言，这意味着他们不需要担心在备份数据时意外删除或硬件损坏。

即使有这个功能，DropBox 声明他们也不对丢失数据负责。

至多，遭遇数据丢失的用户将因损失而获得几个月的信用，而由于数据丢失，他们可能会损失更多。

现实情况是，无论服务或设施的设计如何精良，都会发生硬件故障，并且必须为任何不测事件做好准备。

即使经历了亨特的经历，他也承认“现在，在亚马逊的辩护中，我们已经在这里托管了这个应用程序和数据多年而没有发生任何事故。”

国内云曾经的一场灾难0%

2018年7月，声称99.9999999%数据可靠性，搭载了云硬盘提供三副本存储策略的腾讯云，给一家创业公司，带来了毁灭性灾难。

作为一家以微信公众号起家的创业公司，前沿数控经过2年的深度垂直发展，将业务扩展至国内外。不仅自行开发了包括网站、H5、小程序产品，且与全球高端装备制造业的德国、日本、瑞士、美国等一批龙头企业建立起深度合作。

为应对迅速增加的流量趋势以及安全可靠的需求，“前沿数控技术”选用了腾讯云服务器。

这时候灾难的开始了。

2018年7月20日，腾讯云出现问题，前沿数控近千万元级的平台数据全部丢失，包括经过长期推广导流积累起来的精准注册用户以及内容数据，这瞬间将一家创业公司摧毁….

遭遇这种变故，对于任何一家公司来说，都是崩溃的。在事故发生后，前沿数控不间断的向腾讯发消息，企图挽救。大概并没有意识到问题的严重性或者是没有把一家公司的生死放在心上，在交涉的过程中，腾讯方给出的答复始终是“已向公司相关部门反馈，请耐心等待”。

事故发生14天，终于等来腾讯明确的答复：补偿责任总额不会超过腾讯云公司就违约服务收取的服务费用总额，另外赠送一个腾讯云价值10万元的套餐包。随后，腾讯云大概感觉到这样的答复好像有什么不妥，很快将赔偿方案中的10万套餐包改为13.29万元现金，说这是他们争取的最大赔偿了。

两年心血打造的平台、千万数据的丢失，一家公司的命脉，13万？

很难相信这是腾讯这样的大公司能给出的解决方案。

云不是100%安全的

此类事件并不少见，2018年6月，阿里云也发生同类事件，导致了国内半个互联网瘫痪。

很多网友表示不满：

在经过紧急的抢修后，阿里发表声明：没有借口，我们不能也不该出现这样的失误！我们将认真复盘改进自动化运维技术和发布验证流程，敬畏每一行代码，敬畏每一份托付。

国内云频频掉链子，国外也同样没那么给力。7月17日，AWS（亚马逊公司旗下云计算服务平台）管理控制台间歇性失灵；紧跟着的第二天，7月18日，谷歌云的平台全局负载均衡服务发生了中断......

大概是坏消息会传染，好像全世界都笼罩在一种惴惴不安的气氛。

解决问题比解决人更重要。能在第一时间成功解决，把损失降低到最低固然是好，但是事情既然发生，就必然会有一方或者多方受到伤害，如何避免此次事故的再发生？

云数据没有99.99%安全，始终切记备份！

因为有时候会0%

转发是对我们最大的鼓励

                                                                                            点个看吧↓

原文始发于微信公众号（红数位）：扯个淡：云数据99.99%安全？有时候0%