（本文作者：储晓颖，支付宝技术研发工程师）
就像一群人在证券所盯着股票大盘一样，看着红红绿绿的各种数字曲线跳动波动然后跟着兴奋紧张。
我就是做这些大盘的
所以……过来刷刷知乎缓解下情绪。
对我们这个岗位，双十一就像高考，而我每年都要复读，每年题目还都比去年难很多。
过完高峰来修改下：
系统没挂！哈哈哈哈哈哈哈
白天值班很轻松再来修改下：
本人一共历经5年双十一（是的，每一年我都参与了）。数据很敏感，代码无国界，不匿名说一些技术上的感受，无伤大雅。
妄自揣测回答一个题主可能关心的问题，相信这个问题能从侧面衬托出作为员工亲历双十一的感受——纯粹从技术角度，为什么需要这么多员工通宵达旦灯火通明的一起来支撑双十一？为什么不安排几个运维同学值班就够了？
第一个例子：
如果你是个程序员，你做了一个最简单的B2C网站，网站的主流功能必然是面向用户的订单、购物车等“前台业务”；同时也必然会有一个“后台”，给你的小二（运营人员）提供运营管理功能（新增营销活动、编辑店铺信息、修改商品信息、查询历史订单）。然后有一天你们要办一个非常重要的促销活动，用户蜂拥而至，突然一个小二做了一个非常复杂的历史订单查询（产生了一个嵌套好几层的SQL），而不幸的是你的系统又没做读写分离（读写操作在同一个DB），DB负载本来就飙升好几倍了，这一下直接干倒，多米诺效应拖垮了web前台，网页404——促销成了微博上茶余饭后的笑话。
怎么避免这种事情？
第二个例子：
程序员应该都熟悉淘宝的tair缓存技术（双十一能成功，它居功至伟，大量的商品信息都是缓存其中，细节不多介绍了）。
如果量少，怎么玩都可以。
但是如果量大呢？
假如你有100台机器可用于部署tair。然后你参与大促的商品一共有100W件。按照最简单的负载均衡思想，应该把100W件商品的信息，平摊到100台tair上，每台缓存1W件商品详情（我们假设一台tair是缓存不了100W件全部商品的，那就必然要有所分工，即使不是按商品的粒度，也可能会按其他更粗的粒度来分工）
现在你的运营过来告诉你，根据市场行情的调查和营销力度的把控，今年大促秒杀iPhone 6的PV可能会达到几百万、iPhone 4会达到....、电饭锅的PV应该是500，电吹风是200……同时今年又是iPhone 6刚刚推出、正值风口浪尖。
如果是我，我肯定拼了老命、赔了老本也要保住iPhone 6的秒杀。至于电饭锅，让它自生自灭吧！
所以我可能会把90台tair都用于iPhone等5W个重点热门商品，10台用于剩下的95W其他商品。
（以上所有数字纯属YY）
第三个例子：
大家都吐槽12306的排队，那么问题来了——如果你的代码真的写的很好了，机器真的不够用怎么办？
只能排队啊。。。
「双十一」对于各银行的科技部都有怎样的考验？历年都有哪些趣事发生？这里可以看看银行的同学们是多么的头疼。
银行啊！大型机啊！都搞不定啊！
所以如何优雅的“降级”，是阿里这几年技术成长的一个重点。想做优雅的排队？对不起，首先你要异步化，否则就只能暴力的把用户拦在外面；想异步化？对不起，你是支付宝，你是金融系统，在异步链路下依然要保证强一致性（告诉用户购买成功、钱却等了1分钟才扣这种现象要尽全力避免——经@曾祥能同学的提醒已修改）。
就算做到这些了，还要一个把并发编程思想发挥到极致的queue中间件，不仅能有条不紊的削峰填谷、蓄洪限流，还要能随时接收参数调整，实时动态并发的改变阀门阈值（什么概念？一点点的差错、1ms的差错，就会导致海量的订单没有按预期流动）
即使这些都已经做的很努力了~还是要不停的改进！能不降级就不降啊、能不限流就别限啊——看评论里同学们的吐槽就知道了，技术上还是有很多不足的。
先就说这三个例子。虽然没有正面回答题主的问题，但是已经很明显的看到，现在的“监控”，已经不仅仅是cpu、load、磁盘、端口、网络这些运维同学的事情了。不仅要做到T+0的实时BI、实况转播、ROOT-CAUSE，还要做到对所有决策的实时反馈、准备应急降级预案、事先规划资源分配……
试想第一个例子，大促开场高峰期要关闭部分后台的复杂查询功能（甚至是“前台”的次要业务），小二和客服的某些服务就会暂停，用户投诉就会上升，就要启动事先准备好的缓和对策，等到压力稳定，要立刻恢复被降级的服务，小二和客服立刻得到通知尽快去解决拖延已久的问题、安抚生气的用户。
补充：（关于降级）我们老家有句话叫“有多少米做多大粑”。客人来的多了，食材不够，这就是现状，是前提，改变不了。在这种情况下还能准备好一顿开心的晚餐，把客人的总体损失降到最低，也是个技术活儿。就连纳斯达克在大公司上市之前也要执行“预演”，避免不必要的交易行为把证券系统搞挂，这也是一种降级。
补充：（提到了银行就再补充一个喜闻乐见的例子）小银行顶不住了怎么办？收银台引导啊、让用户用扛得住的银行卡啊！银行都挺不住怎么办？充值送红包啊，让用户多用支付宝余额啊！银行的量还降下不来怎么办？多送点红包啊！300不行送500啊！运营找财务拨钱来发红包啊！决策小组亲自审批啊！营销规则要立刻发布更新啊！这一切要在几分钟内完成啊！就酱紫……
想要把整个双十一玩转，需要PD、运营、中间件、业务系统、决策小组、客服等N多个部门一起合作。因为在这么大的数据量面前，技术上纠结的程度已经具体到电饭锅了。
所以亲历双十一是什么感觉？
就是你看到作战室（超大会议室）里十几个大屏幕上翻滚的各种业务指标、系统数据，各种红红绿绿的报表曲线提醒着每一秒钟的业务健康情况、决策执行情况、降级损害程度……
然后决策小组的一帮最高指挥官通过这些数据做出各种决策，有些闲庭信步、有些壮士断腕。
运维人员和系统owner以最高效的方式执行决策并跟踪反馈决策效果。
DBA、中间件的同学盯着自己的DB、系统在强大的压力下随时准备申请执行预案（还能撑一点！加油啊儿子！我靠不行扛不住了、首架我要执行Plan B！……）
运营和客服的同学更不用说了，已经忙翻天了，她们可是要根据决策小组的决策不停变换工作策略！
至于我？那些屏幕上的数字还在动，是准的，够用，我才能安心的过来写知乎啊~
针对评论的一些补充：
看了评论里的吐槽都指向收藏夹啊？暂时得到的反馈是收藏夹大促未做降级，肯定还是量太大没有稳住。
可惜的是这一块的业务监控做的很弱（之前都重点覆盖购物车等业务了……），目前没有什么有用的指标，大促之后我得到原因再过来反馈。
另外很多热爱coding的同学都在寻求技术答案，我知识面有限，难以全部回答准确，qcon上支付宝架构师胡喜的支付宝弹性计算架构应该能够帮助同行们了解一下支付宝技术上的努力，淘宝的就更多了，很多早就开源的优秀解决方案。技术问题我就不一一解答了，可以私信留言，我去帮你翻翻资料尽量回复。
评论好多……我知道有很多朋友觉得阿里这种“人为创造春运”的行为不好，明明可以把交易分摊到更久的时间段里慢慢买的，为何要人为的创造这样一个“节日”来折腾员工、折腾用户、折腾快递小哥。这个问题好大，我只是一个码农我只能回答一个码农的观点：
大家觉得春运不好，本质还是运力不足、经济发展不平衡，这些才是痛点的源头啊。可是互联网、电子商务、IT技术，这些可以不痛啊。我听过这样一句话：
在很多科技领域，我们赶超欧美日本等发达国家还有很长的路要走，人家比我们提早了几百年。但是计算机，我们的起步只落后几十年，尤其是软件，落后的更短，而且软件的资源成本、硬成本较低，它的关键是人才。
支付宝从最初的一个小工具，到赶超VISA、支付能力甩它几条街，我们并没有消耗浪费很多的社会资源，我们一年又一年的性能优化项目反而是在降低资源消耗。这个“人造节日”，锻炼出了一批又一批的高素质软件人才，无论他们去向哪里，都会成为编程好手、架构栋梁，促进整个IT业的发展，改变我们依赖洋大人、天天学SSH、天天捧着Google的论文尊为圣经的现状。
起码对程序猿，这是好事儿，不是吗？
|
