从5月28日中午11:09，携程旅行网开始无法正常登陆，直到28日23:29分才完全恢复正常。经携程技术排查，确认此次事件是由于员工错误操作，删除了生产服务器上的执行代码导致。根据携程第一季度财报数据，携程宕机损失为平均每小时106.48万美元，本次宕机超12小时可谓损失惨重。

一、那么本次携程宕机事件能缩短到10分钟内吗?

为什么携程宕机持续了超12小时?显然是没有启动任何灾备系统。如果及时进行灾备切换，宕机时间最短可以缩短到10分钟内吗?笔者为此采访了某资深云计算架构师侯老师，“如果在部署了有效灾备的情况下，技术人员可以分秒内启动灾备服务器，从而代替生产服务器正常运行网站。且与生产服务器相比，灾备服务器仅缺少最近4个小时的数据，我们可以快速上传备份数据以保证完整性。”

二、本次数据恢复时间可以缩短吗?

诚然，类似携程这样的大型网站承载着繁多业务，其后台是一个由SOA(面向服务)架构组成的庞大服务器集群，子系统与子页面间相互关联相互依赖，且数据库庞大，但是12小时的恢复时间是否太长了呢?

候老师表示，“虽然携程网站系统非常复杂，但我们可以采取复制灾备服务器的方式，以应对生产服务器的复原。恢复时间视数据量大小而定，但与备份上传方式相比，时间会大大缩短。”

三、本次事件有可能避免吗?

携程已确认本次宕机是由员工误删执行代码所致，为避免此类事情的发生，只能加强数据访问权限管理。

那么问题来了，权限管理到底能严谨到什么程度?

侯老师表示，无论数据存储在云端还是物理端，都可以根据数据的重要性及私密程度，进行分级设置。类似本次被误删的根目录代码，其删除会引起整个数据库的丢失，应该仅对最高级别技术人员开放，并且设置删除询问及二次审核制度。当然，还是需要各位IT人员工作时多加注意，避免疏忽。