蚂蚁前端灰度监控与变更防御

1. 前端灰度监控与变更防御饶海（陆沉）前端工程师@蚂蚁集团

2. • Content Title 2 • Content Title 3 • Content Title 4 • Content Title 5 • Content Title 6

3. 饶海（陆沉）支付宝 - 体验技术部 - 前端基础平台雨燕架构师雨燕前端监控负责人 React / Data Visualization / DevOps “每样都懂一点点” https://github.com/raohai

4. 大纲 • 背景介绍 • 监控覆盖率提升 • 灰度发布与前端灰度监控 • 基于灰度监控的变更防御 • 总结与展望你可以： ✅ 了解蚂蚁前端监控在安全生产下遇到的问题和挑战 ✅ 了解建设前端灰度监控的思路 ✅ 了解研发平台建立变更防御的思路和方法 ✅ 了解实施前端变更防御会面临哪些问题、如何应对

5. 安全生产背景下的挑战核心问题策略解决方案推进监控覆盖率监控发现率低建设场景 - 模板体系监控覆盖率低、很多应用没有监控或者监控配置不对增加监控覆盖率监控能力建设建设前端灰度监控体系变更型故障多灰度过程可监控变更故障占比 77% 推进监控与研发平台融合平台安全生产体系弱灰度过程问题可发现没有形成交付保障机制建设基于灰度监控的变更防御体系平台和监控结合不足建立应用交付保障体系

6. 安全生产背景下的挑战问题互相交织，解决只能一步步来 3 建设基于灰度监控的变更防御体系 2 建立应用交付保障体系建设前端灰度监控体系 1 推进监控覆盖率建设场景 - 模板体系增加监控覆盖率灰度过程可监控灰度过程问题可发现

7. 大纲 • 背景介绍 • 监控覆盖率提升 • 灰度发布与前端灰度监控 • 基于灰度监控的变更防御 • 总结与展望

8. 监控模板 - 解决温饱问题实现监控的传统路径 • 监控提供埋点 SDK / 探针，用户手动接入 • 自动采集 / 手动上报 • 手动配置监控问题是什么开发者平台 / 架构 • 接入烦琐、不会配置 • 相同场景重复劳动 • 采集到的指标有限 • 维度、指标无法规范统一 • 框架维护者、架构师介入程度低

9. 监控模板 - 解决温饱问题破局：场景 - 模板体系 • 相同场景的应用有通用的监控项 • 按场景梳理通用监控项、配置为模板 • 打通框架上报、容器数据。开箱即用 • 模板 - 监控一秒更新业务自定义架构师定义业务自定义业务监控项业务上报运行时异常 JS Error 捕获上报框架捕获异常 Worker Error Runtime Error 框架上报容器捕获异常白屏 / 闪退容器上报

10. 监控模板 - 解决温饱问题 5 大监控场景小程序、 H5 离线包、H5 在线、PC、 PC 微前端场景 97% 监控覆盖率高可用等级 H1、H2 应用监控模板业务自定义脚本捕获框架捕获异常容器捕获异常 ✅ ✅ 小程序 ✅ H5 在线 ✅ ✅ ✅ ✅ H5 离线 ✅ ✅ ✅ ✅ PC ✅ ✅ ✅ PC 微前端 ✅ ✅ ✅

11. 监控模板 - 解决温饱问题

12. 大纲 • 背景介绍 • 监控覆盖率提升 • 灰度发布与前端灰度监控 • 基于灰度监控的变更防御 • 总结与展望

13. 蓝绿发布 / 灰度发布线上版本线上版本 90% 流量负载均衡线上版本逐步扩大新版本蓝绿发布新版本 10% 流量灰度发布

14. 灰度发布生效原理访问支付宝客户端拉包灰度决策用户拉包白名单灰地域灰度进入灰度进入生产验证前置条件灰度 5% 推送灰度 10% 灰度 50% 生产推送 CDN

15. 灰度发布 - 遇到什么问题开发者没有发布安全感变更相关故障占比高平台 / 架构 • 可灰度、可监控、可回滚机制不完善变更过程可监控性不满足需求 • 监控无法感知灰度过程 • 线上和灰度数据混在一起 • 不知道发布过程中发生了什么 • 不知道对比线上情况如何想象中的指标变化情况实际的指标变化情况

16. 建立前端灰度监控体系使用迭代标识区分监控迭代标识使用自动注入上报迭代标识迭代标识初始化监控

17. 建立前端灰度监控体系以迭代标识为顶级维度清洗数据业务监控项 90% 流量运行时异常线上版本框架捕获异常线上版本数据新版本数据另一个新版本数据容器捕获异常业务监控项 10% 流量新版本运行时异常框架捕获异常容器捕获异常 GROUP BY 迭代标识

18. 建立前端灰度监控体系 • 0 配置。开箱即用的前端灰度监控 • 迭代信息关联 / 版本覆盖率 / 基线对比 • 精准区分此次迭代引起的数据变化 • 迭代新增异常第 9 ⻚

