前言
前面的幾篇文章從生產全鏈路壓測的定義，內部立項和技術調研，聊到了測試驗證以及全鏈路壓測的對企業業務和技術團隊的價值，算是整體上的構建一個認知的概念。
從這篇文章開始，會進入具體的落地實踐環節。這篇文章中，我會介紹生產全鏈路壓測的落地實施全流程，即每個環節要做什麼事情。
四大階段
如果將生產全鏈路壓測作為一個階段性的技術專案來看，全鏈路壓測從開始到專案結束，需要經過四個階段。
整體的實施流程圖如下所示：
接下來我來為大家解密，生產全鏈路壓測落地實施，在不同的階段都會做哪些事情。
籌備階段
確定業務範圍
一般來說線上實施線上全鏈路壓測之前，要明確本次壓測需要驗證的業務範圍。
核心業務定義
- 出問題會影響其他業務鏈路；
- 流量較高且出現問題會影響整體業務目標的達成；
核心專案定義
前面提到了生產全鏈路壓測是個複雜的技術專案，那麼如何定義這種技術專案呢？
- 大型業務活動有關的專案，如電商雙11大促；
- 影響業務目標達成的專案，如電商每年的各種購物節；
- 風險相對可控的核心專案，一般核心業務穩定性要求更高；
注意事項
按照5W+1H原則進行梳理，交付的checklist一定要準時明確；
儘量不要在大型業務活動前進行大量變更，如有需要明確變更的範圍和風險；
明確業務目標
確認業務範圍後，接下來就是明確業務的目標。常見的業務目標，包含哪些資訊呢？以電商的大促舉例：
- 單日GMV/DAU、客單價；
- 支付訂單量、訂單履約率；
- 使用者復購率、推薦準確率；
轉化技術指標
明確業務目標後，接下來就是要將其轉化為技術指標，這是個很吃技術設施建設以及經驗的活兒。下面是一個例子：
以上述的GMV和客單價為例，假設：
- 客單價為500，單日GMV為10億，那麼支付訂單量為10億/500=200W；
- 假設日常支付訂單量為50W，支付轉化率為40%，訂單支付QPS峰值為200。預估大促時的支付轉化率為60%，則可得：大促峰值訂單支付QPS為（200/40%）*60%*（200W/50W）=1200QPS。這個1200QPS是個保底數值，一般為了留有一定冗餘空間，會上浮30%，即訂單支付的QPS預估為1500；
- 電商的導購瀏覽下單支付轉化鏈路一般為：首頁→商品詳情→建立訂單→訂單支付→支付成功，這個過程是類似漏斗的一個轉化邏輯。假設首頁→商品詳情轉化率為40%，商品詳情→建立訂單轉化率為40%，建立訂單→訂單支付轉化率為40%，那麼可得：建立訂單QPS為1500/40%=3750，商品詳情QPS為3750/40%=9375，首頁QPS為9375/40%=23437；
所以，你學廢了麼？這裡只是舉個例子，大家在實踐中可以按照具體的情況進行轉化計算，案例僅供參考。
任務拆解&組建團隊
這裡是2部分的內容：任務拆解和組建團隊。
任務拆解
任務拆解即將下述備戰階段的各個一級目標，拆解為多個更詳細的二級甚至三級任務，並且對應到人和時間。
組建團隊
一般來說，這種複雜的大型技術專案，建議組建一個臨時的虛擬技術保障團隊，涉及到的每個團隊指定對應的owner來負責，做到事和人有一一對照的關係，這樣才能更好的保障業務目標達成。
大促保障kickoff
kickoff即舉行一個啟動會，一般會由這個專案的總負責人對專案的關鍵目標和指標進行介紹，虛擬技術保障團隊的構成，以及拆解到每個owner身上的任務，做到資訊同步，便於後續的任務開展。
kickoff有四大關鍵要素，分別是：
組建技術團隊
- 專案管理團隊：一般是由專案負責人和PMO團隊構成；
- 任務執行團隊：各個任務的owner以及各團隊的核心成員；
- 後勤保障團隊：IT、行政都部門負責網路、飲料零食、加班叫車等後勤事宜；
明確關鍵目標
- 大促業務目標
- 大促技術指標
- 關鍵里程碑節點
合理拆分指標
- 備戰階段目標
- 作戰階段目標
- 覆盤階段目標
定義關鍵機制
- 資訊同步機制：複雜的技術專案，資訊同步的效率和一致性很重要；
- 團隊協作機制：拆解出來的任務，很多需要多團隊協同配合，因此需要制定合理的合作機制；
- 緊急事件處理機制：如線上緊急變更、緊急釋出、目標變更等都需要有對應的應對策略，否則容易手忙腳亂；
備戰階段
核心鏈路梳理
核心鏈路梳理主要是做下面幾件事：
- 根據業務範圍確認應用範圍；
- 根據應用範圍和訪問量確認核心鏈路；
- 根據核心鏈路和監控確認流量轉化的漏斗模型；
- 根據核心鏈路梳理不同應用和介面之間的強弱依賴；
- 根據強弱依賴制定大促時候的各種技術預案和應急處理手冊；
線上容量評估
容量評估需要考慮如下幾點因素：
- 當前線上的流量和資源的使用率；
- 按照預估的技術指標提前預購準備相應的資源；
基礎準備工作
基礎準備工作，無非就是下面幾件事：
- 環境準備：包括生產環境的改造、影子庫表等準備；
- 資料準備：包含基礎鋪底資料、測試資料、預熱資料；
- 指令碼準備：包括壓測指令碼、任務更新指令碼、一些運維的ansible指令碼；
技術業務優化
常見的優化項如下：
- 大促作戰的監控大屏，包含技術和業務監控；
- 服務保護措施如限流、降級、熔斷、災備等；
- 資損防護處理，如異常流量、異常支付、輿情風控等；
技術方案評審
這裡的方案主要包含2類：
壓測方案：即本次大促或者技術專案的整體壓測方案；
大促預案：包含前置的主動預案、業務活動的緊急預案以及容災恢復預案。其主要構成分別是：
- 前置主動預案：限流、降級、熔斷、隔離；
- 活動緊急預案：業務（活動入口關閉/防資損）、技術（服務當機/CPU使用率過高/磁碟空間不足）；
- 容災恢復預案：緊急擴容、機房斷電處理、斷網備份方案；
封版&線上預熱
這一階段，主要進行下述的幾件事：
- 大促封版：即如非必要，禁止線上釋出變更，必須釋出走審批流程，確保活動期間的線上穩定性；
- 流控檢查：相關同學針對各個應用核心鏈路和介面及外部互動等流量出入口進行查驗，避免出現異常情況；
- 許可權檢查：針對服務保護及其他相關穩定性系統的許可權，授權給相關人員，便於活動期間及時排查解決問題；
- 系統巡檢：針對系統執行狀態、資源使用率等情況進行每日定時檢查，避免異常因素導致的整體穩定性受損；
- 線上預熱：這是線上壓測前的最後一環，對線上需要擴容的機器、所需的資料進行提前預熱，可通過小流量試跑來驗證線上預熱準備是否充足；
實施線上壓測
線上壓測的過程，實際上和日常壓測沒太多區別，下面這張圖足以說明一切：
預案演練驗證
預案演練驗證環節，即針對之前備戰階段梳理出的各種預案，進行一一驗證。主要驗證如下兩點：
- 預案是否按照預期生效；
- 預案生效後對正常的業務是否造成影響；
作戰階段
執行前置預案
如果有經歷過電商雙11大促值班的同學，或許應該能明白這點的作用。
一般前置預案包含定時JOB時間調整、部分邊緣業務降級（如商品評論、小紅點）、支付入口調整、訂金結算等。
線上值班保障
線上值班保障，主要是應對在峰值流量衝擊時候，各個應用和對應人員能及時應對突發的各種問題。如下圖所示：
如果一切正常，那就一切正常。
如果出現異常情況，就按照預定的各種預案進行快速處理，核心目標是線上業務止血並快速恢復。
這裡就體現了作戰手冊和大促保障kickoff階段的三大關鍵機制的重要性了，我們再次回顧一下，他們分別是：
- 資訊同步機制：複雜的技術專案，資訊同步的效率和一致性很重要；
- 團隊協作機制：拆解出來的任務，很多需要多團隊協同配合，因此需要制定合理的合作機制；
- 緊急事件處理機制：如線上緊急變更、緊急釋出、目標變更等都需要有對應的應對策略，否則容易手忙腳亂；
覆盤階段
覆盤是個好習慣，知道哪裡做得好，哪裡做的不好並找到原因加以改正，持續優化我們的系統。一般覆盤主要做下面四件事：
業務覆盤
- 訂單增長率：客戶支付訂單同步環比的增長率，推薦品類購買的轉化率；
- 支付履約率：使用者從首頁導購到商品詳情以及訂單支付的履約率，整體的轉化漏斗；
- DAU轉化率：日活和業務增長之間的轉化比率，評估紅包&優惠券及業務活動的效果以及ROI；
技術覆盤
- 場景覆蓋率：本次大促的技術準備對業務的覆蓋率，建議結合QPS等指標一起分析；
- 監控覆蓋率：綜合監控指標的時延、準確率、告警提示、異常指標分析等體系的不足進行分析；
- 預案覆蓋率：針對主動、緊急、容災預案的執行百分比以及效果進行評估。主動預案執行率和目標達成率越高，緊急和容災預案執行率越低，證明預案更完善；
- 容量評估準確率：根據壓測結果和資源成本以及實際的使用量，評估容量的精確性不足之處，為容量規劃和成本管控提供決策參考；
- 壓測模型準確率：根據實際訪問量和壓測的流量模型進行對比分析，不斷優化流量模型的精準度；
- 溝通協作問題覆盤：評估整個專案實施期間，團隊在溝通、資訊同步、跨團隊協作方面的不足之處；
改進落地
通過覆盤，找到不足之處，然後針對性的落地改進措施，這是一個case by case的過程。
好的case應該進行提煉，不斷優化，甚至加強宣導和獎勵。做的不好的case也要落地改進TODO項並及時跟進驗證。
SOP宣講
所謂SOP，是Standard Operating Procedure三個單詞中首字母的大寫，即標準作業程式，指將某一事件的標準操作步驟和要求以統一的格式描述出來，用於指導和規範日常的工作。
而全鏈路壓測的SOP，就是將這個技術專案中適合本企業或者團隊的流程和過程通過標準化的定義而成為一種規範。
SOP的主要目的在於：記錄過程、沉澱經驗、賦能團隊、提高效率。
文末回顧
本篇文章主要介紹了生產全鏈路壓測落地實施的全流程，當然由於細節太多，很多內容無法描述的很清楚。
部分事項為什麼要這麼做的原因，我會在後續的系列文章中一一為大家拆解和講解。
最後，推薦一個很好的Github專案：大型營銷活動技術保障作戰手冊-數列科技出品。
我曾參與這個作戰手冊的製作，這個手冊很好的為這種大型的營銷活動和技術專案提供了一個全新的豐富視角，很值得技術同學去了解學習。