回顾与反思：支付宝携程相继宕机的黑色48小时

5月27日、28日，短短48小时内，支付宝、携程、艺龙、知乎、Uber等多家知名互联网企业先后出现故障，再次将互联网安全问题推至风口浪尖。

今天，当故障已修复，网站服务恢复正常，对安全隐患的拷问，却不该这么早结束。

让我们一起回顾和反思互联网行业的黑色48小时。

1

5.27支付宝故障

事件

5月27日下午17时许，支付宝全国大范围故障，用户登录支付宝无法转账、无法查看余额等信息。

恢复

5月27日晚上19点20分，支付宝方面宣布用户服务已经恢复正常。

原因

支付宝公司发布公告，称支付宝故障原因，是杭州萧山一处光缆被挖断。

解决

方式

支付宝在系统上采用了“异地双活”架构，即杭州和外地两处机房同时为用户提供服务，系统会自动将全国所有用户的需求分流到两处机房。

在光纤被挖断的意外发生后，支付宝立即将用户发往杭州机房的需求引流至异地的机房，所以在受损光纤并未接通的情况下，支付宝服务已经可以恢复正常。

2

5.28携程宕机

事件

5月28日上午11:09，携程官方网站及APP出现无法正常使用的情况。

恢复

5月28日23:29，携程官方网站及APP全面恢复正常。

原因

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

损失

按照携程一季度财报公布的数据，携程宕机的损失为平均每小时106.48万美元。

解决

方式

一般来说，类似携程这样的大型网站承载着繁多业务，其后台是一个由 SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由上千个应用子系统以及上千个Web Service组成，而每个应用子系统和每个Web Service之间都存在着相互调用的依赖关系。

发生事件后，携程的技术人员除了需要恢复生产服务器上的执行代码以外，还需要做的是恢复并确保每个应用子系统以及每个Web Service的功能正常，同时确保应用子系统与Web Service间的调用关系得以正常执行。

这种验证性的操作需要携程的工程师及运维人员通力合作，尽快恢复生产代码并通过反复地、持续性地调试以确保应用子系统与Web Service功能的正常运行。

3

艺龙遭攻击

事件

5月28日下午17时许，艺龙网首页出现无法访问的问题。

恢复

28日下午17:30许，艺龙网服务恢复正常。

原因

艺龙网在携程故障后遭受了大流量DDoS攻击

解决

方式

艺龙网紧急接入腾讯云大禹系统，过滤攻击流量，将正常流量引入网站。

拨开安全迷雾

反思

互联网不及挖掘机？

“再牛的互联网公司，也干不过挖掘机。”虽然只是一句玩笑话，却形象地道出了互联网公司 的“七寸”，而这仅仅是从移动支付应用的硬件基础上来说。移动支付的安全既包括网络硬件设备的安全稳定，也包括对 软件漏洞的防护、应用场景的使用流程等。安全需要产业链联手共筑防线。

数据架构存在问题？

卡巴斯基相关负责人：

支付宝事件按官方的说法是光纤被挖断，是一个意外，但对这种关键性应用需要几个小时才能恢复，说明支付宝方面的数据中心架构存在问题，一个真正的“异地双活”架构只会让很少的用户受到影响，而且整个业务恢复的时间一般按分钟计算，不会以小时计算。”

运维之殇？

资深运维从业者，自动化运维和 云计算倡导者智锦：

传统的运维人员实际上是所谓的“黑盒运维”，不断的去做重复性的操作，时间长了之后，只知道自己管理的服务器能正常对外服务，但是却不知道里面应用的依赖关系，哪些配置是有效配置、哪些是无效配置，只敢加配置，不敢删配置，欠的技术债越来越多。在这样的情况下，遇到这次携程的极端案列，需要完整的重建系统时候，就很容易一筹莫展了。

“大数据时代带来一个非常重要的挑战，那就是安全的挑战，如果没有一个好的对大数据安全的保护，我们今天所有设想的大数据可能都会变成空中楼阁。”