携程解释瘫痪原因：员工错误操作 删除服务器执行代码

[pimin]

1、事件发生原因
经携程技术排查，确认此次事件是由于员工错误操作，删除了生产服务器上的执行代码导致。
2、为什么恢复时间那么长
一般来说，类似携程这样的大型网站承载着繁多业务，其后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由上千个应用子系统以及上千个Web Service组成，而每个应用子系统和每个Web Service之间都存在着相互调用的依赖关系。
发生事件后，携程的技术人员除了需要恢复生产服务器上的执行代码以外，还需要做的是恢复并确保每个应用子系统以及每个Web Service的功能正常，同时确保应用子系统与Web Service间的调用关系得以正常执行。
这种验证性的操作需要携程的工程师及运维人员通力合作，尽快恢复生产代码并通过反复地、持续性地调试以确保应用子系统与Web Service功能的正常运行。
携程再次保证，数据和数据库并未受到此次事件的影响，用户订单数据也完整无损，请用户放心并继续使用携程网站及App。
3、如何杜绝此类事件的再次发生？
携程在系统上做了改进，规范并杜绝技术人员错误删除生产服务器上代码的操作。

[pimin]

虽然吹了那么多B，仅仅因为代码被删除恢复就要12+小时依然不能接受。

[can]

误删除这哥们怎么处理的？凌晨一点半才解决问题……这是给Google I/O 2015的新闻让路吗？

[kliy]

太凑巧了吧

[JoshOY]

醉，真的是误删？估计这员工玩大了。

[est]

删了就出错？搞笑呢。一看就是外行人写的。删了重启，多半重启会失败，这个时候强制杀老进程才会出错。

当然aspnet可能是重启iis就嗝屁咯

[xbb7766]

这员工权限好大，可以把差不多整个网站都干掉……

[RJZATJZL]

因为如果说是员工报复，那么对用户和投资者、甚至行业来说都是一个非常负面的消息。

这个时候，只能有苦难言了。

唉，妈蛋，这次睡太晚了。

[clino]

好奇怪,只有一份代码吗?不是应该有服务器集群吗?没有备份服务器?
难道是批量删除滴?

[wy315700]

@clino 听说是部署服务器出问题了，然后发出指令让集群都把代码删了

[crazyxin1988]

这个解释看起来不太对劲
就算是删除了，部署系统都是可以回滚应用版本的啊
那怕不回滚，重新上线一下 也用不上12个小时呢

[keruran]

这应该只是个对外的解释吧

[c0878]

alias ls='rm -rf'

[101]

“工程师及运维人员”
从这个措辞的区别就能看到携程出问题几乎是必然，运维都没地位嘛，连工程师都算不上

[janon]

这是真正的原因？还是对外的解析？

[johnsmith123]

过几天写篇见解吧。。v上没多少人懂运维。。

[scys]

@johnsmith123 期待大作~~~

[fxxkgw]

是不是集群是puppet管理的 先后改乱了puppet的pp文件导致？

[hzqim]

@c0878 root 用户必须培养以反斜杠运行命令的习惯？ 如：\ls

[leemail]

http://img3.douban.com/view/status/median/public/43499c276d6da51.jpg

[debuge]

很多如雷贯耳的大公司光环下面其实就是个小作坊，码农工厂，运维只能算低级员工，苦逼中的苦逼

[holmesabc]

这个肯定不真正原因。
对外这么说吧

[ningmeng]

感觉不太像是误删。
能删代码的权限也比较高了吧，
也算是大牛了吧，
能犯这么低级的错误？

可能是他们公司人事管理出了问题，
但是公司声明只能说是误操作，
总不可能说是本公司内部人员恶意操作或者报复吧。

不过还算好，总算是恢复了。、

[initialdp]

实在难以置信：员工居然可以直接操作生产环境；而且居然拥有如此之高的删除权限。

这感觉像是初创企业才可能犯的错，作为携程来说，不太可能吧？！

[ymdqqqq]

我猜他是误操作了部署系统（就是更新代码的时候，往成千上万台server上部署代码的东西）。
然后所有的server上代码就死光了。

然后他们从新部署，发现部署不了——于是只好手动部署千千万万的server。

手动部署的时候，组件、服务之间有错综复杂的调用关系，所以可能会出各种问题（部署的先后顺序啦、报错以后的处理啦etc），所以耗了很长时间也可以理解。

总之：
这个解释虽然是给外行人看的，但是内容并不离谱，可以理解。（不管他是不是真的。。。）
PS：我写过我们公司的部署系统，所以了解一点。

[Phariel]

这么一个人 掌管着生产服务器的生杀大权 应该没有借口说是临时工干的了吧

[pimin]

@ymdqqqq 即便 如你所言
这种情况依然不能被消费者和投资人以及携程本身所接受吧
这里的小伙伴即便对运维没有非常详尽的认识，也是绝对不太相信成熟产品会有那么长的部署期。
且不说是日营收几千万的平台

[ymdqqqq]

@pimin

就算正常情况分分钟部署完（which is totally impossible），手动部署也有可能要很久啊。
因为平时部署的时候各种service什么的不是处于挂光的状态啊。

部署的时候，既要保证新内容上线，又要保证过程中所有的服务可以stable的继续运行。
还要做持续集成啊、各种test啊、防止被黑啊、压缩加密啊、脚本的编译啊等等等等（这还只是我知道的，我不是运维）。
所以越大的平台，部署时间往往越长。

再给一个时间参考，某G开头的顶尖美国大公司的某个广告方面的大组，现在部署时间大约是一天（24小时）。