前言



回顾近年来企业的发展趋势，企业数字化转型的出现使得越来越多的业务演变成数字业务，数字化业务对信息技术提出了更高更严苛的要求，比如：快速响应市场需求，尽快交付让客户满意的高质量产品，并及时得到市场和客户的反馈，从而可以及时调整公司战略和产品方向，提升市场占有率和企业竞争力。



持续交付：指代码从本地提交后的构建、部署、测试和发布整个过程的自动化实现。 

DevOps：通过整合工具、方法、技能和流程等建立一个流水线的过程，使业务更快的运营，并更快地应对变化。在EXIN DevOps体系中由三大支柱（规范敏捷、持续交付、IT服务管理）和一个基础（精益管理理念）组成。



新的数字化业务需要新的应用架构（如：微服务）来支撑，而新的应用架构需要新的基础架构（如：容器化）来支撑。同时，新的应用架构和基础架构变化带来了运维管理模式的转变。新的运维管理模式需要引入并借鉴新的理念和实践（如：持续交付和DevOps等）。



在过去这么多年，很多企业的研发团队已经采用了Agile，Scrum和XP等方法论来缩短开发周期和提升研发效能，但是发现整体的业务交付效率还是不够高，而且发布变更成功率仍然没有得到改善，传统的应用系统发布模式已难以支撑新业务的发布要求。



本文结合了我们的工作经验和思考，谈谈如何通过“十步法”实现应用系统的高效率发布，同时做到“事前审批、事中控制和事后审计”。



第一步：发布人员左移化



任何工具和系统的推广都是一种文化变革，应用系统的自动化发布也是如此。早期的发布模式中，往往是等开发人员完成软件开发后才向运维人员做正式的移交和发布工作（DevOps的反模式之一），这意味着：运维人员在此刻才拿到应用软件的信息和发布方式，没有足够的准备时间和充分的发布过程测试，随之而来的是，更长的发布变更时间和更高的发布失败率。



在新的发布模式中，需要引入“主动运维”方法，运维团队提前深入项目过程，与项目组讨论非功能需求，制定移交方案，使运维人员提前掌握运维技能，快速推进运维移交，并对发布过程和工具进行充分的测试。主动运维的左移模式让开发和运维部门不再存在无形的“沟通”壁垒，而是更好的协作。



第二步：发布对象应用化



当我们在实际运维工作需要对操作对象（比如：主机）执行脚本时，一般有如下3种情况：



1. 通过远程登录（或通过堡垒机登录）实际的主机，在主机层面执行脚本操作；

2. 通过类似Ansible等工具使用SSH协议远程登录并批量执行脚本操作；

3. 在主机操作系统安装Agent，通过作业调度平台（如：蓝鲸作业平台）实现脚本的批量操作。



如果我们需要对一个包含100台机器的应用系统执行发布操作，我们如何记录这个应用系统包括哪些机器？实际操作中是否会遗漏机器或是发布到错误的机器呢？



对此，我们可以通过构建“以应用为中心”的服务树（也称为“业务拓扑”）来解决，将应用系统从应用-环境-服务/子系统-模块/组件-主机列表进行层级的划分，这样在实际的应用发布、巡检和监控测试配置时直接引用对接的层级即可，而无须记住对应层级包含的主机信息。（当然，针对层级下主机的维护可以通过主机命名规则的标准化，自动更新和移入对应的层级。）





一般情况我们建议服务树的层级不超过5层，以一个“个人网银“系统举例如下：





应用系统：处于服务树的顶层，如：个人网银、手机银行、柜面系统等。



环境：指应用系统具体运行实例所在的物理环境，比如：开发测试环境、准生产环境和生产环境。



服务：或称为子系统，是指应用系统中的子功能模块，如：前置服务、后台服务、报表服务等。



