本文面向受眾可以是運營、可以是產品、也可以是研發、測試人員,作者希望通過如下思路(知歷史->清家底->明目標->定戰略->做戰術->促成長)幫助大家能夠瞭解電商大促系統的高可用保障,減少哪些高深莫測的黑話和高大尚的論調,而是希望有個體系化的知識讓讀者有所得。 ...
本文面向受眾可以是運營、可以是產品、也可以是研發、測試人員,作者希望通過如下思路(知歷史->清家底->明目標->定戰略->做戰術->促成長)幫助大家能夠瞭解電商大促系統的高可用保障,減少哪些高深莫測的黑話和高大尚的論調,而是希望有個體系化的知識讓讀者有所得。
一、【知歷史】電商大促的簡介
1.1、什麼是電商大促
電商大促是電商平臺組織的一種大型銷售推廣活動,目的是通過提供各種優惠、折扣等方法,提高商品銷售額和網站流量,增加消費者的購物欲望,以實現銷售目標。電商大促活動通常會在一些特定的節點或者節日舉行,比如“11.11”、“618”、“黑色星期五”等,這些時期的電商大促極具吸引力,既有大量的商品打折優惠,又有豐富多樣的活動供消費者參與,是電商平臺提升銷售業績的重要手段。 電商大促活動期間,大家可以購買到平時心儀已久的商品,並且價格通常會遠低於平時,而電商平臺也會通過活動吸引更多的消費者流量和購買力,進一步提升其在電商行業的影響力。電商大促不僅僅是一種營銷方式,也是電商平臺和消費者互動、提高用戶粘性的有效方式。
1.2、典型的電商大促活動簡介
618大促: 每年6月是京東的店慶月,也是京東的電商促銷主戰場,在店慶月京東都會推出一系列的大型促銷活動,從6月1日延續至6月18日(近幾年開始從5.20日左右開啟預售模式,但是整體時間依然是以6月1日開門紅為準)。從2010年開始,以滿減、優惠券等活動的方式,通過單品類、跨店鋪等方式逐步蔓延到23年的百億補貼,歷時已經13年之久為整個京東零售平臺的GMV營收帶來不小的貢獻。
11.11: 11.11是指各網路購物平臺在每年11月11日的大型促銷活動,最早起源於中國阿裡巴巴旗下購物網站在2009年11月11日舉辦的“淘寶商城促銷日”,現已演變成全行業一年一度的購物活動,及影響全球零售業的消費現象。2012年11月11日網路購物全日銷售額超過美國網路星期一,成為全球最大的互聯網的購物節日。(備註:淘寶商城項目剛獨立,後更名為天貓,該營銷活動主打品牌商的商品,是想要模仿美國感恩節大促銷這種活動,通過一個活動或一個事件,讓消費者記住淘寶商城)。(參考維基百科)
黑色星期五: Black Friday最早於2005年美國網路shop.org創造的購物節日,與11.11被電商炒成購物節原因相似。與之相對應的還有興起於法國、葡萄牙與德國的Cyber Monday。關於黑色星期五這一叫法的起源,較普遍的一種認為看法是,由於這一天是感恩節(11月第四個星期四)後開業的第一天。再加上人們通常由此開始聖誕節大採購,很多商店都會顧客盈門從而有大額進帳。傳統上商家會用不同顏色的墨水來記賬:紅色表示虧損即赤字;反之黑色則為有盈利。商家把這個星期五叫做黑色星期五,用以期待這一天過後,年度營收由負轉正,由紅字轉為黑字。而商店的員工則使用黑色星期五這一名字來自嘲,表示這一天會非常忙碌。黑色星期五這一天一般都會是一個大的採購狂潮,銷售額是一年中第二或第三高的一天,而通常一年中銷售額最高潮是聖誕節前夜或之前的一個星期六。(參考維基百科)
除上述比較大型的電商促銷活動外,其他零售電商平臺比如蘇寧818、國美418,以及其他電商平臺也在自己造節日,而近幾年的拼多多、抖音、快手等電商平臺更多的是借勢11.11或者618來提升整個電商平臺的GMV交易額。
二、【清家底】電商平臺的商業模式與系統
2.1、電商平臺的商業模式
經過上面電商大促簡介,大家心裡已經有一個簡單的電商大促活動認識,對於電商行業從業者,電商大促活動是基本的知識,近幾年隨著“新零售”、“無界零售”、“全渠道”等新詞的頻出,給原本電商大促活動增加了更多的業務複雜性。這也是為什麼會在這裡提下系統分類的原因。在整個零售業鏈路的節點上,劉總曾經提到過“十節甘蔗”理論,而我們致力於做的事是後5節甘蔗的內容,大家知道京東是以自建倉儲物流打通供應鏈為核心驅動力,而淘寶天貓平臺更多是聚集在平臺交易環節通過營銷和兼併購買生態產品帶動流量增長為核心驅動力(近幾年阿裡也開始佈局菜鳥平臺開始衍生至其他節甘蔗);拼多多商業模式更側重於不同的營銷模式,所以系統也聚焦在營銷、交易側,採用第三方商家和物流配送體系;抖音、快手直播電商本身是在構建一個流量場,從開始京東、淘寶天貓入駐流量場到現在獨立發展電商,他們更多是希望搭建的平臺場來實現交易額;
通過上面的講述其實是想要說一件事,如果單純字面上說電商大促備戰是沒有意義的,針對不同環節的"甘蔗",整個電商大促中重要性不同,所以電商大促備戰中,需要明確自己的系統在整個業務鏈路中的位置,同時系統提供的核心功能,是否涉及資損、用戶體驗、阻礙交易行為或者影響公司名譽、品牌、集團戰略、營銷計劃等內容。
2.2、電商平臺下的系統鏈路劃分
基於上述內容,我們可以基於營銷、交易、倉儲、配送、售後來劃分京東零售整個系統的業務鏈路環節初步劃分,從大促活動來看營銷是吸引流量、聚集流量、進行流量轉化的手段,屬於整個大促活動的核心環節;從我們的電商平臺大促目的來說,大促活動更多的是希望帶來交易訂單的達成,促進交易額的提升,所以整個交易鏈路是真正目標核心鏈路,屬於整個大促活動的最重要環節;從倉儲、配送、售後來看更多的是交易後履約服務保障,這裡面更多的是給電商平臺帶來的口碑影響,和用戶的長期體驗,對於電商平臺長期發展來看也是非常重要,但是在電商大促的特定場景下可能相對前置的交易屬於次重要核心環節。因為涉及業務知識比較龐大,以下我簡要說明下鏈路作為大家一個參考(如有不對,可聯繫ERP:liuxiaocheng6反饋)
營銷鏈路:營銷策略方案制定->營銷方案採銷/商家宣講->營銷方案外部市場公關->營銷活動創建->營銷活動審核->營銷活動投放->促銷招商->商家報名->商家選品、發品->營銷活動商品審核->營銷活動、優惠券、商品的投放&推薦
交易鏈路:登陸(網站/APP/小程式/H5)->京東首頁(搜索&推薦)->商詳->購物車->結算頁->收銀台(支付)->訂單(訂單列表/訂單詳情頁)->資金對賬
履約鏈路:訂單拆分、轉移、下傳、出管->POP商家(採銷/供應商)接單->發貨、揀貨、打包、出庫、列印面單->分揀、配送、自提->確認收貨
售後鏈路:拒收/訂單取消/售後退貨、換貨、退款->商家審核/快速退款/糾風判責->暫停修改訂單、攔截物流返倉、原路(部分)退款、上門維修、換新單等->財務對賬->客戶滿意度評價
上面提到的鏈路因為分叉分支很多,比如時效保證、開寄發票、預售先款/先貨、商品評價、直播空間、店鋪評價、客服處理等等內容未涉及,也從側面想說明如果想要保障整個電商平臺的大促穩定,如果不區分重點的話,那麼眉毛鬍子一把抓是肯定完不成好的效果,所以這一個環節主要想要闡述說明在特定場景下,電商大促更多的是保障重點在哪裡。
三、【明目標】大促備戰目標
大促備戰目標的核心一個點:穩。在我們工作中,很多有經驗的同學會發現,如何去設計一個良好的系統,大概會從如下幾個要素考慮:功能性、可用性、性能效率、安全和擴展性,有些場景可能比如秒殺系統更多考率的是高併發因素。那麼在整個大促備戰過程中,基於場景不同,所以我們的大促備戰目標也不可同述。但是整體的總目標來說,依然維持在可用性,如何保障交易核心鏈路更穩、更好的支撐用戶購買下單,促成交易。
但是事與願違,往往我們會發現管理者、項目、產品、研發、測試總是會面臨同樣的一個問題,資源不足,無論是人力、物力或者財力,永遠資源不足的問題是我們要解決的一大核心問題。從古至今,上到將軍打仗、皇帝恩濟百姓,下到企業家創業,資源不足就決定了我們在做決策的時候,需要集中優勢力量兵力結合正確的戰略方針,攻擊目標最薄弱的環節,保障方案正確落地,正所謂蛇打七寸。所以接下來就很明晰我們要做什麼?如何做是我們要考慮的重點。
四、【定戰略】大促整體備戰思路
大促備戰是一個完整的事件,具備著詳細的故事線,這裡面延展開說明下,在領域驅動設計的建模過程中有個事件建模其實就非常好的應證了這一個點,如果我們將人類文明的活動想要梳理清楚,其實很多時候會發現越理越亂,所謂的點-線-面-體,其中線是我們更好的中間表述環節。基於故事線來看的話,那麼整體備戰思路,我們拆解為事前-事中-事後來考慮, 相對而言會比較全面的將大促備戰體系針對特定場景下的備戰儘可能全面。
4.1、事前:基於現狀進行整體提前工作安排
(1)參與部門/集團大促啟動會,及時獲取最新集團備戰導向和最新的戰略內容,比如京東的三道防線戰略。
(2)進行資源盤點梳理,包含人員、應用、上下游依賴、中間件、資料庫,本次大促的SLA約定,值班上下游群,問題反饋群,大促備戰手冊等。
(3)針對可以降低發生概率的事項進行改造,比如梳理核心鏈路,針對鏈路上的薄弱點進行改造,並對於日誌進行改造可以基於不同場景進行日誌輸出,規範整個大促備戰的指南方案。
(4)宣講儀式增強備戰感知,比如基於大促封板需求開始,進行大促意識宣講,同時完善監控大盤,補充關鍵日誌,報警郵件簡訊治理,歷屆大促相關指標同環比數據對照分析數據表等。
(5)宣講會後日檢工作內容,比如成立應急故障虛擬小組,基於歷史故障和常見問題形成故障手冊,同時制定限流和降級預案等指南手冊。
4.2、事中:基於備戰情況保持警惕備戰狀態
(1) 每日郵件指標報表通曬
(2)每日錯誤日誌收集並反饋和解決
(3)每日監控報警根因分析
(4)每日站會同步當天系統應用和人員情況
(5)跟進部門/集團大促備戰日例會
4.3、事後:基於整個備戰結果進行效果復盤
(1)業務目標的達成情況,比如某個營銷活動的達成情況,做的好的,待改善的,可以萃取經驗的內容。
(2)產研測團隊的系統需求保障情況,比如大促前期和中間上線的需求,上線情況和需求收益達成情況。
(3)系統應用的指標、資源成本、人力成本投入情況,比如每年大促備戰基於成熟化的工作流程、工具等內容,在業務變化不大的情況下,成本投入應該逐年下降等。
(4)備戰沉澱的經驗形成文檔資產,每次大促都是系統歷煉的一次非常好的機會,期間形成的文檔資產都可以歸檔方便下次使用。
(5)大促備戰中的待辦工作內容和事項持續跟蹤,很多時候團隊部門缺少跟蹤事項表,只是記錄了時間和人但是持續跟蹤的事情沒有持續性。
五、【做戰術】大促整體備戰工作
5.1、流量沙漏防護原理介紹
因為上述戰略中我們提到的內容比較多,我們這裡以系統應用為切入點,開始進行系統評估是否屬於良好的應用,如果特征因素中有不滿足的我們進行薄弱挖掘,比如大促備戰中,其實整個防護工作是以流量沙漏防護原理為核心的,從流量請求開始,CDN、Nginx、業務網關/前端應用直到後端應用(包含中後臺系統)以及依賴的相關組件和其他應用,其實是在一個整個流量沙漏下,最複雜最核心的也是我們最常講的就是後端應用故障穩定保障。
5.2、流量沙漏防護原理後端應用考慮因素評估表
基於上述的流量沙漏防護原理我們可以進行如下的考慮因素進行後端應用評估,挖掘薄弱點。
考慮因素 | 特征 | 措施 |
---|---|---|
功能/適用性 | 合適原則 | 系統需求的可理解 |
性能效率 | 全面性 | 頁面、介面、功能載入時間 |
時間性 | RT響應時間、吞吐量 | |
資源利用率 | 記憶體、磁碟空間、CPU使用率 | |
可擴展性 | 代碼、架構設計 | |
可用性 | 全面性 | 平均無故障時間、平均修複時間、平均故障間隔時間 |
穩定性 | 平均停機時間 | |
容錯性 | 錯誤崩潰、代碼覆蓋率、多機房容災、冗餘備份等 | |
可維護性 | 全面性 | 應用維護人力投入情況 |
模塊化 | 結構清晰、邊界清晰 | |
可重覆使用性 | 代碼、功能復用情況 | |
可測試性 | 代碼覆蓋率 | |
可分析性 | 複雜性、代碼圈複雜度、服務之間交互耦合等 | |
可變更性 | 代碼大小、變更、代碼耦合、服務單一職責等 | |
成本 | 全面性 | 開發、測試、部署維護 |
基礎設施 | 雲/本地基礎設施成本 |
5.3、流量沙漏防護原理的備戰重點&應用健康度
CDN動靜分離:主要集中在我們的前後端分離場景下,但是據筆者瞭解因為歷史、組織結構調整交接等各種原因依然有很多應用沒完整徹底的前後端分離,界面還是以後端維護和編寫;但是如果是核心應用的話基本上都完成了前後端分離,所以這塊優化相對簡單。
網關安全保障:通常我們的網關分為技術網關和業務網關,技術網關更多關註的是安全、鑒權、防刷、防攻擊、限流和降級等功能,業務網關更多的是偏BFF層的業務介面適配、裁剪等能力。這塊我們應該更多面對的是熱點流量峰值的不確定性、用戶行為的不確定性以及安全攻擊等風控行為,需要結合風控團隊對於黑產異常流量、異常IP、Cookie自動加入黑名單進行限流操作;同時結合大促壓測進行壓測指標評估,結合大促預期目標對於系統應用有個合理的閾值和水位管控。
後端應用:後端應用類型、功能、服務面向用戶不同決定了高可用的保障手段不同,比如後端應用分類可以基於任務類、工具類、支撐業務類、核心業務類等劃分;根據其應用分級的定義程度我們進行應用健康緯度的評估,評估基礎硬體資源、容器資源、應用資源、監控報警、鏈路維度等明細情況,進行薄弱環節治理,比如公司平臺的應用健康度能夠合理的給應用進行畫像,便於問題的診斷和定位。
類型 | 檢測指標 |
---|---|
基礎資源 | 應用跨集群 |
應用跨機房 | |
應用跨POD | |
應用POD分佈 | |
JIMDB POD分佈 | |
網路TCP重傳 | |
應用容器CPU | |
JIMDB CPU | |
JMQ CPU | |
資料庫 CPU | |
JIMDB分片拓撲 | |
JIMDB分片POD | |
資料庫主從 | |
資料庫機房 | |
資料庫規格 | |
JMQ POD | |
VIP機房數量 | |
後端機房數量 | |
錯誤後端(ip) | |
集群環境一致 | |
容器 | 容器存活 |
應用模塊化 | |
GIT分支 | |
灰度更新超時 | |
CPU利用率 | |
記憶體使用率 | |
磁碟繁忙 | |
網路流入 | |
TCP連接數 | |
CPU利用率 | |
記憶體使用率 | |
Swap使用率 | |
磁碟繁忙 | |
磁碟使用率(根目錄) | |
磁碟使用率(export) | |
網路連通性 | |
網路流入 | |
網路流出 | |
系統時間偏差 | |
應用 | JSF版本 |
JMDB版本 | |
JMQ2版本 | |
JMQ4版本 | |
UMP版本 | |
DUCC版本 | |
LOG4J版本 | |
JVM版本 | |
Full GC/Young GC | |
JVM_XMX最大堆記憶體 | |
JVM_XMS最小堆記憶體 | |
JVM_堆外記憶體 | |
JVM_ParallelGCThreads | |
JVM_GCConcGCThreads | |
JVM_CICompilerCount | |
JVM_Metaspace | |
JVM_CMS回收閾值 | |
JVM_新生代大小 | |
JVM_HeapDump | |
JVM_Server模式 | |
JDOS_日誌清理 | |
JSF_Timeout超時時間 | |
JSF_跨單元調用 | |
JSF_跨環境調用 | |
JSF_跨機房調用 | |
JSF_重試次數 | |
負載均衡 | |
JSF_限流 | |
JSF_動態別名 | |
JSF_設置黑名單 | |
JSF_同機房部署 | |
JSF_別名命名規範 | |
JSF_混合環境部署 | |
color網關timeout | |
最大連接數 | |
初始連接數 | |
connectTimeout | |
SocketTimeout | |
maxWait | |
時區 | |
JIMDB FAILOVER狀態 | |
JIMDB 熱KEY | |
JIMDB 大KEY | |
JIMDB 慢日誌 | |
JIMDB 掃描過期頻率 | |
JIMDB 服務端版本一致 | |
JIMDB 服務端風險版本 | |
淘汰策略 | |
JIMDB_Swap交換區 | |
JIMDB_綁核 | |
JIMDB_CPU模式 | |
JIMDB_網卡軟中斷 | |
慢SQL | |
優先治理慢SQL | |
含外鍵表 | |
索引過多表 | |
自增溢出表 | |
大表 | |
接入方式 | |
最大線程數 | |
JIMDB讀超時 | |
JIMDB跨單元調用 | |
JIMDB連接超時 | |
JIMDB等待超時 | |
JIMKV連接超時 | |
JIMKV讀超時 | |
JMQ_sendTimeout | |
空應用 | |
純預發應用 | |
單實例應用 | |
預發流量過大 | |
預發資源過多 | |
不活躍預發分組 | |
應用_實例存活 | |
應用_Port存活 | |
應用_URL存活 | |
JSF_Provider介面存活 | |
JSF_Consumer介面存活 | |
依賴JIMDB集群異常Server_OPS次數 | |
Server_CPU利用率 | |
Server_記憶體使用率 | |
Server_記憶體RSS | |
Server_網路流入 | |
Server_網路流出 | |
Server_連接數 | |
tp99異常次數 | |
積壓 | |
broker 主機-負載 | |
broker 主機-磁碟繁忙 | |
JED Qps | |
JED連接數 | |
JED主從延遲 | |
監控報警 | CPU利用率 |
負載 | |
記憶體使用率 | |
Swap使用率 | |
磁碟繁忙 | |
磁碟使用率 | |
網路連通性 | |
TCP連接數 | |
TCP重傳 | |
網路流入 | |
網路流出 | |
系統時間偏差 | |
JsfProvider組件報警 | |
JimDB組件報警 | |
JmqProducer組件報警 | |
Mysql組件報警 | |
SpringMVC組件報警 | |
UMP JVM監控 | |
UMP 方法監控 | |
JVM_CPU利用率 | |
JVM_記憶體使用率 | |
JVM_線程數 | |
FULLGC次數 | |
YONGGC次數 | |
方法TP99 | |
方法TP999 | |
方法可用率 | |
方法TP99配置合理性 | |
方法TP999配置合理性 | |
方法可用率配置合理性 | |
方法調用次數 | |
Port存活 | |
URL存活 | |
OPS次數 | |
連接數 | |
記憶體使用率 | |
主從斷開 | |
主從複製延遲 | |
積壓 | |
重試 | |
主從延遲 | |
Logbook關鍵字報警配置 | |
鏈路超時 | 鏈路超時 |
鏈路超時JIMDB組件 |
其他應用/中間件/資料庫:我們會發現很多時間我們的問題引入集中在三方因素較多,也是在備戰中需要關註的重點:
•- 介面定義不合理,業務周知不到位,新上的業務需求直接在某個時刻脈衝流量到達薄弱依賴將服務打掛;
•- 還有部分是因為上下游依賴不穩定,比如遇到性能瓶頸,業務系統強依賴無法作出降級操作,只能靜靜等待恢復故障;
•- 在機房方面沒有容災,可能因為通信機房網路問題,電纜被挖斷或者信號中斷等問題導致網路癱瘓故障不可用;
•- 中間件使用策略異常,比如沒有做業務冪等性操作、重試策略未控制次數和時間導致依賴的業務系統無法承接脈衝流量從而服務不可用;
•- 還有依賴的中間件和資料庫容量水位已到閾值,沒有及時擴容,從而引發業務系統的不可用。
•- 應用操作資料庫線程阻塞、死鎖、慢SQL等造成資料庫拖垮服務應用
•- 應用操作緩存/ES出現熱點的商品造成的數據流量不均引發的服務不可用。
•- 應用記憶體泄漏、JVM配置不合理等等
通過上述的流量沙漏防護原理是希望幫助大家能夠對於大促備戰有個整體框架,從而更好的結合三道防線戰略,以及考慮因素評估表和應用畫像來決策如何治理整改應用不合理的內容,最終形成相對合理的應用架構。
六、【促成長】其他
電商大促相對每個人來說都是很好的成長機會,通過大促備戰能夠讓你更好的補齊自身知識的不足,也能更深入的瞭解所在團隊的核心業務,所以建議無論是業務運營、產品、研發、測試人員都可以簡單瞭解下。
那麼如何成為一個合格的團隊大促備戰師呢?筆者以自身當時經歷來說,就是大促備戰師要做到胸有成竹,在大促備戰前應該充分瞭解核心鏈路業務,做好事前工作梳理,能夠有著大促指南手冊宣導給團隊每一個人,做到精兵強將,人人互為備份,將監控報警可視化面板進行大屏展示,及時捕捉和觀察業務變動情況。
那麼如何成為一個事業部架構師或者集團架構師呢?筆者認為需要有嚴格清晰的備戰路線和里程碑,關註的重點事項以及日例會進行事項跟進和同步,因為當人數超過幾十人以後,大促備戰更多的是管人、管流程,而不是管應用,所以需要責任到部門、到個人,緊抓流程,同時日例會及時信息溝通減少信息變更差。
作者:京東零售 劉曉成
來源:京東雲開發者社區