之前在某东待了3年半，经历了4个618，3个双十一。之前所在的团队是京东PC端三级列表页，关于我们项目的架构介绍，可以参考这篇文章。每年两次大促，每年也需要为这两次大促进行长达一个月的准备。
压测
压测不光是要大促的时候压，平时每个月都会压。每个月压单机，压的链接是线上抓取的真实访问链接，我们线下找一台机器。压测单机会根据不同的并发进行压，一般从5并发开始，逐渐增加，直到TP99下降到不可接受为止。每次压测都会和之前的进行对比，如果发现性能下降，需要定位原因和优化。
大促压测每年集中在5月和10月，会在夜里进行。整个项目组的所有机器（或者一个机房的所有机器）进行压测，从入口开始压。大促前的压测标准是之前大促峰值的流量，能够能扛得住之前峰值的倍数，能达标就行，不能的话需要优化或者加机器（主要还是加机器）。
全链路加测。这个是最近开始搞的，全公司的同一个夜里一起加班压。这个会模拟当时的实时流量，并不会像单独压测的时候那么狠。
性能
对于性能最重要的指标还是TP99，公司对性能其实有不成文的规定，TP99要小于200ms。如果大于这个值，用户会明显觉得卡顿。
禁止读库、禁止跨机房调用
线上只读服务，比如我们列表服务，禁止直连数据库。用户的任何操作都不能发生数据库操作。平时我们经常会写这种接口：取缓存读数据，没有的话去读库，然后把数据设置到缓存里。这种方案只适用于小流量的情况，一旦数据库来个慢查询或者数据量变大，所有接口都会挂，所有哦。这也算是雪崩的一种吧。
跨机房调用一个是慢，一个是这样的话就失去了双活的意义了。不过我们的降级方案里有跨机房方案，不过常规方案里要禁止。
监控
监控非常重要。程序接口和关键模块都需要加监控，包括性能和流量监控，报警阈值也需要调整成一个合理的值。发送异常问题需要能立刻报警。
除了接口监控，还需要有实例监控，防止机器或者服务挂了自己没有感知影响到了用户。一般我会选择监听端口获取发起一个HTTP请求来检测存活。之前就遇到一个问题，重启nginx失败了，没有设置报警，导致刷新页面会偶尔跳错误页，害得我会滚代码第二天才重新上。
还有一种监控是针对页面的，定时调用指定页面，并渲染页面，渲染完成后通过抓取页面上的HTML信息检测业务是否正确。回归测试中非常有用。
服务降级
依赖的模块有时候会发生异常，比如Redis，每过几个月就会来一次，一般原因是某个分片过大，分片过大性能会下降。还有一些情况，比如硬件维修，这个时候需要摘机器等。
方案有很多，比如双机房，双集群，多组Redis等。当时我们设计了十几套降级方案，尽量把所有的降级操作都压缩到最小。
兜底
上面说了，nginx出错会跳错误页，而不是nginx的默认错误页。而我们的要求是三级列表页能根据每个类目跳兜底页面。也就是说，兜底的时候用户有可能并不会发现我们兜底了。这样可以保证在后端服务发生任何异常的时候都能给用户一个友好的页面。
对于一个电商而且是上市技术公司来说，兜底是非常重要的，它会影响到公司的股价。如果发生时间很长的故障，而且又引发一些舆论效应的话，损失的就不是那些订单了，而是市值。分享一个真实的事情：有一次我的接口出了问题，没有返回正常的数据，前端接口没有兼容，在用户端看到了nginx的404页面，当时要求第一个要修复的是兜底方案。
事故
写到这里，线上紧急问题的处理方法已经有了，自动的有兜底，手动的是报警+降级操作。可以这么说，这几个部分是影响绩效的最重要因素。线上问题不管多么严重，衡量级别的最重要因素是影响时间，处理得快，比如十五分钟内，问题不算大；如果超过半个小时，事故级别就会往上走了。
处理事故最重要的，还是要快。自己操作时需要权衡，如何快速恢复。处理问题最差的方案是改代码。如果实在找不到问题，可以考虑强制更改数据库或者缓存来解决。紧急问题处理的快慢主要还是看平时项目预留了多少调试的方案和快速定位问题的辅助工具。真发生紧急问题一般会比较着急，没办法集中注意力，所以前面提到的调试工具或者降级方案就显得很重要了。
值班
进入6月份和11月份就要封版了，那个时候也没啥需求了，主要就是值班。一般1号是秒杀日，那天凌晨需要值班。移动端的流量很大，移动是未来啊。有时候每个夜里都得留人值班，不是每次都这样，这个主要是领导决定。17和10号夜里一定得留在公司值班，夜里也不能回家，2点流量下来后需要到公司附近的酒店休息，早上8点前回来，因为早上8点有秒杀。
连夜值班我还是比较喜欢的，可以换调休，第二天还可以休息一天。一个组的会经常大促一起开房，大家的基情是其它公司比不了的。
每次值班领导都会给买吃的，各种吃的，还有饮料，我最喜欢的还是那个豚骨汤泡面，在每个值班的夜里，泡一碗，周围都是这个味，最后大家都开始吃这个了。
一般17号或10的时候就需要进值班室了，值班室挺挤的，大家在那里呆一宿，全是味。在那边有基础服务的人，出了问题方便解决。0点的量真的很大，那个时候大家都很紧张。
讲一个真实的值班情况：那天我像往常一样在值班，那是我第一次负责我们组所有的大促服务稳定和降级策略，所有准备工作都像往常一样过完了，能想到的意外情况也都做了准备，但还是发生了意外。10号晚上23:20，流量突然可以激增，是平时流量的几倍，触发了报警。看到流量还在上涨，就得找上涨的源头。我们的服务除了给自己的列表用，其它部门也会调用，我们把请求量大的都做了单独的监控，但是这次的流量上涨却没找到源头。这个平时量太小，被我忽略了。没办法，只能上nginx去看access log，找出流量来源。发生这种情况，都很意外，不过我们服务性能很好（曾经有一度可以单台抗所有量），我定位起来也就没有很紧张了。后来找到了调用方，他们在大促前更新了缓存服务，这个服务并不是那么可靠，导致10号晚上缓存被击穿，流量回源，全到我了这里。平时QPS应该是个零点几的样子，那天晚上那么短的时间QPS有几十万，还好我们服务扛得住，否则的话只能把这个来源降级了。
很多情况下问题就是这么来的，你觉得可以没什么，优化了一把，跑得也正常，大促极端情况下就会被击穿了，下游服务都扛住了，如果下游依赖的很多服务因为流量突然上涨没有扛住，问题就很严重了。
最后
今年双11是第一次没有亲自参与的大促，我自己也没买什么，感觉大促气氛不像以前那么浓烈了，大家是什么感觉呢？
原文链接：在这个大促的日子聊一聊我的大促经历，转载请注明来源！
