今天谈下业务系统割接上线方案的内容，对于大项目来说，业务系统在建设完成并UAT测试通过后，最终的割接上线往往是一个系统工程，不能有丝毫的马虎。

系统割接上线概述

临近项目上线，最近周末都在加班处理上线前的数据初始化，系统环境部署，系统参数配置，服务部署，权限设置等基础工作。对于系统上线，最重要的还是要有详细的上线和割接计划，同时有完整的检查单CheckList，否则就很容易遗漏关键事项。

对于ESB平台来讲，由于本身就不存储数据，同时服务本身运行无状态，因此对于平台的上线并没有太多的期初数据初始化问题。更多的是类似接入系统，服务元数据，服务授权和安全等基础元数据导入，系统配置设置等相关事宜。这比业务系统上线和割接本身要简单的多。

一个大项目的上线，需要多方，多个业务系统配合，步调一致才能够完成。而对于ESB平台来说，更多要做的还是进行服务注册和接入，发布最终的服务目录，同时对接入系统和服务授权信息进行校验，确保这些信息在正式生产环境开始运行的时候不发现错误或问题。

如果对于业务系统的上线或割接，大家都比较清楚，需要有详细的上线割接计划和方案，方案中必须还包括出现问题后的回退方案。同时对于系统上线，需要考虑期初静态数据的初始化，动态流程中数据的导入，系统配置等各项工作，这些都是在生产环境部署完成后必须进行初始化和检查的关键工作。

一个系统如果是进行版本更新或割接，那么一定会强调在割接过程中的平滑性，即在系统上线或割接后不能对老的业务，已有的业务流程造成影响。同时在割接过程中希望的是能够最短时间完成，建设停机消耗和等待时间。

如果能够做到应用系统本身的热部署，或者或灰度发布往往更优。

系统割接上线，从自身系统需要考虑对已有功能的向下兼容性，从外部系统协同角度，需要考虑在割接完成后自身提供接口服务的注册，已经割接完成后自身业务系统消费的服务是否能够正常提供。这些都必须步调一致来完成，否则就很容易出现由于各级时间差导致的各个业务系统基础数据不一致，控制逻辑不同等问题。

对于系统割接上线完成后就是正式的生产环境，如果要在生产环境进行最终的系统功能验证往往直接会影响到业务，也可能影响到基础数据的不一致。而这个时候常见的做法主要有：

其一就是将生产环境的应用和数据再复制回测试环境，然后再测试环境进行模拟生产环境的进一步验证；其次就是在割接完成后必须要提前对消费的服务进行连通性侧设验证，确保在生产环境割接和部署完成后能够正确的消费到外部系统的服务。

对于已经上线的业务系统，在互联网领域更加强调灰度发布能力，而实际上可以看到对于ESB总线项目，仍然可借鉴灰度发布的思想，先根据省份或服务提供方进行灰度发布，在验证来没有问题在进行英语程序部署包的全面部署和发布。

割接上线关键内容准备

下面再谈下系统割接上线内容准备的一些关键点。

第一就是生产环境安装和部署手册

这里面实际是包括两个方面内容，一个是标准的数据库和应用中间件的安装，一个是应用程序的部署，服务的部署。对于数据库和中间件的安装和基础配置，数据库和应用中间件的参数调优等，往往应该提前就很早做完。而实际上线都是指的应用和服务部署。

对于应用和服务部署，最重要的就是基于持续集成的思路，应该是将UAT环境测试通过的部署包迁移到生产环境进行部署，整个部署包不再进行重新编译构建，而只是应该修改相关的配置文件和参数设置。这样可以确保部署到生产环境的应用和程序是测试环境测试通过的版本。

而实际我们在做项目的时候，往往在交维前各个环境都是我们自己管理和部署，不一定形成了很完整的文档，导致这个环境部署工作很随意，这也是导致后续生产环境部署后出现问题的一个原因。

