我所经历的京东618

国内电商两强公司阿里和京东都有自己的电商促销节，阿里以双11闻名，首创了国内网购节，从09年至今已有5年历史，京东以618店庆力度最大，从交易额和影响力上来讲俨然成了唯一能与双11媲美的网购节。至于现在的大促是不是真的有打折，我也不得而知（大家别喷我），不过今年的618是继京东5.22上市之后的首秀，必然要拿出一份不错的成绩单给华尔街看，当然这里面的个中事情与这篇文章关系不大。

有关淘宝双11如何做的各种技术架构调整和降级预案等可以问度娘，有很多大牛的专业分享，对应到京东来说应该也是八九不离十是这么干的，这里我只是说说我所在的大部门是如何度过618的。

会议

在我入职不久，公司技术部门就组织过618战略会议，各个部门的技术负责人都需要出席并在会后给出一个相关系统的负责人名单，在618时需要参与到监控队伍中，特别是那种有大量用户高并发的系统需要评估性能及做好应急预案。

洗脑式的618 party on广告

也许你在楼宇里或者电视上或者电脑视频里或者微信朋友圈里，看过那则广告，可以说是比较富有创意的洗脑式的party on广告征服了很多人，我也义务性的转发到了朋友圈里替京东宣传宣传。

加机器

加机器是解决性能问题最直接且简单有效的方法，当然也需要根据同比环比的各项数据对比出来大概的访问量和并发数来评估的。大家提前一个多月把要申请的机器数量上报并在618之前接入到线上系统。

禁止随意发布上线

进入6月之后，对所有的上线做好严格把控，以免因为引入bug影响了618，如果要上线需要VP（副总裁，Vice president，简称VP）及以上Level的人审批通过后方能操作，所以大家为了确保618万无一失，上线比以往少了很多，即便是新成立的广告事业部，原来开发人员自行上线的行为也在这个时候少了很多。

组织降级及性能评估

除了加机器，还需要对系统进行性能评估，当时我所负责的产品线中就有两个系统有高并发的访问，需要进行评估，所以我也参与其中了。其中一个系统是与网站首页搜索页等多个广告位素材获取有关，另外一个是跟联盟推广的广告有关，因为公司层面有一个专门的性能测试团队，他们有较为真实的与线上环境配置差不多的测试环境，所以就联系他们帮助做了性能测试的工作。我主要参与了性能的评估，与他们的对接及问题分析跟踪等，记得当时发现了两个问题：一个是当有大并发量访问时出现一些timeout的问题，原因是nginx和tomcat设置的timeout时间太长，导致当连接数满了之后如果系统没有在指定的时间内响应的话，新的连接会一直等待，出现少量超时，所以统一把线上服务器都设成了3S的timeout时间，如果3秒内未响应就断开该连接，不影响后面等待的连接；另外一个是与我们系统相关联的一个系统也有高并发的可能，但是那个部门并没有考虑到这一点，后来告知他们后硬是加了几台机器快速解决了，好在618安然无恙。

除了做好性能评估外，其中还需要做好降级预案及容灾工作。降级预案的意思是按照业务重要性及调用次数进行综合评估排序，把优先级不高的功能通过开关方式进行禁用或者以cache方式/读内存方式调用，保证核心功能无误。容灾就是要保证依赖的接口或者系统宕掉或timeout之后系统有做对应的处理，要么能正常work，要么能有友好的提示。好消息是在618时降级预案都没有用上，这两个系统平安度过了，坏消息却是另外一个系统在617时出现了小故障，在大家紧急抢救之后恢复了正常。

618指挥部

没错，这的确像是一个指挥部，所有重要系统都需要派出代表到指挥室，6.17～19号3 X 24轮班换人做好监控，而在这个指挥室里，放着好几台电视和大尺寸的显示器，显示着实时订单数和销售额，以及各个主要系统监控指标的状态，进入这个屋子里的人有免费的水果，饮料和午餐晚餐享用。其实大家的工作主要是等待系统出问题时及时进行处理，但是需要大家留意的是不要因为其他人的系统出问题了就凑热闹，却忘记了自己的系统。

除了在指挥部里的人需要监控外，办公室里同样需要派代表做好监控，而我们测试部门派出了2个人轮番进行，每天到晚上10多左右，发现了问题及时通知值班的开发人员。

高层慰问

在618快要开始前的几天，各个一级部门都做好了条幅打好了标语，贴到了办公室里，充满了浓浓的战斗气氛，到目前为止，都还挂着没有撤掉。而在618当天，包括老刘及CMO等公司高层都深入到群众中做好了慰问工作，鼓励大家做好618的各项工作，保证618顺利进行。而在6月份一直到618结束，大家也有了额外的福利，每天下午6点左右有蛋糕和水果发放。每到发放时我们这群技术宅们都蜂拥而上，很是壮观。

战果硕硕

617晚上10点多时，我还特意去了指挥部，亲眼目睹了令人激动的数字，实时更新的订单量和成交金额，让人心潮澎湃，我在的那几分钟，以每秒钟6位数的成交金额刷新着以往的记录。