2018年，雙11迎來了十週年。

十年間，依賴於迅速崛起的網際網路技術以及各項新興技術的沉澱，阿里巴巴締造了全球數字經濟時代的第一“作業系統”。在這個作業系統上，讓全球消費者和商家買、賣、逛、聽、看、遊得順心、放心、舒心。

十年間，阿里巴巴的技術同學和全球開發者們，一起把網際網路前沿技術轉化為全球消費者、全球數字經濟參與者可以感知的便利。

它如今已經不僅僅是全球消費者的狂歡節，更是名副其實的全球網際網路技術的演練場。

第十個雙11即將來臨之際，阿里技術推出《十年牧碼記》系列，邀請參與歷年雙11備戰的核心技術大牛，一起回顧阿里技術的變遷。

今天，天貓技術質量部資深總監、雙11大隊長霜波，將帶領大家，細數每一年雙11的重要節點和突破，遺憾與不足。我們相信，無論是雙11，還是你正在經歷的專案，都需要敬畏和細緻的態度。

雙11大隊長霜波

2009年

2009年是淘寶商城成立的第二年，這一年的秋天，運營的同學想搞一場營銷活動，逍遙子喜歡四個一，而11.11又是網民創造的“光棍節”，所以就選擇了這一天。誰也沒有想到，這樣一個帶著點隨意的選擇，竟然在若干年後成為影響中國乃至全球的大事件，造就了電商行業最具影響力的品牌——雙11。

第一屆雙11的活動口號是全場五折，拉了幾十個商戶參加，未曾想效果驚人，淘寶商城的成交額是平時的十倍。幸運的是，在2009年初，“五彩石”專案，將淘寶和商城的系統底層架構統一了，雖然商城的成交額增加十倍，但由於基數還比較小，這個成交額和淘寶的日常成交額比起來並不大，因此係統上沒有出現特別重大的事故。

儘管如此，暴增的流量還是讓工程師們措手不及。採訪當年第一屆的工程師四虎時，他回憶說：“第一年雙11，作為交易系統的owner，接到老闆指示，光棍節要搞個活動，你值一下班。那年我們啥都沒做，就坐在那看伺服器的情況。0點一到，發現伺服器流量暴增，一下子伺服器就掛了。我們就手忙腳亂地去重啟伺服器，恢復系統。系統起來後，發現店鋪和商品圖片又出不來了。第一次雙11，可以說完全是意料之外，沒有做任何準備的，不僅僅是把我們的交易和商品系統壓掛了，同時把很多商家的外部圖片空間也給壓掛了。伺服器容量、網路頻寬容量、系統保護都是沒有的。”

2010年

吸取了上一年的經驗，2010年雙11之前技術部門專門成立了大促小分隊，負責保障穩定性的同學在創業大廈10樓集中辦公。那一年，高峰不在0點，而是出現在第二天白天，早上10點左右CDN的容量很快達到上限，圖片展示越來越慢，眼看就要出不來了。大家緊張起來，激烈地討論還有什麼辦法。有人提出搜尋的圖片展示佔了很大的容量，可以將搜尋的大圖降級為小圖。然後給搜尋的負責人打電話，通知他：“對不起了，我們要對搜尋的圖片降級了，雙11結束就給你們恢復過來。”這一招幫助當年的雙11渡過了容量的最大風險。

之後，每一年的搜尋大圖降級小圖都成了雙11的必備降級方法之一，雖然後面再也沒有啟用過。同時，每一年雙11之前CDN都會拉一個大會，讓所有業務評估自己雙11當天的CDN使用量，提早2個月就開始擴容的準備。“所有的苦難都是用來幫助我們成長的”，這句話用在雙11當中特別合適。

四虎回憶第二年的情景：“第二年，我們開始有了心理準備，預計流量是平時的3倍5倍，但是實際流量遠遠超出我們的想象，達到了平時流量的十幾倍。不過基於前一年的經驗，這一年我們做了很多工作，分散式系統的防雪崩、核心系統的自治，這些技術改進讓我們的系統比上一年好了很多，雖然0點高峰還是出現大量的購買失敗，但是伺服器沒有大面積宕機，流量下降後能夠繼續良好地服務。”