对于IT管理和治理比较规范的企业而言，往往有严格的版本发布和上线流程，即使是对于全新项目生产环境的上线也不能由乙方自己去操作，必须填写上线申请单，提供安装脚本和部署包，部署详细步骤说明，转由交付IT运维人员进行操作。在这种情况下往往上线过程会更加严谨受控。

第二就是数据初始化脚本

对于应用的数据初始化脚本实际上包括两个方面的内容，一个内容是应用本身的参数配置脚本，一个是涉及到应用的静态数据初始化和导入脚本。这两部分脚本都必须提前准备好，对于前者往往涉及到应用系统本身的元数据管理功能存储到数据库，也可能存储在应用服务器的操作系统，应用本身的配置文件中，都必须考虑到。而对于静态数据初始化脚本，往往需要提供相应的初始化sql脚本进行导入，而不是简单的提供Excel，这样才能够方便甲方的系统管理员进行批量导入。

对于数据初始化脚本，应该有完整的数据导入和校验逻辑，异常提升逻辑，以方面在数据初始化失败的时候查找问题。同时在数据导入后，最好再提供相应的数据验证脚本，对导入的数据的正确性进行验证和确认。而不是完全依靠人工的方式去核查和比对。

第三就是应用上线和部署完成后的检查单CheckList

这个清单相当重要，一定不要相信自己的脑袋能够记住所有的检查项而没有遗漏，一个应用系统的上线涉及到数据库，中间件，应用程序，数据，接口，应用功能多方面的内容，要确保上线功能没有问题必须每个点都需要检查到位，因此必须要有详细的检查清单，按照清单进行逐一的检查才可以。

检查单就是起到这个作用，我们只需要提前想清楚所有的检查点，并给出具体的检查方法，然后在系统部署和上线完成后，按检查单里面的检查项进行逐一的检查就可以了。这样可以确保没有任何的遗漏。

最后就是上线完成后的人工验证

这个步骤也不能少，即我们的应用在上线完成后，往往会在生产环境部署完成的应用上进行一个初步的冒烟测试，确保所有功能都没有问题。在这个过程中可能会产生垃圾数据，可以在测试完成后进行清除。整个测试过程为了不影响到实际的组织和用户，我们也可以在系统里面单独建立一个临时组织和用户，用分配的临时用户进行相应的单据创建，流程审批，单据生效，接口和业务联通流转等方面的测试，确保整个端到端流程是完整的。

当然还有一种方法就是我们在生产环境正式部署和配置完成后，可以将生产环境的整个内容再完全克隆回UAT环境，在UAT环境进行相应的测试工作，这样可以确保生产环境不进垃圾数据，同时又确保生产环境的配置没有任何问题。在从生产环境克隆回来的时候，注意重点是克隆生产环境数据库和参数配置内容，而对于测试环境的一些参数配置项仍然需要保留测试环境的。

系统割接上线方案模板

在这里给出一个业务系统割接上线的方案模板，对于系统建设实施过程中，割接上线方案也是整体项目最终交付和验收的一个重要文档。因此在这里专门再谈下割接上线方案应该包括哪些具体的内容点。

1-系统当前现状分析

1.1 系统部署架构现状

1.2 系统当前硬件资源详细描述

1.3 系统技术架构现状

1.4 核心数据库，中间件，技术组件说明

第一部分重点说明当前应用部署架构现状，硬件和存储等IT硬件设施逻辑架构和详细资源清单说明。同时说明业务系统的IT技术架构，使用到的核心数据库，中间件，技术组件。

在逻辑架构中，应该能够体现出具体各个中间件，技术组件，应用的逻辑部署关系。

如果是全新的业务系统部署上线，则不存在这部分内容的描述。

2-本期系统目标架构说明

2.1 系统目标部署架构

2.2 系统硬件资源列表

2.3 系统技术架构

2.4 核心数据库，中间件，技术组件说明

2.4 目标架构和当前现状差异分析