组件：或称为模块，是指用来对应用系统的逻辑模块进行精细化的定义，如：PC接入端应用主节点组件、PC接入端应用集群组件。针对同一个应用服务下各服务器在发布操作中的行为差异做进一步分组，也就是意味着：在应用发布选择发布对象时，我们只需要选择最底层的层级即可，无需选择具体的服务器对象，否则服务树就失去了意义。



服务器/主机：即具体的组件/模块（程序包）运行所在的操作系统。



第三步：发布流程标准化



标准化先行，唯有建立在标准化基础上的自动化才有可能，否则运维的自动化很可能比手工操作更加糟糕。对应用发布来说，我们需要通过梳理、映射和绘制出每个应用系统的发布流程，包括具备哪些步骤、登录哪些平台、每个步骤的执行操作、执行权限和执行对象等。



发布流程的最佳实践在于确定应用系统每次发布的步骤是一致的，即对于不同的环境（开发、测试、生产）采用同一脚本、同一工具和同一操作进行发布，针对无法固定的可作为“变量”，比如：发布对象和发布文件包等。





上图列举了一个简单应用系统的发布流程，这一个发布流程就至少涉及到了四个工具/平台（我们可以称为“原子能力”），包括：制品库、作业平台、监控告警平台和自动化测试工具等。



版本打包：开发从git或svn将文件打包并交付给运维人员；



版本文件上传：通过作业平台把版本文件上传到发布平台的中转机；



屏蔽告警：前往监控系统屏蔽对应的业务告警策略；



停止进程：上机用命令行或脚本将进程临时停止，为更新做准备；



更新版本：通过作业平台把版本文件分发到各个对应的服务主机上；



进程启动：上机用命令行或脚本将服务进程重新拉起，使其恢复服务；



测试检查：利用自动化测试工具或系统跑一遍测试流程，验证可用性；



告警屏蔽解除：确认OK后，登录监控系统将之前的屏蔽策略解除。



当然实际的发布流程和步骤复杂得多，我们将在后面的篇幅说明如何实现跨系统的调度自动化。



第四步：发布步骤原子化



发布流程的每个步骤需要具备原子性，原子性意味着一个步骤只完成一项操作，只涉及一个操作平台/工具，且操作内容应独立和完整。





如上图所示：



• “版本文件上传” 步骤只登录 “作业平台” 执行 “文件传输”操作；

• “告警屏蔽” 步骤只登录 “监控告警中心” 执行 “屏蔽告警”操作；

• “停止进程” 步骤只登录 “作业平台” 执行 “脚本执行”操作。



第五步：原子能力平台化



基于平台化的建设，原子能力具备天然的优势。首先，平台自带的原子能力模块（配置模块和作业调度等）统一注册在API Gateway，并向上层提供全面通用的Restful接口；其次，平台化具备足够的包容性，支持企业已有的存量系统作为能力模块接入到平台；最后，平台化提供了低代码运维开发框架，支持快速编排和定制运维场景工具。





另外，平台化提供的运维编排引擎有助于将日常运维经验沉淀并固化到步骤中，实现操作标准化；平台化提供的运维开发平台有助于运维场景的工具化；平台化建立的运维工具生态提供了开箱即用工具有助于运维服务的自助化和自动化。





第六步：发布编排图形化



应用系统发布的过程可以简单理解为：使用“工具”按照一定的“顺序”完成一系列“动作”。基于平台化的能力，图形化的发布编排引擎/工具有助于降低使用门槛和工具的推广，从而提升发布效率。





用户可以通过图形界面进行任务流程编排。在编排页面，用户可以通过左侧的工具栏来添加节点，流程节点包含流程控制节点和任务节点。



• 流程控制节点包括：



开始节点——标识流程的开始；



结束节点——标识流程的结束；



并行网关——标识并行执行的开始；



分支网关——标识分支执行的开始（每个分支都需要设置分支表达式，执行时只有一条表达式为 True 的分支会被执行）；



汇聚网关——标识并行或分支的结束。



• 任务节点包括标准插件节点和子流程节点，包括：



