推薦序

序一

2016年“天貓雙11全球狂歡節”又攀上了新的高峰——單日交易額定格在12。數字背後更重要的是，在五年、十年以後回過頭來看2016年的雙11，這是整個社會走向“新零售、新制造、新金融、新技術、新資源”的起點。

正是阿裡巴巴集團堅強的技術後盾，支撐起了全球範圍內都難得一見的龐大且復雜的交易體繫和交易規模。在2016年雙11當中，阿裡巴巴的技術團隊又創造出非常驚人的紀錄——每秒同時創建17.5萬筆訂單以及1秒鐘同時完成12萬筆支付。正是八年雙11的鍛煉，使得阿裡巴巴集團沉澱出了這樣的技術能力。

展望未來，雲計算、大數據將成為未來社會的新引擎和新能源。我們堅信數據將在商業變革中發揮重要的作用，整個商業變革一定會跟互聯網、跟技術去完美擁抱。我們堅信這樣的變革終會產生化學反應，產生全新的結合和全新的價值。而這樣的價值的創造，毫無疑問會讓社會商業出現很多新的模式、新的業態。阿裡巴巴集團希望通過各種方式，賦能給合作伙伴和客戶，並輸出成為商業社會的基礎設施，讓整個商業社會的變革更加高效、順暢。

《盡在雙11——阿裡巴巴技術演進與超越》以雙11為著眼點，從技術的角度，展示了阿裡巴巴的演進、變革與發展，繫統地闡述了阿裡巴巴重要階段的技術進步歷程。進無止境，我們希望將我們的經驗分享給更多人，並希望與大家一起共同探索未來。

張勇

阿裡巴巴集團CEO

序二

雙11誕生的2009年，恰逢中國互聯網第三年。大數據、雲計算、無線在這個時期逐漸成為主流技術。在雙11八年的發展歷程中，阿裡人從互聯網發展的大潮中汲取了豐富的技術能量。

作為雙11這個阿裡巴巴的集團級項目的技術負責人，這八年裡，如何在技術上持續創新、調動和提升工程師的工作效能、激發戰鬥意志和創造力是巨大的挑戰。從技術管理的角度上，我分享三點，與大家共勉。

，既要有夢想，又要有實力。如果沒有對夢想的堅持，以及對實現夢想的不懈努力，今天雙11很可能與一般的線上大促沒有什麼區別，更不會成為中國乃至全世界普遍關注的社會現像。阿裡巴巴是一家使命驅動的公司，雙11是阿裡人自主創新、追逐讓天下沒有難做的生意的夢想的具體體現。同時，實現這個夢想需要有強大的技術實力作為基礎。以計算為例，雙11有大量的計算，一切關於搜索、推薦、人工智能的“夢想”都需要計算平臺的強力支撐，阿裡巴巴如果不打破傳統Hadoop框架的藩籬，自研非常高效的離線和實時計算平臺，用戶在交易的過程中就不可能有“絲滑般的順暢感受”。

第二，鼓勵技術創新。沒有阿裡人在技術拓展商業邊界上持續的突破，就沒有雙11持續的成功。雙11當天交易峰值較平時增長400倍，平日運轉良好的繫統面對突發的業務流量，所有的問題都會被重新定義。全鏈路一體化方案通過逼真化模擬實際大促時的流量特點，以自動化的方式評估、優化和保護整個交易鏈條，確保了雙11的穩定性。全鏈路方案是阿裡工程師的創造，無論在國內還是國外，都是前所未有的。類似於全鏈路壓測這樣的技術創新在雙11中還有很多。

第三，協同的重要性。業務發展到一定階段都會遇到“飛機在全速飛行的前提下換引擎”的問題，是在現有框架下對兩個業務分別改造，還是推倒現有模式建立一個技術共享的新模式？這不僅是對架構能力的挑戰，更是對團隊的協同作戰能力的考驗。五彩石項目就是一個生動的例子。作為該項目的負責人，我親歷了將淘寶網和淘寶商城（後更名天貓商城）兩個繫統，在會員、商品、交易、店鋪、優惠積分等數據層面打通的全過程。五彩石項目是一次協同角度上的偉大的技術變革，提出了“共享服務化”的理念，為包括雙11在內的幾乎所有阿裡業務所采納，並與分布式中間件架構一起成為互聯網電商業務事實上的標準。

