其他
背景随着企业规模的扩大和技术日趋复杂,对生产环境的稳定性需求日益凸显,尤其对于大型互联网企业而言,稳定性的重要性不可忽视。在这一背景下,变更管理显得尤为关键,因为变更通常是导致线上故障的首要因素。据谷歌SRE统计,高达70%的生产事故与线上服务的变更直接相关。因此,防控住变更带来的风险将有助于从源头上杜绝大部分潜在风险,确保企业生产环境的可靠性和稳定性。本文将基于当下变更管控的困局,引入变更的核心概念定义,然后围绕变更管控的逻辑思考,进而解答变更管控为何要做、如何去做和怎么来做这三个核心问题。最后为大家介绍B站目前的变更管控平台实践情况,期望可以为读者提供一个全新的变更管控思路和启示。当下变更管控困局变更已然是一个老生常谈的话题了,相信大家都不陌生。在技术标准里面,ITIL的每个版本里面,都有他的篇幅描述,在ITIL中对于变更管理的核心是通过合理的流程和步骤来确保变更的有效管理,最小化潜在风险,保障服务的稳定性和可靠性。更多的是在强调对于将要发起的变更流程的规划、控制、评估和记录。但是缺少对于变更执行过程的过程管控,这里涉及对于过程对象的定义、过程自身的定义和过程的干预等等。在笔者与业界一些公司的沟通交流中也发现,目前大家对于变更的重视程度已然达到了顶峰。在实践过程中,基本上是围绕变更方案评审,变更发起前控制(重大活动/节假日等关键时间控制),变更事件记录这些开展变更管理工作。这种做法应对传统的IT架构是足够的,但是在目前围绕云原生+微服务的这套复杂技术体系来看,存在着诸多问题,诸如:评审围绕流程驱动,在评审环节依靠人的经验来确保方案的正确性,过于依赖经验并难以持续保证效果由于资源的稀缺性,难以确保每个变更都能够纳入评审,仅能覆盖部门高优重保的大型变更计划评审行为仅能约束变更的发起,无法保障变更执行过程按照要求切实有效执行,比如强制分区灰度要求,强制观察时间要求等基于人操作的变更和平台操作的变更,围绕技术平台的基础设施和业务平台的配置变更,散落在各个地方,各自对于变更用了各自的流程定义和描述,难以收归一起管理和分析单纯的变更记录,难以支撑当下复杂场景下由某个边缘变更、底层变更导致的级联故障定位由于缺乏完整的变更管控技术框架,难以实现公司内部所有变更的平台托管,即无法知晓到底存在多少变更行为,哪些地方会发起变更,每次变更具体是变了什么东西,变更影响具体影响了什么对象和范围等面对以上诸多局限,我们秉承技术问题还需要技术解法的原则,将变更作为一个独立的技术域,抽象和定义了变更的对象概念,规划和设计了变更管控技术框架,围绕这个框架打通从变更元信息定义、变更平台/场景接入、变更防控到变更分析的全流程链路,来实现变更的一体化和多层次管控。下面我们从变更的定义出发,看整个变更管控体系是如何设计和落地的。什么是变更?变更定义日常变更无处不在,那到底什么才是稳定性领域中的变更呢?通过对行业理论和实践总结的梳理,我们认为变更是指任何对服务运行状态造成影响的行为。这些影响可能源自研发、SRE、产品或运营的各种活动。从本质上来讲,稳定性问题通常是服务从一种稳定状态转变为不稳定状态的熵增过程。变更生命周期在上面对于变更的定义里面,我们明确了几个关键的点,服务,状态变化和过程。一个变更的生命周期,其实就是对于变更过程从变更发起、执行到结束的描述和管理。传统中,一个完整的变更流程包含变更计划、变更预审、变更评审、变更执行和变更校验等环节。在变更执行环节,往往会围绕变更对象的范围,拆分多个批次进行变更的灰度化,减少因异常变更熵增带来的影响面过大问题。变更平台/场景关于状态变化和变更过程的描述,我们采用了“变更平台”和“变更场景”这一概念。变更平台是指发起变更的平台,其负责提供具体变更的功能。变更平台会托管一系列变更场景,以数据库管控平台为例,它涵盖了新建数据库、扩容实例、SQL