摘要 : 我们不得不承认，安全问题是一个相对的概念，公关是一个突发的事件。这些不确定性事件构成了黑天鹅事件，既然类似携程这种黑天鹅事件无法避免，那就想办法从中获取最大利益。

在澳大利亚的黑天鹅没有被发现前，人们认为所有的天鹅都应该是白色的；在昨晚的携程事件之前，99%的企业都会认为自己是不会出问题的。

5月29日1：30分，携程官方微博发布声明表示：经携程技术排查，确认此次事件是由于员工错误操作导致。由于携程涉及的业务、应用及服务繁多，验证应用与服务之间的功能是否正常运行，花了较长时间。昨天携程的股价也出现下降。

从昨天的11：09分开始，直到晚上22：45分才基本恢复，此次携程网站崩溃事件共持续了近12个小时，无论从宕机时长还是从产生的影响，都会在以后被作为一个“著名”的案例被不断提及。

我们不得不承认，安全问题是一个相对的概念，公关是一个突发的事件。这些不确定性事件构成了黑天鹅事件，既然类似携程这种黑天鹅事件无法避免，那就想办法从中获取最大利益。每一件事情都会从波动得到利益或承受损失。脆弱是指因为波动和不确定而承受损失。反脆弱则是让自己避免这些损失，甚至因此获利。尼采名言：「杀不死我的，使我更强大」。所以，我们需要知道我们会被那些东西杀死，以及如何变得强大。

从携程的声明中表明，导致此次事件的直接原因是员工误操作造成，但请注意“应用”二字，作为一个十几年历史的公司、作为曾一度被认为仅有的几家因专注而著称的上市公司、一个后端还连接一个3万人的呼叫中心系统，对接国内外的海量的机票和酒店库存系统的在线海量交易平台，这的确是个令人沮丧的原因。我们可以通过防火墙、数据容灾备份、云存储等等方式，让数据更加安全，甚至准备了N套应急预案，所以外界一度猜测的“员工恶意物理删除数据库”、“黑客入侵”，如果存在的话应绝对不会花上近12个小时去解决。只有应用程序出错才会出现这种情况，这也印证了为什么会出现“写好的程序被删”的情况，也印证了为什么在所有代码都存在、数据库备份依然完好、数据没有丢失的情况下，恢复起来却如此漫长。

笔者比现在年轻10岁的时候，每次看到军事演习都会在心里暗暗的为如此大规模的浪费而惋惜，10年后，我知道这是错的。而企业灾备同理。灾备不是简单的存储、简单的备份，这些工作都是为了一个目的——数据恢复，我相信携程肯定会与自己的数据中心、自己的灾备系统、甚至自己的私有云等等。但很多企业，甚至可能包括携程在内，往往热衷于建立一个“高大上”的灾备中心，却忽略了备份演练，更不用说定期做演练，灾备中心变成了“观光中心”。

多备份CEO胡茂华认为，要防范此类异常情况，一是应用发布平台要改造，做好应用程序的动静态分离，制定并遵循严格的工作流审批发布程序；二是核心流程自动化测试，缩短应用上线服务验证时间；三是所有在线应用程序都要做备份和版本管理，需要一个可视化的集中管理平台维护最新版本和应用之间的关系；四是则是如上午提到的重视演练，灾难恢复要做到一周一小练，一月一大练。

资深运维从业者智锦认为，真正有效的根源解决做法是从黑盒运维（运维人员不断的去做重复性的操作，不知道应用的依赖关系，哪些配置是有效配置、哪些是无效配置）走向白盒运维。运维的核心和难点其实是配置管理，运维人员只有真正的清楚所管理的系统的功能和配置，才能从根源上解决到处救火疲于 奔命的情况，也才能真正的杜绝今天携程这样的事件重现，从根本上解决运维的问题。

运维派创始人赵广认为，虽然我们听到了No ops（不需要运维）的声音，但携程的这次事件再次向我们表明运维人员的重要作用，云计算、大数据、互联网+的繁荣，增大了基础设施的建设，系统的架构更加复杂、数据量更大，这些都是对运维的挑战，与其说是No ops，莫不如说是Not only ops!而在数据恢复方面，运维团队则需要多多思考数据备份归档后，是否有去校验数据备份完整性？是否有在日常去演练过数据容灾恢复流程？

此次事件对于携程来说当然是一件坏事，但却为众多的企业敲响了警钟，非常不可能发生和无法预测的事件，存在于世界上几乎每一种事物之中，墨菲定律也一再上演，企业需要将不确定性变成一件好事，同时，以反脆弱的方式建立各种业务，包括数据安全、灾备以及公关。