阿里大促技術負責人：支撐雙11也就那麼一回事吧

　　進阿里以來一直聽說一句話：“沒有經過雙11峰值驗證過的技術都是玩具”。雖然有些誇張，但是不可否認的是，一年一度的雙11，是技術的孵化器，也是技術同學最嚮往的閱兵場。

　　我很榮幸，擔任今年年中大促的技術一號位，也就是技術負責人。今天就來跟大家聊一聊我們作為一名技術在大促中要去做哪些技術保障，以及如何去做。也希望大家看完，就像身臨其境的感受了一次大促。

　　我將故事分為三大部分：事前、事中、事後，最後我們再總結。　　

　　 事前

　　1、KO會議

　　首先在事前，我們第一件事就是參加KO會議（Kick Off Meeting，專案啟動會）。

　　它主要會傳達以下幾個資訊：

　　大促的背景與意義

　　大促的目的與目標

　　業務的具體玩法以及具體時間

　　大促的人員組織架構

　　也就是說，在這裡，我們技術需要從中獲取如下資訊：

　　業務預期DAU

　　業務預期DAT

　　具體有哪些活動玩法

　　活動玩法的具體時間段

　　哪些商品參與大促，是否有第三方商品

　　這些商品的庫存分別是多少

　　2、溝通

　　KO大會上，可能會是一個全域性的，整體的，對於一些細節，下來我們需要與業務進行溝通，比如活動粒度是多少？宣傳力度是多少？業務的預期DAU與DAT如何評估的？是否準確？等。

　　這一步的目的是確認你的資訊是無誤的，以及瞭解一些細節。

　　3、流量評估

　　你需要清晰的知道，當前階段每天的流量、DAU、DAT是多少，業務評估是多少，技術側評估又是多少，當前階段的效能是否能支撐即將來臨的大促，如果不能，需要做出什麼調整。

　　最佳化？怎麼最佳化？最佳化哪些業務？現在最佳化還來得及嗎？

　　擴容？擴容哪些服務？擴容到多少？為什麼要擴容到這麼多機器？

　　降級？什麼業務降級？業務是否支援降級？什麼時候降級？

　　這麼多問題，看起來現在就需要對業務進行一次梳理了。

　　4、業務梳理

　　我們需要梳理出哪些業務是核心業務，哪些業務是非核心業務，哪些業務是可降級業務，這類資料大致可以從上一次大促獲取。

　　再加上上次大促到本次大促期間所產生的新專案(業務專案或技術專案)進行梳理，是否影響核心鏈路？是否進行了壓測？壓測結果如何？這些專案可能存在什麼技術風險？

　　你的服務依賴哪些下游服務，這些下游服務又是如何依賴的，這是個很麻煩的事情，因為隨著業務變大，依賴關係會變得非常複雜，很難判斷與梳理。儘管很難，但是這個依賴關係仍然要梳理清楚，只有梳理清楚了，才有全鏈路。

　　5、壓測　　

　　有了業務梳理和業務指標，那麼就在技術上要能夠支撐到這個業務級別，那就是壓測了。

　　到目前為止有兩種壓測方式：

　　不擴容壓測

　　擴容後壓測

　　不擴容壓測一般不推薦，這種方式需要對業務指標打折作為目標來進行壓測，最後在擴容的時候還是需要壓測一次，因為區域性壓測不能完完全全代表整體壓測，如果整體壓測出現問題，那麼所有的區域性壓測都是白費苦工。

　　擴容壓測，就是指容量擴容到大促支撐位，然後進行壓測。

　　值得注意的是，壓測一定是針對生產！

　　有些同學對開發環境、測試環境、預發環境、灰度環境、模擬環境進行壓測，從而推斷出生產環境的效能。這是萬萬不可取的，因為環境不同，伺服器的效能不一樣，生產環境和其他環境的DB效能也不一樣，還有一些中介軟體效能也不一樣。所以，壓測一定要在生產環境壓測，但是有一個缺點，就是會對線上的正常流量產生影響，這也是不可避免的，所以壓測的時候，一般都會選擇流量不大的時候進行，儘量減少對正常流量的影響，一旦產生影響，請立即停止壓測。

　　還有就是壓測需要流量爬坡，切記不可一步到位，按照一定比例逐漸施壓，每一個坡度都觀察幾分鐘，沒問題繼續施壓，達到目標後觀察幾分鐘沒問題直接停止壓測，不可戀戰！

　　為什麼不戀戰？因為大促的流量趨勢就是那幾分鐘，長久的施壓對伺服器的效能有一定影響，比如CPU飆高啊，頻繁GC啊等，所以在在壓測過程中還需要不斷觀察系統整體效能，還有就是也會影響到正常的使用者訪問。舉個例子，奧運會舉重，明明只需要保證舉起來三秒即可，你訓練的時候難道要舉起來三分鐘嗎？

　　6、限流　　

　　壓測完了後，我們需要輸出一份壓測報告，比如商詳支援多少qps，下單頁支援多少qps，下單支援多少tps等。

　　這些資料說明了，我們的系統，有多少例項，哪個介面能承受的最大峰值是多少。那麼我們就需要對這個介面或這些介面做限流。　　

　　這裡我們說一下單機限流與叢集限流，單機限流指的是每臺機器自身的限流，叢集限流指的是整個服務叢集的限流。

　　單機限流的目的是保護服務本身，保證自身服務不被流量擊垮。

