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