是能力更是文化，谈谈 IT 系统的安全发布

引言

在前边一篇文章如果只有一周时间，怎么快速提升线上系统的稳定性？中我们总结了影响 IT 系统质量和稳定性的因素以及如何快速提升系统质量和稳定性的途径。我们知道生产事故跟架构设计、代码开发、上线变更、业务配置、运维操作以及外部依赖等研发运维全生命周期都相关，而其中架构代码问题（代码 Bug+架构设计）约占 30%，还有约 70%的事故是程序编码出来之后到实际运行过程之间产生的，与架构代码本身关系不大。这些非架构代码问题主要与 IT 变更失误、业务参数配置失误、性能容量不足、外部系统依赖错误以及 IT 运维操作失误等因素相关。其中 IT 变更失误及业务参数配置失误其实都与版本发布相关，合并计算的话两类因素占所有生产事故的 20%以上，占非架构代码问题的 1/3 左右。今天我们就来总结一下安全发布的相关实践和经验。

什么是一次版本发布？

首先，我们有必要先明确以下几个定义，以确保我们讨论的和你所想的是同一件事情。

第一，什么是一次版本发布？任何由 IT 实施的，会对生产系统行为产生改变的内容（哪怕只是一个系统参数设置变化）和过程的集合是一次版本发布。它既包括版本自身，又包括发布过程。

第二，一次版本发布包含哪些过程？既然一次版本发布包括发布过程，那有哪些过程呢？如下图所示，笔者所在的团队认为一次版本发布是从接到“版本需求”开始，到发布完成并开始“发布跟踪”结束，至少包括发布需求澄清、发布策略制定、准备待发布版本、执行发布以及发布跟踪等多个阶段。

第三，版本分类。在践行安全发布理念的过程中，不同发布规模的版本所需要重点关注的内容以及安全保障流程会有较大不一样。根据笔者所在团队的实践经验，我们大致将版本按发布规模的不同做如下分类：

1. 小规模版本。发布需求可能是一个很小的 Feature，也可能是一个 BugFix，一般仅涉及一个系统模块或一个微服务本身。

2. 大规模版本。发布需求可能是技术上的一次大型升级迭代，比如系统架构从单体式应用升级为微服务架构，或者是数据模型数据库结构发生大的变化。也可能是业务上一次大型的业务上线，比如一个新业务从 0 到 1 发布，涉及上下游多个系统或者服务配合，发布本身也有可能会分几次才能全部完成。

3. 普通版本。介于小规模版本和大规模版本之间，可能涉及一个或几个（不超过 3 个）不同的模块或者微服务变更，系统架构或者业务模式没有大的变化，一次发布可以完成一个普通版本上线。

如何实践安全发布？

笔者所在团队对过往因版本发布直接引发的生产事故（约占所有事故的 20%）进行了细分，得到如下数据。

此处不包括代码本身 Bug 导致的生产问题，因为我们在对生产事故统计时，将代码 Bug 问题单独进行了分类。根据长期实践，基于版本发布生命周期概念及上述事故分类占比，笔者所在团队根据不同版本规模采取不同的措施保证安全发布。

先来看看小规模版本发布。小规模版本发布一般不涉及上下游协同，发布方案可以极简为“开发-测试-发布”的简单流程。也即是，小规模版本发布的关键是保证众所周知的代码本身质量可靠，上线部署过程不出意外即可。历史事故分析也告诉我们，代码质量问题至少占 30%，“变更操作失误+测试脏数据”等上线部署过程中的人为操作失误也至少占 10%以上。为了解决这两类问题，业界有非常多的优秀实践。如同事间的代码评审、严格执行的质量门槛、自动化功能及性能测试等实践可以确保代码本身质量；而可重复的部署变更流水线则可以实现部署过程全自动化，避免人为操作失误。这些都是 DevOps 和持续交付理论要着重解决的问题，相关材料不计其数，此处不展开。

