“不要“泰囧”!盘点酿成断网事情的各种诱因”

本篇文章4712字，读完约12分钟

引言:

人再囧途中的泰囧在年末年初在床下刷新华语电影的票房记录。 但是，在it行业，数据中心频繁出现的安全障碍也冲击了公司客户的心理防线。 但是，我们希望数据中心的安全问题不要成为人们再次囧囧的“泰囧”。

云计算服务在这个时代以成为it圣者而自豪，所有的服务都被“云计算”化了。 但是很多企业第一次吃螃蟹后，往往最容易受伤的也是他们。 近年来，云服务不断断网，使业界震惊。

人们逐渐回归理想，更清楚地看到楚云计算的真面目。 无论是多么高的梦想，还是为了找到坚实的立足点，云服务最终都会从一个数据中心传输到另一个数据中心，这个过程不会摆脱用户、计算机、互联网、电力、存储等之间的协作 这样的话，整个过程难免会发生错误和脆弱性，会增加天灾和人祸。 因此，要使云服务有效，需要一定程度的觉悟，需要第二二手的应对措施。

编辑回顾一下这里近年来发生的一系列断网事件背后的原因。 2009年-从年开始。 即使计算机错误看起来不可避免，再保险措施似乎也只能把安全控制在小概率范围内。

网络断开类型1 :系统故障

典型的事情1 :亚马逊aws平安夜断网

故障原因:灵活的负载均衡服务故障

年12月24日，刚过的圣诞节平安夜，亚马逊没有让他们的顾客太平安。 aws在美国东部1区的数据中心发生故障，灵活的负载均衡服务( elastic load balancing service )中断，netflix和heroku等网站受到影响。 其中，heroku还受到过以前aws美国东部地区的服务故障的影响。 但是，有些偶然事件是netflix的同行竞争对手，亚马逊自己的业务amazon prime instant video没有因为这个故障而受到影响。

12月24日，亚马逊aws中断服务不是第一次，当然也不是最后一次。

年10月22日，位于亚马逊北弗吉尼亚的互联网服务aws也中断了。 那个原因和上次相似。 事故影响了reddit、pinterest等知名网站。 影响灵活的豆子服务，然后继续进行灵活的豆子服务控制台、关系数据库服务、灵活的缓存、灵活的计算云ec2和云搜索。 这次事故使很多人认为亚马逊应该升级北维尼吉亚数据中心的基础设施。

年4月22日，亚马逊云数据中心服务器大规模停机被认为是亚马逊历史上最严重的云计算安全。 由于亚马逊在北弗吉尼亚州的云计算中心停机，包括回答服务quora、新闻源服务reddit、hootsuite和位置跟踪服务foursquare的站点受到了影响。 根据亚马逊的官方报告，这次的事情是因为ec2系统的设计有脆弱性和设计缺陷，同时主张是为了不断修复这些已知的脆弱性和缺陷，提高ec2 (亚马逊elasticcomputecloud服务)的竞争力。

年1月，约6.8万名salesforce客户经历了至少1小时的停机。 salesforce由于自身数据中心的“系统错误”，导致所有服务(包括备份)暂时中断。 这也显示了salesforce不想公开的锁定策略。 旗下的paas平台，force不能在salesforce之外采用。 所以如果salesforce出现问题，force也会出现问题。 因此，服务长时间中断，问题变得棘手。

第2页:网络断开诱因2 :自然灾害

网断诱因2 :自然灾害

典型的事情1 :亚马逊北爱尔兰柏林数据中心停机

故障原因:闪电击中柏林数据中心的变压器

年8月6日，北爱尔兰都柏林发生的闪电导致亚马逊和微软的欧洲云计算互联网因数据中心停电引起了大规模停机。 闪电击中都柏林数据中心附近的变压器后爆炸了。 爆炸引起的火灾使所有公共服务机构的员工暂时中断，整个数据中心瘫痪。

这个数据中心是亚马逊欧洲唯一的数据存储区。 也就是说，ec2云计算平台的客户在事故中没有其他数据中心可以临时使用。 停机中断了使用亚马逊ec2云服务平台的多个站点两天。

