B站容器应用安全变更实践_TakinTalks稳定性技术交流平台

本期作者

张晨铖

哔哩哔哩资深开发工程师

李思捷

哔哩哔哩资深开发工程师

一、背景介绍

云原生，以容器、不可变基础设施、声明式API等核心技术，实现了业务与硬件及底层架构的分离，使业务实例具备了可移植性、环境一致性，极大地提升了运维效率，降低了线上运维操作的稳定性风险，同时又基于微服务、分布式技术解决了传统架构的单点可靠性问题，提升了业务稳定性和开发效率。近年来，越来越多的应用完成容器化、微服务化改造，并逐步将发布、运维流程迁移到PaaS，这在释放了云原生红利的同时也不可避免的引入了更高的系统复杂度，对生产环境的稳定性也提出了更高的要求。

生产环境的稳定性，是各个互联网行业相关公司都关注的，尤其是对于大型互联网公司来说，稳定性就显得更为重要。以B站为例，从诱发稳定性问题的原因分析来看，2022年至今变更及编码问题所占据的比例，在70%以上，问题的诱因也多种多样，譬如缺少稳定性相关必要的可观测指标、灰度观察过程缺失、故障处理机制不完善等等。同时，随着业务体量的不断增大，组织划分与团队协作关系也变得日益复杂，加剧了沟通成本，也间接导致了变更问题难以管控。

对于稳定性来说，业界的一个共识是：防控住变更风险，稳定性问题就解决了一半以上。

在此背景下，本文以B站容器平台 Caster（以下简称 Caster ）为例，从使用场景、技术设计与实现、运行效果等方面详细介绍从今年8月开始，在容器化应用安全变更方向建设落地的几项关键能力。

二、总体设计

2.1 设计原则

2.1.1 规范研发工作流

问题场景：

代码不经过集成、预发环境直接上生产

漏发、错发代码或配置

回滚时漏了配置，db migration等依赖

…

通过以下手段

1. 校验环境发布顺序

2. 管控构建变更日志及发布版本日志

3. 规范可构建/发布的分支

4. 管控回滚方案

实现系统层面严格控制CI/CD环节，丰富各个节点的准入门槛，明确交付内容、提升交付质量

2.1.2 左移管控卡点

问题场景：

发布时才发现配置忘记变更

发布时才发现发错镜像

发布时才发现引入了存在bug的依赖

…

提供diff能力，在发布创建时即感知此次发布会引入的变更内容，包括但不限于：

1. 应用配置

2. 发布侧配置

3. 镜像（代码、依赖库）

4. 中间件（数据库、缓存服务）

增强发布预检能力，在发布创建时感知可能的风险，包括但不限于：

1. SLO指标

2. 校验变更日志及发布版本

3. 容量

2.1.3 发布过程管控

问题场景：

发完了才发现SLO跌了

并发度不合理容量压力过大

新版本问题还没暴露就发完了

发布过程中SLO指标变化不可追溯

…

引入分级发布，按应用等级的分阶段灰度、等待和观察

应用等级	发布阶段	最大接流/应用实例数（单可用区）	进入下一阶段的观察时间
L0	1	1个	5min
	2	10%	5min
	3	30%	5min
	4	50%	5min
	5	100%	–
L1	1	1个	5min
	2	10%	5min
	3	50%	5min
	4	100%	–
L2/L3	1	1个	5min
	2	30%	5min
	3	100%	–

引入发布阶段中的指标观测并对异常行为做出提示或阻断：

1. 业务 SLO 指标（可用率、错误数、延时等）

2. 业务容量（QPS、CPU 使用率、内存使用率）

发布阶段中的信息上报：发布各阶段中接流实例/总实例比例、应用容量、发布单状态等信息，上报到变更管控平台

1. 研发操作发布单的简要信息（继续发布、自动暂停成功、继续流式发布）

2. 执行发布过程中实时展示接流实例/总实例比例、应用容量、发布单状态等信息

3. 对指标观测异常行为进行上报

增强发布过程中的指标与告警感知：

1. 切分新旧版本指标并对比展示

2. 发布页面增加窗口内告警提示

2.1.4 紧急避险机制

问题场景：

潜在bug需要修复

业务运维成本较高需要时间窗口

线上故障需要快速修复

…

提供绿色通道机制，覆盖预检、阻断、审批，配合全域公告、闭环追溯等运营机制，保证紧急逃生和不被滥用

2.2 技术架构

1. 产品层：面向研发、运营、SRE同学，提供变更信息感知及订阅、变更信息搜索、变更防御策略配置、变更防御异常结果感知、变更分析结果查看、变更绿色通道等产品能力。

2. 变更防御：在 Caster 中集成容器变更场景防御能力，包括变更窗口及封网管控，集成变更约束、变更参数、SLO & 饱和度等指标、业务自定义规则的变更前检测，变更前与变更过程中可观测领域的指标、日志等的异常检测，可配置的多级观察点位、观察时长的变更路障，变更过程中自适应容量的弹性伸缩能力，故障和紧急发布场景的变更绿色通道能力。

