这个内容可能有点长，但请认真看下去，这是一个IT运维界十几年的老兵的经验，相信对你的职业生涯乃至你的人生有很大的帮助，也希望能影响到更多的人。所以我预测携程事件过后，IT运维人反思过后，企业的运维将会是一种享受。
相信这段时间挂在IT界人士嘴边的还是携程网宕机事件，从28号中午11点截止晚上8点，携程首页还是指向一个静态页面，所有动态网页都访问不了。关于事故根源，网上众说纷纭，有说是数据库数据和备份数据被物理删除的，也有说是误操作，导致业务不可用，还有说是黑客攻击甚至是内部员工恶意破坏的，从现象上看，确实是携程的应用程序和数据库都被删除。我分析，最大的可能还是运维人员在正常的批量操作时出现了误操作。
　　　从上午11点传出故障，到晚上8点，携程网站一直没能恢复。实际上大型网站，远不是像把几台应用和数据库服务器那么简单。看似很久都没有变化的一个网站，后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由成百上千个应用子系统组成，每个子系统又包括若干台应用和数据库服务器，大家可以理解为每一个从首页跳转过去的二级域名都是一个独立的应用子系统。这上千的个应用子系统，平时真正经常发布和变更的，可能就是不到20%的核心子系统，而且发布时都是做加法，很少完全重新部署一个应用。
　　在平时的运维过程中，对于常见的故障都会有应急预案。但像携程这次所有系统包括数据库都需要重新部署的极端情况，显然不可能在应急预案的范畴中。在仓促上阵应急的情况下，技术方案的评估和选择问题，不同技术岗位之间的管理协调的问题，不同应用系统之间的耦合和依赖关系，还有很多平时欠下的技术债都集中爆发了，更不用说很多不常用的子系统，可能上线之后就没人动过，一时半会都找不到能处理的人。更要命的是，网站的核心系统，可能会写死依赖了这个平时根本没人关注的应用，想绕开边缘应用只恢复核心业务都做到。更别说在这样的高压之下，各种噪音和干扰很多，运维工程师的反应也没有平时灵敏。
　　简单的说，就算所有代码和数据库的备份都存在，想要快速恢复业务，甚至比从0开始重新搭建一个携程更困难。据网友在微博上发出了携程大楼当天燃灯不灭的不眠夜。
　　携程的这次事件，不管原因是什么，都会成为IT运维历史上的一个标志性事件。相信之后所有的IT企业和技术人员，都会去认真的反思，总结经验教训。但我相信，不同的人在不同的位置上，看到的东西可能是截然相反的，甚至可能会有不少企业的管理者受到误导，开始制定更严格的规章制度，严防运维人员再犯事。在此，我想表明一下我的态度：这是一个由运维引发的问题，但真正的根源其实不仅仅在运维，预防和治理更应该从整个企业的治理入手。
　　长久以来，在所有的企业中，运维部门的地位都是很边缘化的。企业的管理者会觉得运维部门是成本部门，只要能支撑业务就行。业务部门只负责提业务需求，开发部门只管做功能的开发，很多非功能性的问题无人重视，只能靠运维人员肩挑人扛到处救火，可以认为是运维部门靠自己的血肉之躯实现了业务部门的信息化。在这样的场景下，不光企业的管理者不知道该如何评价运维的价值，甚至很多运维从业者都不知道自己除了到处救火外真正应该关注什么，当然也没有时间和精力去思考。
　　在上面的情况下，传统的运维人员实际上是所谓的“黑屋运维”，不断的去做重复性的操作，时间长了之后，只知道自己管理的服务器能正常对外服务，但是却不知道里面应用的依赖关系，哪些配置是有效配置、哪些是无效配置，只敢加配置，不敢删配置，欠的技术债越来越多。在这样的情况下，遇到这次携程的极端案列，需要完整的重建系统时候，就很容易一筹莫展了。
　　对于这样的故障，我们认为真正有效的根源解决做法是从黑屋运维走向白屋运维，和siteview ITOSS中的SAM服务器及应用管理这样的运维工具理念一致，运维的核心和难点其实是配置管理，运维人员只有真正的清楚所管理的系统的功能和配置，才能从根源上解决到处救火疲于奔命的情况，也才能真正的杜绝今天携程这样的事件重现，从根本上解决运维的问题。
从黑盒运维走向白盒运维，再进一步实现从监控到IT服务共享数据中心，就是siteviewITOSS所谓的运维2.0——自动化的IT运维很显然，这个单靠运维部门自身是做不到的，需要每一个企业的管理者、业务部门、开发部门去思考。因此，我希望今天这个事件，不要简单的让运维来背黑锅，而是让大家真正的从中得到教训和启示。

