mywaiting
2015-05-29 20:16:13 +08:00
有大量机器的时候，应该分为好批次的机器吧，代码版本按feature打flag，每次上线按flag部署，几个批次的机器迭代着部署，从几台、几十台、几百台最后全部机器部署，线上按flag分小部分流量实际线上测试代码。
嗯嗯，就是类似facebook那样的上线方式，也不至于像ctrip那样酿成这样的大事故吧。
听说amazon有个叫apollo的上线系统，几乎可以在线上实现每秒部署一次新代码版本，按照ctrip这玩法，amazon早该被删除几十万次了。
反正我是不懂ctrip这么多的运维和安全都是干嘛去了，线上代码上线前没有充分的自动测试和小流量测试的么？代码发布没有统一的管理出了问题要大家去找发布邮件（微博看到的所谓内部聊天记录，不知道真假），这ctrip的技术部门感觉好像是拿了工资不作为啊！莫名其妙的。
而且全部瘫痪这样的事情应该也是线上系统应该考虑的，就没有应急预案和灾备的么？一个NASDAQ上市的大公司这点技术能力都没有，还要恢复这么久，看着我也是醉了。风平浪静的时候，大家都在游泳，潮水退去了，才发现自己在裸泳，这不是一个所谓大公司的技术部的表现啊。
还好有个elong，好歹也是资本意义上的“灾备”，要不这脸都往那搁啊。
总而言之，ctrip这搞什么鬼，也只有他们自己知道了。留下很多的教训，是很多很多的教训，怎么汲取这个教训，就看各个公司的了。