背景概括：

供應鏈大屏做為物流的核心報表，為管理者提供大促決策時的依據。頁面指標超過170+，依賴接口30+，復雜度較高，數據鏈路較長，同時穩定性要求高。

本文將分享供應鏈大屏是如何保障雙11供應鏈大屏的穩定性。

一，供應鏈大屏全鏈路流程圖

保障的首要步驟是繪制供應鏈大屏全鏈路流程圖。在梳理出概覽圖之后，深入指標加工的各個細節去發現問題，然后是因地制宜的制定保障方案。

下邊是梳理的供應鏈大屏加工的全流程圖，圖中標注了各個風險點的保障方案。

?

?

二，供應鏈大屏風險點梳理

在有了加工全鏈路之后，按照從左到右、從上往下的思路分析各個流程節點的薄弱點。

大屏加工按照分層的概念，從左到右依次是數據接入層、指標加工層、指標存儲層、指標服務層。

下邊是各個模塊保障的風險點：

1，數據接入層：

?加工鏈路長：從數據產生到指標加工完成，經過了報表庫、多層蜂巢任務、多層JDQ、多層Flink任務、DTS、CK、Easydata

?涉及依賴方多：依賴大件、服務、逆向、B2B、LDC、冷鏈、實時數據團隊

?涉及接入類型多：離線Hive、jsf接口、http接口、業務導入、CK

2，指標加工層：

?指標存在多種維度，指標計算有先后順序

?外部依賴無法保證100%，數據加工需要有重算功能，需要一定的容錯性及故障自動恢復功能

?業務促銷策略需要靈活調整（促銷策略受友商影響，需支持隨時調整）

3，指標存儲層：

?多業務互相影響

?指標異常需要快速定位

4，指標服務層：

?需要保障接口穩定性

?外部依賴接口需要可降級

?外部依賴接口需要有兜底

?多個業務服務如何隔離

5，監控管理：

?指標加工如何監控

?加工鏈路異常如何快速定位

三，技術上的保障策略

1，數據接入層

1.1，加工鏈路長

1.1.1，全鏈路確定邊界，邊界一定要是清晰的，整個大屏按照責任方拆分為4個區域：

?蜂巢部分：蜂巢團隊保障

?實時加工任務：實時數據團隊保障

?各個接口提供方：各個接口方保障

?大屏加工及查詢部分：SCM保障（自己小組負責）

?

1.1.2，要求各依賴方及接口做高可用

?蜂巢：蜂巢保障高可用、蜂巢報警、蜂巢監控、蜂巢壓測

?實時加工任務：加工任務雙流保障、FLINK加工鏈路壓測

?各個接口提供方：確定接口保障范圍及接口SLA

1.1.3，監控前置

蜂巢、實時FLINK任務都加上了SCM研發，數據積壓作為下游也能提前知曉，同時也是對上游監控的一個補充

具體信息見第三節第5項“監控管理”

1.2，涉及依賴方多

梳理出所有依賴接口，與各依賴方確定SLA，下邊是部分接口示例：

1.3，涉及接入類型多

按照各種類型指定相應措施：

?離線Hive：與離線確定大促重保任務、離線任務監控、烽火臺增加離線推數據表的監控

?業務導入：協助業務做大促數據校驗、頁面開發大促雙11導入數據模擬（見四節）

?外部JSF、HTTP接口：監控、重試、降級、兜底

2，指標加工層

2.1，指標存在多種維度，指標計算有先后順序

指標加工分層，按維度拆分不同的表（單倉指標、區域指標），按功能作用拆分表（分鐘表、小時表、緩存表、歷史表）

?

2.2，重算、容錯及快速恢復

外部依賴無法保證100%，數據加工需要有重算功能，需要一定的容錯性及故障快速恢復功能

加工容錯：對外部每個接口做通用降級方案，接口異常取最近30min內上一次結果

快速恢復方案：提前設計容錯方案，保障在單個或多個外部接口異常時，能快速重算指標并恢復

?

2.3，業務促銷策略需要靈活調整（促銷策略受友商影響，需支持隨時調整）

抽象出業務策略，通過DUCC靈活配置調整

{
    "sTime": "2024-11-xx 00:00:00"， // 大屏策略時間開始
    "eTime": "2024-11-xx 19:59:59"， // 大屏策略時間結束
    "tbSTime": "2023-11-xx 00:00:00"， //同比開始
    "tbETime": "2023-11-xx 19:59:59"，//同比結束
    "hbSTime": "2024-06-xx 00:00:00"，//環比開始
    "hbETime": "2024-06-xx 19:59:59"，//環比結束
    "showType": "24h"，//類型，24h同20h小時，都可以
    "special24hCompDateStr": "2024-11-xx"，//大促24h特殊對比日期，（4h，28h不使用） 主要影響預測；主要用作非 4h/28h 的預測不使用昨日了；
    "specialCompDateStr": ""       //大促4h/28h預測對比天數
}

