对于大部分人意味着剁手，可对于N多背后护持双11的IT人来说，那就是赤果果的——Just剁 IT！
每逢“双十一”最紧张的不是商铺理货，也不是网友紧盯大促商品准备秒杀，而是网购幕后的运维人员，他们最担心：什么网络中断、应用卡顿、响应速度慢，服务器宕机……
双十一作为电商 IT 部门的头等大事，大促前，运维人员就需要早早地做好多套预备方案，并时刻紧绷着神经，经历着上百次模拟演练。他们在后端有多少不眠不休的夜晚，不得而知。几年前，一场秒杀让服务器宕机是常态，现在，一秒数十万的订单，服务器依然坚挺。毫无疑问，支撑起这一切的是强有力的技术和运维人一个个不眠的夜晚。
看似简单的双十一背后牵扯到是包括支付、架构、数据库、网络、运维、电力、客服、物流等整个商业配套基础设施的协同和考验。
天猫双十一大促最早开始于 2009 年，那时候还是淘宝商城，一天的 GMV 只有几千万，而且还没有零点全民疯抢的概念。在大促前工程师们基本上会根据各自的经验判断，比如服务器的当前负载、应用的当前 RT 和 QPS，判断每台服务器最大能支撑多少能力等，然后几个人讨论后就决策拍板，某某核心应用各自要加多少台服务器，到底要加多少服务器，实际上大家的心里没底，实在不放心临时再多申请扩容。总之这个阶段业务量也小，也能应付过去。
后来几年随着天猫品牌的提升，双十一大促逐年爆发，原来的运维方式已经无法适用。业务发展迅速，后端的应用数量也大大增加，各个应用系统之间的调用链路错综复杂。大促前到底要准备扩容多少资源？不能拍脑袋热，因为你申请资源太多会可能被拒绝，申请少了你要承担更大的风险。
这时候用线上压测的方式来解决，比如可以直接在生产环境抽取 1 台服务器，通过模拟回放或者直接引入多倍流量做压测，根据压测结果计算出单台服务器的最大可承载能力，然后用数字来说话，去申请扩容。还有就是即使容量规划做到位了，但在零点峰值的时候还是可能会超出预期，系统还是会挤爆。所以又引入了限流和降级，限流就是对各个应用设置一个最大阈值，超过阈值就立刻拒绝新的请求，这样的好处就是保护应用，避免雪崩。
还有就是降级，由于应用太多，在大促的期间，可以关闭部分非核心功能，保证交易主流程的能力最大化。那个阶段的压测也不是完全精确的，主要问题是压测的局限性，只是对某个应用做单独压测，但是应用之间是有依赖有关联的，特别是一些共享服务中心，基本上被所有应用都依赖调用，那怎么办呢？后来几年时间又研发出新的压测工具，全链路压测。这个对于容量规划来说，是全新的思路，直接在生产环境上通过模拟复制产生大批的流量，每个环节都会被压测到，并有相应的监控系统配套，来找出瓶颈点在哪里，并迅速优化。而且这个过程被自动化完成。
现在的电商双十一大促活动仍旧延续零点疯抢模式，对于应用系统保障来说，能否顺利扛过前 15 分钟，甚至是前几分钟，成为最核心的保障任务。运维界大咖给出了以下几点建议：能否顺利扛过前 15 分钟，甚至是前几分钟，成为最核心的保障任务。具体给出了以下几点建议：
a. 容量规划。 尽可能在生产环境做压测，只有经历过压测，心里才会有底。
b. 关键应用要支持限流。 零点全民疯狂的流量很可能会超出预期，只有设置好限流才能保护好自身应用，否则出现雪崩式连锁反应。
c. 对非核心功能做降级。 每次双十一会投入大量的资源，基本会往核心交易类应用倾斜，那么非核心功能的降级一定程度上是可接受的。
随着云计算特别是公有云的普及，现在的运维人员基本上无需关注机房、网络、操作系统等底层设施。在不断地演练后，如今的电商平台早已采用弹性可扩展的云计算平台，配合分布式数据，高效的 CDN 分发来实现负载均衡，避免在双十一凌晨高并发状态下崩盘。运维人员将更多精力转移到快速上线，快速迭代，去支持业务发展。
大促活动的流量跟日常完全不在一个量级，完全可以利用云资源的按需使用，来达到扩容的需求，而且在成本上是巨大的节省。除了扩容以外，当然还需要准备应急预案。整理出当天可能出现的异常情况，提前预演。
除去上述，所有运维团队还需要提前制定值班计划，对双十一当天可能发生的各种突发情况预案，双十一各时段应该关注的关键点进行详尽计划。总之，每年双十一都是一次检验，一次大考。细节决定成败，对全体运维人而言，必须所有细节都关注到，演练到，准备到，才足以从容应对每一年的双十一大促。
选择一个好的服务商对于电商企业至关重要，神州光大是利用共享经济模式，通过互联网平台聚合工程师资源，为客户提供有质量保证的按需使用工程师资源的IT服务的互联网平台公司。
诸如双十一这样的弹性场景，除了对设备、计算资源等需求会出现爆发式增长，这期间对工程师需求也会大大增加，神州光大广泛的工程师资源，随时满足客户各种场景下的人员需求，新增设备的安装调试、大促前的巡检、突发的紧急故障神行工程师都可以快速响应并提供现场服务。帮企业顺利度过双十一。
