Real-time Data Warehouse Business-Side Chaos Engineering Practice

目前实时数仓提供的投放实时指标优先级别越来越重要，不再是单独的报表展示等功能，特别是提供给下游规则引擎的相关数据，直接对投放运营的广告投放产生直接影响，数据延迟或者异常均可能产生直接或者间接的资产损失。

从投放管理平台的链路全景图来看，实时数仓是不可或缺的一环,可以快速处理海量数据，并迅速分析出有效信息，同时支持投放管理平台的手动控盘。实时节点事故，将可能导致整个投放链路无法正常运行，另外，投放规则引擎是自动化操作，服务需要24小时运行，所以需要配置及时有效的数据质量监控预警，能快速识别到波动异常或者不符合业务的数据，从而计划引入混沌工程，希望可以通过主动注入故障的方式、尽可能提前感知风险、发现潜在问题，并针对性地进行防范、加固，避免故障发生时所带来的严重后果，提高实时数仓整体抗风险能力。

为了能更细致反应出混沌演练情况，根据演练的内容不同，将实时数仓混沌分为两部分： 技术侧和业务侧 。

技术侧混沌 ：基于中间件、数据库、JVM、基础资源、网络、服务等注入常见的异常，根据实际业务中梳理的应用核心场景进行混沌演练，检验系统的脆弱性和应急响应能力，从而提升团队的稳定性保障处理能力。

业务侧混沌 ：对于电商活动密集型的公司来说，各种到达率、曝光率，以及更加宏观的 GMV、用户拉新数、用户召唤数等，都能表现出业务的健康程度，在实际生活中，为了描述一种稳定状态，我们需要一组指标构成一种模型，而不是单一指标。无论是否采用混沌工程，识别出这类指标的健康状态都是至关重要的，所以要围绕它们建立一整套完善的数据采集、监控、预警机制，当业务指标发生波动较大时，我们能搞快速感知、定位、修复止血。

过往 数仓 混沌工程均是技术侧，此次在投放链路已搭建完成主备链路的前提下，期望通可以通过多轮业务侧混沌，提高系统整体的数据异动感知能力。

工欲善其事，必先利其器，在执行混沌演练前，需要准备好前置工作，制定合理的演练SOP、方案、计划，对演练环境、脚本、数据、工具，场景及爆炸半径等进行可能性评估，在确认可行性ok的情况下，约好关联方时间，再进行实践操作。

本篇主要和大家分享基于业务侧的实时数仓混沌演练过程：

红蓝对抗演练，将团队分为红（防）蓝（攻）两组。

测试人员组成蓝军：负责制定混沌演练方案，执行目标系统故障注入，详细记录演练过程；

实时数仓开发为红军：负责发现故障、应急响应、排除故障，同时验证系统在不同故障场景下的容错能力、监控能力、人员响应能力、恢复能力等可靠性能力。

整体演练过程，大致分为三个阶段：准备阶段、攻防阶段及复盘阶段。

准备阶段：方案准备完评审通过后，确认好链路计划；蓝军按计划根据事先制定的攻击方案，提前准备好相应的测试数据、脚本；红军按计划根据事先制定的攻击方案，在演练前，提前确保环境可用，并进行监控防御、应急响应措施。

攻防阶段：蓝队根据事先制定的攻击方案，模拟真实的攻击行为，按照约定的时间在演练链路（备用链路）进行攻击，进行故障注入，同时记录好相应的操作步骤，方便后续报告梳理；红队在蓝军攻击后，通过飞书/邮件告警等通知方式实时关注监控系统运行情况，如有异常告警，需第一时间进行问题排查定位，在评估修复方案。

复盘阶段：在混沌演练结束后，进行总结和评估，分析红队和蓝队的表现，评估系统的安全性和抗攻击能力；总结经验教训，总结成功的防御措施和失败的攻击手法，以便于改进系统的安全策略；根据评估结果和总结经验，制定改进计划，修补系统中的漏洞和薄弱点，提升系统的抗风险能力。

本次演练共计有29个指标波动case，整体演练操作大同小异。

以其中case17 “召回商品收藏uv在某个渠道下整点波动异常”为例，具体的演练操作流程如下：

1.数据准备：通过后台数据库，拉出生产主(备)链路，某个渠道（如`media_id` = '2'）下某个整点（如`hour` = 10）下，召回商品收藏uv对应的整体统计值N。

2.故障注入odps：将需要注入的数据导入odps。

3.odps同步到kafka：执行flink同步脚本，将odsp du_qa_dw_dev.hundun_case表表数据同步到对应的kafka topic中。

4.告警触发通知：红军在演练前，可通过监控平台提前配置好防御规则。在异常注入后，如符合预期，在15min内发现指标波动异常，红军需及时同步到演练群中。

5.演练过程记录：收集、汇总记录演练过程中的每个操作，含时间点、执行人、操作等。

6.演练总结：从0到1，在经过一系列的探索实践后，通过主备链路比对方式，演练期间对于异常波动的指标，可以快速识别感知，从演练结果上，取得了不错的成效，但也存在一定的局限性，如：演练期间，通过人工注入的异常数据，如无法快速清除，可能影响到备用链路使用；对于没有备链路的实时指标波动，需要制定更精细化的可行方案，找寻指标健康波动范围。

这些都需要团队进一步去探索、解决，同时在演练的过程中，我们将不断积累、丰富演练case、完善演练库，后续计划通过引入工具（平台）、建立演练协助机制、定期定时演练等手段，使混沌演练更加自动化、规范化、常态化，提高实时数仓整体数据稳定。