01.发布投产挑战加剧

1）业务规模日益庞大、发布频率日益加快

随着科技的飞速发展和人们生活水平的提高，线下业务加速向线上迁移，线上业务也变得日益复杂。各行各业纷纷投入大量人力、物力和财力进行企业IT建设。业务规模的持续扩大、应用数量的显著增加，使得应用部署节点不断增多。同时，随着敏捷开发模式的普及，企业内部的投产变更操作变得愈发复杂，运维人员的工作量显著增加。

2）应用架构日益复杂、信创适配要求提高

随着企业技术架构的持续演进，应用架构变得日益复杂，通常涉及传统应用、云原生应用以及面向不同终端的应用。尤其在当前国产化信创（信息技术应用创新）的大背景下，企业需要确保各种系统和工具的兼容性和适配性，这进一步增加了技术管理和协调的复杂性。

3）应用变更通常是导致线上故障的首要因素

变更通常是引发线上故障的主要原因。据Gartner研究表明，超过70%的生产事故与线上服务的变更直接相关。变更带来的风险不仅会影响业务运营和经济效益，还可能损害品牌声誉，并带来法律风险。因此，有效的变更管理是确保生产环境稳定性和降低故障风险的关键。

▲故障原因

综上所述，面对这些挑战，传统的人工运维方案已难以满足当前的需求。因此，企业迫切需要从工具、流程、制度和组织四个角度出发，建立一体化的发布变更体系，以确保生产环境的稳定性并降低故障风险。

02.企业应用变更建设路径

1）从行业经验实践看发展趋势

在IT服务管理（ITIL）的演进历程中，变更管理始终占据核心地位，其重点和方法随着版本的更新而不断演进：

• ITIL 2强调变更管理的流程和控制，着重于确保变更的有效性及最大程度弱化对业务的影响。它强调了变更管理流程的重要性，并提出了变更控制委员会（CAB）等概念来审查和批准变更请求。
• ITIL 3强调了与持续交付和敏捷方法的结合，以更好地应对变化和客户需求。它引入了新的概念，如变更评审和变更评估，以更全面地管理变更的影响和效果。
• ITIL 4强调了灵活性、适应性和持续改进，引入了更多与现代技术和方法相关的概念，如敏捷、Devops和持续交付。变更管理不再是独立的流程，而是作为整个服务价值系统的一部分。

2）从嘉为蓝鲸服务客户实践总结

面对上述挑战，企业正逐步构建一体化的发布变更体系。目前，大多数企业内部的变更手段仍主要是手工发布和脚本化发布，发布工具和入口分散，导致发布变更的管控薄弱且难度大。然而，企业已意识到平台化发布建设的必要性，并正在积极向这一方向发展。

▲一体化发布成熟度模型

03.企业应用变更建设思路

在嘉为蓝鲸应用发布中心·鲸舟建设案例总结中，我们得出以下结论：在变更的整个生命周期中，包括变更事前的计划报备与评审、风险及影响分析、变更事中的异常观测与自愈，以及变更完成后的度量与审计，均需通过系统化手段来防控和管理变更流程，以实现变更流程的“三板斧”：可灰度、可观测、可应急。每个环节都应具体落实到相关人员、规范和工具上，以实现变更流程的高效执行和风险防控。

本篇介绍应用变更体系建设思路，将从以下四个关键方面进行设计：

• 制度规范：建立全面的发布投产管理制度，包括发布投产管理办法、变更评审管理办法、实施细则等。这些规范将为发布投产提供明确的指导和约束，确保流程的标准化和规范化。
• 工作流程：设计高效的发布投产流程，包括发布投产规划、实施、运营与改进等阶段。通过制定发布计划、申请、评估、资源交付、制品摆渡、实施检查、应用回退等流程，确保变更管理的有序进行。
• 组织角色：明确组织内各角色在发布投产中的职责，包括研发测试、应用运维、资源运维和业务人员等。通过定义这些角色的具体任务，如版本发布计划、质量改进、版本准入、投产实施、数据分析等，确保发布投产流程的顺利执行。
• 工具平台：引入先进的发布投产平台，以支持各类变更管理流程的自动化。在价值流交付的理念下，需要与Devops平台、ITOM运维平台联动，实现从研发、运维、运营的全生命周期管理，以提高发布投产的自动化和效率。

