在阿里巴巴或小微金服現場經歷 2014 年「雙十一」是一番怎樣的感受？

11-16

就像一群人在證券所盯著股票大盤一樣，看著紅紅綠綠的各種數字曲線跳動波動然後跟著興奮緊張。
我就是做這些大盤的
所以……過來刷刷知乎緩解下情緒。

對我們這個崗位，雙十一就像高考，而我每年都要復讀，每年題目還都比去年難很多。

---------------------------------------------
過完高峰來修改下：

系統沒掛！哈哈哈哈哈哈哈

----------------------------------------------
白天值班很輕鬆再來修改下：

本人一共歷經5年雙十一（是的，每一年我都參與了）。數據很敏感，代碼無國界，不匿名說一些技術上的感受，無傷大雅。

妄自揣測回答一個題主可能關心的問題，相信這個問題能從側面襯托出作為員工親歷雙十一的感受——純粹從技術角度，為什麼需要這麼多員工通宵達旦燈火通明的一起來支撐雙十一？為什麼不安排幾個運維同學值班就夠了？

第一個例子：

如果你是個程序員，你做了一個最簡單的B2C網站，網站的主流功能必然是面向用戶的訂單、購物車等「前台業務」；同時也必然會有一個「後台」，給你的小二（運營人員）提供運營管理功能（新增營銷活動、編輯店鋪信息、修改商品信息、查詢歷史訂單）。然後有一天你們要辦一個非常重要的促銷活動，用戶蜂擁而至，突然一個小二做了一個非常複雜的歷史訂單查詢（產生了一個嵌套好幾層的SQL），而不幸的是你的系統又沒做讀寫分離（讀寫操作在同一個DB），DB負載本來就飆升好幾倍了，這一下直接干倒，多米諾效應拖垮了web前台，網頁404——促銷成了微博上茶餘飯後的笑話。

怎麼避免這種事情？

第二個例子：

程序員應該都熟悉淘寶的tair緩存技術（雙十一能成功，它居功至偉，大量的商品信息都是緩存其中，細節不多介紹了）。

如果量少，怎麼玩都可以。
但是如果量大呢？

假如你有100台機器可用於部署tair。然後你參與大促的商品一共有100W件。按照最簡單的負載均衡思想，應該把100W件商品的信息，平攤到100台tair上，每台緩存1W件商品詳情（我們假設一台tair是緩存不了100W件全部商品的，那就必然要有所分工，即使不是按商品的粒度，也可能會按其他更粗的粒度來分工）

現在你的運營過來告訴你，根據市場行情的調查和營銷力度的把控，今年大促秒殺iPhone5的PV可能會達到幾百萬、iPhone4會達到....、電飯鍋的PV應該是500，電吹風是200……同時今年又是iPhone5剛剛推出、正值風口浪尖。

如果是我，我肯定拼了老命、賠了老本也要保住iPhone5的秒殺。至於電飯鍋，讓它自生自滅吧！
所以我可能會把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的論文尊為聖經的現狀。

起碼對程序猿，這是好事兒，不是嗎

