每年雙11都是一個比較艱難的項目。我現在的職位是阿裡集團的技術風險負責人，所謂技術風險就是穩定性的保障是我這邊負責的。對阿裡巴巴來說，對整個經濟體來說，每年技術風險最大的一次就是雙11。
為什麼說雙11是每年技術保障穩定性最困難的一次？每年雙11我們都會向大家分享交易額是多少，連續12年的數字大家可以在各種媒體看到。但是對技術來說，我們其實不看這個，我們看訂單建立的量，看訂單建立每秒多少QPS，就是每一秒有多少使用者請求進來。為什麼每年在雙11零點的時候都會有人被限流下單會失敗？進入量超過系統容量就會被限制住，第二次下單的時候大機率就會成功了。從下圖中可以看到，雙11的峰值這幾年每年都是幾萬幾萬的上漲，至少五萬五萬上漲。當一個非常大的流量到來的時候，對系統來說這是完全沒有經曆過的。是以當遇見一個不可确定的事情的時候，對技術的挑戰是最大的，這就是為什麼每年雙11都會有不少的同學出現各種各樣的問題。
2020年雙十一的峰值
以下是整個雙11的技術保障目标：
對阿裡來說，我們不管做一件什麼事情，第一先聊KPI，有了KPI之後才知道目标，才可以拆解，每個BU要幹什麼都是按照KPI分解的。這麼多年來第一項KPI一直都是如此，交易限流在多少，我承諾給業務，能夠保證每秒鐘進來這麼多使用者，但是如果當天的使用者超過這個承諾，其他的使用者需要二次下單，一次下單會被限制住，這是第一個承諾。
第二個承諾就是穩定性。對所有穩定性的衡量都是一個，叫故障數。故障對應的就是使用者體驗和使用者期望的差距，差距越大，比如使用者的投訴量到達多少，一般四個使用者投訴就計為故障。我們要求不能夠發生任何系統問題。
第三個承諾就是，要求全過程使用者的體驗是流暢的。很多使用者第一次下單雖然失敗，但是第二次你進入限流範圍之内，我們要保證你的整個支付行為是沒有任何差錯的，尤其是金額絕對不能有任何問題。
最後一個，全鍊路壓測百分之百驗收成功，這是這兩年加上去的目标。
對于雙11這麼大的項目，尤其對阿裡經濟體來說，一共有50多個BU一起加入雙11，首先要考慮怎麼組織和營運。第二，備戰方案還有一些技術的創新，最核心的就是讓我這個隊長放心，說這件事情真的已經成功了，如果沒有技術方案保證，每次都是靠人的承諾其實是不靠譜的。第三，雙11當天，52個BU同時迎接這個流量高峰的時候，哪裡出現了問題，哪裡需要去協調，哪裡需要去擴容，當天的保障方案。最後還有多年雙11這些經驗是怎麼傳承下來的，這是今天要分享的四個環節。
一 組織和運作
每年雙11都會成立一個集團技術大促小分隊。對阿裡巴巴經濟體來說，是一個很大很大的BG，在下面會有很多很多BU。每個技術部門歸屬是不同的BU，但是雙11今年是52個BU共同參加，這些BU怎麼協同起來，每個時間點怎麼把它整體運作起來，這裡的組織方式首先會有一個技術團長，會任命出來，在團長之後會有大隊長的角色，過去幾年我都是技術大隊長的角色，技術大隊長之後就是每個BU都會有一個技術隊長，技術隊長之下每個BU的人員都會固定下來加入這個BU的隊長。
集團技術大促小分隊：52個BU
在此之後，我們就開始整體的運作。從7月份的時候就要開始方案尤其是PRD今年采取什麼樣的營銷玩法，哪些BU參加，參加的時間點，比如今年要做雙波動，8月的時候可能就要開始決定雙波動怎麼做，怎麼通知到商家，怎麼通知到使用者，是以7月、8月就結束了。8到9月是集中開發上線的環節，會有技術備戰的彙報，同時這裡都是用雙周會的形式運作，到10月的時候就會有作戰手冊的彙報。作戰手冊也是很關鍵的環節，每年雙11等到10号的時候，我們會做很多之前的預操作，因為為了應付零點，我們會有很多其他的功能的降級，機器的協調，所有的預熱，這些情況都是在頭兩天必須完成的，這裡甚至一個降級開關如果沒有成功，有可能當天的雙11就會面對很大的風險。今年我們提前降級的開關有兩千多個，如何保證全部都是降級成功，不能夠出一點問題，基本上是每個降級開關執行最後都有人驗證。我是2008年加入的阿裡，是廣告技術部的品質負責人，2012年的時候收到組織調動，去做天貓品質負責人，調動的時候大概是6月份，完全不知道，為什麼突然之間組織調動了。
2020雙11技術隊長溝通節奏
二 備戰方案和技術
我們一直以為商家想要的一定是給我更多的流量，讓我賣更多的貨，賺更多的錢，這應該是商家的選擇。但是2011年，90%的商家在填問卷調查的時候，選擇的是系統穩定。有一個商家解釋了為什麼會選擇系統穩定。他說2011年我參加雙11，零點的時候收到天貓的電話，告訴我所有的商品下架，當時全部公司的員工都在值班，聽從你們的話把商品下架，一直等到早上6:30，沒有一個人敢回家，因為回家之後對家裡人說的一句話就是我的公司要破産了。每年大家為了雙11商家特别辛苦，要準備平時十幾倍的量，之前要做大量采購、庫存，如果這些在雙11當天賣不出去，對商家來說是風險很大的一件事情。直到早上6:30的時候，接到天貓的通知說你們現在可以重新上架。是以聽到這個故事的時候，我心裡确實壓力很大。
這些年，平台的穩定性已經變成了商家對我們的一個基本要求，如果平台不行的話對商家的影響是非常大。我回去之後想了解為什麼在2011年的時候會出現這樣的情況，必須在零點的時候通知商品下架，後來知道了那一年出現了一個功能性的錯誤。雖然之前我們做了很多的驗證操作，但是在那天晚上8點的時候，收到商家回報，說他把折扣填錯了。折扣是這樣的，報名參加了幾折，3折就填3，但是有商家填成了0.3，這個時候系統×0.03，他就會賣虧。我們當時一聽說就擔心很多商家會發生這樣的情況，就做了一個決策，把所有的商品的屬性導了出來，低于1折的商品恢複到原價，然後再寫進系統裡去。這個寫進系統的所有的商品的庫存，寫進去的時候漏了一個參數，把SKU弄沒了，那個SKU比如說是衣服的話，就是大小、顔色都沒有了，全部寫成空。是以那一年零點的時候商家告訴我，我貨賣出去了，但是我不知道賣的什麼大小，如果發不出去貨天貓又是30%的賠付，是以最後集體包括業務和技術再一次做決策，把所有SKU的商品全部下架。我們修了很久，修到早上6點半。那個時候量很大，白天雖然晚了6個小時，但是白天還賣的可以，最後商家的反彈不是很大。聽到這個時候，我就覺得系統保障一定要做好，再也不能出現這種功能性的BUG。
到了2012年的時候，其實我做了特别多的工作，就是所有的功能測試下單有沒有SKU肯定要一個個驗證，價格不能出錯。我還做了很多的預案，防止一旦容量過大的時候，我們有哪些降級方案。還做了性能測試，但是性能測試那個時候都是叫縮容測試，縮容測試就是比如線上是400台機器在扛一個系統，它的QPS是4，用線下4台機器搭一個環境，看看上市之後能不能成功。基本上那個時候品質團隊能夠用的方法全部用了，當時的天貓技術負責人每天問我，因為大家都特别緊張，我就告訴他不會有問題了，功能測試我都是自己一個一個去驗證的，保證不會有問題。
2012年，當時系統成功率隻有50%，也就是說一個使用者進來有50%的機率是要失敗的，一直持續了一個小時之後，系統成功率才慢慢回來。我當時作為品質負責人看到各種各樣的錯誤頁面，浏覽的時候就失敗了，确認訂單失敗了，下單失敗了，支付失敗了，那是我看到的最多的一次錯誤頁面，各種各樣的錯誤頁面。回去之後其實就複盤，我們就在想确定究竟哪裡出了問題，最後是網卡被打滿，商品中心是IC，商品中心網卡被打滿，網卡是50%被打滿，導緻50%的使用者下單失敗，但是商品中心是一個特别核心的系統，因為你浏覽的時候要調商品，下單都要調商品，都要去商品中心确認一下，一旦網卡被打滿的情況下就會出現這種情況。
複盤的時候大家心情都很沉重，為什麼沉重？當時我們就想，針對這個問題我們明年有什麼樣的解法？當時在技術上沒有一個好的解法，因為我們所有的壓測，是縮容壓測，可以把機器縮10倍，可以線上下去搭。但是我的網卡能不能縮？網卡就是千兆網卡，是以這個情況下怎麼辦呢，那個時候複盤的時候提出一個方案，我們必須到線上做真實的全鍊路壓測，不能在下面搭一個測試環境壓，必須到線上把所有的容量模拟雙11的峰值直接壓上去，這是當時提出來的方案。
這個方案提出來容易，但是實作是很難的。很多東西之是以前人沒有做隻有一個原因，就是太難了。為什麼不敢做呢，很簡單，因為線上壓測的時候都是測試資料，測試資料一寫到線上的生長庫，使用者的資料馬上就會被污染掉。是以那一年第一個退出這個項目的是支付寶，支付寶的同學跟我們說，如果使用者發現他的錢出錯了，多了幾個0，影響面太大了。2012年的複盤會議上，人就分了兩派，一派這個太難了，線上做不出來。還有一派人，沒有辦法做不出來也得做。作為隊長，實際上這個時候是沒有退路的，因為我心裡很清楚，用原來的方法是不可能保障雙11系統穩定性的，是以在第二年一直讨論方案，讨論方案的時候提出來，為了不影響線上的使用者，我們再做一套資料庫。方案想出來了就要開始實行，實行的時候改造量是非常大的。因為從剛開始的CR系統，到後面所有的應用系統，每個應用系統都必須加一個測試标，必須要判斷一下什麼是測試标，什麼是真實流量。還有中間件，中間件全部要進行改造，底層還有資料庫，阿裡所有核心系統全部要針對全鍊路壓測做改造，幾千個應用系統，幾十個中間件，現在是幾十萬的資料庫全部進行改造，工作量是非常大的。但是當時既然成立了這個團隊，從6月份的時候就開始做，一直做到10月第一周，距離雙11隻差一個月，到了10月第一周的時候我們還沒有壓測上去一次。
真實的壓測是一個脈沖上去然後看系統的情況，但是到十月第一周的時候還沒有成功一次。所有的隊長在一起，各個BU的隊長也加入進來讨論，這個時候應該做一個什麼樣的決策。有一部分同學就提出來，說這個時候我們應該趕快回到老的方法，就是原來的縮容壓測。當時我是第二派，這個時候兵分兩路，一些人做線下，一些人做線上。我還記得很清楚，那個時候是天貓的技術隊長叫南天，他當時拍着桌子非常強硬地說我們線上全鍊路壓測隻許成功，不許失敗，雖然我們當時分了三派，但是大家開會的時候一般誰勝出？誰說話聲音最大誰就赢，他當時真的是拍着桌，隻差站在桌子上，要求每個BU的核心系統再投入一個同學加入壓測團隊，因為他特别強勢，大家都被他吓着了，趕快交人。幾十個同學就加入了，原來就是十幾個同學，現在一下子幾十個同學加入，一周之後全鍊路壓測成功了，那一年線上全鍊路壓測最後發現的BUG有六百多個。
是以通過這全鍊路的壓測學會一個問題，就是真正的創新其實就像我們長跑一樣，剛開始的時候會覺得特别難，做到中期的時候發現更難，但是一定要相信自己可以成功，在最後的時候不放棄，總會有跑到的那一天，所有的創新基本都是這樣來的。
可以看到這就是2011年系統功能BUG，通知商家下架，2012年雙11有了預演，2016年把預演變成了系統，2012年成功率低于50%，2013年誕生了交易全鍊路線上壓測。2014年的時候這個量更大了，大到杭州機房，一個機房已經裝不下這麼多機器，這個時候就必須開始分機房，但是分機房的問題是，使用者如果在不同的機房，延遲是很大的。這個時候我們就做了異地雙活，有一個用處，當出現問題的時候，杭州的機房出現問題，比如說斷網立刻可以切到另外一個機房，但是這個時候對系統同樣有要求，必須是單元封閉，保證所有的使用者在一個機房之内運作。
接下來，等到2013年、2014年，我們叫穩定性的兩年。到了2015年、2016年我們又出現問題了。當時做了所有的線上交易全鍊路的壓測，但是2015年出現了一個很大的變化，就是雙11的時候，有50%的使用者從以前的PC全部轉到了手機，2016年90%的使用者全部到了手機端。這是使用者行為的變化，是我們始料未及的，剛開始的時候更多是關注PC端，手機那邊的流量猛增超出預期，導緻出現了問題。
2016年是自己系統出現了問題，這個問題就是一個冷庫和熱庫。那時候我也是技術隊長，我發現這兩個曲線挺好的，但是對比2014年這兩個曲線爬坡爬得特别慢，什麼原因呢，頭兩年的時候我們沒有看，2016年的時候就變成下滑的一個坑，一分鐘一個坑慢慢下去。為什麼會慢慢爬，就是一個程式的問題，程式有預熱，剛剛上線的時候本身預熱是不夠的，當到了一個大流量的時候，熱了，對資料庫來說也是的。當你去調用它的時候，如果它的資料是熱的，會提前寫到緩存馬上能夠讀，但是如果冷存就要調用所有的資料庫。為什麼有全鍊路壓測還會出現這些問題，全鍊路壓測每次的資料都是一批的資料，之前就已經是熱的資料。這就是為什麼在2016年的時候頭2分鐘下去然後自己會起來，是一個冷庫下去了，但是當熱起來的時候自己又會爬起來，系統不做任何的操作。2017年就做了預熱平台，2017年的時候取得了非常好的效果。
這是雙11的一些故事。等到2018年的時候又出現了一個問題，我們那年的KPI沒有完成，因為2018年的時候修改收貨位址出了問題，系統直接挂了，就是寄到預設位址，不能改變位址，很多同學把大米寄到了廠房，原因也很簡單，當你忽視任何一個系統壓力測試的時候，一個系統沒測試到，風險其實就會特别大。
但是2019年、2020年這兩年還是比較穩定的，是以今年大家可以體驗一下，今年是這麼多年來限流最少，使用者體驗最好的一次。
下圖就是我們當時做線上全鍊路壓測的照片，每次都是幾百号技術在一個房間裡面，一旦哪個系統有問題，大家就叫一下什麼系統出問題，壓的時候大家也還比較緊張，因為随着峰值越來越上去的時候，我們特别想看到究竟是哪個系統第一個挂掉，大家就想着我不要做第一個挂掉的系統。
全鍊路壓測
整體上來說，第一要改造的就是施壓的來源，現在施壓來源為了真實的模拟線上，采用的CDN在全國兩千多個節點的機器，如果是在一個機房施壓，是模拟不了那麼多場地的，包括我的網絡來源，但是現在CDN在全國都有部署，來源比較準确。然後是模型的預測，基本上所有的線上使用者去取出來，還有流量的隔離，就是我的流量如何保證是進入線上影子庫的，最後是線上真實的施壓。
這是整體的全鍊路壓測的架構圖。下面就是我們模型資料，比較核心的就是模型一定要準确，到現在為止，如果壓測和真實出了問題基本就是模型出了問題，比如說優惠券有多少，使用者買的商品，一個商品有多少下單。
全鍊路壓測的架構圖
下圖是全鍊路壓測在第一年發現的各種性能問題，這些問題線上下壓測很難發現。第一是硬體問題。因為線上下那4台機器大機率是最新的機器，但是線上有些老舊的網卡和機器，還有小記憶體和中間件的問題，基礎服務比如系統大規模釋出在那天會出現問題，還有限流。雖然前面說限制了60萬的數值，但是這個限流隻要調一次就有可能是不對的，你怎麼保證是對的？還有容量的問題，領取的容量不夠，包括業務系統，業務系統逾時的時候，在上下遊逾時情況下，會出現哪些問題，都隻有在全鍊路壓測的時候才能夠發現。
全鍊路壓測發現的問題
第二個技術是全鍊路功能。這個更晚一些，它的特點就是在做壓測的時候不能驗證一樣東西，使用者下單是不是成功，隻能驗證容量是夠的。那個時候很多人回報我從購物車選擇全選一鍵下單是很難成功的，甚至有人得出來雙11零點搶貨的攻略，就是一件一件下單成功率比較高，如果包含很多訂單，隻要一筆訂單失敗，全部的訂單都會失敗，确實會有一部分訂單會失敗。怎麼樣保證雙11當天所有的訂單下單都是成功的呢？這裡就提出了全鍊路的功能。全鍊路功能是，在大家下單之前基本上會把在購物車裡面的商品，所有的提前下單，就是全鍊路的功能。其實訂單已經被系統下單過一次，确定這些訂單下單的時候都是成功的。在下單的時候就要檢測使用者的優惠券有沒有正确使用，最後的支付有沒有成功。其實就是靠一個線上的環境，第一是在隔離的環境，第二是線上全量的資料，幾千萬的商品、幾千萬的使用者，基于線上的模型，所有的時間會放在11月11号，因為所有的優惠都是11号生效，一旦改了時間，這些優惠才能夠使用，這是功能的圖表。下面是資料的轉換，上面是測試運力的生成，下面是分析，就是每筆訂單産生止損，下單的金額和預想的金額是否一緻，全部在這裡檢測出來，這就是全鍊路的功能。
全鍊路功能
應對這種大促，我們怎麼樣做好穩定性的保障？其實對于系統來說，最高危的問題都是變更導緻的，但是雙11那一天，我們是不能夠允許出現一點點錯誤，這個時候就會提前封網，封網最早的時候隻做應用類的封網，把釋出系統封了。但是底層更慘，現在底層在雲産品上，從第一層基礎設施開始，第二層雲産品，計算、存儲、網絡、排程、資料庫、中間件，一層一層全部有一個集中的管控，這樣能夠保證雙11當天，之前所有測試驗證過的結果和當天是一樣的。
封網管控
攻防演練是這樣的，我們其實很擔心雙11當天會不會出現什麼問題，出現問題之後，我們能夠做什麼？是以在這之前就要模拟各種會出現的問題，包括網絡掉電、伺服器硬體設施故障等。在這種情況之下，我們能夠做什麼？是以對于攻防演練來說，就是曆史所有的故障隻要發生過高可用故障都會記錄下來，接下來進行模拟，當再發生這個問題的時候我們能否快速恢複。給所有經濟體提的一個目标，叫做：1、5、10，要保證所有的系統10分鐘之内恢複，如果不能恢複這個系統要進行改造，所有的故障近期都有突襲，現在所有的系統都是在阿裡雲之上，阿裡雲的斷電斷網，最多模拟800台容器同時斷掉，還有機房整體挂掉的模拟，我是怎麼樣逃逸的，通過這場逃逸才能夠讓這個機房真正使用起來。隻有這些突襲和演練才能夠把這個系統出現故障的時候能夠快速恢複。
突襲與演練 – 紅藍軍
三 當天保障
雙11當天資訊會特别多，有很多人問我，雙11當天釘釘是不是會爆掉？确實，雙11當天釘釘肯定是爆掉的，每個BU所有的操作所有的變更同一時間去了解，還要了解系統的情況。雙11當天怎麼組織所有的問題的收集？第一就是前線，前線就是問題的來源，CCO會收錄所有客戶回報的問題，如果是技術問題就計入雲頂，雲頂就是大促指揮台，雲頂會自動同步，一旦計入雲頂的問題，根據涉及是哪一個BU，自動拉群，BU情報員和通信員會馬上處理相關的問題。還有重大故障，一旦到P2以上就是重大故障，隊長優先級第一處理所有的重大的故障，在重大故障裡面做所有的決策。BU的值班人還有應急協同群，還有進階情報員，覺得涉及比較大的風險，就直接到指揮部，指揮部一般會給出最終的決策，比如說這個項目你要不要修複，還是輿情上怎麼處理，商家怎麼通知等等，這些所有的應急通信全部是在這一個系統上做出來的。
雙11應急協同流程
下圖是我們穩助大促一系列營運序列。大家可以看到從最早的要點提醒到作戰手冊，這是各種專項，突破演練，破壞性的報告，雲頂怎麼樣使用，全部通過直播的方式進行開課，所有技術同學能夠知道雙11當天我們要處理什麼樣的流程。
穩助大促系列營運
四 複盤總結
對雙11來說，每年都有新的BU加入。前幾年的時候我們就發現，每年出現的新故障總是在新加入的BU裡面，之前的經驗沒有傳承下來。是以在複盤和總結的時候，我們也做了一個系統，叫大促指揮台，這裡面會列出各個BU每年每次活動所有的複盤報告，大家如果想知道去年是怎麼做的，發生了哪些問題，在這裡面全部都能找到。
針對每年的大促，比如618、雙11，會有新的隊長，這個時候也有一個傳承，就是新人大促教育訓練營，一旦隊長确定了，大促教育訓練營所有的課程講師就會每年都上課，告訴大家應該要怎麼做，做好哪些系統和限流。