VMware也玩停机——首次停机后的恢复工作中遭遇二次停机

Cloud Foundry服务器接连遭遇停机

VMware公司在对其推出的新云计算服务器进行停机恢复时，无意中于次日造成了第二次停机，此情况目前已得到该公司证实。

VMware新的Cloud Foundry服务器——仍处于测试阶段——在上一周遭遇了超过两天的停机问题，而就在不久之前，刚刚发生了广为人知的Amazon弹性云计算服务大停机事件。

Cloud Foundry，一款平台即服务产品，为开发人员在网页应用程序的构建及组织方面提供所必需的支持，于今年四月十二日发布，但旋即于同月二十五及二十六日接连发生“服务中断”事故。

***次停机事件的起因是某供电柜发生故障。应用程序仍能够在线访问，但开发人员无法执行类似登录或创建新应用程序等操作。该次停机持续了近十小时，并于当天下午得到修复。

但就在第二天，当VMware公司的官方工作人员尝试实施先期检测方案以避免前一天的事故再次发生时，意外导致了新一轮停机。

VMware公司的官方发言人Dekel Tankel解释说，四月二十五号的供电中断是“随时可能发生的意料内事故，”而VMware公司已经通过对相关软件、监控系统以及运作模式方面的强化来确保客户不会因系统停电而无法接入服务。

考虑到这一点，VMware公司第二天就开始部署“一套全面的、用以进行先期检测、预防以及恢复操作的方案”。

“上午八点钟（四月二十六号）该方案开始由我们的执行及工程团队进行审查，并预计会在中午时得到初步认定，”Tankel写道。“当时这套方案还只停留在理论层面，我们的计划是先进行模拟实践练习（即在不触动键盘按键的前提下进行部署练习），直到审查工作彻底完成。不幸的是，当天上午十点十五分，执行团队中的某位方案规划工程师触动了键盘。这直接导致了整套Cloud Foundry网络基础设施的停转。该操作使得所有负载平衡器、路由器和防火墙都被清空；造成了我们的部分内部DNS基础设施停转；同时导致全部外部连接都无法接入Cloud Foundry。”

在接连发生的两次停机中，第二天的停机尤为严重。

“这是我们面临的***次停机问题，这是一次很大的事故，我们需要临时布置系统维护页面，”Tankel继续说道。“在停机过程中，所有的应用程序及系统组件仍在继续运行。然而，随着前端网络的失灵，所有外部用户都无法应用服务，因此只有我们自己知道设备仍能工作。当日美国太平洋时间上午十一点三十分，前端网络运行全面恢复。”

VMware公司第二次停机事故表明了人为失误在云服务网络故障中所占的比重之大，正如Amazon在对其云服务中断进行深入分析后得出的结论一样。在Amazon事件中，系统升级过程中的一次人为失误引发了极大的麻烦，造成的严重后果耗费了数天才得以完全修复。（详细内容可参考：“Amazon：计划升级过程中的操作失误导致停机”）

VMware公司，一直以其服务器虚拟化技术而著称，是公开类云服务领域的后起之秀。在此之前，VMware公司的主要业务是帮助客户及服务供应商建立自己的云平台。

因为就目前来看，Cloud Foundry还属于一项新兴的业务，因此服务器停机并未对太多客户造成影响，至少不像Amazon事件的影响那么巨大，因为后者发生故障的同时，导致了无数依赖于其基础设施的其它站点陷入瘫痪。但VMware公司无疑已经从这次事件中吸引了教训，想要成为服务供应商，一定要对极端情况做好充分的心理准备。

原文名：VMware causes second outage while recovering from first 作者：Jon Brodkin

【本文乃精选译文，转载请标明出处！】

【编辑推荐】