我是數據團隊的，就是做那個大屏幕和周邊屏幕的團隊。限於保密制度對數據不能多說，就分享一下從保障雙十一到現在整個期間的生活吧。
1.我旁邊的大哥，就是我們的team leader已經一周沒回家了，吃住都在公司，唯一的出門需求就是出門買煙（園區內不賣煙），從十一回來之後回家就不超過五次。有一天我們都在碼代碼的時候他突然說了一句：我靠我的頭好癢啊我要去洗個頭……全部人-_-!!!
2.已經連續加班若干個星期了，兩三點是家常便飯，十號凌晨我主管本來已經回家了，兩點多被我們叫起來審批許可權，然後在旺旺上問我還有問題沒有，我說有點小問題，然後對面就沒聲了，我心想不會過來了吧，果然，過了一會從濱江開車回來了，出門的時候因為著急車還撞到了花壇。這一天我們全體通宵到早上七點。
3.我10月18號那天跟女神表白成功，緊接著20幾號的時候連續好幾天被同事問有沒有女朋友要給我介紹…我說我有了，對方問，是咱們公司的么？我說不是，他們大驚：你天天加班還能找到不是咱們公司的女朋友？
4.團隊裡面有個九二年的小伙長的很可愛，被我們叫做小鮮肉。Hr姐姐有一天給我們送零食，看著他惋惜的說，天天熬夜小鮮肉也變老臘肉了啊…
5.10號晚上十點多的時候出了一點幺蛾子，大家心裡都捏了一把汗，直到屏幕完美無瑕的顯示出來我們才鬆了一口氣，效果比我們前幾夜看過的都要好，那種感覺…就像是高考考出了模擬考試中的最好成績。
6.過了十二點半媒體開始散場，我們才能騰出手來刷刷微博，看到滿世界的媒體都在引用我們團隊的成果…那種感覺…說實話還挺自豪的。
7.11號凌晨三點我和小鮮肉一起回家，因為他家太遠早上六點要起來繼續保障第二天，乾脆去我家睡了，回去的時候我很作死的騎車抓著騎電動車的他肩膀然後飈到40碼，然後我摔了個七葷八素，今天忽忽悠悠的就瘸了……這個故事告訴我們，No zuo no die why you try。回到家我們匆忙洗了睡了，關燈的時候他壞笑著對我說，我女朋友平常就睡我左邊，你晚上要小心啊…
8.報告廳現場人太多，平常的辦公無線網登不進去，沒有乙太網口的air黨只好連公用wifi然後撥vpn進去…
9.給媒體看的那幾個大屏幕有個很土的登錄界面，因為應用就部署在內網，知道域名就可以用園區內的任何一個瀏覽器訪問，萬一擴散出去全公司人民都來圍觀我們腫么辦！要知道為了保證實時性我們可是沒有用tair的！不過媒體是看不到的，登錄密碼強到令人髮指的地步，幾乎就是隨機的字元串，因此收到了無數抱怨。另外，密碼是十號那天寫死在Java代碼里的，團隊內部有人問leader密碼的時候他就很不耐煩的說，自己去翻代碼，我哪記得住！
10.因為是完全基於真實數據的繪製，右下角的＂飛來飛去圖＂（內部稱呼）在凌晨一點的時候撐不住了，開始卡…卡…it小哥被迫刷新了一下頁面…原來國外也有這麼多剁手黨，哪天要是淘寶統一世界各位也不要奇怪，世界人民嘴上說著不要身體卻很誠實呢。
11.右下角的飛來飛去圖裡面有個地區是台灣，你造我們改了多少遍它的名字么！最開始叫台灣，放的是青天白日滿地紅，公關部看了說不行，改成了中國台灣，換成了中華台北的奧運五環旗；後來過了幾天公關部跑來說，他們聯繫了某政府部門，要求寫台灣，於是我們又屁顛屁顛的跑資料庫改了中文名；10號下午公關部又說，外交部要求改成中華台北，不！放！任！何！旗！子！縮寫改成TPE，我們整個團隊就斯巴達了，中文名改改就算了，TW可是從前端到Java到資料庫中用的鍵值啊！！！後來被我們拒絕了，這個真不是我們不想改。。。。
最後的效果大概像是醬紫：

此外，大家有木有發現左邊的國旗列表裡面法國國旗出現了好幾次（已用紅框標出）？那是因為。。。這個世界上有很多法屬巴拉巴拉地區，它們的國旗都是法國國旗。

此外，大家有木有發現左邊的國旗列表裡面法國國旗出現了好幾次（已用紅框標出）？那是因為。。。這個世界上有很多法屬巴拉巴拉地區，它們的國旗都是法國國旗。
================
評論里很多詢問我廠加班情況的，在此統一回復：我廠不打卡，有雙休，只要效率夠高上班不刷微博知乎什麼的是完全可以不加班的（可惜我做不到T_T），加班到凌晨只是這兩周的事情，不過加班到凌晨的話第二天一般大家會晚來會，畢竟都起不來…比如我現在就剛起床…總之，我個人還是很喜歡這種自由的狀態的，就醬。
================
大家好像對女神更感興趣一點啊...剛剛還有個小伙給我發了這麼一條私信:

我想說...我跟女神是大學同學啊，我在學校的時候就開始勾搭了，跟我廠沒有關係的！因為是異地所以加班還木有什麼關係，勤打電話就行了。。。未來要是能在一個城市肯定要早早下班去呵護女神的！！！

雙十一前的周末，阿里『老佛爺』前來慰問員工。。

還來了一波又一波的明星給品牌造勢。。小貝，高圓圓，周渝民、楊千嬅等。。

10號白天的園區：

夜色降臨後，整個園區都亮起了彩燈：

直播間來了很多媒體。。都在等著見證0點爆發的時刻。。

待更新。。

謝邀。

限於公司的保密政策，估計只能說我這邊看到的，不能涉及很細節的技術內容或者數據。因此回答也比較簡單。由於我在支付寶這邊，負責的兩個系統比較簡單，且和運費險相關，尚處於比較下游的位置（出單頁），因此壓力不如想像中那麼大。

在雙十一的前一個月就開始了各種全鏈路壓測（通過一個系統向天貓淘寶頁面瘋狂的發出請求，QPS能達到幾十幾百萬量級）。通常壓測都是在凌晨流量較低的時候，壓測時間相對較短。因此絕大部分用戶根本感受不到。壓測會有很多輪，針對每一輪各系統負責人會有針對性的對系統做出各種調整以適應大流量。（其實是挺枯燥的過程，涉及很多諸如限流，降級，cache，tair，hsf等各種配置，以及程序的優化優化優化）最後一次壓測後我負責的兩個系統表現就比第一次好的多，也不枉我和帶我的師兄熬夜這麼多次：）

雙十一當天我是屬於黃龍作戰室，支付寶大樓這邊14樓早早的就布置好了（一共五個作戰室）。從中午開始公司各部門與雙十一相關的技術人員就陸續進場了。會有各種小點心和盒飯派發。

當天我一直沒太大壓力，但是得知我負責的某個系統雙十一當天降級（因為處理一次請求相應時間仍然較長），因此流量不經過該系統了（心疼……）。瞬間感覺壓力又小了一些。

我比較懶，一直呆在工位上（在天貓上挑東西到購物車- -||）。晚上11點才去作戰室。

進去後發現已經嚴重擁擠且沒有位置了。到窗邊找了一個小板凳坐下。我的視野是這個樣子的：

然後聽見身邊的工程師各種胡亂的聊天吐槽添購物車或者看雙十一直播要麼查看系統，總之幹啥的都有。旺旺群里非常熱鬧，我加入的運費險值班群里，接近0點的時候各種緊張啊。還出現一次誤報業務異常的警報，弄成虛驚一場，鬧了個小烏龍。

到了0點，流量噌噌噌爬上去了。大概持續了一段時間。這段時間裡面各位工程師都在購物或者check自己的系統是否正常運作，還有人在關心大盤交易量，各類服務被調用的QPS數量級，屋裡沸騰了，非常熱鬧。
我看了一下我們系統收到請求的峰值比最後幾次壓測低很多，並且也沒有報錯，於是就放心去購物了！

坑爹啊！我就那麼一走神，購物車裡面那麼多想買的東西瞬間就沒了啊！！！

於是我又一邊看著系統監控的折線圖一邊興味索然的買買買其他東西，在作戰室待到了快兩點。其他PE工程師和很多關鍵系統的開發大部分都通宵了。

然後我騎車回家睡覺。亮點是支付寶附近居然還有個別賣點心的攤點在營業。

第二天九點半照常起床上班，該買啥買啥。今天12號，看到了新聞，說是雙十一當天我們賣出了1.87億單運費險，默默地為自己點個贊。該幹嘛幹嘛。

