如果你是雙十一技術負責人，你要怎么準備？
大家好，我是李哥。
進阿里以來一直聽說一句話：“沒有經過雙11峰值驗證過的技術都是玩具”。雖然有些夸張，但是不可否認的是，一年一度的雙11，是技術最好的孵化器，也是技術同學最向往的閱兵場。
我很榮幸，擔任今年年中大促的技術一號位，也就是技術負責人。今天就來跟大家聊一聊我們作為一名技術在大促中要去做哪些技術保障，以及如何去做。也希望大家看完，就像身臨其境的感受了一次大促。
我將故事分為三大部分：事前、事中、事后，最后我們再總結。
1.事前
KO會議
首先在事前，我們第一件事就是參加KO會議(Kick Off Meeting，項目啟動會)。
它主要會傳達以下幾個信息：
- 大促的背景與意義
- 大促的目的與目標
- 業務的具體玩法以及具體時間
- 大促的人員組織架構
也就是說，在這里，我們技術需要從中獲取如下信息：
- 業務預期DAU
- 業務預期DAT
- 具體有哪些活動玩法
- 活動玩法的具體時間段
- 哪些商品參與大促，是否有第三方商品
- 這些商品的庫存分別是多少
溝通
KO大會上，可能會是一個全局的，整體的，對于一些細節，下來我們需要與業務進行溝通，比如活動粒度是多少？宣傳力度是多少？業務的預期DAU與DAT如何評估的？是否準確？等。
這一步的目的是確認你的信息是無誤的，以及了解一些細節。
流量評估
你需要清晰的知道，當前階段每天的流量、DAU、DAT是多少，業務評估是多少，技術側評估又是多少，當前階段的性能是否能支撐即將來臨的大促，如果不能，需要做出什么調整。
- 優化？怎么優化？優化哪些業務？現在優化還來得及嗎？
- 擴容？擴容哪些服務？擴容到多少？為什么要擴容到這么多機器？
- 降級？什么業務降級？業務是否支持降級？什么時候降級？
這么多問題，看起來現在就需要對業務進行一次梳理了。
業務梳理
我們需要梳理出哪些業務是核心業務，哪些業務是非核心業務，哪些業務是可降級業務，這類數據大致可以從上一次大促獲取。
再加上上次大促到本次大促期間所產生的新項目(業務項目或技術項目)進行梳理，是否影響核心鏈路？是否進行了壓測？壓測結果如何？這些項目可能存在什么技術風險？
你的服務依賴哪些下游服務，這些下游服務又是如何依賴的，這是個很麻煩的事情，因為隨著業務變大，依賴關系會變得非常復雜，很難判斷與梳理。盡管很難，但是這個依賴關系仍然要梳理清楚，只有梳理清楚了，才有全鏈路。
壓測
有了業務梳理和業務指標，那么就在技術上要能夠支撐到這個業務級別，那就是壓測了。
到目前為止有兩種壓測方式：
- 不擴容壓測
- 擴容后壓測
不擴容壓測一般不推薦，這種方式需要對業務指標打折作為目標來進行壓測，最后在擴容的時候還是需要壓測一次，因為局部壓測不能完完全全代表整體壓測，如果整體壓測出現問題，那么所有的局部壓測都是白費苦工。
擴容壓測，就是指容量擴容到大促支撐位，然后進行壓測。
值得注意的是，壓測一定是針對生產！
有些同學對開發環境、測試環境、預發環境、灰度環境、仿真環境進行壓測，從而推斷出生產環境的性能。這是萬萬不可取的，因為環境不同，服務器的性能不一樣，生產環境和其他環境的DB性能也不一樣，還有一些中間件性能也不一樣。所以，壓測一定要在生產環境壓測，但是有一個缺點，就是會對線上的正常流量產生影響，這也是不可避免的，所以壓測的時候，一般都會選擇流量不大的時候進行，盡量減少對正常流量的影響，一旦產生影響，請立即停止壓測。
還有就是壓測需要流量爬坡，切記不可一步到位，按照一定比例逐漸施壓，每一個坡度都觀察幾分鐘，沒問題繼續施壓，達到目標后觀察幾分鐘沒問題直接停止壓測，不可戀戰！
為什么不戀戰？因為大促的流量趨勢就是那幾分鐘，長久的施壓對服務器的性能有一定影響，比如CPU飆高啊，頻繁GC啊等，所以在在壓測過程中還需要不斷觀察系統整體性能，還有就是也會影響到正常的用戶訪問。舉個例子，奧運會舉重，明明只需要保證舉起來三秒即可，你訓練的時候難道要舉起來三分鐘嗎？
對于壓測，我們后面再單獨拎一篇文章出來，這里就不過多講述了，敬請期待！
限流
壓測完了后，我們需要輸出一份壓測報告，比如商詳支持多少qps，下單頁支持多少qps，下單支持多少tps等。
這些數據說明了，我們的系統，有多少實例，哪個接口能承受的最大峰值是多少。那么我們就需要對這個接口或這些接口做限流。
這里我們說一下單機限流與集群限流，單機限流指的是每臺機器自身的限流，集群限流指的是整個服務集群的限流。
單機限流的目的是保護服務本身，保證自身服務不被流量擊垮。
集群限流的目的是保護下游服務，保證下游服務不被當前服務擊垮。
比如A->B->C，每個服務三臺實例，整個B集群最大能支持150qps，C集群最大能支持100qps，那也就是說B服務需要設置集群限流100qps用來保證C，B的三個實例需要設置單機限流50qps用來保證自身不被擊垮。
所以如果流量不傾斜的話，B服務每個實例會有33qps，如果傾斜的話，最大50qps。
我們回到大促限流，所以，我們需要拿著我們的壓測報告，針對我們的服務做單機限流與集群限流。
降級
限流后，我們能夠保證服務本身不被擊垮，保證下游不被擊垮，但是，這不是我們的目標，我們的目標是要保證大促期間商詳沒問題，下單支付沒問題呀！
所以，我們要降級，一些比較耗性能的業務降級，一些邊緣業務降級，給核心業務讓路。
然后就需要梳理這些業務，有哪些需要降級的業務？什么時候降級？由誰來降級？什么時候恢復等。
應急預案與演練
當我們保證了核心鏈路的正常后，我們還需要考慮異常的情況。對于電商系統來說，要考慮到整個生命周期異常的可能性，比如：打開商詳頁失敗、打開訂單渲染頁失敗、下單失敗、履約失敗等。說的都比較概括，我們當時準備了上千個預案！
淘系雙11大促，為了安全起見，是不會有任何依賴外部系統的，因為第三方系統都無法承受住淘系大促期間的流量波。
如果你的電商系統有依賴外部系統的，那么你還要梳理出哪些渠道哪些商品會參與本次大促，這塊也需要針對渠道做壓測與限流，有可能渠道由于體系較小不支持壓測，這時候你可能要考慮到在履約的時候做蓄洪與泄洪，使用真實流量來沖擊渠道，用于檢驗渠道的性能。另外在有第三方參與的情況下一定要有每個渠道的應急預案，對應給用戶展示的文案是什么都是不一樣的。
最重要的是要與合作伙伴共同制定一份SLA(Service Level Agreement)：服務級別協議，服務提供商和客戶之間的協議，用于確定所需的服務和預期的服務水平，對互聯網公司來說是網站服務可用性的保證。
在這里SLA約定了客戶對于合作伙伴的線上運維、計劃運維、業務連續性以及故障處理能?的要求。
做完預案后，要通過預案平臺進行演練，或者人工演練，要當做到熟能生巧，大促出問題后才會顯得臨危不亂。
監控
大促出問題？你怎么知道這塊出了問題？這時候需要監控，需要告警。
大促大盤監控、全鏈路監控、核心鏈路監控、壓測監控、限流監控、資源監控、網關監控、渠道履約監控......
規范
大促期間是需要制定很多規矩，比如發布紅線、紅線問責、預案執行規范、緊急擴容規范、緊急發布規范......，我們這里統稱大促變更規范吧。
無以規矩不成方圓，制定這些規范的目的是能讓我們明確問題發生后我們應該按照什么流程去應急。
其他
還有很多其他的一些雜七雜八的，比如大促前每周周會、大促值班人員排班、大促作戰室、問題的上升制度等。
到這里，我們萬事俱備，只欠東風了。
2.事中
事中是整個環節最簡單的，跨度最短的階段，但是簡單不代表不重要。主要是關注以下幾件事情：
- 大促的關鍵節行為節點記錄
- 大促問題記錄
- 重點關注告警與監控
- 出現問題按照預案與預案規范執行，按照問題升級規范升級
- 大促期間嚴格控制發布變更與數據變更，避免影響大促
- 大促日會
最重要的就是要持續關注告警與監控，一旦出現問題需要及時響應與止血，嚴格按照預案執行。另外就是關注大促每個場次的峰值情況，通過自動記錄或人工記錄的方式進行記錄峰值，方便作為下次流量評估的依據。
3.事后
事后我們最重要的就是要做大促復盤，盤點大促期間的一些好的點和不好的點，對于好的點如何延續到下次大促甚至更好，不好的點如何進行調整。業務上關注哪些商品在哪些區域更好賣一些，哪些玩法更能讓用戶接受一些；產品側需要關注配合業務對于現有的產品模型做出一些調整與優化；技術側重點關注性能，本次大促是否存在性能瓶頸，瓶頸在哪里，如何優化，架構上是否需要調整，下次大促如何去支撐等。
其次是降級恢復，在大促前做的降級，在大促后需要對其恢復。
我們還需要對于系統存在的性能問題進行持續優化改進，然后進行壓測，得出結論，再優化，再壓測，優化，壓測，......。
總結&展望
大促前：KO大會、大促周會、細節溝通、流量評估、業務梳理、壓測、限流、降級、預案、演練、監控、規范。
大促中：值班、記錄、關注告警與監控、執行預案、執行規范、日會。
大促后：復盤、降級恢復、持續優化、持續壓測、持續發布。
每到大促，如何保障系統高峰扛得住、長期平穩是每個大促人必須面對的問題。大促期間發生的每一個問題都可能被無限放大，所以我們需要謹慎對待，這開不得玩笑。
