今年，中证协下发了《证券公司网络和信息安全三年提升计划》（详见 https://www.doc88.com/p-40959715591002.html ） ，今天对第2项“全面管控信息系统变更风险”做简要个人分析。

1. 系统变更管理概述

架构即未来》中有一段关于变更的描述：“ 经验告诉我们，生产环境中发生的事故，有很大一部分是由软件和硬件的变更引起或触发的。如果不主动地管理变更，有意识地降低风险，服务将恶化或瓦解。必须对变更进行管理，以确保有可扩展的服务和有快乐的客户。 ”

对于运维团队，变更管理是IT服务管理的一个重要流程，是IT交付核心价值链最后十公里，涉及组织架构、变更流程与协同机制、工具平台等一系列管控工作。变更管理的目的一是为了有效防控变更引发的业务连续性风险，二是协调资源，让IT需求交付速度加快，提升IT需求交付质量。

指导意见中，围绕系统变更风险，从变更风险评估、自动化操作、操作风险控制、自动化发布、变更管理机制、质量度量体系等进行了要求。 下面我 将指导意见要求归纳为“加强变更风险评估、落地变更操作自动化、建立变更管控机制” 3点，做个简要梳理。因 在上一篇中 “加强系统上下线管理”中梳理了系统上线业务风险评估、可运维性评估、上线的技术运营保障，同样适用于变更管理，所以本篇涉及这3点的将简化。

2. 加强变更风险评估

指导意见的描述是“加强信息系统变更风险的管控，采取合适的 技术手段 ，准确 识别系统变更的关联关系 ，充分 评估变更影响 ，提升 变更风险 评估全面性。”指导意见中重点提出应用技术手段识别变更关联影响。

变更 带来系统稳 定性风险。 从生产变更故障引发率看，来自变更的故障遥遥领先其他因素引发的故障，变更后通常是运维组织最为繁忙的时段。 不管是大的软件基线，还是小到一个功能迭代，甚至一个参数或配置的调整，也可能引发一个重大故障。变更带来的风险点很多，有设计上的程序缺陷类的问题，也有管理上的版本管理的问题，也有操作层面的执行问题，也可能是协作层面上下游系统沟通不畅引发的相互影响的问题等，解决变更带来的风险问题是一个极为复杂的系统性工作。所以，加强变更风险评估是变更管理一项重要又复杂的工作，我认为变更风险评估重点围绕：

一方面要 融入到软件生命周期，运维需要推动左移 ，比如上一篇中提到的系统可运维性涉及的日志、监控、拨测、终端体验、服务性能、重要状态、极限值等数据埋点的标准与落地；重要变更、系统组件退出环节涉及的架构韧性、性能及容量伸缩、可运维性的落地；变更涉及的业务监控、技术与业务验证、上下游协作、技术文档、应急方案等的交付标准与验收；主动推动 性能、容量、破坏性测试、压力测试等；推动系统在设计环节建立功能和服务层面的调用关系，并结合生产环境基于 CMDB 的部署关系、最小单元调用关系、分布式服务调用链等，围绕配置对象为节点落地数字化的关联影响关系图。

另一方面， 运维需要以变更评审作为风险管理的收口 。 变更评审主要是为了 降低系统变更投产带来的风险，并让变更如期交付业务。 在实际的变更评审中，不同组织会在系统交付生命周期的不同阶段建立相对应的变更评审机制，比如项目立项环节的可用性评审、技术或部署架构可用性评审，设计阶段的非功能性、可运维性评审，上线环节的CAB评审等。关于变更评审， 光大银行彭晓总在朋友圈曾做过很全面的分享：
“ 一是 考虑风险和效率 ，生产系统变更是支持业务发展的关键环节之一，变更容易带来运行环境的不稳定，可能产生生产事件，变更评审就是发现风险，确定应对措施，从而降低风险。
二是 考虑当前与长远， 当前考虑的是 本次变更的关联度、实施步骤、回退方案、验证方案、有效实现变更 初步目标；长远考虑的是 配置管理是否到位、运维监控、处置工具与预案、容量评估方法、系统关联关系梳理与入位、与业务部门的沟通机制、是否带来了不可控组件、自主可控目标是否实现 。
三是 考虑分类与评估方法 ；
四是 考虑过去和未来 ，过去是这个系统的前世今生，是新系统吗？ 原来出过什么问题，架构、设计、测试评审有什么问题和结论，各专家前期评审的问题有哪些，未来系统的定位是什么，支持哪些业务，业务推广计划和资源投入计划是什么 。变更评审最终要评估、控制好风险，兼顾效率，服务好广大客户。 ”

可以看出彭晓总在技术评审中融入了变更内容、架构、影响、实施、变更后可运维性、历史事件、专家意见等方面的考虑，可以在变更中增加评审范围，并利用技术手段降低评审范围的成本与提高评审效率。

