云计算成长路上的坎坷

“云”可谓是现在的热门词汇，似乎不管什么公司，都要搭上“云”这个概念就是引领潮流、适应时代了， 所以“云杀毒”、“云安全”都出现了，一时间阿猫阿狗都上云了。《蜗居》里面有句台词：原本光鲜亮丽之后，就是衣衫褴褛。国际化大都市，就是一个舞台，所有的焦点，都会聚集在镁光灯照射的地方，观众能看到的，只是华美壮丽的一面。可这光鲜照 不到的地方，即便是有灰尘，甚至死耗子，谁又会注意呢？同样的，互联网上镁光灯聚焦的云计算背后，是否也有着不足为外人道的酸楚呢？下面表格列举了全球知名的一些云计算、云服务的提供者成长路上摔过的跤：

 

云供应商	发生时间	故障时间	影响范围	原因及总结
微软Azure	2009年3月	中断近22个小时	测试阶段，试用期的测试应用	发生在测试期，令其管理者学会了应对灾难与宕机的处理方法
Rackspace	2009年6月 2009年11月	不详	服务器停机	跳闸后备份发电机又失效。 透明、持续地在博客上更新服务中断的原因及修复进展，得到用户的充分谅解
Salesforce	2010年1月	1小时	68000名Salesforce.com用户	数据中心的“系统性错误”。
Heroku	2010年1月	1小时	4万4千个运行服务中断	依赖的Amazon EC2实例出现瘫痪。 教训：全部运行实例都运行在一个单一的可用区域，容易发生服务中断故障
Terremark	2010年3月	7小时	2%的Terremark用户服务瘫痪	“连接丢失”导致。 用户对供应商的故障处理方式极为不满，没有提供状态报告和服务预警。
Intuit	2次：2010年6月、7月	2天、数小时	包括Intuit自身主页在内的线上产品瘫痪	原因不详及停电
Amazon	2009年6月 2010年4月、5月	5小时、6小时、8小时……	服务中断、整机架服务器断电等	雷雨影响、UPS故障、电力短路、车撞电线杆…… Amazon一次比一次处理成熟，AWS状态页面提供背后原因相关的信息以及解决方案

 从以上事例可以看出，2009年至2010年 “云计算”概念喧嚣尘上的这段时间，全世界不同的云供应商发生了大大小小多次故障，原因有三类：电力系统、网络连接、自身软件问题，而其中电力系统占了多数。事情并不是到此为止，可以肯定的是，往后的日子里，这些大大小小的云朵，还会遇上风雨，甚至随风而逝。云计算并非生而完美，必定要经历一系列挫折，而 在这个过程中，供应商们需要做的就是研究这些故障产生的原因，及时改进，同时与用户充分沟通，达成谅解。唐太宗讲以史为鉴可以知兴替，这些前车之鉴，是我们很好的镜子，帮助我们避免重复犯相同的错误。 而云也不是解决一切问题的万能药，对天上飘着的云的朵，不能只看到它的美丽光鲜，也要看到其背后隐藏着的雷电。从结构设计上就可以考虑周全的，千万不要重复这些IDC停电、UPS故障、互联网出口单点之类的低级错误。