携程数据库事件，技术专家怎么说

• 张鑫，ZStack发起者和总架构师

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

• 王津银，资深运维专家，曾参与腾讯、YY、UC运维（微信公众号：互联网运维杂谈）

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

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

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

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

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

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

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

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

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

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

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

本文为ImapBox原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)