3. 落地变更操作自动化

指导意见的描述是“提升运维自动化能力，积极运用 持续发布、容器以及相关的运维自动化技术 ，实现重要信息系统变更的标准化、自动化和平台化，有效 控制生产环境的变更操作权限 ，降低人员变更操作风险。重要信息系统组件的 自动化发布比率不低于40% ，发布失败后具备版本的 快速回退能力 。”

指导意见重点强调了变更操作的线上化、自动化，以降低操作风险，并明确的提出重要信息系统自动化发布率与配套快速回退的能力。按生产环境的操作看，主要包括计划性的软件、硬件、数据、配置、参数层面变更，常态化的巡检、例行操作，以及临时性的应急等操作。行业总体的思路是，应尽量将上述生产操作，能自动化的自动化，不能自动化的线上化或工具化，且所有操作均应有据可依。除去一些与应用系统配套维护功能以外，运维组织可以考虑搭建操作平台底座，并在底座之上构建场景工具。

操作平台底座的思路很早就由 腾讯蓝鲸提出，蓝鲸在行业运维自动化工具解决方案烟囱林立时，率先抽出“ 以脚本为原子，对原子进行有机组装形成各类运维场景”的指导思路，包括脚本、编排、任务、网关、工具的底层思路，打造运维工具的PAAS平台。目前行业对操作自动化的底层能力与蓝鲸这个思路很相似，主要包括：

• 支持高性能、高可靠的服务端与生产对象具体操作的执行能力 ，通常采用代理、网络协议、SDK等方式建立服务端与生产对象之间的通讯连接，重点关注效率、安全、低耗能等。
• 低门槛的脚本应用能力，脚本开发能力可以作为一线运维的基本能力，操作平台需要降低一线运维编写、调试、审核、执行的门槛，提供所见即所得的脚本开发能力。
• 集中式脚本管理能力， 提供脚本库管理，包括脚本的集中管理。
• 脚本编排能力， 脚本的实现偏向底层，为了尽可能实现自动化，需要进一步将脚本开发与使用的门槛降低，实现多个脚本的组合，形成多个脚本的流程。
• 任务调度能力， 实际的操作自动化中，除了针对特定一次性的操作需求外，还会有大量例行的脚本或流程，比如基于crontab、XXL之类的任务调度。

• 所 见 即所得 的低代码 开发能力 ， 对于工具，脚本是面向生产对象的原子模块，低代码为工具提供更加友好的操作体验、安全管控的前端，更利于自动化操作的应用。

  以场景驱动自动化工具建设。操作类工具层重点关注带有特定场景的操作工具，比如变更类、检测类、执行类、应急类、风险控制类的工具。指导意见中心提到的CD持续交付就是面向软件发布的场景工具，在当前企业DevOps的思想的推动下，市场上此类工具已经比较成熟。在实现上，CD自动化 部署通常会被理解为程序部署，比如获取发布二进制包文件、包文件校验、停止服务、环境验证、程序备份、数据备份、数据变更、程序更新、配置修改、启动服务、技术检查、回滚等涉及的流水线步骤，通常涉及流水线的编排、脚本执行、配置修改、文件分发等。除了软件程序部署以外，以全配置管理角度看看部署，还包括环境部署、数据变更，配置变更等，所以持续交付系统在设计上要融入到整个 IT 架构中，比如要与 IaaS 的 CMP 打通进行基础设施环境配置，与 PaaS平台 打通进容器、数据库的部署等，与测试环境打通自动化测试工具，与生产环境关联监控、问题定位（日志）、环境（堡垒机）等。 如果要真正落地 DevOps的持续交付中“持续”的思想，需要分析企业研发、测试、运维的生命周期中的工作方式，选择一个可以融入多环节的技术方案，这是当前CD软件发布的难点。

  软件发布是变更管理自动化的一个工具，在实际工作中，还会有较多数据维护、参数调整、配置管理等，以及特定业务系统配套的的维护工具，在实施上很难打造一个可以包打天下的一站式自动化工具。更好实施的方式是，将底层操作平台一站式，上层以具体工作场景为单位打造工具。

4.建立变更管控机制

指导意见的描述是“持续完善 变更管理机制，制定变更实施方案、变更影响分析、应急回退方案、业务验证 等重要环节的落地要求，通过 工具平台予以固化 ，并引入 变更质量度量体系 ，完善系统变更前后的质量评估，对 测试过程、变更过程 进行有效评价和持续优化。”

从实施上，变更管理通常涉及运维前移、变更评审、变更流程管理、变更实施、变更运营分析等工作。其中：

（1）运维前移重点围绕技术架构规范前移、软件交付要求前移、非功能性需求设计前移、技术架构韧性前移、运维保障要求前移等。

（2）变更评审重点围绕降低变更风险，并让变更正常交付涉及的变更风险评估及相关准备工作。