典型的事情2 :卡尔加里数据中心火灾事故

故障原因:数据中心发生火灾

年7月11日卡尔加里数据中心火灾事故:加拿大通信服务提供商shawcommunicationsinc在卡尔加里艾伯塔的数据中心发生火灾，当地医院数百家手术延误。 由于该数据中心提供了管理应急服务，这次火灾影响了支持重要公共服务的主要备份系统。 这次的事情要向一系列的政府机关敲响警钟，确保及时的恢复和故障转移系统，结合灾害管理计划。

典型的事情3 :超级飓风桑迪袭击了数据中心

故障原因:数据中心因暴风雨和洪水而停止工作

年10月29日，超级飓风桑迪:纽约和新泽西州的数据中心受到了这场飓风的影响。 这包括曼哈顿市区的洪水和设施停止，周边地区数据中心的发电机异常等。 桑迪带来的影响超过了通常的单一中断事故，给受灾地的数据中心产业带来了规模空前的灾害。 事实上，柴油已经成为数据中心恢复事业的生命线，作为备用电源系统接管整个地区的负荷，促使特别措施，维持发电机的燃料。 随着眼前的业务点转向灾后重建，需要长时间研究数据中心的位置、工程和灾难恢复。 这个话题可能会持续几个月到几年。

第3页:网络断开诱因3 :人为因素

断网诱因3 :人为因素

典型的事情1:hosting服务中断事故

故障原因:服务提供商因断路器操作顺序不正确而关闭了ups

年7月28日hosting停止:人为错误通常被认为是数据中心停止的主要因素之一。 7月hosting中断导致的1100名顾客服务中断就是一个例子。 停机是因为ups系统在特拉华州纽约的数据中心进行了预防性维护。 “由于服务提供商操作断路器的顺序不正确，ups关闭是导致数据中心套件中设施丢失的重要因素之一。 ”。 hosting CEO Artzeile说。 "重要的电力系统和备用电源系统没有出现故障，完全是人为错误造成的。"

典型的事情2 :微软中断了bpos服务

故障的原因:微软在美国、欧洲和亚洲数据中心的明确配置错误

年9月，微软为美国西部几周内至少发生了三次托管服务中断向客户道歉。 这是微软第一次暴露出重大的云计算。

事故发生时，客户访问BPOS ( BPOS )服务时，利用微软北美设施访问服务的客户可能出现了问题，这个故障持续了两个小时。 之后，微软工程师声称处理了这个问题，但由于没有处理根本问题，9月3日和9月7日的服务再次中断了。

微软clint patterson说，这次数据突破的原因是微软在美国、欧洲和亚洲数据中心的明确安装错误。 bpos软件的离线通讯簿在“非常特别的情况下”提供给非法客户。 这个通讯录包含公司的联系新闻。

微软表示，这个错误在发现后两小时就修复了。 微软表示，有跟踪设施可以与错误下载这些数据的人取得联系，删除数据。

第4页:网络断开诱因4 :系统故障

网络断开诱因4 :系统故障

典型的事情1:godaddy网站dns服务器中断了

故障原因:系统中一系列路由器的数据表导致互联网中断

年9月10日godaddy网站dns服务器中断:域名巨头godaddy是最重要的dns服务器供应商，拥有500万个网站，管理着超过5000万个域名。 所以9月10日中断事故将是一年中最具破坏性的事情。

一个炒作甚至认为这次长达6个小时的中断是拒绝服务攻击的结果，但godaddy后来说是路由器表的破损数据造成的。 “服务中断不是外部影响造成的。 “”godaddy的临时首席执行官斯科特·瓦格纳说。 “既不是黑客攻击也不是拒绝服务攻击( ddos )。 我们发现，服务中断是由于内部一系列路由器的数据表导致的互联网损坏。 "。

典型的事情2 :盛大的云存储中断

故障原因:数据中心的物理服务器磁盘已损坏

