没有十全十美的技术，在携程事件之后，技术专家们的建议与反思

　　携程的宕机事件留给业内无数的反思。官方最初说法是“部分服务器遭到不明攻击”，然而“紧急恢复”迟迟不成功，在5月29日凌晨恢复服务后，携程称是“员工错误操作导致”。而网上流传的说法说数据库数据和备份数据被物理删除者有之，说各个节点的业务代码被删除有之，不一而足。本文根据微信群的专家讨论和各公众号文章整理技术人应该得到的一些启示。

　　林帆，ThoughtWorks成都办公室CloudOps小组成员，DevOps爱好者

　　简单来说，事故根本问题是服务依赖和启动依赖管理没有做好，使得局部问题扩大化了。从携程最后的解释来看，他们的后端是典型的微服务架构，但是恢复时间这么久，也就是没意识到微服务会带来依赖管理的隐患，自己把自己坑进去了。

　　那么几百上千个服务相互依赖，如果只是平时在线部署更新，不会停止服务，都看似运行稳定。但是一旦一个服务挂了，它就连带整个系统像多米诺骨牌一样依次挂掉，这就是为什么一开始只是APP服务出问题，发展到后来整个后端都不能运行了。然后恢复这上千个服务的时候，因为复杂的依赖，确定启动顺序以及启动以后的验证就非常耗时。说明他们内部服务部署的依赖管理是没有足够智能和自动化，掺入了不少手工操作的工作。

　　所以我个人觉得携程这次出现问题，主要还是在微服务架构实践上的失误。如果使用了Docker这样的容器，在后期恢复服务时候能够获得不少部署速度上的提升，也许可以减少恢复所需的时间。但是并不能从根本上杜绝这种问题的发生。Docker在集群化部署的实践里面会比较强调依赖管理自动化，比如Compose就是做这个的。但也不是所有Docker集群工具都有，比如Kubernetes就不包含服务依赖的管理。

　　使用了容器，比如Docker以后，会让服务的部署变得简单，运维人员就可以把注意力更集中在服务层面的调度和管理上，不被细节分心。从这个层面上就更容易从系统全局上关注部署顺序和局部故障处理这些事情。

　　郭理靖，京东云平台开放云事业部与公有云事业部高级总监

　　在虎嗅发表了一篇文章《携程可能摊上大事了——崩溃原因分析之「高能技术贴」 》分析的很深刻。

　　从这次攻击的事件来看，数据库整体被攻击的可能性非常大。虽然黑客有可能把数据从云存储的应用端删除，但是服务端这些数据可能还存在。数据是否可以恢复要取决于私有云存储的架构。从公开的报道来看，携程内部私有云用的是OpenStack，那么很有可能是使用Swift的存储，除非黑客也是非常熟悉Swift的架构，把Swift上的三个备份的机器找到，进行物理删除。否则，数据还是有可能恢复的。如果到备份到存储一体机，我相信数据还是有可能找的回来的。

　　最坏的情况是：黑客掌握了携程大部分机器的root权限,同时进行无差别的毁灭性的攻击的话(业务节点、数据库节点、存储节点)，则后果不堪设想。

　　智锦，资深运维从业者，自动化运维和云计算倡导者，原支付宝运维团队创始人(微信公众号： 数据中心操作系统)

　　作为运维老兵，智锦第一时间在公众号也发了一篇深度文章《 深入解析和反思携程宕机事件》。

　　从现象上看，确实是携程的应用程序和数据库都被删除。这是一个由运维引发的问题，但真正的根源其实不仅仅在运维，预防和治理更应该从整个企业的治理入手。运维就是需要预防小概率事件，运维制度化是靠产品化去实现的，制度和流程要固化到产品中去。

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

　　从黑盒运维走向白盒运维，再进一步实现devops(开发运维衔接)和软件定义数据中心，就是所谓的运维2.0。单靠运维部门自身是做不到的，需要每一个企业的管理者、业务部门、开发部门去思考。

　　张鑫，ZStack发起者和总架构师，在微信群中提到：

　　我今天在想，与其运维产品化，是不是运维制度化更加重要，也更容易实现?其次，下面的IaaS层是不是有问题?这个情况下，应该销毁已出问题的虚拟机，直接重新部署新的。而不是复用以前的，因为你根本不知道以前的里面感染了什么问题。