（3）变更流程管理主要指建立变更发布计划，并通过线上化流程方式进行变更申请的审批，流程规范、标准化变更的一个抓手。

（4）变更实施主要指变更计划制定、现场实施管理，以及变更发布执行涉及的操作，比如变更窗口管理、大版本变更管理、上下游协作、数据迁移、自动化操作、变更后技术与业务验证等。

（5）变更运营分析主要指围绕变更管理的执行情况进行数据运营，以持续提升变更管理水平。

上面提到的一些变更管理机制，指导意见中重点提到了要将变更管理机制平台化，并引入数字化的变更度量体系，这里的管理机制平台化并非指发布执行的自动化，发布执行是管理机制平台化的一部分。变更管理机制的平台化难度很大， 一方面，结合康威定律，平台化的有效落地要达到一定的平衡，才能更好的持续优化；另一方面，企业里通常经过长期经验智慧的沉淀，已经在不同的职能线落地了一些流程，平台化需要将部分流水线融合起来。同时，建立持续优化的变更管理能力，还需有数字化运营手段，度量变更管理的计划性、关联风险、交付速度，比如 变更分类数量、变更失败量/率、未按计划执行变更量/率、紧急变更量/率、被拒绝或退回变更量/率、变更负责人平均处理变更数量/时长、引发事件的变更数/率、未准时执行CAB评审的变更数/率、客户满意度、变更文档不全数/率、非CD发布的变更次数、未经测试的发布数/率、平均带缺陷发布的数/率、不在制品库的软件包等。

场景是变更管理机制平台化的一个很好的实施思路。关于变更管理场景，我在我的 运维数字化书籍中有一节分析，预计最近一两个月可以出版。 下面摘出变更场景在构建时，对“ 人、事、时间、协同、环境”5要素的梳理。

“人”： 包括各职能线团队运维人员、CAB委员会、技术架构委员会、在软件交付过程中参与的研发/测试/产品/项目人员、业务部门人员、合作方人员、供应商、变更协作机器人等。

“事”： 包括新系统的技术可行性、技术选型、软件设计、变更申请、变更评审、软件发布、变更验证、变更窗口运营分析等环节的工作事项。 场景重点需要建立端到端的协同连接，将上述变更的“事”线上化连接起来形成闭环 ，对于需要向外开放的新系统技术评审、软件变更、变更评审的申请性工作服务化与流程化；将涉及复杂的协同工作线上工具化； 将基于与变更对象相关数据的“感知、决策、执行”闭环能力融入到每个环节的“事” ，比如将部署架构、生产对象容量与性能数据与评审环节关联，辅助评审；将与生产操作相关的线上化、自动化。这些“事”，最终由场景中“协同”要素的线连接在一起。

“时间”： 变更管理场景的时间可以包括变更申请前的设计阶段、变更申请后的变更发布阶段，以及变更发布后的复盘阶段。设计阶段，重点是关注如何将变更前移的相关工作融入到IT组织的项目管理流程。变更发布阶段，重点关注从变更管理流程、软件发布、变更后验证管理的在线化与互联互通。变更发布后的运行保障、复盘阶段，视组织变更机制而定，比如统筹的变更窗口复盘，或以团队、系统、个人组织的复盘。

“协同”： 主要针对人、事、机器的在线协同，场景将重点放在变更管理流程、软件发布、变更后验证的几个环节的协作，其中ITSM负责审批流程的打通 ， CD负责软件发布动作的在线上化 ， CMP或IaaS云平台负责硬件变更的线上化，变更后验证与值班管理任务整合 ， ChatOps将人与事的沟通协作连接起来，数据将整个过程整合在一起，达到过程可观测。

“环境”： 变更管理场景的环境主要建立在线下与线上相结合的工作环境，以及变更管理相关机制标准、规范、规程。线上以变更审批流程、评审线上辅助工具、变更过程的指挥管理工具、变更操作执行工具等能力的整合。线下主要针对具体的人与人之间协作，或物理环境的下变更操作，将结合ChatOps在社交协作工具，辅助管理机制更好的落实到行动管理。变更管理机制应以变更管理规范为基础，并制定技术架构评审、架构可维护性标准、CAB评审、变更审批流程等标准规范细则。

总的来说，变更 管理与故障管理是运维组织、流程、 平台、场景建设中出现频率最多的两个流程，故障管理 是 运维 底线， 变更 管理 是 为了 有效防控变更 引发的 业务连续性 风险 ，减少故障事件，并能够在故障真正发生时能够更加从容的应对。 同时，通过建立完善的变更协同机制，能够推动运维前移，主动 协调好资源，让 IT 需求交付速度加快，提升 IT 需求交付质量 。

相关阅读：

《证券公司网络和信息安全三年提升计划》分析之一：“加强系统上下线管理”