作者：京东物流 李武勇
背景概括：
供应链大屏做为物流的核心报表，为管理者提供大促决策时的依据。页面指标超过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灵活配置调整
json
{
"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，团队的力量
双十一大屏保障的好，并不是一个人的努力，而是团队内每个人的齐心协力，以及上下游的同事共同协作支持才达成的。我深知一个人的力量终究是有限的，但团队的力量可以创造无限的可能。