19. 建立前端灰度监控体系第 9 ⻚

20. 大纲 • 背景介绍 • 监控覆盖率提升 • 灰度发布与前端灰度监控 • 基于灰度监控的变更防御 • 总结与展望

21. 基于灰度监控的变更防御平台安全生产体系弱没有平台机制保障交付安全生产没有切入点 • “充分灰度” 、“看监控” 全凭用户自觉 • 安全生产经验没有复用机制 • 出现问题时没有机制阻止影响面扩大 • 各职能团队没有途径参与安全生产保障 • 经验口口相传故障案例：以去年的某起故障为例： • 发布的灰度时⻓仅 30 分钟，在半夜流量不够的情况下未发现问题 • 在监控上发现了异常。但因为没有配置报警，未能及时发现问题止血

22. 分批灰度和变更防御流程配置灰度批次开发者灰度 5% 重新检测进入灰度中止发布验证前置条件验证失败开始阶梯灰度灰度 10% 推送灰度策略 … 重新检测灰度 50% 全量验证成功 / 扩大灰度灰度后置验证验证失败验证成功 / 完成发布

23. 灰度后置验证灰度后置验证？进行哪些验证？验证哪些指标？这些验证是如何保障灰度发布的？

24. 背景 / 挑战 - 策略 / 解法 - 结果基于灰度监控的变更防御变更防御规则专家模型规则平台希望用户关心什么 • • • • 灰度有没有充分变更防御规则灰度版本实际有流量灰度引流符合预期流量规则说明当前版本有真实流量进入当前版本的流量占比符合预期我有没有把应用 / ⻚面 / 小程序搞挂有没有引入新的异常异常相比线上有没有变多了变更防御规则指标白屏闪退率阈值白屏 / 闪退变更引入新异常新增异常异常率变更使异常相较基线增加业务关心什么 • 指标重要业务指标有没有变遭规则说明当前版本的白屏闪退率有没有超标当前版本有没有新增异常当前版本的异常基线占比有没有变化业务规则变更防御规则指标业务自定义规则业务指标规则说明业务指标符合预期

25. 基于灰度监控的变更防御 - 两种拦截类型一旦出现，则立刻拦截 • • 在变更防御执行过程中，一旦发现指标满足某些要求，则立刻触发拦截白屏、闪退、新增异常等属于此类型默认拦截，直到满足条件再放行 • • 在变更防御执行过程中，默认不通过。直到指标满足要求流量、灰度覆盖率属于此类型

26. 基于灰度监控的变更防御充分灰度是一切的前提 • 当前灰度的迭代标识必须有真实流量进入（不解释……） • 当前灰度的迭代标识流入的流量必须接近灰度引流百分比 • （例如设置了 5% 灰度），则流入当前迭代标识的流量必须接近全量的 5%

27. 基于灰度监控的变更防御新增异常拦截 • 对于每一个异常建模，记录首次出现时间、首次出现迭代 hash: 4cd2fcdbaf95dd0c94b387816188e3ac 首次出现时间: 2021-05-21 首次出现迭代: 0.2.2105201954.59 • 在灰度过程中如果捕获到错误，且错误首次出现的迭代标识是当前正在灰度的迭代标识 • 一定程度上说明当前变更引入了新的异常。此时拦截

28. 基于灰度监控的变更防御异常率拦截 • 异常率 = 每分钟异常发生次数 / 流量 • 基线异常率 = 全部异常发生次数 / 全部流量 / • = 2.8 % 灰度异常率 = 灰度版本的异常发生次数 / 灰度版本流量 / • 可以发现，当前灰度版本的异常率显著高于基线，因此触发拦截。 = 14 %

29. 基于灰度监控的变更防御雨燕⻔禁雨燕监控⻔禁项自动化测试雨燕元信息 … 监控规则匹配卡口代码提交迭代推进灰度防御后置校验能力执行监控防御规则监控模板流量充分灰度结果回调异常新增异常白屏闪退雨燕标准研发模型线上数据白屏雨燕统一调度系统雨燕数据资产自定义监控灰度数据容器数据拦截结论

30. 完整的灰度发布与变更防御流程

31. 完整的灰度发布与变更防御流程

32. 大纲 • 背景介绍 • 监控覆盖率提升 • 灰度发布与前端灰度监控 • 基于灰度监控的变更防御 • 总结与展望

33. 总结与展望变更防御 = 研发流程 X 监控 X 数据 • 灰度监控与变更防御：给用户发布安全感 • 前端监控和数据要结合研发平台才能发挥更大价值 • 后续会支持用户配置自定义的监控防御规则、组合防御规则等 • 把当前基于规则的变更防御升级成智能变更防御规则提供开箱即用的监控和防御，而不是让用户自己实现 • 技术普惠 • 使用平台机制保障安全生产 • 让各职能团队有途径参与安全生产

34. AFI.team

35.