我的观点

携程网从28日11点发生故障到23点29分恢复服务，期间服务中断11个半小时。从29日携程网官方微博的申明来看，携程网将这个事件定性为内部员工误操作导致。

我只能根据现象和它自己的申明来分析。1、不是硬件或线路故障。这点比较明显，没有任何消息说明是硬件和通讯线路原因。这些原因也不会造成如此大的影响。2、遭遇黑客攻击。如果是遭遇黑客攻击，携程会有说明，并应该在各个层面有蛛丝马迹可循，目前看不太像。3、内部恶意破坏或误操作，删除主数据库，也同时删除备用库。从表面现象看比较像，但数据恢复时间如此之长，看上去不太能理解，因为整个携程是由很多服务组成的，应该也有很多业务数据库，应该可以并行恢复，有些规模小些的数据库肯定可以快速恢复，从而可以把这部分服务先恢复，然后逐步恢复全部服务，但携程在长时间内，一直无法提供所有服务，如果真是数据库删除原因的话，那也就是说携程只有一个大库，数据恢复时间很漫长。后来从恢复后用户订单都没有丢可以看出不是数据库被删除了。4、内部恶意破坏或误操作，删除所有服务器上的所有应用代码。从表面现象上看也像，但从一般金融企业的情况来看不太可能，因为携程网有数千台服务器，快速删除所有服务器上的所有应用代码一般来说很难做到。碰巧携程不是一般金融企业，它是家完全的互联网公司，它的基础架构和运维方式和金融企业完全不同，但却是很多互联网企业的通用做法。据网上的消息，携程的应用组件是SOA方式组建的，代码发布时是通过SOA的方式全自动化部署的，可以快速在数千台服务器上部署代码。这样做效率非常高，但导致了一个问题：如果有人恶意破坏，或误操作写错代部署码，会在短时间破坏所有应用服务器，而且由于携程应用组成较多，导致部署代码结构复杂，代码量大，查找原因消耗时间会比较长。从携程官微含糊的表达误操作说明来看比较像这个原因导致的。

－－－－－－－－－－－我是万恶的分割线－－－－－－－－－－－－

从上面的分析来看携程有很多制度、流程、安全上的问题，一般领导一定会去研究怎么从这些方面去杜绝类似问题再发生，也可以显示其视角和立意之高，管理能力之强之类的。

但我不是一般领导啊，所以我会从另外一个方面来谈，而且不会给出解决方案，因为不是所有事都有解决方案的。

－－－－－－－－－－－我是万恶的分割线－－－－－－－－－－－－

携程停服事件在我看来从根本上说传统金融IT的SDLC（软件开发生命周期管理）和互联网新兴的敏捷开发之间的矛盾。传统金融IT一般采用完整的BA、DEV、SIT、UAT、QA、Online等流程，是非常严谨的，环节一个都不能少，所有测试必须在准生产环境中走过才能投产。这保证了软件的投产质量，但效率偏低。互联网企业为了快速响应用户需求一般采用敏捷开发流程，快速迭代开发，快速上线，快速试错，保证了软件更新的高效率，但有时质量偏低。

鱼与熊掌不可兼得，这两种开发方式从本质上说没有优劣，要看适用的场景。以前一般金融业因为应用涉及财产金额，所以在开发流程上比较严谨，不轻易采用快速投产流程，而一般互联网公司应用并不涉及财产金额，所以在开发流程上倾向于快速敏捷。

互联网金融产生后，这两种开发模式产生了互相影响，传统金融IT的互联网企业的强势宣传下，领导感觉自己落后了，必须一切都“互联网＋”，所以开始学习如何改造传统SDLC流程转而向敏捷开发靠拢；而互联网企业开始涉足金融产品，敏捷开发开始碰到的麻烦，因为“试错”变成了禁区，敏捷开发有时敏捷不起来了。

携程的问题正是由于在敏捷、快速迭代、不断试错的开发模式下，一旦出现漏洞和问题会被迅速放大到不可收拾的地步而导致的。

我认为无论在传统金融企业还是互联网金融企业中，开发模式不是固定的，而是根据应用的具体情况来决定。但是，无论怎么决定都会有倾向，不是倾向严格SDLC流程就是倾向敏捷迭代，这取决于该企业是否愿意承担的放弃另外一个模式而带来的代价。世界上有时候就是没有两全其美的事。

今天就聊到这里，晚安。