▲发布投产体系设计

1）制度办法

变更管理，制度先行。变更的执行需要按照变更管理制度执行，建立完善变更管理制度是变更管理常态化开展的基石。应用变更体系的制度规范设计可分为四个层级，即一级文件阐明服务蓝图、总体纲领和管理方针，二级文件包含管理规范和管理办法，三级文件为实施细则和操作手册，四级文件为各种表单模板和维护记录。通过这四个层级的系统化拆分，以全面支持各类软件变更场景。具体如下：

▲制度办法设计思路

这四个层级文件对应的详细规范手册包括：

① 一级文件

• 《应用变更管理办法》
• 《应用变更服务蓝图》

② 二级文件

• 《安全生产门禁》
• 《代码分支发布规范》
• 《应用模块管理规范》
• 《制品管理规范》
• 《生产制品晋级规范》
• 《应用配置管理规范》
• 《发布流程管理规范》

③ 三级文件

• 《发布平台使用指引》
• 《配置管理操作指引》
• 《作业维护操作指引》
• 《标准流程操作指引》

④ 四级文件

• 《常规变更申请提单模板》
• 《紧急变更申请提单模板》
• 《发布结果归档》

2）工作流程

应用变更主要分为两种类型：标准变更和紧急变更。标准变更是指根据预先规划好的版本更新，而紧急变更则是针对线上故障的应急处理。无论哪种类型，均需要遵循变更管理工作流程。

变更管理工作流程主要包括计划变更、审批变更、实施变更和反馈变更。需要将变更管理流程与变更管理工具平台联动，通过流程和工具相结合，将变更管理流程线上化，通过工具流程控制变更风险，落实审批、双人复核、访问控制等要求。以下是对这四个阶段的详细描述：

▲变更工作流程

计划变更

• 提交变更申请：需求方在IT服务管理中心发起变更申请，内容通常包括：变更背景、变更内容、变更版本、预期影响和需求描述。
• 制定变更实施计划和方案：变更申请提交后，进入方案制定环节，详细制定变更实施计划和方案，包含发布方案、验证方案、回退方案、测试报告、应用变更清单、配置变更清单及数据库变更清单等。

审批变更

• 变更评审会：变更评审会通常由技术骨干及专家组成，包括首席技术官、业务负责人、研发经理、测试经理和运维经理。评审内容主要涵盖 部署资源的准备情况、上下游业务协同的准备情况、投产方案的完备情况，以及变更紧急联系人是否确定。

▲变更评审点

• 制品摆渡：经过变更评审会的批准，自动化系统将触发制品晋级流程，确保验收UAT环境中得到验证的制品，能够平滑摆渡到生产环境。制品摆渡通常包括程序包、配置文件、SQL、投产脚本、投产方案等。

▲变更评审点

实施变更

• 实施变更投产：实施变更投产是将应用版本包部署到生产系统的过程，通常安排在统一的变更窗口。若涉及停业或影响到上下游业务，必须与相关部门提前沟通协调。投产过程需严格按照步骤和方案进行，通常由自动化部署工具完成，以减少人工干预，并监控投产期间的业务影响。如遇业务指标异常，应及时启动应急方案，快速完成版本回退。

▲变更评审点

• 验证变更结果：验证变更结果需要业务方或开发方进行上线结果的确认，以确保变更满足业务需求。若涉及上下游业务，还需进行联调以确保业务流程的完整性。实施变更投产阶段的实施人员验证不能作为最终的验收依据。

反馈变更

