B站安全生产专项建设实践

在一些列变更事故后，我们内部经过多次的沟通、决议，由技术委员会（下文简称 TC）先后发布《安全生产门禁》、《系统变更管理规范》、《代码分支发布规范》三个围绕安全生产的管理规范和政策来指导内部的安全生产建设，规范变更的同时让大家重视和敬畏线上环境。

安全生产的主要要求可以集中总结为以下几点：

1. 明确不允许发布的时间范围，以及封禁的操作

2. 明确定义发布过程的：可灰度、可观测、可恢复

3. 明确定义环境与代码分支的关系

为实现要求中的各项规范内容，底层平台也需要进行功能上的改造和适配，并通过一定的管理中间环节，对不断具体和丰富的规则进行托管，那么我们是如何将这一系列规范通过系统的方式拆解又是如何落地的，下面会阐述整体的设计方案。

安全生产主要涉及的平台如下图所示，包含：变更管控平台、变更平台、质量平台、告警/监控平台等：

基于用户通过变更平台执行变更操作的基本调用关系如下图：

平台在项目中的定位：提供最靠近用户变更操作的执行平台，包含：容器、网关、配置、物理机等执行发布的平台。

变更平台在支持用户发布的过程中需要做到，可灰度、可观测、可恢复，同时执行发布过程之前需要进行前序检查以保证进入到发布过程的应用符合要求。

1.发布前序检查：

当前发布前序检查会包含：资源容量、SLO 指标、应用以及其关联组件的变更 Diff、业务自定义检查规则、公司要求规则等。在发布之前提示，本次发布中未达要求的检查项，在正式进入发布之前提前发现部分问题并及时拦截，减少故障。

2. 可灰度：

按照《系统变更管理规范》的要求，不同等级的应用既需执行不同时间（最少5分钟）和批次的发布等待，也不允许同时执行多可用区的发布（极少数实在无法在发布中执行分级发布规范的应用除外），一旦出现变更异常可及时刹车和控制爆炸半径，最大限度的减少故障影响面。

3. 可观测：

发布过程中的可观测主要包含两个部分，指标类、告警类；目前指标类会涵盖服务可用率指标和饱和度指标，可用率指标作为默认指标悉数展示，饱和度指标由业务自行定义并开启，目的为了让执行操作人可以更快速的感知到应用的异常，及时做出判断从而规避故障。

这块我们实现过程中做了几次迭代优化：

第一个版本，仅展示当前版本的可用率情况，实现过程中发现，很难通过一个版本当下的数据判断新版本服务的可用率情况；

第二个版本，展示上一个基线版本与当前发布版本的对比数据，但是仍有优化的空间，因为展示值仅为瞬时值，很难直观看到趋势，并且发布过程中的告警信息不够明确直观；

第三个版本，展示上一个基线版本与当前发布版本的数据趋势，覆盖当前版本发布的时间段，同时增加该时间段内执行发布应用的告警信息辅助定位。

4. 可恢复：

关键在于可以快速止损，在发布之初，平台会要求用户对于本次发布如果失败，填写相关的止损策略，这不只是一个简单的“回滚”，更重要的是让用户重视发布可能出现问题的风险提醒，也希望可以让用户在遇到问题时，可以有所准备地完成一系列止损操作。同时配合管控平台的绿色通道加以快速逃生、快速恢复。

可恢复除了发布平台侧的快速回滚以及快速逃生外，还有常态化的故障演练、多活切流演练等，加速故障发生后的恢复速度。后续我们也会有相关的主题内容和大家分享，聊聊我们对于快速恢复的一些思考和落地实践案例。

基于以上四点实践下来，仍有需要我们去思考和优化的，如变更过程中是否能更少的让人去参与，让指标变更更具自动化，让应该刹车的发布执行刹车，让符合标准的发布合理放行，增加应用上线的效率。

因此后续的改进会由平台侧加强与指标的联动，对于没有异常的情况，用户可以直接执行发布，无须强制等待 5 分钟，对于异常情况，平台会快速给出问题原因以及开启逃生通道，用于止损。”

平台在项目中的定位：作为安全生产的基座系统，通过定义标准的变更信息结构和交互协议，提供统一的变更信息归集、变更感知&订阅&检索、变更强流程执行、变更防御配置&检测&阻断和应急逃生等能力，确保公司内部涉及变更的平台能够标准化、轻量化的接入和纳管，实现公司层面基架&业务系统在变更领域的统一化管控，以期在灾难来临时能够快速识别变更风险，降低故障影响。