再来看看普通版本发布和大规模版本发布。与一般的小规模版本发布最本质的不同在于，这两类发布涉及更多系统模块或服务，需要更多上下游协调。如上述事故分类占比你所展示的，“发布方案错误”和“上下游协同”相关的变更失误生产事故至少占 30%，如果只考虑需要详细制定发布方案和上下游协同方案的较大规模发布，这类问题导致的生产事故占比会更高。因此，对较大规模的版本发布，除保障小规模版本发布的 DevOps 和持续交付实践之外，更重要的是制定完善的发布策略和上下游协同机制，从源头上保证发布安全。下边，我们来重点讨论一下这两类问题。

面向发布的研发上线流程

针对发布方案错误或上下游协同带来的生产事故作进一步分析，我们发现这些错误表现其实大致可以归结为如下几类：

• 对待大型业务需求时仅考虑系统架构变更和开发排期，未从发布角度考虑发布计划和系统架构

• 发布策略制定太晚，主体需求临发布前才识别到相关联模块影响，致使瘸腿上线或延期上线

• 系统或架构太复杂，评估不到位或者评估有遗漏致使系统上线存在缺陷

• 发布策略太激进，采取一次性的 BigBang 变更，未从业务影响角度充分考虑发布节奏和系统架构调整

• 发布计划欠考虑，流于形式。未制定应急回退方案或者应急回退方案无法实施

要解决上述问题，做到安全发布，需要明确以发布为中心的“面向发布的研发上线流程”。下边，我们以一个典型的大规模版本发布为例来描述这个流程的关键内容。

例：在公司的一个主力业务中，运行了两套并行的系统，老系统是上个时代基于数据库的单体式应用，新系统是基于内存计算的分布式系统。经过一段时间的并行运行验证，业务方决定将剩余的绝大部分业务流量迁移至新系统，迁移的过程要充分考虑已有业务的连续性，迁移后希望业务开展的延迟、TPS 和容量等性能有巨大的提升。新老系统在数据上不可兼容，新系统则涉及多个数据中心。

1. 制定可执行的发布策略并且将策略制定环节左移。

针对较大规模版本，发布需求确定后的第一件事即是制定可执行的发布策略，而不是一上来就做架构设计，有时甚至需要根据发布策略调整发布需求。一个好的发布策略是具备可行性的策略，要有明确发布内容和组织形式（版本），发布计划，以及计划执行中的组织和人力保障。

• 发布策略至少包含“版本方案”和“发布计划”两部分。版本方案指根据版本需求确定的系统边界和模块组成部分。无论涉及的系统或模块是否存在代码或配置修改，只要是跟完成对应需求相关的系统，都是版本方案的一部分。发布计划是针对确定好的发布版本，识别相关方并确定将版本落地实施的完整计划。在制定发布策略的最初阶段，或许不需要非常清晰的 DayByDay 计划，重点是要识别出相关方和对应的职责，以及除 IT 系统变更以外为保证版本落地实施需要的组织保障。

• 发布策略需要所有直接参与方认可和支持。直接参与方是指在“版本方案”中涉及到的所有业务方、产品管理方、研发团队、测试团队、运维团队以及基础设施和安全相关的团队。

• 发布策略要指定明确的发布负责人。

以示例中的业务迁移需求为例。此次版本发布包括老系统、新系统、业务在新老系统中的数据及对应的数据库系统、运行新老系统的数据中心及网络等基础设施。因为新老系统数据不兼容且新系统涉及多数据中心，除关注新系统自身可能涉及到的改造外，发布计划需要重点关注业务数据的迁移方案，业务迁移到新系统后底层基础设施的保障方案以及业务迁移到分布式系统后的跟踪反馈机制建设。很明显，要顺利完成业务迁移，能够协调多方的产品负责人或者新系统的负责人是比较理想的发布负责人。在上述内容确定后的第一时间，发布负责人应召集所有相关方对计划中的关键问题充分讨论，形成一致方案和行动计划。