作业节点：分发文件、脚本执行、作业执行和定时作业等；



VMware节点：创建VM、关闭VM、启动VM、重启VM；



监控告警节点：屏蔽告警、取消告警屏蔽；



其他：发送通知、定时、暂停、手工审批；



自主开发插件：提供一套完整的开发流程规范，通过丰富的表单界面和验证逻辑将企业内部各个系统、各个平台的 API 组装成一个标准插件。



第七步：审批流程轻量化



事前审批，相信目前绝大部分的企业已经实现了运维流程的电子化，如使用ITSM系统实现流程管理和审批，包括事件管理、变更管理、请求管理、可用性管理和问题管理等。



但是，往往一个应用系统的发布和上线流程审批完成需要多则1~2周，少则3~5天。这跟数字化时代的快速响应客户需求和缩短软件交付周期的要求是不匹配的，因此，在EXIN DevOps体系和ITIL 4中均提出了包含最少必要信息（MRI）的轻量级ITSM，重点关注在业务连续性和高可用性。





来源：EXIN DevOps Master白皮书

基于轻量级ITSM或敏捷ITSM原则，应用发布的流程审批系统建议包含如下功能：



支持符合用户个性化场景需求的自定义流程设计



为响应不同用户的服务管理场景，流程服务提供可自定义的流程设计服务以满足用户的个性化需求。用户可以根据自身需求进行工作流程的设计及日常管理。



工作流可视化



为让用户更加直观感受服务场景下的工作流向及进度感知，通过后台设计环节中的预览式界面，和前台单据的流程视图，提升用户体验友好度。



组件服务，促升服务效率



通过平台的其它能力（配置模块、监控模块等）和企业服务总线，实现统一登录，人员权限，信息推送的集中化管理，降低信息维护和管理成本，提升流转效率。





第八步：发布人员角色化



事中管控，为了在发布过程中更好的实现权限管控，应用系统发布模型中按照角色进行划分，根据以往的项目经验，我们建议应用系统发布平台至少包含4种管理员角色：



发布平台管理员：



平台的最高权限，具备所有的权限；



发布模型管理员：



具备发布流程设计和编排的权限；



发布模型审核员：



具备对发布流程和步骤查看的权限；



发布操作员：



具备执行发布流程的权限，理想状态下发布操作员选择发布的目标对象和文件包后，只需要点击“发布”按钮即可发布到测试、UAT或生产环境。





基于角色化的管理方便统一的审计，可以通过审计中心对系统内所有任务审计的总览视图，做到事后审计。





第九步：发布操作自助化/自动化



基于平台的图形化发布编排工具完成发布步骤的编排后，我们可以实现应用系统发布操作的自助化和自动化操作。



自助化：对于生产环境的发布或是有变更窗口的发布工作，我们可以通过一键式的自助发布来实现。当审批流程走完或到发布窗口时间，由发布操作员选择“程序包”和“发布对象”后，点击发布流程的“启动”按钮即可开始应用系统的自动化发布。





自动化：对于测试环境的发布或低风险发布，发布的动作可以由流程来触发，当发布流程审批完成后自动启动发布流程或定时启动发布流程。





第十步：发布过程可视化



应用系统发布状态的实时状态有利于及时了解发布进展，通过多种颜色展示不同的状态，如：绿色代表执行成功，橙色代表正在执行，蓝色代表等待执行，红色代表执行失败。





对于需要更好展示效果的，可通过大屏可视化的设计器构建应用系统的发布状态或应用墙。





总结



任何技术或工具的推广都是一种文化变革，新的时代需要新的理念和新的思维模式。以上从发布人员、步骤、流程和工具等方面谈了笔者对于应用系统发布的一些看法和建议。在应用系统发布时，做好这十个方面，能够大大提高应用发布的效率，缩短发布周期，提高团队效能。同时也欢迎各位一起探讨和交流，共同探索更高效的思维和理念。