# 一分钟精华速览 #
大约70%的故障都是由变更引起的，B站也深受其害。在经历了多起由变更引发的事故后，B站设计并实施了变更防控平台，从技术支撑能力、技术落地、跨领域赋能、组织文化建设等多方面入手，以期变被动应对为主动防御。目前，该平台已接入60 平台、400 场景，每天执行超过1000次变更检测，日拦截100 次潜在故障。自平台上线后，B站变更类事故占比得到有效下降，实现业务稳定性和效率的双重提升。详细的解决策略和方法，请参阅文章正文。
作者介绍
哔哩哔哩平台工程负责人——刘昊
TakinTalks稳定性社区特邀专家，哔哩哔哩平台工程负责人。从业十余年，专注于运维效能、质量运营等领域。2017年加入哔哩哔哩，先后负责了B站运营研发、中间件研发和SRE体系等方向，构建了B站的统一作业&流程&鉴权服务，主导了数据库&缓存相关中间件的自研落地。目前主要负责SRE体系化建设和人员转型培训，设计落地应急响应、变更防控、风险治理、容灾演练和运维数据资产等系统，持续优化业务稳定性、提升人员效率和降低资产成本。
温馨提醒：本文约8000字，预计花费13分钟阅读。
后台回复 “交流” 进入读者交流群；回复“Q115”获取课件；
背景
在当下，变更防控为何备受关注？外部因素显而易见：行业故障数量持续上升，其背后原因错综复杂。在过去几年中，行业普遍追求成本效益和效率提升，却也带来了一些长期问题。随着稳定性运营能力的增强，我们开始发现并解决之前未曾察觉的问题。云原生和微服务技术的广泛应用使故障原因更加多样化，服务变更可能意外地影响到其他看似不相关的服务。此外，变更执行人员的匆忙和缺乏深思熟虑，未能进行充分的规划和监控，也是导致故障频发的原因之一。更重要的是，变更在故障原因中占据了高达60-75%的比例，这一数据不容忽视。
内部动力同样至关重要。作为稳定性领域的专业人士，我们常处于被动的状态，长期精神紧张。我们逐渐认识到，仅依靠事后的被动防御和响应远远不够，必须采取更主动的措施，将工作重心前移，从传统的后置保障转向前置防控，尤其是在变更防控、混沌工程和风险管理等关键领域，以弥补当前稳定性领域的不足。
基于外部和内部动力的考量，我们开始思考推动变更防控平台的设计，实现业务稳定性和效率的双重提升。
一、如何制定策略和衡量战略价值？
1.1 围绕变更整活的思路
在当前的环境下，为什么要特别关注变更管理？这是因为，尽管变更是软件工程中一个无处不在的概念，但由此引发的故障并没有因此而减少。我们必须思考，如何通过管理变更来降低故障发生率和影响面，这是提升稳定性的一条可持续、高ROI的路线。
我们首先要了解行业是如何进行变更管理的。从早期的 ITIL 到现在的更先进的实践，几十年里变更管理始终是一个核心议题。从V2的变更审查请求的提交，到V3的变更评审评估，再到V4将变更纳入价值流交付的过程中，都在不断深化对变更管理的理解。但我们也认识到，仅仅通过管理手段很难有效管理变更，因为变更最终是由人执行的，而人的不确定性是一个重要因素。
因此，我们提出了两个主要的解决思路：减少变更的数量和提高变更的质量。减少变更数量并不意味着减少故障的概率，因为软件层面的变更不会因为数量的减少而减少内容的复杂性；而提高变更质量，在全集团内又会变成人的管理问题，难以得到有效的整体性提升。
基于这些思考，我们认为应该采用软件工程和系统工程的思维来专项解决变更问题。我们需要建立统一的信息中心，实现变更行为的统一托管和管控。通过中控系统，可以将以往的规章制度转化为系统策略，统一管理各个平台的变更。此外，还需要建立变更的法律法规，并进行文化宣导，提高员工的意识和规范性，从而形成一个全面的变更管理体系。
1.2 定性和定量价值衡量
通过提升变更的可控性，能够有效降低由变更引发的故障数量，从而增强业务的稳定性。基于这个战略价值，我们会常态去做定性和定量的价值衡量。
定性方面的价值体现在四个方面。首先，通过变更领域的能力建设，实现标准化能力的实施，形成一系列变更的定义和标准流程。其次，建立技术框架后，构建体系化的管控能力，为变更领域提供健全的运营手段，输出标准完整的解决方案，规范变更行为，扩展到整个平台的变更管理。接着，需要增强观测能力，尤其是在变更过程中的可观测性。最后，技术的普惠性，通过建立统一的变更管控平台，使更多中小平台和业务受益，无需投入过多时间和成本。
在定量方面，我们专注于具体数据和结果。我们期望通过引入变更管控，能够拦截故障数量、减少整体故障数量，以及降低变更导致的故障占比。此外，我们也关注变更影响的时长和范围，通过建立统一的数据中心支持故障分析，快速定位变更问题点，缩短变更影响时间。最后，我们致力于提升防御能力，确保核心变更场景得到有效覆盖，并在所有场景中实现有效的故障防御。
二、如何设计变更防控体系？
2.1 从挑战而生的方案
在这里，我想引入产品领域的两个核心思考模型，希望能为技术设计提供一个新的视角。我们关注的焦点在于用户价值和交易的相对价值。
用户模型分析场景:用户价值=新体验-旧体验-替换成本 交易模型分析场景:相对价格=(直接成本 交易成本)÷效用组合
简单来说，我们正在构建一套变更领域的全新解决方案。需要关注的是，这套方案能为研发、测试、各个平台的使用方等职能角色带来哪些新的价值。方案设计的目标是确保新的体验要优于旧的体验，并且这个体验的增长，是要大于迁移和替换成本的，即相对而言要有增量。我们不希望开发出的新系统最终只是无谓的折腾。
第二个方面是交易模型。我们构建了一个独立的变更领域平台，需要将过去几十个旧平台迁移过来，要从交易的角度评估，所提供的价值和成本是否相对合理和有效。
具体来说，可以将挑战分为技术与文化两个部分。
从技术角度来看，挑战非常明确。B站有大量的内部变更平台，数量从几十到上百个不等，参与这些平台使用和建设的角色众多，涉及到的变更对象也多种多样，包括各种服务、容器集群等。这导致改造成本非常高。解决这一问题的方法包括实施标准化、统一模型和统一流程。我们还会对变更进行分级，目的在于不必对所有平台都提出最高要求，而是根据重要性进行分级管理。在变更领域，要做好的是建立生态能力，从而为用户带来更多价值。在执行过程中，我们将优先处理高优先级的场景，快速取得成果后再逐步推进，并进行长期的、持续的运营。基于这些，我们得出结论，需要构建一个独立领域的技术运营平台。
在文化方面，需要强化风险意识，并在企业中建立强有力的红线意识。过去在平台建设中，我们可能过于追求效率，而在资源投入和沉淀通用方法上做得不够。解决这一问题的方法是，首先向高层传达变更领域建设的长期收益，然后推动企业制度和条例的完善和落地。最后，在推行方面，我们将举办各类活动，如安全生产月，以增强宣讲力度。这些都是围绕组织文化建设的重要内容，后续我将详细分享平台建设和组织文化的相关实践。
2.2 体系化解决方案
我们设计了一套体系化的解决方案，类似一个房子的模型，整体上分为四个部分：技术支撑、技术落地、跨领域赋能和组织文化。
技术支撑：依托底层数据支撑，比如服务树、CMDB、可观测，来构建变更元模型和变更实例模型。围绕这些模型，将实现变更核心能力，包括变更托管、变更感知、变更防控、价值可视化和开放能力。这些核心能力将为用户输出产品能力，如概览大盘、托管接入、检索订阅、防控配置、变更分析、数据可视等，构成了技术支撑能力。
技术落地：我们将在研发过程中的代码变更、配置变更，以及基础架构中的流量调度系统、资源管控系统、作业调度系统和常态维护系统中实现这些技术支撑能力。例如，数据库管控系统属于资源管控类，而四层七层负载均衡的流量调度则属于流量调度类。此外，业务配置变更，如运营活动中的开关变更，也需要纳入技术落地的范畴。
跨领域赋能：我们将变更能力应用于应急响应场景，进行变更定位和溯源。还利用变更能力进行攻防演练，模拟故障，验证变更领域建设的防御能力。此外，我们关注大模型技术，考虑与AI团队合作，利用大模型技术处理变更领域的数据，提供变更领域的问答服务，帮助用户更有效地查询变更信息、给出防控建议和意见。目前这块工作正在由B站内部专家小组落地。
组织文化：单纯依靠技术建设是不够的，还需要组织和文化的支持。我们将推进安全生产委员会的建设，推行安全稳定性负责人制度，制定安全生产要求和安全变更规范，建立红线文化，并通过培训、考试、专题分享等活动进行宣贯。
三、B站有哪些落地实践经验？
3.1 变更定义
变更定义的核心任务是构建统一的变更描述模型和过程模型，以此提升人与系统之间、系统与系统之间的认知。通过合理分级，我们确保变更的实施能够精准发力。
3.1.1 统一变更描述模型
变更的描述模型旨在解决一个基本问题：变更是谁执行的、在什么时间、通过哪个平台、对哪个具体对象进行了怎样的变更，即变更来源、时间、执行人员、变更对象、变更环境以及变更的具体内容。我们希望通过模型抽象出这些信息，类似于在编写代码时定义一个类，明确类的名称、功能、输入输出以及具体的变化。
3.1.2 统一变更过程模型
接下来需要建立一个统一的变更过程模型，详细描述变更过程中的具体操作。在这个模型中，将加入变更前的准入检查和变更后的准出检查。我们可以将变更过程细分为多个阶段，每个阶段都包括前期检查和后置检查。这样的设计允许我们在每个阶段实施灰度发布和批次准出，控制变更的影响范围。
3.1.2 图 - 变更过程被分解成3个部分
3.1.3 变更等级分层
此外，还引入了等级分层的概念。这样做的目的是实施有效的管控，能够在实施变更时有的放矢，对高优先级的场景进行重点管理，而对低优先级的场景则采取较低级别的管控措施。通过这种方式，可以确保变更管理既严格又灵活，以适应不同场景的需求。
在变更防控方面，我们参考了阿里的做法，将其分为五个主要部分。
3.1.3 图 - 参考阿里的变更防控划分了五个层级
3.2 变更托管
定义了变更之后，我们的目标是通过托管变更的源信息、行为信息和过程信息来实现对变更的全方位管控。拥有变更的干预能力至关重要，如果不能在出现问题时及时干预和控制变更，那么就只是具备了信息管理的能力，而没有真正的控制能力。
3.2.1 变更元信息托管
基于前面提到的模型，我们需要录入产生变更的业务平台和场景信息。平台信息包括对变更的平台、负责人、覆盖环境、管控覆盖率及其级别进行详细记录。场景信息则包含名称、环境、变更对象、变更内容以及管控策略等描述。
3.2.1 图1 - 变更元信息托管-平台信息
3.2.1 图2 - 变更元信息托管-场景信息
3.2.2 变更信息托管
为此，我们提供了多种托管方式，包括OpenAPI、SDK和消息队列，以便将变更信息上报并对接至系统。上报的内容应包括变更场景的具体实例信息，以及变更前后的信息对比。
3.2.3 变更过程托管
过程托管则要求将变更过程精细化拆分，分为不同阶段和批次，并在每个阶段前后加入检查项。这样的设计使得我们能够在变更流程的每个环节实施必要的检查和控制，确保变更过程的安全性和可控性。
3.3 变更感知
在实现了变更托管之后，就有了变更感知的能力。这意味着，随着变更信息的上报，我们围绕全域构建了一个变更信息整合的体系。通过对这些信息的清洗、分批处理和关联，得以建立起多样化的检索和触达手段，从而实现变更信息在人与系统间的灵活流通。
3.3.1 变更检索
变更检索功能允许我们在出现问题时，针对单一对象或平台进行查询，比如查看特定人员在特定时间段内对哪些平台进行了变更操作。检索维度非常广泛，可以基于之前结构化的信息，对变更标题、变更状态、源平台、对象、环境、操作人、影响范围等进行检索。
3.3.2 变更订阅
检索功能之后，我们又将其扩展到订阅系统，使得检索到的信息可以通过订阅机制进行投递。这就增加了一个触达机制，无论是投递给个人、群体，还是通过Web能力触达某些系统，都能够实现。
3.3.3 变更分析
变更分析主要是针对故障定位的场景，利用检索能力，结合时间、静态拓扑以及动态变化，与可观测团队共建了故障变更分析的能力。这种分析能力使我们能够在生产环境中迅速定位故障，理解变更对系统的影响，并采取相应的措施。
3.4 变更防控
经过定义、托管和感知阶段后，到达了核心环节——变更防控。我们的目标是构建一套通用的防控技术方案，结合通用防御能力和自定义防御能力，以最大化地对变更场景进行防御布控。
3.4.1 防控技术方案
防控技术方案依赖于之前提到的变更流模型，该模型定义了前置阶段和后置阶段，从准入到执行，再到准出，形成了一个链式的执行链路。在弃用策略上，先采取一种执法观察者模式，在前置阶段触发检查并反馈结果，但不会直接执行拦截。一旦检查发现问题，则进入执法模式，实施干预。
我们的防控策略包括阻断防控，即在出现问题时拦截变更；预警防控，即提示异常但不阻断；以及在出现问题后升级审批流程，阻断变更过程并启动审批流。
此外，还提供了熔断策略，以防新加入的变更系统出现问题影响其他系统。我们要求定义检查项时考虑到检查出的问题，决定是忽略检查项结果继续执行还是阻断变更过程，为用户提供降级方案和兜底策略。
3.4.2 防控能力概述
防护能力主要分为通用检查项和自定义检查项。通用检查项包括活动封网拦截、SLO检查、批次检查、环境检查等，而自定义检查项则允许其他团队根据特定需求建立自己的检查项。例如，安全团队会添加安全扫描检查项，以确保服务上线前不携带漏洞。业务团队会将他们的发布SOP集成到变更防控检查项中，确保业务应用发布前满足特定的准出标准。
3.4.3 技术交互模式
整个技术的交互模式是，当变更源平台接入并执行变更时会调用变更源平台，触发相应的检查项执行，完成后再链式返回。这样的防控执行后，将获得大量的变更行为数据，这些数据可供我们后续进行挖掘和可视化，已产生更大价值。
3.4.3 图1 - 技术交互模式流程图
3.4.3 图2 - 对变更场景进行防御检查
3.5 变更价值挖掘与可视
我们希望通过多维视角对变更数据进行深入分析，发现潜在风险点，并明确优先级，使项目价值得以可视化。
首先，我们对数据进行分类，包括覆盖性数据、防御性数据和运行性数据。覆盖性数据帮助我们了解变更管理的覆盖范围，包括覆盖了多少平台、多少场景，以及当前的防控等级。防御性数据则涉及防御机制触发了多少次，拦截了多少次，以及整个拦截的效率。运行性数据则关注变更的数量，是否有突增等异常情况。目前我们还关注两个指标——紧急通道和活动封网，确保数据分类的维度是足够详细的。
在落地实施中，我们的关注重点如下——
最初关注的是变更的整体覆盖情况，确保所有基础架构的变更平台都接入变更防控。随后，关注业务团队配置性变更的防控接入情况。我们要求所有相关平台都必须接入，以实现百分之百的覆盖。
对于变更数据使用情况，我们与可观测团队合作，打通数据，以便于在应急场景中发挥作用。
我们特别关注核心场景的故障阻断率，以B站为例，核心场景包括代码发布、配置变更、流量切换变更等，围绕这些核心场景来建设防御能力，并定期进行数据通晒。目前B站的核心场景阻断率是百分之十几。
我们还关注核心场景中的核心检查项，比如SLO检查项，确保在发布过程中一旦SLO指标下降，变更就会被及时拦截。这里的阻断率数据是很理想的，因为SLO指标足够清晰明确，所以带来了更高的准确率。
最后，定期回顾变更导致的故障数量占比，以评估我们的变更管理实践是否有效，以及是否实现了故障数量的环比下降。通过工作台的数据看板，可以实时监控检查项的执行占比。通过日常的钻取分析工作流，也能为我们提供更多分析视角和分析结果。
3.6 演进历程
变更管理体系的演进历程经历了三个重要的迭代版本。整个演进过程通用性较强，即先实现源信息的托管和感知，再固化防控措施，接着落地防控框架，最终朝着智能化方向发展。
3.7 场景实践
以一个容器场景的事实践为例，我们来看看变更管控是如何在实际工作中解决问题的。
3.7.1 实践场景一
问题：
过去的实践中，代码有时会不经过集成预发环境就直接部署到生产环境。在发布代码时，我们并不总是清楚变更的具体内容，这可能导致漏发或错发代码。其次，回滚过程中，由于发布流程不清晰，有时会漏回滚配置。
解决方案：
为了解决这些问题，我们建立了通用检查项，加强了环境监察，并明确了变更场景，从而确保发布分支的规范性。此外，还有一些技术方案：
- 校验环境发布顺序
- 管控构建变更日志及发布版本日志
- 规范可构建/发布的分支
- 管控回滚方案
效果展示：
3.7.2 实践场景二
问题：
发布过程中，我们可能会忘记配置，因为配置通常是静态的，而且会在代码发布时一并上线。如果不清楚变更的具体内容，就难以确保配置的正确性。此外，还有可能发错镜像或引入旧的bug。
解决方案：
- 提供diff能力，在发布创建时即感知此次发布会引入的变更内容，包括但不限于：1、应用配置 ；2、 发布侧配置；3、镜像（代码、依赖库）；4、中间件（数据库、缓存服务）
- 增强发布预检能力，在发布创建时感知可能的风险，包括但不限于：SLO指标、校验变更日志及发布版本、容量
效果展示：
3.7.2 图1 - 在发布创建时即感知发布会引入的变更内容
3.7.2 图2 - 在变更前巡检指标是否有问题
3.7.3 实践场景三
问题：
发布完成后，我们可能发现SLO下降，但在发布过程中并没有进行监控。同时，可能存在并发度设置不合理，或者新版本的问题未能及时暴露就发完了。
解决方案：
- 发布过程的实时上报，涉及信息：发布各阶段中 接流实例/总实例 比例、应用容量、发布单状态等信息
- 发布过程引入防控能力，基于以下指标提示和拦截：1、 业务 SLO 指标（可用率、错误数、延时等）；2、业务容量（QPS、CPU 使用率、内存使用率）
- 发布过程的观测加强：1、突出变更内容的差异提示；2、突出新旧版本的指标间差异；3、发布工作台增加实时的异常信息流提示
效果展示：
3.7.3 图1 - 发布过程可视化，被阻断情况展示
3.8 组织文化
在我们深入场景实践的同时，组织文化的作用不容忽视。我们期望通过组织架构的支持，实现责任的有效划分。当责任明确后，执行工作将更加高效。
四、总结与展望
4.1 经验教训
文章最后我想分享一些我们在变更管理领域积累的经验和教训。这些经验可以概括为五点：充分设计、找准切入、兼顾效率、保持效用和日拱一卒。
4.2未来展望
我们有一个愿景——通过实现B站变更防控体系的充分性、高效率和有效性，来对业务持续保稳提效，并在复杂多变的业务情形下借助数据&智能建立可持续的变更防控机制。
首先，我们需要确保充分的业务覆盖，这样我们的变更平台和变更场景才能得到充分管理和有效控制。对于历史上已有的变更故障，我们将构建有效的变更防御手段，并结合混沌工程进行有效验证。
在效率方面，我们希望持续降低平台接入改造的成本，并减少用户在变更托管后的变更过程中的感知。同时，我们希望引入智能防御手段来提高变更过程中的异常检测效率和防御触发效率，减少变更引发的故障和风险。
对于有效性，我们将确保已经发生的问题可以被有效回溯，并且对于已经布控的变更场景，能够有效进行阻断。此外，我们将通过联动预案平台，实现触发防控后的有效恢复。（全文完）
Q&A:
1、初期对于变更防控的规则的粒度是怎么选择的？有没有什么判断原则？
2、需要根据不同变更场景的特点，定制不同的防控策略吗？
3、能否分享一些具体的防控技术，比如封网拦截或SLO检查是咋实现的？
4、变更信息关联的时候，具体使用了哪些关联规则和分词技术？
5、请问，变更感知背后的数据支撑是如何构建的，以及日常怎么管理和维护这些数据呢？