3. 变更分析：变更前的影响面分析、风险分析、可观测性分析能力，会对变更内容、变更制品和配置、变更影响面、变更执行策略进行分析，同时基于这些分析结果形成变更预检报告，便于变更操作人、审批人用来评估变更风险。

4. 和周边平台的协同

a. 变更管控平台：提供全局通用的变更管控能力，包括标准变更元信息定义、变更信息感知和订阅能力、变更管控策略配置、变更预检防控和防护阻断能力；Caster基于统一变更管控平台获取变更管控策略，按照标准变更元信息定义同步变更状态到变更管控平台，并由统一变更管控平台做变更策略上的决策调整；统一变更管控平台从质量平台获取业务指标数据，用于变更管控策略决策
b. 质量平台：基于可观测平台的基础指标监控数据，提炼分析业务SLO、业务饱和度指标，并支持按业务场景设置自定义指标；支持业务指标异常自动升级故障
c. 可观测平台：提供业务、K8s Node和容器资源等的基础指标监控数据

2.3 核心流程

三、详细设计

3.1 发布预检

发布预检旨在将发布过程中的风险项尽可能左移至发布开始之前。

根据 流程规范、稳定性、变更管控 三个维度下钻预检项，由容器发布平台和变更管控平台进行发布预检收口：

1. 容器发布强相关的由容器发布平台收口

2. 容器发布关联性较弱、与应用强相关，可供其他平台共用的部分由变更管控平台收口

3. 稳定性相关的，可靠性要求较高的预检项由发布平台收口

从而保证了发布强相关预检的稳定性，同时兼顾了上下游链路对发布预检项的扩展性诉求。

预检维度	预检项	收口平台
流程规范	镜像是否填写变更日志	容器发布平台
	镜像是否经过测试、预发环境发布
	规范可构建/发布的分支
	管控回滚方案
稳定性	镜像版本是否为已知有bug或废弃版本	容器发布平台
	依赖库和中间件的版本及变更
	容量配置是否合理(HPA合理性，发布并发度，实例数)
	SLO指标是否存在风险
变更管控	是否触发安全管控‍	变更管控平台
	是否触发版本封控(节假日、重大事件)
	其他平台引入的变更预检(代码扫描、混沌测试等)

3.2 分级发布

分级发布旨在通过引入强制发布阶段观察窗口，降低变更导致故障的产生几率和影响范围。

3.2.1 前置准备

达成目的需要一些前置条件：

1. 发布过程可观测指标细化

SLO指标只有应用粒度，需要细化至版本粒度
SLO指标只有一个聚合指标，需要细化到http、grpc、可用率等更细粒度的指标

2. 应急场景下的逃生能力

故障场景

故障真实发生时，第一要务应当是快速止损和恢复，仍需要分级等待有可能拖长故障止损时间，使得故障进一步恶化，故而设计在故障已经发生的场景下，联动质量平台，自动开启绿色通道，跳过分级等待。

紧急场景

有些场景未必已经通过可观测或人工的方式触发故障，但仍然有快速发布的需求。例如：已经识别到的高危潜在bug的快速修复；热点事件或突增流量下的预防式发版。故而设计在发布全生命周期设置了快捷的绿色通道申请流程

3.2.2 发布逻辑适配

发布形态主要有单应用单可用区发布和多应用多可用区组合发布

发布策略在抽象后主要有迭代发布和蓝绿发布

迭代过程主要有批次发布和流式发布

发布行为主要有继续和继续所有

发布策略适配

迭代发布

迭代发布是在发布过程中实例随着并发度逐渐替换为新版本的策略，故而对应的分级发布管控行为可以理解为在实例数到达对应阶段规则要求时进行等待。

// 发布阶段初始化...// 根据dep类型、部署策略、是否属于组合发布等信息判断是当前是否支持强制等待，是否上报前置校验信息；var phase inttargetReplicas := newGrapherTargetInstancedep := newGrapher.Deployment()if dep.PhasedPublish() {  if oldGrapher != nil {    err = oldGrapher.Refresh()    if err != nil {      deployStepInfo.Paused = false      deployStepInfo.ErrorMsg = err.Error()      return deployStepInfo, err    }  }    // 获取规则和等待时间  waitRule := newGrapher.WaitRule(logger)  waitTime := newGrapher.WaitTime(logger)    // 获取开启的绿色通道  greenChannel := newGrapher.GreenChannel()    // 绿色通道、计算批次和分级规则共同作用下当前阶段目标版本实例数  targetReplicas, phase = calcParamsByWaitRule(logger, waitRule, waitTime, newGrapher.QualifiedReplicas(), newGrapherTargetInstance, greenChannel) // 基于等待规则，覆写newGrapherTargetInstance  newGrapherTargetInstance, oldGrapherTargetInstance = adjustGrapherTargetInstance(newGrapherTargetInstance, oldGrapherTargetInstance, targetReplicas)  if oldGrapher == nil { // 无旧版本情况    oldGrapherTargetInstance = 0  }}// 上报变更前置校验信息reportErr := reportStepInfo4PreCheck(newGrapher, oldGrapher, targetReplicas, phase, batchSize)if reportErr != nil {  beego.Error(reportErr)  //logger.LogInfo("前置校验信息上报失败：", reportErr)}

