在应用系统业务连续性保障过程中，应用版本的投产部署是其中一个重要的因素。本文简要总结应用版本部署流程、版本生命周期管理以及其中的应用版本投产策略和数据库资源的投产注意点，并结合实际投产过程中潜在的问题进行总结。
1、应用版本整体流程
应用版本变更由需求方发起需求，需求经过分析后提交评审，评审通过后进行下一步的编码开发和测试。
开发团队进行业务功能开发和产品功能开发，开发完成后交由测试团队进行业务功能测试和性能测试并提供专项测试报告，对于涉及数据库资源的需要提供SQL审核报告和DDL规范检查报告。这些测试报告和检查报告作为投产资源进行交付。
开发和测试完成后，版本交付团队发起投产流程并制作应用版本。应用版本交付中须包括投产资源包、投产手册、测试报告、技术和业务检查方案、应急处理方案等内容。
运维团队对应用版本投产进行评审，评审通过后对交付的应用版本进行演练验证，并在应用投产窗口实施版本部署。应用版本投产部署时会进行技术验证和业务验证，验证不通过的将进入应急处理流程。
2、应用版本生命周期管理
应用版本流程管理的各个阶段，包括版本开发、版本测试、版本制作、版本交付、版本验证和版本投产等，如图所示：
版本开发：应用软件开发设计和编码的过程；
版本测试：指应用软件单元测试、功能测试、验收测试和性能测试等测试阶段；
版本制作：将达到开发和测试标准的应用版本制作成安装包的过程；
版本交付：将制作完毕的软件产品按规范交付给运维部署团队；
版本验证：对软件安装包进行审核、投产演练，验证产品是否符合投产要求的过程；
版本投产：将验证完毕的产品包部署在生产系统的过程；
应用版本类型分为月度大版本和补丁小版本；版本资源包括应用程序和脚本、数据库资源和投产手册等。
2.1 应用版本开发
应用版本开发是根据业务需求和产品需求进行代码开发和需求实现的过程，开发过程遵循应用开发规范和数据库开发规范，包括应用程序和数据库异常处理、应用接口和日志规范要求、并行设计原则等。其中应用设计方案涉及到基础设施调整的，需要提前和运维团队进行联合评审。
2.2 应用版本测试
单元测试针对软件设计中的最小单元进行测试，程序员从程序内部结构触发设计的测试用例应尽量覆盖各分支；
集成测试将多个模块进行组合，进行接口测试，验证多个模块之间的参数传递、功能调用是否正常；
功能测试根据软件需求说明书对系统的功能、流程、数据和业务规则等进行测试，按规定提交测试计划、测试方案、测试用例和测试报告。
验收测试指在产品交付前，由用户进行测试验证，用来确认规定的条件下产品运行情况是否满足规定的要求。
性能测试针对系统软件和硬件进行压力测试，对性能可靠性、稳定性以及其它性能负载进行测试评估是否满足上线要求，并提交性能测试报告；
安全测试是针对软件包中是否存在安全漏洞，比如漏洞扫描、防病毒扫描等
兼容性测试是不同操作系统、不同硬件平台和不同软件版本下应用的兼容性，确保所有用户都能正常访问；
针对应用版本中涉及数据库资源变更操作进行专项测试并提供性能测试报告和影响分析报告，比如SQL规范和DDL规范扫描。
2.3 应用版本制作
应用程序版本：将代码工程区和依赖包一起编译打包后生成程序版本包，注意应用程序运行环境须与生产系统运行环境保证一致；
数据库资源：包括表结构定义、表DDL和DML执行语句；
批量运行任务调度：涉及到批量运行编排或定时任务有关的调度配置和编排；
应用脚本和配置文件：脚本中避免出现和运行环境依赖的信息，必须保持一致的运行环境需要和生产系统保持一致。
应用版本投产手册：包含环境检查手册、关联系统投产手册、部署操作手册、技术检查和业务验证手册、应急回退方案、应用程序和数据库投产资源清单等内容
2.4 应用版本交付
应用版本交付是将应用版本交付到运维部署团队的过程，持续时间从版本交付阶段开始启动到应用版本投产前。版本交付中引入版本号作为应用版本标识以区分不同的版本类型，比如月度版本和补丁版本。应用版本交付可以通过一些CI/CD工具如Jenkins将构建好的应用版本交付到运维团队，提升版本发布和部署的效率。
图中是基于Jenkins+Docker实现应用版本自动化部署流程，参考《基于Jenkins+Docker的自动化部署实现》。
2.5 应用版本验证
应用版本交付到运维团队后，由运维人员按照投产手册进行正式投产前的安装验证。应用版本验证按照以下流程执行：
版本检查：根据版本部署手册进行检查，包括版本资源一致性和完整性、投产手册和技术检查手册、环境资源和网络检查等内容；
版本安装验证：根据投产手册进行版本安装部署，部署过程中相关问题及时登记反馈；
版本交接：版本验证完成后整理验证过程、反馈验证过程中的问题进行版本或投产方案优化整改，评估投产时长和业务影响，有条件的可以进行联机类或批量业务验证。
应用版本验证非常重要，往往可以提前发现版本部署过程中步骤或者方案问题，甚至是一些性能上的问题。版本验证通常在类生产环境进行，和生产系统保持对等的部署架构，甚至在部署资源上保持对等。比如版本验证中的部署时长作为实际应用版本时间窗口参考，影响到停业时间的报备等；验证过程中提取发现的应用设计方案或者数据库性能问题，避免投产后出现故障影响业务的连续性。
2.6 应用版本投产
应用版本投产是将应用版本包部署到生产系统的过程，版本投产一般安排在统一的变更窗口，涉及到停业的需要单独申请停业报备。应用版本投产过程中严格按照投产步骤和方案实施，通常由自动化部署工具完成部署操作，在部署过程中减少人工处理操作，并及时监控投产过程中上下游的业务影响。投产过程中如果遇到问题应做好应急方案，必要时候需要回退版本。需要注意的是，版本部署中下游应用系统的关联投产、多中心应用架构下的投产流程以及投产后的技术检查和业务验证。以下将重点展开介绍应用版本投产部署流程。
3、应用版本投产部署流程
3.1 应用版本的部署策略
在应用版本部署和发布过程中，分为不同的部署策略，包括蓝绿发布、金丝雀发布（灰度发布）等。
3.1.1 蓝绿发布（Blue-Green Deployment）
一种以最小的停机时间做服务升级的策略，需要维护两个版本的环境，一般当前生产流量指向环境为绿环境，而在蓝环境上部署新版本，短时间内作为测试环境。发布流程包括将一半的服务流量从负载均衡列表中移除，并更新服务版本，验证新版本没有问题后，将生产流量指向蓝环境，然后对老版本的绿环境进行版本升级，最后将所有服务流量加回负载均衡。
对于多中心部署架构的应用，非常适合蓝绿发布方式，先将同城中心的流量切换到生产中心后，再在同城中心部署应用并进行部分流量验证，验证通过后再进行所有站点的投产部署。不过这种发布只适合应用程序版本部署，因为如果应用版本中涉及到数据库的变更，由于多中心也是共享相同的数据库资源，数据库层的变动是有全局影响的。
3.1.2 金丝雀发布（Canary Release）
不停止老版本，额外搞一套新版本，不同版本应用共存。
灰度发布中，常常按照用户设置路由权重，例如百分之九十的用户维持使用老版本，百分之十的用户尝鲜新版本。
3.1.3 CI/CD的局限性
持续交付中提出了“部署流水线”的概念，指的是将代码从版本库自动化部署到生产环境这一过程。基本的部署流水线如图所示：
版本库的维护：由于开发测试环境和生产系统运行环境网络的限制，开发的代码库是无法直接集成到生产版本库中。因此需要维护两套库：开发库和生产库，二者之间的版本同步更新管理也是一个问题。
测试阶段验证的充分性：开发的版本部署到生产环境，中间需要经过一系列的测试验证，包括业务功能性、性能测试以及投产方案验证，持续部署过程中可能存在测试不充分情况。
上下游系统时序依赖：在一些重要应用系统投产时候可能是系统群集的投产，会存在上下游系统的时序依赖，持续部署在涉及到系统之间部署的时候增加额复杂性。
CI/CD流水线配置复杂化：CI/CD自动化部署流程根据投产需求需要进行配置上的调整，而且代码质量和依赖关系等不稳定因素，导致交付过程中的复杂化。
3.2 应用版本部署流程
版本投产前检查：包括系统环境检查、参数配置检查、服务运行状态检查等；
关联应用系统投产：在投产时序有依赖的需要提前投产，包括应用连通性检查、监控配置和运维支撑平台的接入和权限开通；
投产前备份操作：投产部署过程中变更的资源提前备份，包括应用程序库、数据库表结构定义和表数据逻辑备份、应用脚本及参数配置等；
投产执行操作：投产部署由自动化平台完成，包括停止应用服务、程序包下发和数据库资源变更等。通常应用服务分批投产，不涉及停业的问题，但是数据库资源中非在线DDL和热点表的变更操作，必须停业才能完成，因此在评审时评估好停业窗口。
投产执行和检查完成后，启动应用服务
应用服务启动后执行技术检查和业务验证，验证通过后投产完成
3.2.1 应用版本投产基本原则
应用版本投产部署窗口和基础设施变更窗口错开，避免相互影响
涉及到数据库重建表和表结构变更，投产步骤中包括数据逻辑备份
关联上下游应用系统投产的，在投产时序标明并注意对应的管理参数和配置同步修改
应用版本经过充分测试验证后才能到生产环境部署，应用尽量具备和生产系统对等的验证环境
应用版本中包括详细的技术验证方案、应急回退方案、影响评估报告等
应用版本中临时路径的命名规范以及清理机制等
应用版本投产期间和投产后对应用和系统运行状况进行实时监控，并出具运行报告
应用系统具备多中心架构的，检查确认各中心同步投产完成
3.2.2 应用版本多中心投产流程
对于多中心架构的应用系统，在应用版本部署时会考虑高可用的部署流程进行跨站点部署、灰度验证，以减少投产期间的业务影响，保障业务的可用性。
持续部署自动化平台实现跨中心的应用版本部署，同城和灾备站点批前投产、生产站点批后投产
同城中心投产时将流量全部切换到生产站点，应用投产完成后将部分流量（如1%）切换到同城进行灰度验证
数据库DDL和生产的应用版本在批后投产，将流量全部切换到同城后再部署生产应用
应用部署完成后恢复投产前的流量配比
基于多中心的架构，整个应用版本部署流程上尽量减少应用影响，保证业务连续性。需要注意的是，如果涉及到热点表或者非在线DDL的变更操作，需要安排在停业窗口执行，并充分评估好窗口的执行时间。注意到的是，这种应用投产部署策略和蓝绿发布策略很类似，不同之处是先进行同城站点的部署，验证通过后再进行生产站点的部署。
3.2.3 应用版本灰度投产流程
在应用服务器集群选取部分应用服务器进行投产，在网关或路由层对这部分投产新版本服务器进行部分流量访问进行灰度验证。投产失败或者技术及业务验证异常后触发应急流程，决定是版本回退还是修复版本后重新投产。
第一批应用服务投产成功后，选取第二批应用服务进行投产，所有应用服务器投产完成并且技术及业务验证完成后，本次应用版本投产完成。
灰度验证适合于不具备多中心部署的应用系统，在本地生产中心选取部分服务器优先部署并进行流量限制访问以进行业务功能验证，降低版本更新异常带来的业务影响。
4、应用版本中数据库资源部署
应用版本部署中将数据库资源单独拿出来是因为数据库相关的变更非常重要，不同于分布式应用中各应用服务其实是多活的状态，在部署的时候可以采用分批或者蓝绿的策略减少业务影响，数据库层的变更多数情况下是全局生效的，一旦变更将会有全局影响。当然如果是在数据库层做到单元化的部署架构，能够将变更影响降低到一个单元内，在一定程度上也是能够减少业务影响范围的。
4.1 应用DDL部署
数据库的DDL变更分为在线DDL和非在线DDL：在线DDL变更可以联机在线操作，对业务无影响；非在线DDL变更对业务有影响，需要停业执行。常用的在线DDL包括添加字段、修改非空和默认值约束、新增和删除索引、新增和删除分区、表清理和碎片整理等；非在线DDL操作包括删除字段、修改字段类型、修改表字符集以及改表名等操作。在应用版本DDL部署流程中，需要进行DDL规范和SQL规范检查、DDL投产时长评估和验证以及DDL投产异常时候的应急处理，如下图所示：
业务需求开发过程中涉及到的DDL变更管理统一登记到表结构管理平台，测试团队拉取表结构并进行DDL规范检查，DDL规范检查报告提交评审，并随投产包交付到运维团队。
DDL版本根据DDL变更类型分为在线DDL和非在线DDL，其中非在线DDL变更需要在停业窗口进行投产。热点表由业务开发团队提供清单，并在每次版本制作之前进行热点表DDL变更的影响评估。
DDL版本需要在版本验证环境进行测试验证，评估DDL投产窗口时长以及业务影响，该评估将作为投产窗口报备的重要参考。投产验证过程中遇到异常及时反馈并进行整改，验证通过后在投产窗口进行正式投产。
DDL版本投产在应用投产窗口执行，按照应用版本数据库资源进行部署。部署过程中因为业务冲突、系统软件环境问题或者版本问题导致的出错会触发应急处置流程进行紧急处理。
DDL在生产环境部署时，可能会因为表资源被占用导致执行失败情况，因此在投产部署时检查应用对表的访问情况并且错开业务高峰期变更。在分布式数据库中，还可能存在部分分片执行成功部分分片执行失败的情形，因此在执行完DDL变更后还需要针对性的执行表结构一致性检查。
另外，在DDL投产后关注应用SQL执行计划的变化，防止出现因为执行计划变差出现的应用性能问题。同时，针对生产环境投产的表结构以及热点表清单，要同步到开发测试环境进行表结构版本统一管理，形成闭环。
4.2 应用DML部署
SQL规范要求：执行的DML语句是否全表扫描、分布式数据库是否存在所有分片下压执行等影响性能的语句存在；
并发控制：DML语句的并发不能太高，影响到正常的业务运行；
事务大小控制：控制每次commit的笔数和记录数，避免出现大事务；
运行时间评估：DML语句运行控制在变更窗口内，超过时间的需要评估影响；
DML错误结果处理：DML执行过程中处理错误的数据需提供差错处理方案
DML部署时候的SQL性能在应用版本部署时候很容易忽略掉，同时为了减少变更时间加大并发提高效率，而这些往往会加大数据库集群的压力，对正常的业务访问造成影响。
5、应用版本部署潜在问题
对于生产运行的应用系统，大多数时间保持平稳运行的状态，影响业务连续性的事件往往是因为应用版本迭代或者基础设施变更引起的。因此在应用版本部署时候应该经过充分的测试验证，确保投产方案和架构设计上的完善，除此之外还有一些潜在的问题需要注意。
应用系统上下游投产又依赖关系的时候，下游系统优先投产并且对外开放了业务接口，新的业务请求过来时发现下游接口请求不存在。因此在涉及到上下游关联投产的时候，下游系统优先投产或者上游系统投产后的接口设置白名单，等投产完成后再对外。
应用投产后反馈交易访问变慢，响应时间变长，通常是因为执行计划变差导致。虽然经过版本部署前的SQL规范检查，但还是存在测试环境和生产环境的差异性导致的SQL检查不准确，还可能存在部分新增的业务表一段时间后才有数据量导致的统计信息变动。这些情形下只能采取些应急措施，添加索引以使得执行计划最优，减少业务影响。
部分应用采用热部署的方式，投产时候无需进行应用重启操作。但可能存在热部署不生效的问题，因此最优的部署策略还是采用分批重启或者蓝绿部署的方式。热部署不生效在投产演练阶段可以提前发现，能够及时的调整投产部署方案。
很多时候测试验证环境和生产环境在环境配置和资源上存在差异，版本测试验证也只是流程上的验证，无法做到性能上的测试验证。比如和环境依赖的配置参数部署到生产、数据量变化导致执行计划不准确、高并发的条件下暴露的性能问题等。
应用版本部署DDL的时候可能会出现数据库资源冲突，导致DDL执行不过去，影响投产窗口的运行。一般是因为长事务或者长SQL占用表导致，这种因为生产业务的偶发性在投产验证阶段通常也是不能发现的。
由于前期系统容量和资源评估不充分，导致应用系统上线后在业务高峰期或者秒杀时段达到系统所能支撑的极限。这个一般在投产窗口不能及时的发现，等到压力时段的时候才能体现出来，问题发现的时候需要采取应急策略如资源扩容等。
应用版本在投产时候执行的一些DML语句操作，本身性能不好比如全表扫或者全分片访问，加上高并发操作，导致对数据库资源造成压力，影响了正常的业务访问。这一点很容易被忽视，因为这一类投产语句只运行一次，没有考虑到投产过程中带来的业务影响。
应用版本部署过程中潜在的问题远不止以上这些，这里只能抛砖引玉、举一反三进行总结。
参考资料：
分布式核心系统运维的一点思考