我推薦《盡在雙11——阿裡巴巴技術演進與超越》這本書，它是迄今為止對雙11技術演進客觀、詳實的還原。無論是互聯網工程師，還是商業領域的從業者，以及工程或商業專業的在讀學生，都可以從書中找到自己感興趣的內容。

後，在閱讀這本書的過程中，那些年、那些人、那些事兒重新回到眼前。謝謝所有參與《盡在雙11——阿裡巴巴技術演進與超越》撰寫的同學們，你們用另一種方式又走過了一遍雙11。

行癲

阿裡巴巴集團CTO

引言

不知不覺中雙11已經走過了八年，從剛開始的全新概念，到現在的舉世關注，有偶然也有幸運的成分，但是細細數下來，每一步，每一刻，都是好多人殫精竭慮、費盡心思的結果。對技術而言，每一年的雙11都是一場嚴峻的考驗，從被流量衝擊得潰不成軍，被迫奮起抗擊，到現在通過技術的力量不斷改寫雙11的用戶體驗和參與感，阿裡的技術伴隨著雙11成長起來，強壯起來，自信起來。

從組織上來說，雙11從年的突發奇想，野生無序，逐漸發展下來，已經成為一場整個阿裡及其生態聯動的戰役，雙11已經不僅僅是天貓的雙11，也不僅僅是阿裡所有事業單位的雙11，而是整個互聯網生態的雙11。

2009年我們技術部門隻有幾個人臨時安排值班，高峰每秒隻有400個請求，到2016年阿裡有23個事業單位、幾千位技術人員一起加入了雙11的備戰。杭州西溪園區1號樓的7樓、6樓和5樓都成為了雙11的集中作戰室，實現了每秒處理1.7萬條請求的技術奇跡。為雙11做出艱苦備戰的還有商家、銀行、物流公司，他們和我們一起迎接流量高峰的挑戰，一起為了互聯網更加完善的用戶體驗不斷努力和前進。

面對新的挑戰，我們從不敢放下的是對用戶的敬畏和感激之心，借由本書，借由雙11的歷史，將阿裡這些年在大流量管控上所做的技術創新共享給關注我們的朋友，並答謝所有雙11的貢獻者、參與者、傳播者、提及者和知曉者。

2009年：雙11誕生效果驚人

2009年是淘寶商城（淘寶商城：2008年4月成立，是一個高品質商品的綜合性購物網站。2012年1月11日上午，淘寶商城正式宣布更名為“天貓”。）成立的第二年，這一年的秋天，運營部門想搞一場營銷活動，逍遙子（逍遙子：現任阿裡巴巴集團首席執行官，同時是阿裡巴巴集團董事局董事。2008年逍遙子是淘寶網首席運營官兼淘寶商城總經理。）喜歡四個一，而11.11又是網民創造的“光棍節”，所以就選擇了這一天。誰也沒有想到，這樣一個帶著點隨意的選擇，竟然在若干年後成為影響中國乃至全球的大事件，造就了電商行業影響力的品牌——雙11。

屆雙11的活動口號是全場五折，拉了幾十個商戶參加，未曾想效果驚人，淘寶商城的成交額是平時的10倍。幸運的是，在2009年年初，五彩石項目將淘寶網和淘寶商城的繫統底層架構統一了。雖然淘寶商城的成交額增加10倍，但由於基數還比較小，這個成交額和淘寶網的日常成交額比起來並不大，因此繫統上雖然出現一些小問題，但是沒有產生特別大的影響。

盡管如此，暴增的流量還是讓工程師們措手不及。采訪當年屆雙11的工程師四虎（四虎：2007年加入阿裡，參加屆雙11的開發，連續參與雙11八年，現在是聚劃算技術負責人。）時，他回憶說：“年雙11，作為交易繫統的owner（所有者），接到老板指示，光棍節要搞個活動，你值一下班。那年我們啥都沒做，就坐在那看服務器的情況。零點一到，發現服務器流量暴增，一下子部分應用的服務器就掛了。我們就手忙腳亂地去重啟服務器，恢復繫統。應用繫統起來後，發現店鋪和商品圖片又出不來了。次雙11，可以說完全是意料之外，沒有做任何準備的，不僅把我們的交易和商品繫統壓掛了，同時還把很多商家的外部圖片空間也給壓掛了。服務器容量、網絡帶寬容量、繫統保護都是沒有的。”

