5月29日携程宣布其官网和APP瘫痪是由于IT人员的错误操作，删除了生产服务器上的执行代码导致。类似携程这样的大型网站承载着繁多业务，其后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由上千个应用子系统以及上千个WebService组成，而每个应用子系统和每个WebService之间都存在着相互调用的依赖关系。所以为了排查这些关系而花了整整12小时！

这里，学过ITIL的童鞋都应该知道，防止这次的错误再次发生，应该从配置管理流程、变更管理流程和发布管理流程三个方面来优化改进。

首先，如果携程建立了完善的CMDB，应该根本不需要花12小时来寻找故障根源，因为CMDB中的CI项关系清楚记录了每个Webservice这样的组件对应用系统的支持关系，能指导技术人员快速定位故障根源；

其次，如果发布管理的DML做了很好的管理，就算各SOA组件系统的代码被全部删除，也可以从DML中马上找出最后的授权版本进行复原；

最后，我们也要问问，这个员工对系统的致命错误操作没有得到授权？如果这个重要变更得到了授权，我们还需要再问，变更风险和业务影响得到了有效的评估了吗？变更风险在实施前都得到了有效控制和处置了吗？

这次携程事件，给各位ITIL学员上了生动的一课，也帮助大家再次理解了ITIL转换阶段三个最重要流程的含义。

塞翁失马，希望携程能吸取教训，同时也更重视ITIL在他们机构的落地。

本周四晚8点半YY讲堂：[专家讲师风采] 2015年第18期ITIL先锋讲堂《CMDB建模规划与工具实操》

http://www.itilxf.com/thread-48807-1-1.html

好文章啊。。。