1、变更元信息定义

所谓“知己知彼，百战不殆”，我们想要管控好变更，首先需要知道有哪些变更。在公司内部，存在多少个平台，每个平台又存在多少种变更场景，这些变更场景又具体会产生什么样的影响。

基于这种思考，我们采用程序化的编码设计，将变更的元信息像代码的模块、类、实例一样清晰定义出来。通过这样的定义，我们就可以清晰知晓整个变更域内，存在多少变更场景，哪些变更场景会对我们核心的业务、应用或集群造成影响。

基于这个基础框架，我们在后续的持续迭代运营上，会深入研究和细化每个变更场景，定义单一变更场景的对象、环境、时间和人员等纬度，并适应性的增加防御策略进去。

2、变更数据归集

在异常和故障场景下，为提升变更类问题的响应和解决速度，我们定义统一的变更信息模型，将内部系统的各类变更按照变更平台、场景、对象、环境、时间和人员等纬度进行抽象，通过OpenAPI、SDK和消息队列等方式，让上层变更平台快速接入。基于统一建模和归集后的变更数据，我们就能实现快速地异常变更定位、上下游关联分析和检索，大幅缩短变更类问题的排查定位时间。

3、变更防御阻断

传统模式下，每个变更平台都会在平台内的变更流程中增加一些防御阻断策略。这些防御策略有业务专属的，也有通用的。从公司管控层面来讲，我们围绕一些关键的场景梳理和制定了通用性的限制规则，并通过TC下发了一系列的强制约束和手段措施。

在系统层面，变更管控平台承载了这些约束和措施的定义、实施和托管，在平台内这些内容被定义为防御检查项。每个防御检查项，存在着检查项的检查定义和检查执行。

在单个变更场景内，上层变更平台可以在变更执行的准入阶段、批次过程阶段和后置完结阶段加入这些防御检查项来激活防御。

通过变更管控平台提供的统一变更框架和防御能力，上层业务平台可以快速接入这些已有的变更防御能力，大幅降低每个平台的改造成本。

4、应急逃生能力

随着变更被统一化管控，我们不免担忧这些严格的限制策略对故障恢复造成效率上的影响。基于此，我们单独开辟了逃生能力通道，确保应用在故障场景可以快速响应，绕行非必要防御策略。在逃生策略方面，我们采用了紧急和常态化两种策略。

绿色通道：主要用于快速止损，仅豁免 1 个小时，即开即生效。开启绿色通道后，以私信的方式发送给操作人、应用研发、应用负责人，同时支持订阅方式将消息发送到工作群。

白名单：主要用于长时间豁免管控规则，一般用于活动期间的保障场景下一旦出现问题需要快速止损的情况，需要事前提交申请，并审批通过。

平台在项目中的定位：度量业务/应用的SLI并设置对应的SLO，基于可用率SLO提供发布检测和阻断阈值，给到变更平台做变更风险检测，并对阈值持续运营、保准

1.度量业务/应用的SLI并设置对应的SLO

质量平台定义了业务/应用的常见的SLI指标，如可用率、延迟、流量，并在应用框架、APIGW、SLB 链路中度量实现，基于标准化的元信息和指标，自动化生成一整套SLI和SLO规则

2.基于SLO定义发布检测和阻断阈值

发布过程中根据已经定义的可用率指标设定两个类型的阈值，用于配合发布过程的提示和阻断。

• 检测阈值：该阈值用来提示当前应用指标存在异常，低于可用率SLO要求，但是尚未严重到发布要被阻断和故障应急；

• 阻断阈值：该阈值一旦触发，则表示当前的应用出现了严重的问题，需要立即止损，故障应急平台会基于SLO阈值下跌自动拉起故障应急，并迅速进入应急协同流程。

3.阈值持续运营、保准

在日常使用中，变更时基于SLO的检测、阻断会遇到服务不会拦截、频繁拦截或误拦截的情况，分析发现常见case如下

• 内网服务，未接入APIGW、SLB，服务框架埋点指标也不规范，SLO默认没采集到，需要推服务覆盖