2010年：搜索降級渡難關

吸取了上一年的經驗，2010年雙11之前，技術部門專門成立了大促小分隊，隊員包括各個核心繫統的開發人員和技術保障部軟硬件維護人員，當時還成立了大促指揮團，由振飛（現任阿裡首席風險官。2010年任技術保障部副總裁。）、周明（現任基礎架構事業群資 深 總監。2010年任技術保障部總監。）、範禹（現任天貓事業部技術部資深總監和研究員。）統一負責大促技術方案的相關決策。

負責保障穩定性的人員在指定地點集中辦公。那一年，高峰不在零點，而是出現在第二天白天，早上10點左右，CDN的容量很快達到上限，圖片展示越來越慢，眼看就要出不來了。大家緊張起來，激烈地討論還有什麼辦法。有人提出搜索的圖片展示占了很大的容量，可以將搜索的大圖降級為小圖。然後給搜索的負責人打電話，通知他：“對不起了，我們要對搜索的圖片降級了，雙11結束就給你們恢復過來。”這一招幫助當年的雙11渡過了容量的風險。之後，每一年的搜索大圖降級為小圖都成了雙11的降級方法之一，盡管後面再也沒有啟用過。同時，每一年雙11之前CDN都會開一個大會，讓所有業務評估自己雙11當天的CDN使用量，提前兩個月就開始做擴容的準備。“所有的苦難都是用來幫助我們成長的”，這句話用在雙11上特別合適。

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

2011年：匆忙中解決突發事件

2012年：繫統超賣了

2013年：有驚無險

2014年：順利的雙11

2015年：移動端購買率大大提升

2016年：實現雲化

（注：以上2011—2016年雙11的具體描述見書中的“引言”，這裡省略）

從2010年開始，為了雙11的順利進行，阿裡每年都會任命一個雙11技術部團長來整體負責雙11技術的穩定性工作。在團長之下，會成立一個大促小分隊，然後在各個事業群選撥合適的同學作為各個事業群的隊長。隊長在負責本BU技術工作的同時，還負責和其他BU進行聯動和消息共享溝通。隊長通過周會的形式來互報進度和風險。為了雙11當天的穩定，每年都會安排4至6次的功能回歸演習和全鏈路壓測驗證工作，這些工作會在幾十個事業群中同步進行。通常參加一次全鏈路壓測的技術人員都會在300人以上。

這麼多年雙11下來，有些人好奇：“做了這麼多年了，該準備的都準備好了，為什麼每次技術部還那麼緊張啊？”聽完了這些歷史，也許能有一絲明白，每年的雙11，我們的玩法都在變化，我們的流量不斷挑戰高峰，我們的技術也在效率和創新上實現著自我突破。雙11沒有一年不辛苦，沒有一年不緊張，沒有一年不需要加班熬夜通宵，沒有一年不是戰戰兢兢。有人在解決問題時一邊哭泣一邊寫代碼；有人在雙11結束的第二天就會去找主管“我明年再也不要干雙11了”；有人由於身體或者家庭的原因申請離開。但慶幸的是，每年都會有更多的人加入進來，帶著新的熱情和夢想，明知路難行，明知山有虎，但總需要有那樣一群人，咬著牙，紅著眼，在再大的壓力下，在再苦的環境下，在已經通宵神志不清的情況下，把問題一個個解決掉，然後笑著告訴大家：“今年我們一起又把雙11扛過去了。”

這是我們阿裡技術對所有用戶的態度，我們不完美，我們會犯錯，我們沒有提供給用戶好的體驗，我們很抱歉，我們會在深夜哭泣，哭泣我們不小心的遺憾，哭泣我們一個疏忽給用戶帶來的嚴重影響。但是我們在努力，我們在前進，我們在錯誤中不斷反思，繼而成長。感謝這些年用戶對我們的接納和信任，請相信我們在努力。也借這本書答謝所有參加過雙11的朋友們，謝謝你們對我們的信任，我們會帶著這份信任一路前行，讓中國互聯網的聲音響徹全世界。

2.2 全鏈路壓測，大促備戰的核武器

全鏈路壓測被譽為大促備戰的“核武器”。如果之前關注過阿裡雙11相關的技術總結，對全鏈路壓測一定不會陌生，這個詞的出場率幾乎是100%，從對雙11穩定性的價值來看，用“核武器”來形容全鏈路壓測毫不為過。