唯一後悔的事情是值班的那段時間沒有把手剁掉。看著支付寶賬單，心好痛。

還好我有運費險，可以無憂退款呢。

就醬。

（本文謝絕一切形式的轉載。）
____________________________________________________________________________
以下為私貨，和我的工作密切相關。評論區中題主好奇我們在運費險環節可能出現的問題，簡單解釋如下：

凡是與程序相關都會出現bug：）在天貓或者淘寶完成一次完整的購物體驗牽涉到淘系和支付寶系統後端的各種hsf，sofa服務調度。在可能調用到的幾百個hsf服務中只要有一個簡單的環節出現問題，就有可能導致該服務timeout，拋異常是肯定的。當嚴重的異常堆積起來以後該伺服器延遲增大，請求堆積。。如果該異常比較嚴重（例如付款和展現相關的，造成的可能後果是價格不對，用戶載入不出網頁等等），無法及時處理，伺服器就線程池滿。。。最終的結果可能就是放棄一部分用戶的請求。。讓這部分請求自生自滅了。。。至於運費險定價是我負責的比較核心的技術，具體細節無法透露，然而一次個性化定價，需要調用各種風控介面，通過查詢後台資料庫，查詢定價模型進行計算給出結果，牽涉到數十項外部服務。只要有一處hold不住，我們就有面臨掛掉的風險。個性化運險定價就無從談起了。

發點圖吧，感謝大家的堅守

2014年天貓雙11創下兩項吉尼斯世界記錄，http://www.guinnessworldrecords.cn/news/2014/11/tmall-61758/

24小時內在線零售額最高的單一公司

24小時內單一網上平台售出最多部手機

這兩個記錄的判定依賴的具體數據，有非常重要的一條是我們交易系統的時間和標準北京時間完全同步，剛好我負責伺服器時間同步，雖然我們線上伺服器的時間精度遠超審計要求，但是如何向非IT專業的審計人員解釋清楚網路時間同步的原理與細節還是頗費功夫的。

因此10號晚上就和PwC審計人員坐在一個會議室，講解伺服器授時原理，從網路時鐘同步的基本原理開始，到什麼是一級、二級時間伺服器？如何通過GPS、北斗衛星信號授時和銣原子鐘守時？再到如何保證GPS、北斗衛星信號丟失或受到干擾的情況下依然確保準確的授時等等，最後演示線上交易伺服器時間準確度，然後驗證、截圖作證等一系列數據提供。

11號零點提供完數據，我當天的外部任務就算完成了，會議室外突然有人喊"三分鐘10億了！"，一屋子人包括PwC的審計們也都沸騰了起來，過兩分鐘又有人喊"5分鐘20億了!"，接著是14分鐘50億，38分鐘100億.....

雙11之所以能搞這麼熱鬧，不是因為某一個商家、某一個消費者，而是源於圍繞阿里的整個生態系統，消費者、商戶、快遞員、淘模特、網店的設計師、商品圖片的攝影師、網店後台軟體開發維護者，這場活動背後是千千萬萬的人。阿里能夠做到服務億萬消費者和商家，不是因為自己的員工有多牛（雖然實際上也很牛），而是因為自己所站的位置以及所生活的這個時代！

一年比一年刺激，不過今年作戰指揮樓層的雙11的伙食沒去年好了……去年還有自助餐吶！

悄悄傳兩張圖，所有員工非特殊情況全部在崗，不是大家所看到的幾個高峰點，而是一直在，應急預案早有多個方案，發現問題排查解決，雙十一前後幾天對於阿里員工來說都是非常辛苦，但是又是非常激動迫不及待的。雙十一對於用用戶來講是個購物狂歡節，對於阿里員工來講，是對用戶交上滿意答卷的一場考試，支付系統的安全與流暢，服務品質的提升與專業，都在過去一年不斷打磨中想要變成大家想要的樣子，這一夜，阿里燈火通明期待您的批閱。，