1. 根据发布策略调整架构设计和测试方案。

将发布策略环节左移到架构设计之前的主要原因在于，发布策略中制定的版本方案在很多时候需要架构设计及相应的测试方案配合才能实现。

比如示例中的业务迁移需求，至少有两种不同的发布/迁移方案。

方案一：一次性将业务数据从老系统迁移至新系统，迁移后试运行期间保证新系统出问题时可以一次性将业务数据回迁至老系统。

架构设计：重点设计相应的回迁方案和工具保证业务数据一次性回迁的可行性以及低耗时。

测试方案：重点测试和演练业务数据迁移和回迁方案及耗时。

方案二：分批次将老系统的业务数据迁移至新系统，在客户访问环节根据不同客户做路由，每批次迁移时先将访问请求同时路由至新老系统，新系统接受请求并处理但不返回响应，仅作验证用，验证无误后切换真实业务流量。

架构设计：新增客户访问网关同时支持新老系统，根据业务分批策略对业务访问做路由，并支持在运行过程中更改路由逻辑；有可能老系统也许作相应的修改使得业务部分迁移是可行的。

测试方案：重点测试访问网关的自定义路由能力及网关路由的稳定性和性能，测试时应尽可能 100%模拟目标生产环境的真实部署情况。若老系统也需要架构修改，则对应的测试方案也是必须的。

1. 尽早组织所有人评审详细发布执行计划。

发布版本的相关改造基本完成之后，应该在测试验证的同时并行制定详细的发布执行计划并由发布责任人召集所有相关方评审以锁定发布资源或作相应的调整改造。发布执行计划应该至少包括以下基本元素：

实践该执行计划时，每一项主要内容都最好有一个标准的 checklist，并以标准的方式（如执行计划表或者变更管理系统等）将所有的发布执行计划统筹管理，便于与发布管理机制结合以及逐步改进。

1. 对涉及较多人工协调和操作的关键环节要做充分演练。

如示例中的方案一，业务数据一次性迁移和回迁过程本身可能会涉及多方协作，必须结合架构设计、迁移回迁工具等，组织所有人员进行提前演练，多做几遍。

1. 发布执行完成不等于发布结束，发布后跟踪确认无误才是发布结束的标志。

只有当“首次运行检查列表”中的所有检查内容都已被覆盖且检查确认无误，本次发布才算结束。

安全发布应成为一种文化

笔者所在的团队进行了非常多的探索、实践和改进，最终沉淀了一些实践经验和方法论。大家可能已经发现，上述安全发布提倡的“面向发布的研发上线流程”其实只描述了安全发布涉及的关键环节，每个关键环节的核心工作内容，并未对如何开展这些工作以及由谁来实施给出建议。

事实上，如何达成上述安全发布的形式是多种多样的。笔者所在团队践行了包括变更评审、事故跟踪、事故分析、以稳定性为目标的演练和架构改造等等实践，有得也有失。我们发现要使上述流程和工作实践发挥最大效力，以最大限度保障发布安全的最重要因素其实是每一个版本发布责任人/实施者是否能够高质量践行该流程，这包括其自身能力，也包括组织能力。因此，如果说“面向发布的研发上线流程”能够帮助组织和人提升安全发布的能力的话，那高质量践行该流程则是一种安全发布的文化。培养安全发布的文化需要坚持以下几条原则：

原则一：每一个版本发布责任人应当对版本安全发布负全责

原则二：组织或管理者应当创造合适的机制使得版本发布实施者能够负全责

原则三：坚持“面向发布的研发上线流程”，将发布安全性作为研发流程、架构设计等是否合理的重要评价标准

原则四：小步快跑，尽最大努力避免大规模版本发布，只在不得已的时候做超大规模版本发布

参考资料

1. 《DevOps 实践指南》

2. 《持续交付》