蓝绿发布

蓝绿发布则是在发布伊始就全量拉起新版本实例，并在后续过程中梯度接流，故而该场景的分级发布管控行为可以理解为对接流阶段的管控，即在接流阶段实例数满足对应阶段规则要求的实例数时进行等待。

迭代过程、发布行为适配

批次发布和流式发布的主要区别在于：批次发布是按并发度步进，等当前批次完全更新完后再进行下一批次更新，可能存在长尾的情况；流式发布允许容忍一定比例的异常实例，按并发度执行发布时，如果当前并发轮次有异常或未发布完成的实例，在未达到比例时允许继续执行后续轮次的发布。

故而按分级发布规则对新版本实例总数进行实例数发布等待观察窗口点位计算后，调整每阶段目标至对应点位值，即可在发布至阶段目标点位时完成对应阶段进入等待流程。

在等待后再根据当前行为是否是继续所有，是则自动推进下一阶段的发布流程。

组合发布适配

组合发布主要面临的场景在于：

1. 各个不同应用的分级规则不同导致等待节点和时长不同

2. 绿色通道开启场景下的规则

聚焦使用场景后可以发现，当前组合发布主要作为多应用间的并行操作入口，对并行的应用间并没有阶段保持强一致的诉求，故而将继续行为幂等后即可覆盖：让需要等待的应用继续等待，已经等待或不受管控的应用继续发布行为。

3.2.3 发布态HPA

在Caster旧版本实现逻辑里，为避免HPA和发布流程的冲突（如扩容/缩容了不符合预期版本的Pod；业务手动扩缩容发布过程中HPA动态调整了目标实例数等），影响发布流程和稳定性，会在发布过程中禁用HPA。然而发布过程长的可能持续数小时甚至数天，过程中难免出现流量高峰导致的扩容需求，稳定性风险切实存在。

因此设计引入了发布态HPA，通过抽象新的控制面，统筹决策HPA和发布过程产生的变更。

设计原则

1. 容量因子单向从上往下渗透

2. 容量因子来源收口且闭环

3. 容量最终值由唯一的模块决策

4. 发布过程中业务容量风险控制

5. 完全适配现有发布流程

6. 完全适配分级管控

3.3 绿色通道

绿色通道旨在在紧急场景下提供快速逃生的通道，在风险已知或线上问题、故障已经发生的场景执行快速修复。

3.3.1 场景剖析

1. 故障真实发生

SLO指标故障自动触发

人工在质量平台录入的故障

2. 有潜在风险

线上有代码bug，但还没有业务触发，触发则可能引发风险

上下游引入的问题需要快速降级

3. 应急场景

突发热点导致部分服务需要紧急扩容

3.3.2 流程设计

绿色通道作为逃生通道，应当为业务提供端到端的逃生通道，避免业务一次变更在多个平台申请绿色通道；与之相应的，绿色通道的来源可能有多个渠道多种平台来源，需要在全链路平台共同起作用。

另外与分级发布类似，各个平台的SLA要求不同，容器发布平台的SLA要求更高，故而需要为SLO规则设计稳定性流程。

四、实现效果

发布过程指标可视化效果展示

发布预检的效果展示（为方便演示，后台设置阈值为101%）

分级发布效果展示

五、总结与展望

1. 自定义分级发布规则

不同部门、业务的管理诉求不同，为满足更严格的管控诉求，需针对不同的应用范围执行不同的管控规则。

2. 自定义指标预检及发布提示/阻断

除了SLO指标及基础的饱和度指标之外，还需要增强对业务核心指标的覆盖（如发布平台的变更单成功率等），提供更贴近业务特性的预检及发布提示/阻断能力。

3. 智能分析和评估发布风险

基于应用画像、用户行为画像、发布日志等实现智能分析和评估发布风险，沉淀变更防御专家经验到发布系统，将故障风险消除在变更操作执行前。

六、参考文献

1、阿里巴巴超大规模Kubernetes基础设施运维体系揭秘：https://developer.aliyun.com/article/840561?utm_content=m_1000314776

2、浅析微服务全链路灰度解决方案：https://developer.aliyun.com/article/918366?utm_content=m_1000342276

3、 SOFAStack：http://nobodyiam.com/2020/12/26/large-scale-implementation-and-prospect-of-sofastack-mesh/

4、蚂蚁集团变更管控平台AlterShield：https://blog.csdn.net/TRaaS/article/details/131174460

开发者问答

关于容器平台的安全生产环境建设，大家还遇到过哪些典型的场景和问题，最终又是怎么解决的？欢迎在留言区告诉我们。转发并留言，小编将选取1则最有价值的评论，送出日版赫斯缇雅手办景品一个（见下图）。12月26日中午12点开奖。如果喜欢本期内容的话，欢迎点个“在看”吧！

往期精彩指路

本篇文章来源于微信公众号：哔哩哔哩技术

本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。

B站容器应用安全变更实践

相关推荐

云厂商CDN故障后，连夜设计了云边端协同新方案

会员购故障演练平台实践

B站稿件生产平台高可用建设分享

发表评论

请登录