2.4，大屏加工及查詢部分

指標緩存：使用redis緩存指標

接口壓測：forcebot按預估量壓測

鏈路雙流：

下邊是SCM指標加工查詢CK的一鍵主備切換功能，在收到報警時可以快速切換查詢鏈路

?

3，指標存儲層

3.1，多業務互相影響

3.1.1，根據業務，Mysql采用一主三從的方式，數據庫劃分為：

主庫、大屏查詢、核心看板查詢、其它報表

?

3.1.2，根據服務劃分，大屏及核心報表存儲Mysql，easybi報表使用Doris（Doris數據由Mysql binlog異步同步）

?

3.2，指標異常需要快速定位

3.2.1，打標字段存儲為json

根據sql從json里邊過濾

3.2.2，mysql數據通過binlog異步存儲到Doris（Doris支持更長時間數據）

?

4，指標服務層

4.1，需要保障接口穩定性

?壓測

?底層存儲隔離

?業務隔離

4.2，需要可降級

外部接口單次異常，取當前促銷策略內，最近30min的上一次成功數據

4.3，需要有兜底

預測時異常品類的兜底策略，保障數據不會異常

5，監控管理

總結為2個點：

1，監控前置：盡可能監控前置，提前感知上游異常，提前采取保障措施

2，監控全面：盡可能能覆蓋所有環節；加工環節、查詢環節、推數據環節、數據準確性環節

5.1，蜂巢：報警增加SCM研發，研發監控前置

下邊是我們收到上游蜂巢的報警，以及積壓恢復告警

?

5.2，實時加工

5.2.1，報警增加SCM研發，研發監控前置

下邊是我們收到的實時JDQ報警

?

5.2.2，我們維護了一份實時任務的JDQ層級列表，我們也能快速定位具體積壓點

圖1是實時加工鏈路，紅色箭頭從我們開始，箭頭指向更遠端上游。

圖2是我們維護的JDQ對應的上級各個速查監控url，紅色箭頭從我們開始，箭頭指向更遠端上游的表。

?

5.3，SCM加工監控全域看板（依賴方接口可用率、自己方法可用率、是否調用）：

?

5.4，SCM接口查詢監控全域看板：

?

5.5，SCM指標數據準確性監控：

主要使用烽火臺，監控數據是否重復寫入，數據量級是否合理以及依賴數據是否具備

四，其它流程上的保障策略

1，溝通協同，建立大屏大促保障溝通群

由于涉及眾多依賴方，大促溝通保障群建立了一條高效快捷的溝通機制

2，依賴方全鏈路演練

每年兩次大促間隔時間長，各系統負責研發可能會變化，研發人員配置也可能會生疏。組織大屏全鏈路預發演練，一方面各系統人員都建立起溝通，另一方面提前熟悉配置，也校驗了配置策略的正確性。

另外大屏大促需求都臨近大促，各個系統方都有變化，這些變化基本都是大促特殊策略設置平時也驗證不了，全鏈路對特殊的策略下的演練，也能提前發現功能的一些隱藏問題。

3，與業務聯動、業務導入提前模擬校驗

3.1，針對大屏用到的歷史同環比數據，聚合到各個維度，拉著業務去確認數據的準確性

針對業務導入數據：通過策略修改及mock日期配置，業務可以在預發環境看到提前導入的雙11數據在大屏的展示，保障業務導入數據的準確性。下方展示了跟業務聯動，測試各個策略時間段下各個條線的業務數據準確性。

?

3.2，策略配置雙人double check，歷史問題歸納總結為check SOP

?

4，結果第一

結果第一，是我們保障大屏的方向指導，所以我們不光著眼于我們自己的系統，還從全流程上不斷地去找方法、找薄弱點，去保障大屏的穩定性、數據的準確性，更好地服務于業務。

結果第一，也是每次大促我們催著業務導數，而不是業務有問題了找我們然后才解決。業務說省區的都不著急為啥你們研發著急，不導入是省區的問題又不是你們研發的問題。對于這個問題，我是這么回復業務“我們的目標是雙11大屏的穩定與準確，而不是說是因為誰的問題導致的大屏數據異常”，這是我對結果第一的理解，這也是我認為我們團隊能做好大屏保障的根本原因。

?

5，團隊的力量

雙十一大屏保障的好，并不是一個人的努力，而是團隊內每個人的齊心協力，以及上下游的同事共同協作支持才達成的。我深知一個人的力量終究是有限的，但團隊的力量可以創造無限的可能。

?
審核編輯 黃宇