• 核心服务默认检测阈值是99.99%，但此服务实际日常可用率为99%，导致被频繁拦截，需要调整阈值

• 服务接入了APIGW、SLB两个流量网关，都被SLO系统采集到，但SLB的流量已不影响服务主功能，需要关闭SLB的检测、阻断

为此我们设计了阈值巡检的能力，通过经验与服务常态化指标拟合算法模型动态调整阈值。

4.公司全域稳定性大盘：

平台通过可用率指标绘制了公司的整体稳定性大盘，可以让 SRE 团队，快速获悉存在风险的业务并做出应急响应。

项目落地过程一共分为四个阶段：最小 MVP（方案验证）、增加管控条件（完成单一平台的所有管控规则接入）、扩大管控覆盖面、推进持续运营。

• 第一阶段：最小 MVP

为保证方案的可行，第一阶段仅设计了规范中最为重要的几个部分，由发布管控平台和容器变更平台执行接入。

变更管控平台：实现托管分级发布管控，以及封网管控按照应用维度的规则定义，由接入方容器变更平台进行实时检查。

容器发布平台：对接变更管控平台在用户执行发布过程中进行分级等待，对接变更管控平台的逃生能力。

• 第二阶段：增加管控条件

增加发布过程中可观测的信息展示，逃生通道能力重新定位，实现分支管控规范接入，实现应用/业务可用率管控规范接入，完善安全生产的全部功能。

变更管控平台：支持业务自定义管控规则；重新定义逃生能力涵盖白名单以及绿色通道；对接构建平台接入分支管控规范，对接质量平台接入发布观测、阻断阈值规范；对接发布平台进行发布事件的元数据统一管理。

容器发布平台：完善发布前检查项内容；增加应用可用率、错误数、QPS 等观测指标，增加发布过程中的告警信息展示完善发布中可观测；增加观测、阻断指标的提示与禁止发布；增加绿色通道入口实现快速逃生。

质量平台：完成应用/业务的可用率指标定义，设定发布中的观测、阻断指标阈值，针对所设定的可用率指标、发布观测阻断阈值的常态化巡检和动态调整。

告警/监控平台：计算引擎优化以及核心指标的拆分，对稳定性相关指标的打点间隔以及计算间隔优化至秒级；实现基于推荐算法的根因分析。

• 第三阶段：扩大管控覆盖面

增加更多的发布平台实现管控能力，包含：物理机发布、网关配置变更、应用配置变更发布平台，在支持发布能力的同时，优化分级发布管控等待限制，分级仅做刹车，不做强制等待，提升发布效率。

• 第四阶段：推进持续运营

安全生产除了完成平台功能的开发还需要同步进行公司内部的宣传推广，并针对用户反馈内容做合理调整。

1. 完成平台功能上线前的使用宣讲，收集用户使用问题，优化迭代

2. 围绕“安全生产”进行公司内部文化宣导和培训

3. 增加“安全生产”考试，后期以考试结果准入发布操作

当这一系列的内部规范正式以系统的方式生效的时候，会听到一些反对的声音，认为规范限制了以往自由的发布，影响了工作效率。变革的过程总是存在着阵痛，但是不变革就是长痛，当总体数据开始表明，变更故障比例开始明显下降的时候，这些阵痛都是值得的。当然这些管控都要与每一家公司的实际情况相结合，既要保证安全又要满足合理性，需要适当听取一线的声音，在可行范围内做调整。无论是作为底层基础平台产品的设计还是文化层面的宣导，稳定性建设、安全生产的意识都要一直持续贯彻下去。

本文旨在抛砖引玉，后续我们还将推出围绕安全生产各平台的具体实践介绍，尽请期待。

参考资料：

《Google SRE 运维解密》

《Google SRE 工作手册》

《Google 系统架构解密-构建安全可靠的系统》

《【IDC 蚂蚁集团】2023安全平行切面白皮书》

《AlterShield-变更风险防控平台，有效防控变更故障》

《阿里云CRE-基于变更管控和故障体系的稳定性实践》

保障安全生产方面，大家做过哪些努力，遇到过哪些困难，又有哪些经验呢？欢迎在留言区告诉我们。小编将选取1则最有价值的评论，送出原田治经典款帆布袋1个（见下图）。12月5日中午12点开奖。如果喜欢本期内容的话，欢迎点个“在看”吧！