Shiply×Bugly｜构建客户端安全发布监控止损体系

一、  背景

随着 DevOps 等持续交付范式的不断发展，热发布（包括远程配置下发、离线资源下发等能力）已成为   持续交付的关键工具。在电商、短视频、本地生活、信息流等多种业务场景中，热发布发挥着至关重要的运营作用。

传统的应用程序发布（冷发布）通常涉及多个团队的协作，是一种高压力、高风险的活动，因为一次发布会包含大量的变更。为了减少这种大规模变更带来的风险，越来越多团队转向 DevOps 进行更敏捷的持续交付。DevOps 也意味着开发人员和运维人员的界限模糊，开发人员对生产环境的控制需求增加，在客户端上，这主要通过远程配置、离线资源（热发布）等发布管理系统来实现。

例如：开发人员可通过特性开关进行灰度（分阶段发布），并根据 A/B 测试等指标观察结果，以决定是否全面推广新特性。若不达标，可关闭特性并在后续迭代中进行优化或下线。

然而，热发布在软件系统中的广泛应用也容易导致发布失误，从而引发运营事故，这样的例子屡见不鲜，例如：

从以上案例可以看出热发布失误不仅会影响软件的稳定性，更有可能造成产品口碑下滑导致用户无形流失。

二、发布存在哪些风险

冷发布（程序包的发布）有隐私合规、稳定性、性能等风险，发布过程中对应的检测、审核、监控机制也都相对完善，在各个环节都有专人跟进，影响可控，真正造成事故的概率是很小的。

而热发布常因为缺少对风险识别的经验，缺乏对应的流程、规范，时而导致事故产生，常见风险如下：

我们可以从一个复盘的改进措施中学习安全发布知识：

其中，关键改进措施就是增加：内容校验、告警拦截、灰度验证、快速回滚、止损恢复等能力。这些其实是一个规范的发布流程必备的，除此之外，还应具备：版本管理、查看变更日志等基础能力。

每次线上发布都伴随着风险，发布过程高度依赖于人的经验和风险识别水平。大多数团队在经历问题后，通过复盘和经验总结，再用规范和强制性的流程约束发布行为，以避免再次发生事故。大部分软件工程实施过程中都会经过这四个阶段：

1.  蛮荒阶段：依赖具体执行人员的经验和认知。

2.  规范化阶段：形成中心、部门级的规范，具备强制性的审批流程。

3.  标准化阶段：形成业务集团（BG）、公司级的标准。

4.  自动化阶段：将经验规范化、将标准工具化、将流程系统化，将执行自动化。

每个团队都需要较长时间从蛮荒阶段往自动化阶段进化。从依靠执行者的风险意识，到依靠系统化的发布风控保障。Shiply 就是满足这一目标的解决方案。

Shiply 作为一站式发布平台，在发布流程的各个节点加入防御和止损机制。实现三级风险控制：

• 事前预防：通过建立标准化、自动化的安全发布流程，预防发布中的各项人因风险。

• 事中监控/自动止损：通过建立灰度策略-AB对比-指标监控，准确告警和自动止损。

• 事后回滚/热修复：通过回滚能力低损降级，或通过热修复能力，无需发版修复现网问题。

从根本上将发布安全由“人为保障”转向“平台保障”，将人的经验转为自动执行的规范标准。

三、  Shiply 安全发布

3.1 事前——安全发布全流程

3.2 事中——监控止损

当一项发布进入灰度阶段时，我们希望能够在灰度早期，影响少量用户时，就能发现问题。但实际上，灰度用户较小时，各项指标的波动都很大，容易出现误报。而常规的监控方案，是通过监控大盘 Crash 率指标来实现的，但这难以发现新增的个例问题，当问题引起大盘波动时，影响已经很大，监控就失去了原本的预警作用。

Shiply 安全发布能够从灰度小样本用户中准确发现问题，我们通过以下思路实现：

1.  建立多维监控能力

我们支持多种指标的监控，及问题全生命周期的观测：

• 支持 Crash、ANR、FOOM、ERROR、隐私合规、业务自定义指标的监控。

• 能够发现灰度新增问题、存量问题恶化、灰度群体问题恶化。

2.  灰度过程中的 AB 对比

我们通过AB对比的方式科学评估每一次发布质量：

3.  提高告警准确性

我们通过告警置信度和动态告警阈值减少误报：

4.  自动止损

我们支持问题自动分析关联性，并自动止损：

•  自动问题归因：平台通过 AB 对比，自动分析问题与发布任务的关联，避免人工分析、归因耗时过长，导致止损时机太晚，造成影响扩大化。

• 自动止损：当问题的指标达到熔断阈值时，平台自动停止发布任务，熔断止损。

  
  

3.2.1 Shiply x Bugly 监控联动能力

Shiply 与 Bugly 在产品和技术上持续探索全面的监控止损体系，建立线上发布的安全防线，为业务的每次安全发布保驾护航。

Shiply 平台通过 Bugly 提供的监控能力来实现 Crash、ANR、FOOM 等问题的监控，配置开关、资源、程序包灰度和市场发布均具备监控止损能力。

• 平台默认监控所有灰度任务，业务可自行设定告警和熔断。

• 平台默认给所有应用开启新增 Issue 告警，覆盖大部分场景。

• 用户可自行开启 Crash 率、突增 Issue 告警和熔断。

• 平台同时支持 ANR、FOOM、Error 等多种指标的监控告警和止损。

• 经过灰度发布流程的任务，会自动进入监控，系统每5分钟抓取数据 Crash 等指标与发布任务进行归因诊断。

• 支持查看 Crash 率等指标在时间上的变化趋势，能够看到每个时间节点的 Crash 率、影响设备数、联网总数。

3.2.2 Shiply 安全发布监控止损效果

通过与Bugly监控发布系统的打通，由发布导致的新增问题，通常在影响设备数小于100人时，可诊断出 Crash、Error 与发布任务的关联性，并及时通知业务通过修改/回滚配置解决，将风险防范于未然，避免了影响面扩大造成线上事故。

3.3 事后——回滚/热修复

发现本次发布出现问题时，可直接停止当前任务，平台会依据下发任务匹配漏斗，自动匹配上一次发布，实现自动降级。也可以选择想要回滚的目标版本，进行手动降级。Shiply 还提供热修复解决方案，实现便捷、用户无感的现网问题修复。

四、  结语

发布的过程就是风险管控的过程。本文以配置、资源等热发布为例，介绍了线上发布存在的风险，以及发布过程中人的风险给发布带来的巨大不可靠性。

Shiply平台通过将经验规范化、将标准工具化、将流程系统化，将执行自动化来保障发布全链路的稳定、高效、安全、合规。Shiply 平台多项下发能力均支持“事前防御-事中监控止损-事后回滚”三级风险管控机制，大幅降低线上事故的风险。

在探索线上监控止损机制上，与 Bugly 平台联动，支持 Crash、ANR、FOOM、ERROR、隐私合规、业务自定义指标的监控、告警、止损。同时通过解决“告警海洋”问题，使告警及时、精准。能够在影响设备数较小时发出告警，同时支持自动止损，助力发布无人值守！

我们在发布风险管控上做了很多努力，但深知与风险斗争的道路没有尽头，因此我们持续提高对发布风险的理解、洞察和防御水平，为业务的每次安全发布保驾护航！