攻击、代码与流言：携程灾难全记录

网传今天中午时分携程公司内技术部现场

携程今日上演了“天地大冲撞”的灾难剧情。来自携程官方的最新消息是：“携程app已经恢复，官网产品正在逐步恢复中。”

今天（5月28日）上午11点左右，携程旅行网官方网站突然陷入瘫痪，登陆显示404错误。

稍后，携程官微发消息称“今天上午11时09分，携程的部分服务器遭到不明攻击，导致官方网站及APP暂时无法正常使用，目前正在紧急恢复。”

根据笔者获得的信息：携程系统昨日便已出现问题，技术部门未能及时解决，今清晨5时许，客户订票无法正常出票。在中午到来前，内网、外网 、App陆续瘫痪。

微博用户 @尜尜DJ ，实际身份为华住酒店集团的产品经理在微博上发布了“还原携程网宕掉事情原委”的信息：

虽然该用户称此微博仅为小道消息和脑补，但是她联系过携程上班的朋友，对方表示线上发布一直有问题，一发布就被删。

这一消息中，“灵异事件”说明其信息不够充分，“发布依旧被删”则与笔者从各渠道获得的信息近似。

其实自今年1月起，乌云平台就已经曝光了超过十次携程的漏洞，包括撞库、官方邮件劫持、内部员工邮箱历史信息泄露、信息泄露，但携程的回应大多是“无影响厂商忽略”。

乌云网官微对上述微博的回复，基本汇总了下午舆论场中对该事件的推测与传言：

“携程业务故障引发了各版本的‘真相’在互联网疯传，什么物理删库、离职员工报复、管理员感情纠葛甚至连乌云君也被拉下水了……从11点到目前仍未解决问题也说明这是其自身甚至国内互联网都没遭遇过的重大事故。”

与最先传闻数据库被物理删除的消息不同，根据笔者接触到的匿名信源透露：数据库并未丢失。问题可能发生在代码上，所有节点上业务代码均被删除，并且发布日志消失，备份也被清除。

机制和灾难应对反思

根据笔者的从业经验来看，大型互联网公司保护数据安全的机制健全，技术也非常成熟。此次携程问题严重，需要从整个机制和灾难应对过程中反思：

1、企业为了信息安全，数据库均会异地备份

首先采用动态备份记录最新形态，还要做静态的异地备份。出错时可以进行恢复，另外还要做至少2个“死备份”，防止备份丢失、损坏或者被篡改。关键数据一般都会进行同城和异地的实时备份，可以保证业务实时切换。一般公司还会制定灾难恢复计划并定期进行测试，确保各个恢复程序。

此次携程恢复时间之长，就说明问题不只出现在数据库方面。携程技术部门的初始工作是在每个节点重新部署业务代码，结果发现无法部署，推断原因可能是服务器被攻击，导致发布通道关闭，甚至会有人员层面的严重问题。

2、对员工的安全审查：

为了信息安全，员工在入职时进行背景调查，在离职时第一时间关闭权限账户。数据库权限对大公司来说会有负责权限级别管理，分为管理员、大管理员、超级管理员，会设置层级限制。涉及到删除操作，会有操作日志，记录是哪个账户执行的。而重要数据的删除会有严格的审核制度。

由于较长的一段时间内无法部署代码，从业者普遍推测：可能是掌握root权限的（现在或者以前的）运维人员写了删除脚本。有未经证实的传闻说，携程的内部检查中发现已离职的具有7级权限的开发总监留下了后门。

3、数据存储采用加密而非明文。

加密的方式主要是MD5，加密之后就算黑客侵犯隐私信息也没什么用，因为只能得到乱码。

虽然上次携程的隐私信息泄漏的安全事故中，人们发现携程使用明文储存。但这一次携程遭遇完全删除，则显然是完全恶意的。

4、web程序和DB服务器分开，服务器群组有防火墙隔离，界面和数据库相互隔离

此次携程的安全问题已超过这个范畴。

至于知乎上的这个问答，只能当作段子来消遣一下：

宕机会损失多少？

先看组历史上互联网公司发生过的宕机，导致损失的数据：

按照携程一季度财报公布的数据，携程宕机的损失为平均每小时106.48万美元，损失的用户数和品牌形象......就难以用货币单位来统计了。