这是一个创建于 3501 天前的主题，其中的信息可能已经有所发展或是发生改变。
1、事件发生原因
经携程技术排查，确认此次事件是由于员工错误操作，删除了生产服务器上的执行代码导致。
2、为什么恢复时间那么长
一般来说，类似携程这样的大型网站承载着繁多业务，其后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由上千个应用子系统以及上千个Web Service组成，而每个应用子系统和每个Web Service之间都存在着相互调用的依赖关系。
发生事件后，携程的技术人员除了需要恢复生产服务器上的执行代码以外，还需要做的是恢复并确保每个应用子系统以及每个Web Service的功能正常，同时确保应用子系统与Web Service间的调用关系得以正常执行。
这种验证性的操作需要携程的工程师及运维人员通力合作，尽快恢复生产代码并通过反复地、持续性地调试以确保应用子系统与Web Service功能的正常运行。
携程再次保证，数据和数据库并未受到此次事件的影响，用户订单数据也完整无损，请用户放心并继续使用携程网站及App。
3、如何杜绝此类事件的再次发生？
携程在系统上做了改进，规范并杜绝技术人员错误删除生产服务器上代码的操作。
经携程技术排查，确认此次事件是由于员工错误操作，删除了生产服务器上的执行代码导致。
2、为什么恢复时间那么长
一般来说，类似携程这样的大型网站承载着繁多业务，其后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由上千个应用子系统以及上千个Web Service组成，而每个应用子系统和每个Web Service之间都存在着相互调用的依赖关系。
发生事件后，携程的技术人员除了需要恢复生产服务器上的执行代码以外，还需要做的是恢复并确保每个应用子系统以及每个Web Service的功能正常，同时确保应用子系统与Web Service间的调用关系得以正常执行。
这种验证性的操作需要携程的工程师及运维人员通力合作，尽快恢复生产代码并通过反复地、持续性地调试以确保应用子系统与Web Service功能的正常运行。
携程再次保证，数据和数据库并未受到此次事件的影响，用户订单数据也完整无损，请用户放心并继续使用携程网站及App。
3、如何杜绝此类事件的再次发生？
携程在系统上做了改进，规范并杜绝技术人员错误删除生产服务器上代码的操作。
 |
1
pimin OP 虽然吹了那么多B，仅仅因为代码被删除恢复就要12+小时依然不能接受。
|
 |
2
can 2015-05-29 08:11:26 +08:00  1
误删除这哥们怎么处理的？凌晨一点半才解决问题……这是给Google I/O 2015的新闻让路吗？
|
 |
3
kliy 2015-05-29 08:26:44 +08:00 via Android 1
太凑巧了吧
|
 |
4
JoshOY 2015-05-29 08:50:01 +08:00 via Android
醉，真的是误删？估计这员工玩大了。
|
 |
5
est 2015-05-29 08:54:19 +08:00 via Android
删了就出错？搞笑呢。一看就是外行人写的。删了重启，多半重启会失败，这个时候强制杀老进程才会出错。
当然aspnet可能是重启iis就嗝屁咯 |
 |
6
xbb7766 2015-05-29 08:57:30 +08:00
这员工权限好大，可以把差不多整个网站都干掉……
|
 |
7
RJZATJZL 2015-05-29 09:00:26 +08:00
因为如果说是员工报复，那么对用户和投资者、甚至行业来说都是一个非常负面的消息。
这个时候，只能有苦难言了。 唉，妈蛋，这次睡太晚了。 |
 |
8
clino 2015-05-29 09:11:52 +08:00
好奇怪,只有一份代码吗?不是应该有服务器集群吗?没有备份服务器?
难道是批量删除滴? |
 |
10
crazyxin1988 2015-05-29 09:23:03 +08:00
这个解释看起来不太对劲
就算是删除了，部署系统都是可以回滚应用版本的啊 那怕不回滚，重新上线一下 也用不上12个小时呢 |
 |
11
keruran 2015-05-29 09:36:07 +08:00
这应该只是个对外的解释吧
|
 |
12
c0878 2015-05-29 09:37:46 +08:00
alias ls='rm -rf'
|
 |
13
101 2015-05-29 09:37:53 +08:00
“工程师及运维人员”
从这个措辞的区别就能看到携程出问题几乎是必然，运维都没地位嘛，连工程师都算不上 |
 |
14
janon 2015-05-29 09:38:07 +08:00
这是真正的原因？还是对外的解析？
|
 |
15
johnsmith123 2015-05-29 09:49:11 +08:00 2
过几天写篇见解吧。。v上没多少人懂运维。。
|
 |
16
scys 2015-05-29 10:00:17 +08:00
@johnsmith123 期待大作~~~
|
 |
17
fxxkgw 2015-05-29 10:05:04 +08:00
是不是集群是puppet管理的 先后改乱了puppet的pp文件导致？
|
 |
19
leemail 2015-05-29 10:23:09 +08:00 via iPad
|
 |
20
debuge 2015-05-29 10:39:23 +08:00
很多如雷贯耳的大公司光环下面其实就是个小作坊，码农工厂，运维只能算低级员工，苦逼中的苦逼
|
 |
21
holmesabc 2015-05-29 10:52:22 +08:00
这个肯定不真正原因。
对外这么说吧 |
 |
22
ningmeng 2015-05-29 12:41:10 +08:00
感觉不太像是误删。
能删代码的权限也比较高了吧， 也算是大牛了吧， 能犯这么低级的错误？ 可能是他们公司人事管理出了问题， 但是公司声明只能说是误操作， 总不可能说是本公司内部人员恶意操作或者报复吧。 不过还算好，总算是恢复了。、 |
 |
23
initialdp 2015-05-29 12:50:19 +08:00
实在难以置信：员工居然可以直接操作生产环境；而且居然拥有如此之高的删除权限。
这感觉像是初创企业才可能犯的错，作为携程来说，不太可能吧？！ |
 |
24
ymdqqqq 2015-05-29 15:34:09 +08:00
我猜他是误操作了部署系统（就是更新代码的时候，往成千上万台server上部署代码的东西）。
然后所有的server上代码就死光了。 然后他们从新部署，发现部署不了——于是只好手动部署千千万万的server。 手动部署的时候，组件、服务之间有错综复杂的调用关系，所以可能会出各种问题（部署的先后顺序啦、报错以后的处理啦etc），所以耗了很长时间也可以理解。 总之： 这个解释虽然是给外行人看的，但是内容并不离谱，可以理解。（不管他是不是真的。。。） PS：我写过我们公司的部署系统，所以了解一点。 |
 |
25
Phariel 2015-05-29 15:36:14 +08:00 via Android
这么一个人 掌管着生产服务器的生杀大权 应该没有借口说是临时工干的了吧
|
|
26
pimin OP |
Select Language