摘要：谷歌原以为只是一个局部性错误，没想到结果却演变成了一场覆盖所有区域的停运事件。
4月11日，谷歌云陷入了前所未有大麻烦之中。由于两个bug的产生，致使谷歌云全线下线，长达18分钟的无云时间使得谷歌云变成了乌云。
谷歌是全球最大的云服务提供商之一，谷歌云在公有云的圈子内也算是巨头级别的存在。越是强大的公司就越不允许有任何的瑕疵，18分钟的乌云时间却足以砸了谷歌云的金字招牌。现在，谷歌的母公司Alphabet已经就此事件的原因进行了解释。Google 的工程副总裁Benjamin Sloss Treyno表示将进行“7×24”的全天候个人道歉。
为什么是Treynor背起这口大黑锅呢？这事也确实与他有着不可分割的关系。作为谷歌的工程副总裁，Treynor的主要工作就是“确保 Google 的网站永不掉线”。谷歌云下线18分钟如此重大的过失让他负责并不为过。
仅仅道歉是不够的，Treynor也就该事件的原因对外进行了解释。起初，谷歌的工程师要对谷歌的网络配置进行瘦身，谷歌计算引擎（Google Compute Engine ，GCE）中的部分IP模块长期未使用，工程师选择了对其删除并让谷歌的自动化系统在谷歌的网络系统里完成剩余的传输工作。
GCE是谷歌云的核心
而IP模块是用于帮助用户数据连接传输到谷歌云的重要模块。于是事故就这样发生了，在机缘巧合的时候，一个IP模块从其配置文件中被删除时，用于网络配置管理的其他配置文件并没有完成相应的传输转移，于是乎这个模块传输失败了。
当传输失败时，谷歌通常会选择还原故障部分到之前的位置，然后添加新的模块重新传输。但是这次，前所未有的软件bug被触发了。这次传输失败后，并没有将故障部分还原到原来的位置，而是将GCE所有的IP模块进行了重新配置。而这次配置的用的就是用于更新的不完整的IP模块。
如果说仅仅是这一个bug，那么正常情况下也不会有太大的问题。谷歌有一个专门巡查此类问题的系统“金丝雀（canary step）”，但是这次金丝雀也出现了一个bug.因为这个bug推动了系统认定此次新的配置有效，并且在全范围内逐步开始推出。
这些新的配置信息从谷歌的数据中心推广到了世界各地的数据库，但这个巨大的变动很快引起了谷歌技术人员的注意。他们立刻宣布停止了所有的IP模块，中止了这一新型配置的推出，并且开启备用的数据中心，最快的速度恢复用户的工作。
两个bug，一个悲剧
另一发面，技术人员在从世界各地的数据库当中将这些没用�**P模块配置信息删除恢复。但这一系列的bug已经导致了谷歌云出现了长达18分钟的中断。18分钟的乌云也许可以很快驱走，但是18分钟的无云却是无法抹平的用户心理阴影。
谷歌方面表示，他们已经第一时间发现了这两个bug，并且网络配置软件方面的负责人也已经解决了这个问题。而且，今后谷歌将推出14种不同的应急解决方案用于预防、检测和缓解类似情况的发生。
飘摇的谷歌云需要挽回用户的信任
但是谷歌能否真正做到这一点依然是值得让人怀疑的，因为早在2015年8月发生过类似的故障。当时的谷歌云因为字符错乱、管理变更、雷击、自动化失败和补丁失败等原因导致过故障，此次故障后的弥补能否真正为谷歌挽回人心呢？
作为此次故障的主要负责人，Treynor发表了一份很长的道歉信。“谷歌非常认真的对待此次中断事件，这次事件影响范围之广使得谷歌的很多客户受到了影响。这一事件的报告比以往的更长和更详细，因为谷歌希望用户能够了解它发生的原因，以及谷歌在做什么。
谷歌希望通过透明化的服务帮助用户建立信心，也用此证明谷歌云平台的可靠性在不断的成长。“而用户的希望则相对简单，以后别再出现这种问题了。
来自中关村在线
本文链接：https://www.yunweipai.com/6601.html
网友评论comments