2.2.1 背景

歷年的雙11備戰過程中，的困難在於評估從用戶登錄到完成購買的整個鏈條中，核心頁面和交易支付的實際承載能力。自2009年次雙11以來，每年雙11的業務規模增長迅速，零點的峰值流量帶給我們的不確定性越來越大。2010年，我們上線了容量規劃平臺從單個點的維度解決了容量規劃的問題，然而在進行單點容量規劃的時候，有一個前提條件：下遊依賴的服務狀態是非常好的。實際情況並非如此，雙11 零點到來時，從CDN到接入層、前端應用、後端服務、緩存、存儲、中間件整個鏈路都面臨著巨大流量，這時應用的服務狀態除了受自身影響，還會受到環境影響，並且影響面會繼續傳遞到上遊，哪怕一個環節出現一點誤差，誤差在上下遊經過幾層累積後會造成什麼影響誰都無法確定。所以除了事先進行容量規劃，還需要建立起一套驗證機制，來驗證我們各個環節的準備都是符合預期的。驗證的方法就是讓事件提前發生，如果我們的繫統能夠提前經歷幾次雙11，容量的不確定性問題也就解決了。全鏈路壓測的誕生就解決了容量的確定性問題！

2.2.2 全鏈路壓測1.0從無到有

提前對雙11進行模擬聽起來就不簡單，畢竟雙11的規模和復雜性都是空前的，要將雙11提前模擬出來，難度可想而知：

• 跟雙11相關的業務繫統有上百個，並且牽涉整條鏈路上所有的基礎設施和中間件，如何確保壓測流量能夠通暢無阻，沒有死角？


• 壓測的數據怎麼構造（億萬級的商品和用戶），數據模型如何與雙11貼近？


• 全鏈路壓測直接在線上的真實環境進行雙11模擬，怎樣來保證對線上無影響？


• 雙11是一個上億用戶參與的盛大活動，所帶來的巨大流量要怎樣制作出來？

2013年8月中旬，當時高可用架構團隊的負責人叔同（叔同：高可用架構&運維產品&基礎產品團隊負責人、資深技術專家）接下了這個巨大的挑戰：打造一套全鏈路壓測平臺。平臺需要在2013年雙11之前上線，錯過了這個時間點，我們就必須再等一年。從立項到雙11，留給我們的時間隻有短短兩個多月，時間非常緊，我們需要在這麼短的時間裡應對一繫列歷史級的挑戰。2013年阿裡搬到西溪園區，其他同學都是搬到新工位，全鏈路壓測項目組直接搬到了項目室，進行閉關攻堅。

業務改造升級

2013年核心交易鏈路就有幾十條，牽涉多個BU的幾百位研發人員，這些業務鏈路絕大部分是沒法直接壓測的，需要進行相應的業務改造和中間件的升級。推動幾百號人在短時間之內完成業務的改造在很多公司幾乎是不可能完成的，何況還牽涉中間件的升級，中間件的升級一般會有一個相對比較長的周期，有不少業務繫統的中間件版本都非常古老（5年前的版本），需要確保無風險直接升級到版本。

在業務端我們需要逐條鏈路進行一一梳理，從請求進來的繫統到請求的後一個環節（復雜的業務會經過幾十個繫統），每一個有阻壓測流量往下走的地方都進行特殊的邏輯改造。改造的業務點牽涉100多個，包括登錄驗證碼、安全策略、業務流程校驗等。在基礎設施和中間件上，我們需要讓業務繫統的代碼盡可能不需要修改，通用的技術通過基礎設施和中間件來屏蔽掉，比如壓測流量的標識怎樣在整個請求的生命周期中一直流轉下去，怎樣來對非法的請求進行攔截處理。

參與全鏈路壓測改造的技術人員體現了良好的協作精神和執行力，為了同一個目標齊頭並進、相互補位，原本認為幾乎不可能的事情，終在一個月內完成了相應的業務改造和中間件升級。

數據構造

數據構造有兩個核心點：

• 雙11的買家、賣家、商品數量都非常龐大，需要構造同數量級的業務數據；


• 需要確保業務數據的模型盡可能貼近雙11零點的真實場景，否則全鏈路壓測結果的誤差會比較大，參考的價值將會大打。