2011年

2011年淘寶商城成為獨立的事業部，雙11對於剛剛成立的淘寶商城技術部已經是一件相當重要的大事，各團隊提早幾個月就開始準備，並且上線了第一期的價格申報系統，完成了雙11的商家商品報名的工作，一切似乎都很順利，可是……

11月10日晚上23點，有人反饋設定的優惠價格寫錯了，3折的商品寫成了0.3折。

23點32分確定砍掉折扣0.5%以下的商品，然後需要推送到整個商品庫。執行到一半的時候，越來越多的人反饋商家把優惠理解錯了，擔心影響太大，決定砍掉1.1%以下的商品，但是由於之前的操作已經執行，所以先要回滾，然後再全部推送。

23點45分，開始回滾。

23點55分，回滾完成，開始重新推送。

11日0點10分，所有推送完成，同時開始收到大部分商品屬性丟失的問題反饋。屬性丟失意味著買的衣服沒有顏色，意味著買的鞋子沒有尺寸，當時使用者由於很多商品都已經在購物車中準備良久，所以並不仔細觀察就下了單，可是商家卻沒有辦法發貨。這是一個非常嚴重的系統Bug。當時唯一能做的事情就是通知所有有問題的商家下架商品，等待系統修復。

11日凌晨1點，定位到錯誤程式碼是回滾程式的Bug。決定釋出新的系統解決問題。

11日早上5點，系統Bug修復，通知商家重新上架商品。

時隔5年，回憶起那一晚，依然心有餘悸。外界往往認為雙11那一晚是精心準備的，技術是遊刃有餘的，可是每一年，我們都在匆忙中解決各種臨時的突發事件。實際上真正痛苦的遠遠不止技術人員，還有那些被影響的商家。

在2012年的6月雙11商家溝通會議上，我們問商家：“對雙11最大的期望是什麼？”反饋最多的期望就是：“系統穩定。”一個商家站起來說：“去年雙11的0點我們被通知下架所有商品，當時團隊10多個人，從0點到早上6點，沒有一個人敢離開。我們借了款，備了平時十倍的貨，如果這個雙11賣不掉，我們回到家，對家人唯一能說的可能就是 ‘對不起，我破產了’，或者‘對不起，我失業了。’”

那個晚上，很多人無眠。

痛定思痛，我們在接下來的一年做了大量的穩定性相關的工作，我們上線了新的招商、價格管控、商品申報和優惠系統。我們做了csp的壓測平臺。我們做了系統限流sysguard自我保護系統。我們在2012年準備了接近3000的降級開關，做了4次大規模功能演習，確定了雙11當天的指揮和決策流程。我們以為2012年我們能做到萬無一失。

2012年

這一年雙11的專案5月就啟動了，當天晚上整個集團的核心技術幾乎都all in在雙11，我們準備了一個很大的房間，每個核心人員做好各種預案手冊，當天晚上全神貫注就等著0點的到來。可是，那個0點，流量來得比以往更猛一些。

0點的時候，系統顯示交易成功率不到50%，各種系統報錯，立刻下單報錯，購物車支付報錯，支付系統報錯，購物車的東西丟失。系統排查的大部分指向都是一個錯誤，取不到商品資訊了。再進去看，商品中心繫統的網絡卡被打滿了，無法再響應請求。情況緊急，商品中心開啟了事先準備的幾乎所有降級方案，但效果並不明顯。大約在1點左右，系統流量峰值慢慢緩和，我們的系統成功率才重新恢復到90%以上。