年8月6日晚上8点10分，盛大的云在官方微博上发表了关于云主机故障导致客户数据丢失的公开声明。 根据声明，8月6日，盛大的云因无锡数据中心的物理服务器磁盘损坏而丢失了“个别顾客”的数据。 盛大的云正在竭尽全力恢复客户的数据。

由于“物理服务器磁盘发生破损”，在“个别顾客”的数据丢失的情况下，盛大的云技术人员解释说，虚拟机的磁盘有两种生产方法，一种是直接采用宿主机的物理磁盘。 在这种情况下，如果宿主机的物理磁盘出现故障，云主机将被迫丢失数据。 这也是这次事情的原因。 另一个是采用远程存储，即盛大的硬盘产品。 这种方法实际上是将客户的数据存储在一个远程群集上并进行多个备份。 宿主机出现故障不会影响云主机上的数据。 由于物理机不容易损坏，因此为了避免意外损失，我们建议在云主机之外也进行数据备份。

典型案例3 :谷歌app engine中断服务

故障原因:互联网延迟

谷歌app engine:gae是web应用程序开发和主机的平台，数据中心由谷歌管理。 中断时间是10月26日，需要4个小时。 反应突然变慢，发生错误。 受此影响，50%的gae请求失败。

谷歌表示数据没有丢失，应用程序的运行也可以恢复备份。 对不起，谷歌在11月宣布了顾客加强互联网服务以应对互联网延迟问题。 “通过增强流量路由功能和调整配置，可以更有效地防止这些问题的再次发生”。

第5页:网络断开诱因5 :系统错误

网络断开诱因5 :系统错误

典型的事情1:azure全球中断服务

事故原因:软件错误导致闰年计算不正确

年2月28日，由于“闰年bug”，微软azure中断了全球大面积服务，中断时间超过了24小时365天。 微软说这个软件的bug是因为闰年的计算不正确，但这件事引起了多个顾客的强烈反应，很多人开始要求微软做出更合理详细的说明。

典型情况2:gmail电子邮件地址发生全球故障

事故原因:数据中心定期维护时新程序代码的副作用

2009年2月24日，谷歌的gmail电子邮件地址发生全球故障，服务中断长达4小时。 谷歌解释了事故的原因。 在欧洲数据中心的定期维护时，试图将地理位置相近的数据集中在所有人身上的新流程代码中有副作用，欧洲的另一个数据中心过载，连锁效应扩展到其他数据中心的接口

典型的事情3 :“切断5.19网”

事故原因:客户端软件错误、互联网终端频繁启动域名分析请求，引起dns拥塞

2009年5月19日21:50，江苏、安徽、广西、海南、甘肃、浙江等6个省的客户报告网站访问速度变慢或无法访问。 根据工信部相关部门的调查，这次全国六省互联网中断事故，在国内某企业发售的客户端软件有缺陷，该企业域名授权服务器的业务异常的情况下，安装了该软件的互联网终端需要域名解析

其中，dn spod是国内知名域名解析服务商之一的n spod企业，服务一些知名网站的域名解析服务。 由于这次攻击，dn spod企业所属的6台dns域名分析服务器停机，包括暴风av在内的多个供应商的域名分析系统停机，导致互联网拥挤，很多顾客无法正常连接互联网。 工信部指出，这次事件暴露了域名解析服务成为当前互联网安全的弱点，并指示各部门加强域名解析服务的安全保护。

总结:

启用云服务的企业认为这样的服务更多，性价比更高。 但是，这样的想法如果以降低安全性为代价的话，预计很多企业的领导会不同意。 陆续出现的云服务的网络切断使我担心云服务的安全性。

现在处理的方法可以从几个角度考虑。 对于公司级客户来说，使用云服务，定期备份云服务的数据，根据需要有第二个处理方案。 对于云服务提供商来说，既然各种网络中断是不可避免的，那么就必须考虑对策，将自己客户的损失降到最低，提高对网络中断的响应效率。

政府部门有监督和警告的责任，与云服务相关的法律陆续制定和完善，同时警告顾客目前不存在100%可靠的云计算服务。