簡介： 為什麼說雙11是阿里每年技術保障穩定性最困難的一次？50多個BU一起加入雙11，怎麼組織和運營？為了保障雙11的順利進行，又有哪些備戰方案以及創新技術？在由阿里雲CIO學院主辦的【2020中國企業數字創新峰會】上，阿里巴巴雙11技術大隊長、技術安全生產負責人、CTO線技術風險部資深總監陳琴（霜波）從組織和運作、備戰方案和技術、當天保障以及覆盤總結四個方面分享了阿里巴巴在雙11技術保障上的實踐經驗。
每年雙11都是一個比較艱難的專案。我現在的職位是阿里集團的技術風險負責人，所謂技術風險就是穩定性的保障是我這邊負責的。對阿里巴巴來說，對整個經濟體來說，每年技術風險最大的一次就是雙11。
為什麼說雙11是每年技術保障穩定性最困難的一次？每年雙11我們都會向大家分享交易額是多少，連續12年的數字大家可以在各種媒體看到。但是對技術來說，我們其實不看這個，我們看訂單建立的量，看訂單建立每秒多少QPS，就是每一秒有多少使用者請求進來。為什麼每年在雙11零點的時候都會有人被限流下單會失敗？進入量超過系統容量就會被限制住，第二次下單的時候大機率就會成功了。從下圖中可以看到，雙11的峰值這幾年每年都是幾萬幾萬的上漲，至少五萬五萬上漲。當一個非常大的流量到來的時候，對系統來說這是完全沒有經歷過的。所以當遇見一個不可確定的事情的時候，對技術的挑戰是最大的，這就是為什麼每年雙11都會有不少的同學出現各種各樣的問題。
2020年雙十一的峰值
對阿里來說，我們不管做一件什麼事情，第一先聊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，會有新的隊長，這個時候也有一個傳承，就是新人大促培訓營，一旦隊長確定了，大促培訓營所有的課程講師就會每年都上課，告訴大家應該要怎麼做，做好哪些系統和限流。
新人大促培訓營