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