圖1.“十節甘蔗”示意

上面提到的鏈路因為分叉分支很多，比如時效保證、開寄發票、預售先款/先貨、商品評價、直播空間、店鋪評價、客服處理等等內容未涉及，也從側面想說明如果想要保障整個電商平臺的大促穩定，如果不區分重點的話，那麼眉毛鬍子一把抓是肯定完不成好的效果，所以這一個環節主要想要闡述說明在特定場景下，電商大促更多的是保障重點在哪裡。

大促備戰是一個完整的事件，具備著詳細的故事線，這裡面延展開說明下，在領域驅動設計的建模過程中有個事件建模其實就非常好的應證了這一個點，如果將人類文明的活動想要梳理清楚，其實很多時候會發現越理越亂，所謂的點-線-面-體，其中線是更好的中間表述環節。基於故事線來看的話，那麼整體備戰思路，可以拆解為事前-事中-事後來考慮，相對而言會比較全面的將大促備戰體系針對特定場景下的備戰儘可能全面。

（1）參與部門/集團大促啟動會，及時獲取最新集團備戰導向和最新的戰略內容，比如京東的三道防線戰略。

（2）進行資源盤點梳理，包含人員、應用、上下游依賴、中介軟體、資料庫，本次大促的SLA約定，值班上下游群，問題反饋群，大促備戰手冊等。

（3）針對可以降低發生機率的事項進行改造，比如梳理核心鏈路，針對鏈路上的薄弱點進行改造，並對於日誌進行改造可以基於不同場景進行日誌輸出，規範整個大促備戰的指南方案。

（4）宣講儀式增強備戰感知，比如基於大促封板需求開始，進行大促意識宣講，同時完善監控大盤，補充關鍵日誌，報警郵件簡訊治理，歷屆大促相關指標同環比資料對照分析資料表等。

（5）宣講會後日檢工作內容，比如成立應急故障虛擬小組，基於歷史故障和常見問題形成故障手冊，同時制定限流和降級預案等指南手冊。

圖2.工作安排示意

（1）每日郵件指標報表通曬

（2）每日錯誤日誌收集並反饋和解決

（3）每日監控報警根因分析

（4）每日站會同步當天系統應用和人員情況

（1）業務目標的達成情況，比如某個營銷活動的達成情況，做的好的，待改善的，可以萃取經驗的內容。

（2）產研測團隊的系統需求保障情況，比如大促前期和中間上線的需求，上線情況和需求收益達成情況。

（3）系統應用的指標、資源成本、人力成本投入情況，比如每年大促備戰基於成熟化的工作流程、工具等內容，在業務變化不大的情況下，成本投入應該逐年下降等。

（4）備戰沉澱的經驗形成文件資產，每次大促都是系統歷煉的一次非常好的機會，期間形成的文件資產都可以歸檔方便下次使用。

（5）大促備戰中的待辦工作內容和事項持續跟蹤，很多時候團隊部門缺少跟蹤事項表，只是記錄了時間和人但是持續跟蹤的事情沒有持續性。

圖3.流量沙漏防護原理示意

其他應用/中介軟體/資料庫：會發現很多時間我們的問題引入集中在三方因素較多，也是在備戰中需要關注的重點：

•- 介面定義不合理，業務周知不到位，新上的業務需求直接在某個時刻脈衝流量到達薄弱依賴將服務打掛；

•- 還有部分是因為上下游依賴不穩定，比如遇到效能瓶頸，業務系統強依賴無法作出降級操作，只能靜靜等待恢復故障；

•- 在機房方面沒有容災，可能因為通訊機房網路問題，電纜被挖斷或者訊號中斷等問題導致網路癱瘓故障不可用；

•- 中介軟體使用策略異常，比如沒有做業務冪等性操作、重試策略未控制次數和時間導致依賴的業務系統無法承接脈衝流量從而服務不可用；

•- 還有依賴的中介軟體和資料庫容量水位已到閾值，沒有及時擴容，從而引發業務系統的不可用；

•- 應用運算元據庫執行緒阻塞、死鎖、慢SQL等造成資料庫拖垮服務應用；

•- 應用操作快取/ES出現熱點的商品造成的資料流量不均引發的服務不可用；

透過上述的流量沙漏防護原理是希望幫助大家能夠對於大促備戰有個整體框架，從而更好的結合三道防線戰略，以及考慮因素評估表和應用畫像來決策如何治理整改應用不合理的內容，最終形成相對合理的應用架構。

圖4.整體架構示意

那麼如何成為一個事業部架構師或者集團架構師呢？筆者認為需要有嚴格清晰的備戰路線和里程碑，關注的重點事項以及日例會進行事項跟進和同步，因為當人數超過幾十人以後，大促備戰更多的是管人、管流程，而不是管應用，所以需要責任到部門、到個人，緊抓流程，同時日例會及時資訊溝通減少資訊變更差。

本文從（知歷史->清家底->明目標->定戰略->做戰術->促成長）的6個環節，詳細闡述了電商大促系統的高可用保障思路。其中對商業模式和業務流程的全面理解、針對性的解決方案、嚴謹的風險評估與控制檢查指標，以及持續的最佳化改進路徑和自身應該成長的要素等，這些又是保障大促系統順利執行的重要基礎。此外，本文也強調了在整個保障思路中，技術和人員的協作是不可或缺的。只有技術和人員達成有效配合，才能使電商大促系統在面臨巨大壓力時仍能保持高可用，保障使用者良好的購物體驗，為公司帶來持續的商業成功。

- 集團軍演全鏈路壓測資料