下边是梳理的供应链大屏加工的全流程图，图中标注了各个风险点的保障方案。

1、数据接入层

1.1 加工链路长

1.1.1 全链路确定边界，边界一定要是清晰的，整个大屏按照责任方拆分为4个区域：

• 蜂巢部分：蜂巢团队保障

• 实时加工任务：实时数据团队保障

• 各个接口提供方：各个接口方保障

• 大屏加工及查询部分：SCM保障（自己小组负责）

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

• 蜂巢：蜂巢保障高可用、蜂巢报警、蜂巢监控、蜂巢压测

• 实时加工任务：加工任务双流保障、FLINK加工链路压测

• 各个接口提供方：确定接口保障范围及接口SLA

1.2 涉及依赖方多

梳理出所有依赖接口，与各依赖方确定SLA，下边是部分接口示例：

1.3 涉及接入类型多

按照各种类型制定相应措施：

• 离线Hive：与离线确定大促重保任务、离线任务监控、烽火台增加离线推数据表的监控

• 业务导入：协助业务做大促数据校验、页面开发大促双11导入数据模拟（见四节）

• 外部JSF、HTTP接口：监控、重试、降级、兜底

2、指标加工层

2.1 指标存在多种维度，指标计算有先后顺序

指标加工分层，按维度拆分不同的表（单仓指标、区域指标），按功能作用拆分表（分钟表、小时表、缓存表、历史表）

2.2 重算、容错及快速恢复

• 加工容错：对外部每个接口做通用降级方案，接口异常取最近30min内上一次结果

• 快速恢复方案：提前设计容错方案，保障在单个或多个外部接口异常时，能快速重算指标并恢复

2.3 业务促销策略需要灵活调整（促销策略受友商影响，需支持随时调整）

{    "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.2 指标异常需要快速定位

3.2.1 打标字段存储为json

4、指标服务层

4.1 需要保障接口稳定性

• 压测

• 底层存储隔离

• 业务隔离

4.2 需要可降级

4.3 需要有兜底

5、监控管理

总结为2个点：

1）监控前置：尽可能监控前置，提前感知上游异常，提前采取保障措施；

5.1 蜂巢：报警增加SCM研发，研发监控前置

下边是我们收到上游蜂巢的报警，以及积压恢复告警

5.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、结果第一

5、团队的力量