分享

2016年2月9日物联网新闻早知道

 秦岭之尖 2016-02-09



2月9日(星期二)

【今日物语】

真正的物联网是数据智能驱动的物联网, 将激发新的经济活力,我们称之为洞察经济。通过云计算、社交和分析等三大引擎的推动,大数据的能量将日益迸发出来,使物联网成为打造全新用户体验的核心驱动力。


——IBM大中华区首席执行总裁 钱大群


【2015年十大云故障盘点】

1月10日~11日,Verizon云


虽然云服务提供商最担心的是长时间停电,但是Verizon通信公司震惊了客户,他们计划让自己的云在整个周末长达40个小时的时间内离线,以实时全面地进行系统维护。

然而讽刺的是,Verizon升级自己云基础设施的一个原因是防止未来的停机。

很多客户都对自己的提供商故意削减他们的云服务感到气恼,但也有人安慰说,Verizon花费这40个小时无缝升级了可能未来让他们在实时系统上不中断运行的情况下就进行升级、甚至是不需要重启服务器的能力。


2月18日~19日,Google Compute Engine


就在午夜前,多个谷歌IaaS数据中心宕机,经过大约一小时的停机,最受影响的客户服务在第二天凌晨一点恢复。

一些连接问题持续了近三个小时,其中大约40分钟的时间内,本该由谷歌虚拟机传送的数据消失在了风中。

谷歌认为这个问题是“不可接受”的,并向受影响的用户道歉。

大约三个星期后类似事件再次发生,谷歌的IaaS同样出现问题,导致一些用户失去了长达45分钟的服务响应。

库评:行走在冬夜的冷风中,一直被打脸的是谷歌。


3月11日,Apple iCloud


在将近12个小时内,全球数百万人无法购买数字音乐、书籍或者是应用。所幸的是,他们大多数没有受到影响。

苹果在向用户致歉中将一个内部DNS错误归结为使iTunes和App Store服务中断的原因。一些iCloud电子邮件帐户也受到了短暂的影响。

库评:大多数人没有收到影响的原因是除去应用之外,购买数字音乐和书籍实在没什么人碰。


3月16日,微软Azure


微软的两项Azure公有云服务在美国中部的客户中中断了2个多小时,微软将其归结为“网络基础设施问题”。

根据微软在Azure状态网页上的报告,这次瘫痪事件发生在CDT时间下午1点刚过,影响到微软Azure虚拟机(基础设施即服务)和Azure云服务(平台即服务)产品的客户。

微软将该问题描述为“部分服务中断”,并表示该服务已经在CT时间3:19完全恢复可用。


3月17日,微软Azure


在第二次故障发生之前,微软公有云甚至都没有撑过24小时,就中断了虚拟机、网站和其他云服务,这次影响到美国东海岸更密集的客户群。

微软在Azure状态页面上报告,这次故障从EDT时间下午1:30开始。作为全球第二大公有云提供商,微软向客户通知称这次服务中断是源自于存储系统发生的故障。


5月20日,Apple iCloud


包括电子邮件在内的11项苹果服务遭遇了11个小时的中断。其中一些完全瘫痪,其他的则运行非常非常缓慢。

中断的服务包括iCloud Drive、Photos、Documents、Find My iPhone、Back to My Mac、iCloud Backup、iCloud Keychain、iCloud Mail、iMovie Theater以及iWork for iCloud Beta。

根据苹果的系统状态页面,全球5亿的iCloud用户中有40%受到了影响。

库评:还记得2014年的苹果泄露明星艳照事件吗。


8月13日~17日,Google Compute Engine


在比利时的一个周四早上,谷歌靠近St. Ghislain的一座超高能效数据中心遭遇4次闪电袭击。

这次雷暴导致一系列技术故障,最终造成一些I/O错误。

据谷歌称,只有很小一部分保存着Google Compute Engine实例的磁盘上出现了数据丢失。

虽然谷歌表示所有数据最终都找回并恢复,但数据中心理应让服务器和客户数据能够应对像这次闪电造成的高压脉冲。

在这种情况下,要责怪的只能是这个超高能效架构遭受的史诗般的雷暴了。


9月20日,AWS


对于亚马逊而言,9月20日是个糟糕的一天。美国东海岸亚马逊网络服务(AWS)出了故障,5小时后才恢复。

一位AWS发言人在对此事作出正式回应时表示,“2015年9月20日太平洋夏令时间凌晨02时13分到早上7点10分,美国东部地区的亚马逊DynamoDB服务的读写操作出现错误率非常大的情况,影响了该地区的其他AWS服务,并造成一些AWS客户也受到错误率增大的影响。“

库评:网友表示,AWS还好不是在周一(9月21日)上午挂掉的,否则网友们少不了吐糟。AWS是周日(9月20日)挂的,周日凌晨太平洋夏令时间3点(北京时间周日下午6点)挂了,几乎没有人注意到。


11月23日,Google Compute Engine


谷歌的网络引擎试图激活一个指向欧洲运营商的链接,但是对方网络处于处理路由一个令人惊讶的高流量,但事实并非如此。

这条线路快速饱和,连接网络丢掉了大多数从受影响的西欧数据中心路由到东欧和中东的数据包。

Google Compute Engine无法与这些地区进行通信长达70分钟,从PST时间上午11:55到下午1:05。

据谷歌称,在该故障发生期间,该季度的流量减少了13%。


12月3日,微软Azure


微软云计算服务Azure在欧洲多个国家发生了停摆故障,这导致许多用户无法使用办公软件。

微软正在向云计算,尤其是传统软件的云服务化转型,这意味着一旦发生网络服务故障,用户将无法访问存放在云中的文档。之前,微软的云计算平台在欧洲多个国家发生了大面积故障,其中Office365的用户也不幸中招。

微软随后表示,是Active Directory配置错误导致了这次瘫痪。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多