為此我們專門搭建了全鏈路壓測的數據構造平臺，對業務模型進行繫統化的管理，同時完成海量業務數據的自動化構造，如圖2-5所示。

數據構造平臺以線上數據為基礎，借助數據dump（dump：在特定時刻，將儲存裝置或儲存裝置之某部分的內容記錄在另一儲存裝置中）工具進行數據的抽取，並對關鍵數據進行相應的處理（脫敏、訂正等）後進入基礎數據池備用。基礎數據池是壓測數據的超集，具體壓測數據的構造基於基礎數據集進行數據的再加工。

除了需要有足夠量級的數據，我們要解決的另一個問題是數據的模型應該是怎樣的。借助BI工具結合預測算法對數據進行篩選建模，並結合每一年雙11的業務玩法進行修訂，產出一份終的業務模型。業務模型的因子牽涉幾百個業務指標，包含買家數、買家類型、賣家數、賣家類型、優惠種類、優惠比例、購物車商品數、BC比例、移動PC比例、業務的量級等。

數據隔離

全鏈路壓測要不要做數據隔離、怎樣來做數據隔離，在項目立項階段經過了非常多的討論甚至爭吵。在開始的時候，我們想做邏輯隔離，直接把測試數據和正常數據寫到一起，通過特殊的標識區分開，這個方案很快就被放棄了：線上數據的安全性和完整性不能被破壞。接下來我們提出了另一個方案，在所有寫數據的地方做mock（mock：軟件開發概念，指模擬），並不真正寫進去，這個方案不會對線上產生污染，但評估時還是被放棄了：mock對壓測結果的準確性會產生干擾，而我們需要一個貼近實際行為的壓測結果。

經過反復討論，終我們找到了一個既不污染線上，又能保障壓測結果準確性的方案：在所有寫數據的地方對壓測流量進行識別，判斷一旦是壓測流量的寫，就寫到隔離的位置，包括存儲、緩存、搜索引擎等。

4. 流量構造

雙11是一場“剁手黨”的狂歡，零點的峰值流量是平時高峰的幾百倍，每秒幾百萬次的請求如何構造同樣成為大難題。我們嘗試通過瀏覽器引擎或者一些開源壓測工具的方式來模擬用戶請求，經過實際測試，要制作出雙11規模的用戶流量，瀏覽器引擎和開源壓測工具需要準備幾十萬臺服務器的規模，成本是無法接受的，並且在集群控制、請求定制上存在不少限制。既然沒有現成的工具可以使用，我們隻好選擇自己研發一套全鏈路壓測流量平臺，如圖2-6所示。

全鏈路壓測的流量平臺是一個典型的Master＋Slave結構：Master作為壓測管控臺管理著上千個Slave節點；Slave節點作為壓測引擎，負責具體的請求發送。Master作為整個壓測平臺的大腦，負責整個平臺的運轉控制、命令發送、數據收集、決策等。Slave節點部署在全球各地的CDN節點上，從而模擬從全球各地過來的用戶請求。整套全鏈路壓測的流量平臺在壓測過程中平穩輸出1000多萬/秒的用戶請求，同時保持過億的移動端用戶長連接。

正式上線

在兩個多月的時間裡，項目組的成員披星戴月，有一半時間在通宵，另外一半時間是凌晨3點以後下班。2013年10月17日凌晨的1號樓，全鏈路次登臺亮相（如圖2-7所示），這一天對整個全鏈路壓測項目組的人都意義非凡，辛苦了兩個多月的“大殺招”終於要派上用場了！當壓測開始的按鈕被按下去，大家都全神貫注地盯著各種繫統等著流量上來，1分鐘、2分鐘過去了，我們的業務繫統卻絲毫沒有流量進來。忙活了一晚上，次亮相狼狽收場，當時全場有200多號人，每一次讓大家準備好卻沒有流量發出去的時候，面對著全場200多雙眼睛，壓測項目組每一個成員的手都是抖的。好在次的失敗讓我們吸取了充分的經驗，又經過好幾個晝夜的奮戰，第二次的壓測比次進步了很多，到了第三次就已經能完全達到我們的使用預期了。

2.2.3 全鏈路壓測2.0平臺升級