　　叢集限流的目的是保護下游服務，保證下游服務不被當前服務擊垮。

　　比如A->B->C，每個服務三臺例項，整個B叢集最大能支援150qps，C叢集最大能支援100qps，那也就是說B服務需要設定叢集限流100qps用來保證C，B的三個例項需要設定單機限流50qps用來保證自身不被擊垮。

　　所以如果流量不傾斜的話，B服務每個例項會有33qps，如果傾斜的話，最大50qps。

　　我們回到大促限流，所以，我們需要拿著我們的壓測報告，針對我們的服務做單機限流與叢集限流。

　　7、降級

　　限流後，我們能夠保證服務本身不被擊垮，保證下游不被擊垮，但是，這不是我們的目標，我們的目標是要保證大促期間商詳沒問題，下單支付沒問題呀！

　　所以，我們要降級，一些比較耗效能的業務降級，一些邊緣業務降級，給核心業務讓路。

　　然後就需要梳理這些業務，有哪些需要降級的業務？什麼時候降級？由誰來降級？什麼時候恢復等。

　　8、應急預案與演練　　

　　當我們保證了核心鏈路的正常後，我們還需要考慮異常的情況。對於電商系統來說，要考慮到整個生命週期異常的可能性，比如：開啟商詳頁失敗、開啟訂單渲染頁失敗、下單失敗、履約失敗等。說的都比較概括，我們當時準備了上千個預案！

　　淘系雙11大促，為了安全起見，是不會有任何依賴外部系統的，因為第三方系統都無法承受住淘系大促期間的流量波。

　　如果你的電商系統有依賴外部系統的，那麼你還要梳理出哪些渠道哪些商品會參與本次大促，這塊也需要針對渠道做壓測與限流，有可能渠道由於體系較小不支援壓測，這時候你可能要考慮到在履約的時候做蓄洪與洩洪，使用真實流量來衝擊渠道，用於檢驗渠道的效能。另外在有第三方參與的情況下一定要有每個渠道的應急預案，對應給使用者展示的文案是什麼都是不一樣的。

　　最重要的是要與合作伙伴共同制定一份SLA(Service Level Agreement)：服務級別協議，服務提供商和客戶之間的協議，用於確定所需的服務和預期的服務水平，對網際網路公司來說是網站服務可用性的保證。

　　在這裡SLA約定了客戶對於合作伙伴的線上運維、計劃運維、業務連續性以及故障處理能⼒的要求。

　　做完預案後，要透過預案平臺進行演練，或者人工演練，要當做到熟能生巧，大促出問題後才會顯得臨危不亂。　　

　　9、監控

　　大促出問題？你怎麼知道這塊出了問題？這時候需要監控，需要告警。

　　大促大盤監控、全鏈路監控、核心鏈路監控、壓測監控、限流監控、資源監控、閘道器監控、渠道履約監控......　　

　　10、規範

　　大促期間是需要制定很多規矩，比如釋出紅線、紅線問責、預案執行規範、緊急擴容規範、緊急釋出規範......，我們這裡統稱大促變更規範吧。

　　無以規矩不成方圓，制定這些規範的目的是能讓我們明確問題發生後我們應該按照什麼流程去應急。

　　11、其他

　　還有很多其他的一些雜七雜八的，比如大促前每週週會、大促值班人員排班、大促作戰室、問題的上升制度等。

　　到這裡，我們萬事俱備，只欠東風了。

　 　事中

　　事中是整個環節最簡單的，跨度最短的階段，但是簡單不代表不重要。主要是關注以下幾件事情：

　　商品大促時段、錢包大促時段時間點值班

　　大促的關鍵節行為節點記錄

　　大促問題記錄

　　重點關注告警與監控

　　出現問題按照預案與預案規範執行，按照問題升級規範升級

　　大促期間嚴格控制釋出變更與資料變更，避免影響大促

　　大促日會

　　最重要的就是要持續關注告警與監控，一旦出現問題需要及時響應與止血，嚴格按照預案執行。另外就是關注大促每個場次的峰值情況，透過自動記錄或人工記錄的方式進行記錄峰值，方便作為下次流量評估的依據。

　　 事後

　　事後我們最重要的就是要做大促覆盤，盤點大促期間的一些好的點和不好的點，對於好的點如何延續到下次大促甚至更好，不好的點如何進行調整。業務上關注哪些商品在哪些區域更好賣一些，哪些玩法更能讓使用者接受一些；產品側需要關注配合業務對於現有的產品模型做出一些調整與最佳化；技術側重點關注效能，本次大促是否存在效能瓶頸，瓶頸在哪裡，如何最佳化，架構上是否需要調整，下次大促如何去支撐等。

　　其次是降級恢復，在大促前做的降級，在大促後需要對其恢復。

　　我們還需要對於系統存在的效能問題進行持續最佳化改進，然後進行壓測，得出結論，再最佳化，再壓測，最佳化，壓測......　　

　　 總結&展望

　　大促前：KO大會、大促週會、細節溝通、流量評估、業務梳理、壓測、限流、降級、預案、演練、監控、規範。

　　大促中：值班、記錄、關注告警與監控、執行預案、執行規範、日會。

　　大促後：覆盤、降級恢復、持續最佳化、持續壓測、持續釋出。

　　每到大促，如何保障系統高峰扛得住、長期平穩是每個大促人必須面對的問題。大促期間發生的每一個問題都可能被無限放大，所以我們需要謹慎對待，這開不得玩笑。