另一個發生問題的是支付寶的健康檢查系統，和所有系統的自我保護系統一樣，這個健康檢查系統會定時掃描線上機器，根據機器應答返回時間判斷是否正常，將超時嚴重的機器在應用列表中剔除，當時用了自研發的ssl 解除安裝 spanner 負載均衡演算法有問題，導致伺服器負載不均，應用那時候用的是apache ，連線數只有1K 多的效能瓶頸，在雙十一的流量之下雪崩了。發現問題之後，我們快速啟動了應急預案，同時做了流量切換，支付成功率重新回到了正常值。在1點之後，我們看到系統各項指標都恢復了，心情稍稍輕鬆了一些。但是白天新的問題又來了。

白天的時候，各種商家開始來電反饋一個嚴重的問題，系統超賣了。就是本來應該賣完下架的商品，在前臺展示依然有庫存，依然不停地被賣出。我們理應給商家一個正確實際的庫存，可是由於0點的各種異常、降級和超時導致庫存的狀態已經不對了。由於資料過於凌亂，系統已經無法當場完成糾正，除了通知商家自己檢查庫存，儘快下架商品之外，我們已經無能為力了。那年的雙11，很多商家由於我們的超賣不得不緊急重新採購，加工，補貨。那年的雙11，應該有不少使用者要等很久才能收到購買的商品。

之後的雙11技術覆盤會上，所有技術同學達成了一個共識，我們一定要有一套系統能夠最真實地模擬雙11當天的流量，能夠及時發現大壓力下線上系統的所有問題和風險，保障雙11的0點體驗。所以2013年，集合了各個BU的力量我們創造了一套全新的壓測系統：全鏈路壓測。

一個全新的系統，從產生到全面實施從來不是一帆風順的。剛開始，大家根本不敢到線上壓，擔心影響使用者，直到有人大膽地承諾：“出了故障我來背！”到9月時，剛開始兩次大規模的壓測都失敗了。有人開始懷疑方案的可行性，思考要不要回到之前的壓測模式，直到有人堅決地前行：“我們這次一定要成功，讓所有的開發一起來加入!”有人在打趣：“摩擦了一晚上都沒有動靜。”有人在寬慰：“第一次從來不會一把成功，我們多磨合幾次。”我清晰地記得第一期的那些開發同學，在一個小小的會議室裡面，晚上12點我回家的時候他們在，早上8點我來公司他們還在。眼睛裡經常有血絲，但是說起話來還是中氣十足。每次給我的答覆都是：“我們會成功的。”感謝這些同學，無論現在是否依然在雙11的崗位上奮戰，但雙11的功臣中一定會有你們的名字。

針對庫存的問題，我們在2013年做了獨有的超賣審計系統，會實時對賬所有庫存，一旦有超賣馬上能收到報警，這個系統在這些年的庫存保障中發揮了很大的作用。

2013年

10月全鏈路壓測終於成功了，幾次壓測中發現了600多個Bug。參加的技術同學紛紛感慨稱之為“神器”。但是在0點開始之前還是出現了一個小插曲。通常雙11之前所有日誌都會清理一遍，但是那一年這個常見的操作卻遺漏執行了，技術同學就在10號晚上發現問題時，臨時手工寫了一個簡單指令碼處理日誌清理，可是指令碼發生了一個小問題導致日誌檔案被刪掉，由於害怕日誌輸出找不到檔案會影響效能，所以決定分批重啟機器，重啟時又發現已經執行的提前預案中有一個Bug，在啟動初始化時有報錯，導致應用啟動失敗。最後只能緊急釋出修復了Bug。所有機器重新啟動完成的時間是10號晚上11點55分。當時大家盯著時間，盯著系統一臺機器一臺機器地釋出，和時間賽跑的感覺歷歷在目。再後來每次大促之前我們會提前準備一份作戰手冊，寫好所有的內容，細化到時間點和執行人，防止再出現任何的意外。那一年，有驚無險。0點的成功率滿足期望。而且系統容量和0點的峰值差不多吻合。使用者體驗剛剛好。

2013年的時候由於各個系統的預案加起來已經超過2000個，無法靠人來控制和梳理了，我們做了一個所有預案的控制系統，提前降級的開關可以準時執行，準備好的預案可以錄入並且做好許可權和通知管理。