• 回顾变更：应用版本投产完成并稳定运行一段时间后，应召开变更复盘会，分析此次变更的实施效果和问题，总结经验，以改进和优化未来的投产变更工作流程。参与方通常包括业务、研发、测试、运维等关键角色。
• 关闭变更：变更回顾结束后，将变更申请、变更方案、测试报告、变更验证结果、变更全过程操作记录等资料整理并归档，以便于审计和知识库建设。

3）组织角色

应用变更体系是一个涉及多方协作的工作流程，明确定义关键角色及其职责至关重要。以下是应用变更体系中的关键角色，这些角色可由实体组织或虚拟组织承担。

• 变更负责人 ：负责整个变更交付的最终结果，与申请人沟通完善变更发布计划、实施方案、回退计划、应急预案和影响分析，并组织评审。变更负责人通常归属于应用运维科室。
• 变更申请人 ：负责整理变更材料、提交变更申请、跟踪和协调变更的准确性，审批、发布和验证流程。变更申请人一般归属于应用开发科室或业务科室。
• 变更审批人 ：通常由应用开发科室、应用运维科室和业务科室的多位领导组成，负责在不同节点审批变更。针对不同级别的变更，会有不同层级的审批人。建议变更申请人和变更审批人应为不同的人，以确保审查的公正性。
• 配置管理员 ：负责管理和维护应用相关的配置项，确保应用的版本和配置在开发、测试和生产环境中的一致性。配置管理员一般归属应用开发科室或独立的配置管理科室。
• 变更复核人 ：复核变更实施的具体操作内容，确认变更方案与实际操作的一致性，核对输出结果是否符合预期。变更复核人一般归属于应用开发科室。
• 变更控制委员会：由来自不同领域的员工组成，协助变更经理进行分析和决策。CAB委员会成员通常包括运维、测试、开发和安全等方面的专家或决策层代表。

▲CAB职责与权力

4）工具平台

应用发布平台是企业用于实现一体化应用投产发布的基础设施，能够对应用发布进行统一管理和自动化执行。平台支持单体/微服务应用发布、分布式/容器化发布、应用全生命周期管理，以及蓝绿/金丝雀发布等多种发布场景。下文将以发布平台对象建模、发布平台功能架构阐述工具平台建设思路：

① 发布平台对象建模应以应用为中心建设应用发布平台，才能符合现代微服务和容器化架构的发展趋势。通过以应用为核心，串联基础资源、应用制品和发布流程，从而实现更高效、可靠和灵活的应用发布管理。如图所示：

▲发布平台对象建模

② 从应用变更体系建设的角度，发布平台功能架构可分为应用层、平台层、通道层和对象层。上游对接运维投产变更流程和DevOps，下游连接可观测平台，形成全链路闭环发布投产能力，为实现业务价值的快速、高质量的交付提供标准化发布能力支撑。以下是各层的简要总结：

• 应用层：包含应用管理、制品管理、配置管理和发布管理四大功能域，支持各种发布场景。
• 平台层：作为发布平台的核心引擎，提供多种基础能力，包括配置平台、作业平台、标准运维、容器管理平台、节点管理和插件中心，为应用层提供支持。
• 通道层：作为发布平台和基础资源之间的桥梁，负责数据传输和作业执行。
• 对象层：作为发布平台的执行目标，主要包括各数据中心的基础资源，如主机、K8s集群/命名空间、数据库实例和中间件实例等。
• 工具集成：发布平台应具备与DevOps、ITSM、制品库和可观测平台的集成能力，实现全链路价值闭环的发布体系。

▲发布平台功能架构

04.结语

综上，我们介绍了一个较为成熟和理想的应用变更体系建设方案，从平台化和工程化的角度拆解。企业在实际落地过程中，可以挑选几类典型系统进行综合考量，以点带面逐步推进。

总体来说，要实现企业应用变更管理的高效、安全与规范，需要在制度、流程、工具和组织方面进行全面的规划和实施。在发布投产管理过程中，需明确各单位的职责，增强各角色的协作，利用先进的工具平台，建立标准化、自动化和可监控的发布变更体系，从而有效降低操作风险，提升业务的稳定性和可靠性。

05.应用发布选型推荐