第二部分应该重点描述目标架构，其中目标架构仍然包括了硬件基础设施架构，也包括了软件技术架构。同时需要分析目标架构和现状差异。

3-割接方案说明

3.1 硬件割接方案说明

3.2 软件割接方案说明

3.3 数据割接方案说明

对于系统的割接可以理解为硬件和两个不同的层面。

有些割接可能只涉及到硬件的增加，比如数据库增加一个RAC节点，原来用的HaProxy需要割接到硬件的F5硬件均衡设备，数据库存储容量需要进行扩容等。

还有一些割接只涉及到软件层面，比如软件重大版本的部署。

也存在同时涉及到软件和硬件层面的割接，比如传统的软件架构当前升级为微服务架构，你可以看到软件层面，硬件层面都存在重大变化和修改。

同时在割接方案中也存在仅仅进行数据割接的情况，比如硬件部署环境和软件当前部署版本均没有发生变化，但是需要对数据库中数据进行割接。比如对于数据库中的物料信息进行新旧代码切换等操作。

割接方案简单来说就是要说清楚从现状到目标的具体变化点。因此在进行割接方案阐述的时候也可以进一步的配合系统物理部署架构和逻辑部署架构图进一步进行对比阐述。以方面阅读人能够更加明显的看到割接前后的差异点和变化点。

4-割接影响分析和割接准备

4.1 割接原则说明

4.2 割接影响分析(硬件，软件，数据，用户)

4.3 割接前的准备工作

4.3.1 需要提前准备和安装的硬件和中间件

4.3.2 数据备份工作

割接影响分析是割接方案里面最重要的一个内容，即需要分析割接对整体业务系统运行的影响情况，在整个影响分析中识别和分析关键的风险点。

影响分析包括了硬件，软件，数据各个层面的分析。同时也包括以用户视角的影响分析和评估。有些割接属于底层割接对用户没有影响，但是有些应用层面的割接往往割接完成后对用户访问方式操作入口，以及具体功能都会有影响，这些也需要进一步分析说明。

割接前的准备工作需要详细描述的内容包括了：

需要提前准备的硬件和网络环境

需要提前准备和安装的数据库和中间件，技术组件等

需要进行的环境配置文件，数据库备份工作

5-详细割接计划

5.1 割接组织和人员

5.2 割接时间

5.3 割接详细的步骤和参与人员

5.4 割接详细内容说明

5.4.1 当前环境备份操作

5.4.2 环境准备和中间件安装

5.4.3 应用安装部署

5.4.4 数据割接和切换

5.4.5 环境配置等

5.5 割接完成后的验证和确认

在割接计划部分需要说明割接组织人员，割接的详细步骤，每个步骤的时间和参与人员，对于每个割接步骤又需要在割接详细内容部分给出详细的割接过程说明。

在割接完成后还需要有专门的割接验证步骤说明，以确保割接成功。

6-割接风险分析和应对

6.1 割接风险分析

6.2 割接回退和恢复方案详细说明

6.3 割接应急方案说明

对于割接风险实际上包括两个层面，一个是在割接过程中就发生了问题这个时候直接进行回退操作即可。也可能是割接本身没有问题，但是系统上线后出现问题，这个时候可能已经产生了新的数据到数据库，因此不能简单的采用回退操作，必须有详细的应急处理方案和回退方案。

如果是简单的回退那么就会造成数据丢失，需要业务人员重新进行补录。因此在这种情况下往往需要考虑的是各种部分回退的策略，或者准备新数据自动签约回老架构和数据库的脚本等。

在当前业务系统间本身存在关联依赖和集成，因此割接影响分析不仅仅是分析对自己系统的影响，还需要分析割接上线后如此系统出现重大问题，对其它外部依赖系统造成的影响。比如上线后，新的数据已经传输给其它业务系统，那么这个时候回退就还涉及到其它业务系统也存在相应的数据回退操作，其复杂度远超过对单个系统的回退处理。