北京 工夫5月29日 信息，携程宕机十多个小时后，终于在5月28日23时左右，除个别业务外，携程官方网站及APP 复原 畸形 。事后，携程 通过排查公布申明，称数据没有 迷失，此事件因员工误操作所致 。

携程宕机缘由 原形毕露(图片来自腾讯)

    今日凌晨1：30分，携程 通过技术排查后确认，此次事件是因为员工 舛误操作招致 。关于 复原 工夫较长的缘由，则是因为 波及的业务、 利用及服务繁多，验证 利用与服务中间的 性能是不是 畸形运行，花了较长期 。

    携程最终还 保障，数据和数据库并未受到此次事件的影响，消费者订单数据也 完全无损，并 示意携程在系统上做了改良， 标准并杜绝技术人员 舛误删除生产服务器上代码的操作 。

    当前，携程官方网站及APP已于28日23:29全面 复原 畸形 。而在5月28日11时左右，点击进入携程网，页面显示404报错， 固然点击“返回忆页”后依旧 可以进入携程网，但其 性能和其它链接均 无奈 使用 。

以下为携程对 有关问题的 注明：

1、事件 产生缘由

　　经携程技术排查，确认此次事件是因为员工 舛误操作，删除了生产服务器上的执行代码招致 。

2、为何 复原 工夫那么长

    普通来说， 类似携程这样的大型网站承载着繁多业务，其 后盾是一个由SOA(面向服务)架构构成的 宏大服务器集群，看似 方便的一个页面背后由上千个 利用子系统以及上千个Web Service构成，而每个 利用子系统和每个Web Service中间都存在着 彼此调用的依赖关系 。

　　 产 惹事件后，携程的技术人员除了需求恢 复活产服务器上的执行代码以外，还需求做的是 复原并确保每个 利用子系统以及每个Web Service的 性能 畸形，同时确保 利用子系统与Web Service间的调用关系得以 畸形执行 。

　　这种验证性的操作需求携程的工程师及运维人员通力合作，尽快恢 复活产代码并通过 反复地、 连续性地调试以确保 利用子系统与Web Service 性能的 畸形运行 。

　　携程再次 保障，数据和数据库并未受到此次事件的影响，消费者订单数据也 完全无损，请消费者 释怀并 接续 使用携程网站及App 。

3、如何杜绝此类事件的再次 产生？

　　携程在系统上做了改良， 标准并杜绝技术人员 舛误删除生产服务器上代码的操作 。