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

导语：Shiply是腾讯端服务（Tencent Device-oriented Service）下的一站式客户端发布平台（支持配置开关、动态资源、热修复、应用升级、应用市场等发布能力）。平台通过多年积累的发布经验，并结合业务发展的需求，逐步将发布规范化从专项、表象、问题驱动的方式转变为工具化、系统化的落地与实践。 Shiply 和 Bugly 在产品和技术上持续探索全面的监控止损体系，建立线上发布的安全防线，为业务的每次安全发布保驾护航。

背景

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

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

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

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

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

二、发布存在哪些风险

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

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

• 使用不规范：错配、漏配、滥用（不需要配置时使用了配置）
• 发布不规范：随意发布、无验证发布、无灰度发布
• 使用了配置、资源但没有兜底处理措施
• 优先级不合理导致配置、资源互相覆盖
• 依赖审核人员对风险的认知水平

系统风险

• 配置变更时缺乏参数合法性校验
• 错误的配置、资源无法快速回退
• 缺乏配置、资源异常检测机制

舆论与合规风险

• 运营内容包含民族歧视、地域偏见、宗教矛盾、民俗差异、文化冲突等内容

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

• 改进措施

1. 增加XX服务白名单生成结果的校验及告警拦截能力；
2. 增加XX服务白名单更新的灰度验证逻辑，提前发现异常；
3. 增加XX服务白名单的快速恢复能力；
4. 加强产品侧的联动恢复能力。

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

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

1. 蛮荒阶段：依赖具体执行人员的经验和认知。
2. 规范化阶段：形成中心、部门级的规范，具备强制性的审批流程。
3. 标准化阶段：形成业务集团（BG）、公司级的标准。
4. 自动化阶段：将经验规范化、将标准工具化、将流程系统化，将执行自动化。

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

descript

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

• 事前预防：通过建立标准化、自动化的安全发布流程，预防发布中的各项人因风险。
• 事中监控/自动止损：通过建立灰度策略-AB对比-指标监控，准确告警和自动止损。
• 事后回滚/热修复：通过回滚能力低损降级，或通过热修复能力，无需发版修复现网问题。

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

Shiply 安全发布

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

• 按自定义时长 + 自定义批次的灰度
• 按自定义时长 + 自定义累计用户数的灰度
• 灰度结束后是否定时发布
• 灰度结束后是否暂停发布

发布审核审核人员可以清晰看到owner对发布任务的修改内容，以便评估修改对线上的影响。

3.2 事中——监控止损

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

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

1. 建立多维监控能力

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

• 支持 Crash、ANR、FOOM、ERROR、隐私合规、业务自定义指标的监控。
• 能够发现灰度新增问题、存量问题恶化、灰度群体问题恶化。

1. 灰度过程中的 AB 对比

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

• AB对照：设置对照组和实验组，确保实验的公正性和结果的可比性。
• 流量分配：根据实验需求，合理分配流量，确保数据的代表性。
• 实验指标监控：在灰度中，针对实验组和对照组，实时监控各项指标的变化。
• 告警置信度：根据灰度设备量级和Crash率的波动关系分布符合正态分布的规律，通过算法计算告警的置信度，在少量样本时减少误报，提高告警可信度。

1. 提高告警准确性

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

• 根据灰度人群大小设置告警阈值：在灰度初期，由于样本量小，设置较高的告警阈值以减少误报。随着灰度范围的扩大，逐步降低告警阈值，提高监控的敏感度。
• 根据历史数据设置告警阈值：参考历史数据，结合当前的业务情况，合理设置告警阈值。
• 提高告警的可操作性：当收到告警信息后，接警人应该可以针对这个告警做出相应的操作。

1. 自动止损

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

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

3.2.1 Shiply x Bugly 监控联动能力

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

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

• 平台默认监控所有灰度任务，业务可自行设定告警和熔断。
  • 平台默认给所有应用开启新增 Issue 告警，覆盖大部分场景。
  • 用户可自行开启 Crash 率、突增 Issue 告警和熔断。
• 平台同时支持 ANR、FOOM、Error 等多种指标的监控告警和止损。
• 经过灰度发布流程的任务，会自动进入监控，系统每5分钟抓取数据 Crash 等指标与发布任务进行归因诊断。

descript

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

descript

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

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

3.3 事后——回滚/热修复

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

结语

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

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

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

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