　　胡茂华，多备份联合创始人& CEO ，曾就职于腾讯、盛大(旅游)、1号店，历任总监、CTO、技术副总裁

　　不难理解，携程做为一个在线海量交易平台，后端还连接一个3万人的呼叫中心系统，以及对接国内外的海量的机票和酒店库存系统，系统的耦合度非常高，应用程序部署在数万台服务器上，即使SOA实施的再完美，这些应用程序二次发布无论是自动发布还是半自动维护，二次重新部署时间一定很长，就这些war包应用程序都有可能把整个内网的流量撑爆，这些应用程序还要分发到不同的IDC，专线肯定都不够用，恢复时长在所难免，同时交易链条越长，整个服务可用性验证也很艰辛。

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

　　总之，运维是一个细活慢活，业务发展的再快再好，也要平时累积资源和能力，正所谓养兵千日，用兵一时，关键时刻还是得靠自动化工具和流程来约束，而不是人肉维护。

　　王津银，资深运维专家，曾参与腾讯、YY、UC运维(微信公众号：互联网运维杂谈)，在微信群中提到：

　　很多技术层面的东西值得细敲，包括他们的DO分离，权限分级，重大变更的确认，统一的应用管理，灰度等等。灰度是最重要的变更策略，都不遵守。 必须把制度和流程固化 到产品中，把变更灰度作为工具的一部分，实现平台约束。

　　把灰度作为变更系统的默认功能，无论是配置管理的变更，还是上层应用的变更，都不会让运维人员一次对全网进行操作的。

　　灰度有两个层面：一个是运维侧的机器级灰度;二是应用级别灰度。对于一个变更行为来说，运维需要少量灰度部分机器，确认变更是否达到预期，然后在逐步放量。另外应用级别的灰度，就是根据用户的信息进行灰度，比如说某个号段，某个区域的用户才能使用新的功能。进一步确定业务功能正常情况。

　　运维级别的灰度几乎是运维规范意识的一部分，需要通过平台约束，否则脚本型批量变更方式必然有这个后果。常在河边走没有不湿脚的。

　　王津银随后还发表了一篇反思文章：《携程事件：运维债务的深度剖析与解决方案》，从架构、流程规范、工具与平台、安全，灰度机制、意识、环境管理、数据管理、架构等多个角度，全面分析了我们欠下的运维债务，并给出实践中的解决方案。

　　王涛，巨杉数据库联合创始人兼CTO，曾被CSDN评为 2014 TOP50最具价值CTO。作为原IBM DB2 Lab核心成员，数据库专家，就本次携程事件发表文章《 携程事件反思：是时候重视数据库灾备了!》

　　主备库之间的延迟。既然主备库分别部署在不同的数据中心，互联网延迟则是必须考虑的因素。主备库之间的延迟越小，当主库出现故障时丢失的数据越少。例如如果主备库之间的延迟可以缩小到一秒钟以内，当主库所在的系统出现人为或非可控灾难的时候，主备库切换所造成的数据损失会被限定在一秒钟内，这样和整个门户网站的瘫痪比起来，企业所遭受的损失几乎可以忽略不计。

　　占用带宽小。一般来说，主备数据中心之间的网络带宽非常昂贵。由于主备数据中心之间的网络一般都是跨广域网的，因此其带宽的承受能力绝对不能像局域网那样假设为千兆或万兆带宽。因此，在网络传输时数据通道的条数，数据传输时的压缩比率都是非常重要的指标。

　　安全的传输通道。既然数据是跨广域网的传输，如果有人在机房外架设嗅探器，是否可以截获我们的网络通讯呢?如果主备节点之间总是以明文通讯，这绝对是一个非常重大的安全隐患。因此，主备数据中心之间的数据通讯是否加密则是第三个重要的安全指标。

　　除此之外，还有安全领域专家的多篇分析。

　　携程目前已经恢复正常，并在5月29日1：30分发布了声明：

　　5月29日1：30分，经携程技术排查，确认此次事件是由于员工错误操作导致。由于携程涉及的业务、应用及服务繁多，验证应用与服务之间的功能是否正常运行，花了较长时间。携程官方网站及APP已于28日23:29全面恢复正常。对用户造成的不便，携程再次深表歉意。

　　当服务越加互联网化，技术就越加重要，技术人的责任感和使命感就要越强。没有十全十美的技术，但可以有更多方案来保障服务的正常运营。留给大家的思考还有很多。