2014年

2014年，由於使用者和資料的急劇增長，杭州的機房已經容納不下我們的系統擴容了。於是我們在上海建立了新的機房，雙11當天，真正啟動並且實現了異地多活的夢想。那一年是最順利的一次雙11，系統和使用者體驗都沒有問題。但是在雙11的總結中我們發現了一個特別明顯的趨勢，就是無線的佔比越來高，雙11當天0點已經超過50%，如何在手機這麼小的螢幕上推薦給使用者他真正想要的商品也成為技術必須解決的難題。

2015年

2015年，第一次有了雙11晚會，晚會現場可以壓團隊，可以現場抽獎，技術部的同學實現了線上和線下的同期互動。效果超出期望的好，然後我們的客戶端註冊系統當場就被使用者的熱情打爆了，緊急擴容解決。

0點無線端導購的流量大大超過了我們的預期，而我們的物流系統和導購部署在同一批物理機之上，機器資源發生爭搶，有10%的物流機器被打死，無法響應，那麼落入這批機器的使用者就會購買失敗。在0點10分的時候，我們做了一個決策，直接剔除了這批死掉的機器，系統的成功率重新恢復到正常值。當時的決策有點風險，因為0點10分的時候流量依然很大，我們無法推測剔除這批機器的風險，那90%的機器如果扛住了，我們就成功了，如果扛不住，可能所有交易就會跌到零。我想一定是使用者的熱情創造了奇蹟。我們幸運地扛住了那個0點。

2015年我們在會場頁面實現了全面的個性化，每個使用者看到的會場推薦都帶入了自己的喜好和偏向，這一變化，讓無線的點選和購買率得到了大大的提升，也為下一年的全面個性化打下了基礎。

2016年

2016年開始，我們的全鏈路壓測加上了導購的流量，而且在2016年我們的導購峰值也從之前的10號10點轉移到了11號的0點，和交易的峰值完全重合，0點峰值的壓力進一步加大。

為了能快速釋放和節省雙11的成本，我們實現50%的雲化，在雙11之後一週內就將機器資源釋放出來，提升機器迴圈使用的效率。

我們手機客戶端自己做起了直播。晚上就可以在手淘和天貓客戶端一邊看晚會一邊參加抽獎和互動遊戲。

產品玩出了跨店的紅包和購物券，可是由於0點的限流產生，就發生了這些組合下單的商品一單被限流支付失敗的情況下其他一起下單的商品由於享受了組合的優惠所以也一起無法下單。雙11前一天已經評估出了這個風險，所以準備了一個後臺程式幫助回補沒有使用的紅包和購物券。可是由於流量的長時間的持續，限流時間超出預期，我們的後臺程式也在大壓力下掛掉了。技術的同學只能對後臺程式進行擴容，從準備的幾十臺機器擴充套件到幾百臺機器，終於在早上6點完成了紅包和購物券的回補。

2017年

2017年的零點是過往歷史上最順暢的一年，包括我們新上的混布系統都在零點很順利的扛過了我們零點的高峰。

可是一點預售付尾款的那一刻，我們卻發生一個功能的bug。飛豬預售訂單無法支付尾款，這也導致飛豬發出的很多紅包無法使用，從而大量的使用者開始投訴。無法回滾，因為回滾意味這很多功能要缺失，不敢切開關，不知切換開關之後對其他bu會不會有影響，我們只能小心地修改程式碼，重新測試上線，所以直到早上6點，這一問題才被解決。而導致這一bug的根本原因是11月8號晚上的一個緊急釋出引入的一個問題，由於太晚釋出沒有趕上功能迴歸的時間節點，於是遺漏到了線上。最終，變成2017年雙11的最大遺憾。

總結

2018的雙11越來越近，第十個雙11，一定要做到十全十美，以史為鏡，每一年的問題都不同，但是阿里的技術人絕不會讓同樣的錯誤重複兩次，我們一起加油！

關注「阿里技術」

把握前沿技術脈搏