这个内容可能有点长，但请认真看下去，这是一个IT运维界十几年的老兵的经验，相信对你的职业生涯乃至你的人生有很大的帮助，也希望能影响到更多的人。所以我预测携程事件过后，IT运维人反思过后，企业的运维将会是一种享受。
相信这段时间挂在IT界人士嘴边的还是携程网宕机事件，从28号中午11点截止晚上8点，携程首页还是指向一个静态页面，所有动态网页都访问不了。关于事故根源，网上众说纷纭，有说是数据库数据和备份数据被物理删除的，也有说是误操作，导致业务不可用，还有说是黑客攻击甚至是内部员工恶意破坏的，从现象上看，确实是携程的应用程序和数据库都被删除。我分析，最大的可能还是运维人员在正常的批量操作时出现了误操作。
　　　从上午11点传出故障，到晚上8点，携程网站一直没能恢复。实际上大型网站，远不是像把几台应用和数据库服务器那么简单。看似很久都没有变化的一个网站，后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由成百上千个应用子系统组成，每个子系统又包括若干台应用和数据库服务器，大家可以理解为每一个从首页跳转过去的二级域名都是一个独立的应用子系统。这上千的个应用子系统，平时真正经常发布和变更的，可能就是不到20%的核心子系统，而且发布时都是做加法，很少完全重新部署一个应用。
　　在平时的运维过程中，对于常见的故障都会有应急预案。但像携程这次所有系统包括数据库都需要重新部署的极端情况，显然不可能在应急预案的范畴中。在仓促上阵应急的情况下，技术方案的评估和选择问题，不同技术岗位之间的管理协调的问题，不同应用系统之间的耦合和依赖关系，还有很多平时欠下的技术债都集中爆发了，更不用说很多不常用的子系统，可能上线之后就没人动过，一时半会都找不到能处理的人。更要命的是，网站的核心系统，可能会写死依赖了这个平时根本没人关注的应用，想绕开边缘应用只恢复核心业务都做到。更别说在这样的高压之下，各种噪音和干扰很多，运维工程师的反应也没有平时灵敏。
　　简单的说，就算所有代码和数据库的备份都存在，想要快速恢复业务，甚至比从0开始重新搭建一个携程更困难。据网友在微博上发出了携程大楼当天燃灯不灭的不眠夜。
　　携程的这次事件，不管原因是什么，都会成为IT运维历史上的一个标志性事件。相信之后所有的IT企业和技术人员，都会去认真的反思，总结经验教训。但我相信，不同的人在不同的位置上，看到的东西可能是截然相反的，甚至可能会有不少企业的管理者受到误导，开始制定更严格的规章制度，严防运维人员再犯事。在此，我想表明一下我的态度：这是一个由运维引发的问题，但真正的根源其实不仅仅在运维，预防和治理更应该从整个企业的治理入手。
　　长久以来，在所有的企业中，运维部门的地位都是很边缘化的。企业的管理者会觉得运维部门是成本部门，只要能支撑业务就行。业务部门只负责提业务需求，开发部门只管做功能的开发，很多非功能性的问题无人重视，只能靠运维人员肩挑人扛到处救火，可以认为是运维部门靠自己的血肉之躯实现了业务部门的信息化。在这样的场景下，不光企业的管理者不知道该如何评价运维的价值，甚至很多运维从业者都不知道自己除了到处救火外真正应该关注什么，当然也没有时间和精力去思考。
　　在上面的情况下，传统的运维人员实际上是所谓的“黑屋运维”，不断的去做重复性的操作，时间长了之后，只知道自己管理的服务器能正常对外服务，但是却不知道里面应用的依赖关系，哪些配置是有效配置、哪些是无效配置，只敢加配置，不敢删配置，欠的技术债越来越多。在这样的情况下，遇到这次携程的极端案列，需要完整的重建系统时候，就很容易一筹莫展了。
　　对于这样的故障，我们认为真正有效的根源解决做法是从黑屋运维走向白屋运维，和siteview ITOSS中的SAM服务器及应用管理这样的运维工具理念一致，运维的核心和难点其实是配置管理，运维人员只有真正的清楚所管理的系统的功能和配置，才能从根源上解决到处救火疲于奔命的情况，也才能真正的杜绝今天携程这样的事件重现，从根本上解决运维的问题。
从黑盒运维走向白盒运维，再进一步实现从监控到IT服务共享数据中心，就是siteviewITOSS所谓的运维2.0——自动化的IT运维很显然，这个单靠运维部门自身是做不到的，需要每一个企业的管理者、业务部门、开发部门去思考。因此，我希望今天这个事件，不要简单的让运维来背黑锅，而是让大家真正的从中得到教训和启示。