全鏈路壓測誕生之後為繫統穩定性帶來的改變立竿見影，2013年經過了幾次全鏈路壓測，雙11零點的表現比以往任何一年都平順。全鏈路壓測也在阿裡一炮而紅，越來越多的業務希望能接入進來。

1. 平臺化

海量的業務接入給全鏈路壓測平臺帶來全新的挑戰：當時的全鏈路壓測操作都需要壓測項目組的成員來進行操控。隨著越來越多的業務接入全鏈路壓測平臺，壓測項目組很快就成了瓶頸，壓測平臺的能力急需升級。2015年，全鏈路壓測“平臺化”項目啟動，我們著手將全鏈路壓測朝著平臺化的目標推進和實施，做到壓測能力開放、業務方自主壓測，讓更多業務方能夠享受到全鏈路壓測的優勢和便利，如圖2-8所示。全鏈路壓測平臺化項目的上線大幅提升了全鏈路壓測平臺的服務能力：2015年大促備戰的3個月內，壓測平臺總共受理近600多個壓測需求（比2014年提升20倍），執行壓測任務3000多次（比2014年提升30倍）。

2. 日常化

全鏈路壓測的壓測流量和正式流量經過的路徑是一致的，如果鏈路中某一個節點被壓掛或者觸發限流，勢必會影響線上用戶的正常訪問。為了減少影響，全鏈路壓測一般都安排在凌晨，通宵達旦，非常辛苦！為了減少熬夜，提升壓測幸福度，我們啟動了白天壓測的項目：將線上運行的機器動態隔離出一部分放到隔離環境中，這部分機器上隻有壓測流量可以訪問，白天在隔離環境的機器上進行壓測。隔離環境與線上環境幾乎一樣，從流量入口、中間件、應用後端實現完整隔離。隔離環境完全打通了配置中心、服務注冊中心、消息中心、地址服務器等基礎設施，不需要業務繫統做任何改造即可完成。並且是直接從線上機器按照特定規則選擇到隔離環境中，機型配置跟線上基本一致，使用完畢之後直接恢復到線上集群中，不會影響線上集群的容量。大促備戰期間，我們可以白天在隔離環境中進行小目標、小範圍的全鏈路壓測，用極小的代價提前發現問題。由於隔離環境場景相對於其他線下環境更加真實、操作快捷、不占用額外機器資源，在預案演練、破壞性測試、線上問題排查、故障演練等其他場合也獲得了比較廣泛的應用。

2.2.4 全鏈路壓測3.0生態建設

2016年在三混合雲部署架構下，電商一半以上的資源部署在雲上。在龐大的電商繫統背景下，如何能夠在短的時間內完成的搭建和容量準備成為擺在我們面前的一道難題，而全靠“經驗之談”和人工介入是不可能完成的任務。2016年初，“大促容量彈性交付產品”立項，旨在減少甚至釋放活動場景的容量交付中的人工投入，並將大促容量交付的運維能力沉澱到繫統中，使全鏈路容量具備“自動化”調整的能力。我們提出了大促自動化備戰的想法，將大促容量準備的各個環節進行繫統層面的打通，從業務因子埋點、監控體繫、模型預測、壓測數據構造、壓測流量發送、壓測結果分析、壓測報表進行自動化串聯，大幅縮減了在大促容量準備階段的人員投入和時間周期。圍繞全鏈路壓測的核心基礎設施，全鏈路壓測的周邊生態逐步建立起來，打通建站、容量、監控等配套技術體繫，如圖2-9所示。

全鏈路壓測在保障繫統穩定性的同時，也為業務穩定性的保障提供了強有力的支持，2016年我們落地了全鏈路功能測試、大促功能預演等一繫列項目：創造性地在隔離環境提前將繫統時間設置到雙11的零點。通過在這個提前的雙11環境購買一遍雙11的商品，進行充分的業務驗證，限度地降低雙11當天的業務問題。

2.2.5 總結

每年雙11前夕，全鏈路壓測都要組織好幾次，不斷地通過壓測發現問題進行迭代優化，全方位驗證業務的穩定性，我們的業務繫統也隻有在經過了全鏈路壓測的驗證之後纔有信心迎接雙11零點的到來。全鏈路壓測將大促穩定性保障提升到新的高度，是雙11、雙12等大促備戰重要的“核武器”，並且隨著業務的發展不斷進化，持續發揮著不可替代的作用。