信息系统不停运检修典型场景介绍-河北新营公司

第一篇：信息系统不停运检修典型场景介绍-河北新营公司

信息系统不停运检修典型场景介绍

一、不停运检修的内涵与定义

信息系统不停运检修是指信息系统检修期间系统功能无离线、无闪断、用户无感知，业务流转无缺失、数据无丢失，具备检修短（开发、测试周期短）、平（检修期间业务系统平稳）、快（检修发布完结快）等特点。

二、适用的架构模式

通常采用负载均衡、应用级容灾和双活等部署架构模式的信息系统，具备采用不停运检修的基本条件。

（一）负载均衡模式 1.F5负载均衡模式

F5负载均衡是用以扩展网络设备和服务器的带宽、增加吞吐量、加强网络处理数据能力的设备。F5负载均衡周期性通过TCMP包对每个负载均衡Pool池中的信息系统服务器（Node节点）的服务端口进行活性检测，具备12种算法通过VIP（虚拟服务地址）截获用户流量并按照规则进行负载平衡。Pool池中的任一Node节点暂离检修不影响对外VIP（虚拟服务地址）地址的服务可用性。

2.阿里云平台SLB负载均衡

SLB（Server Load Balance）服务本身以集群方式部署（可以无限扩容），通过设置虚拟服务地址（VIP），将位于同一地域（Region）的多台云服务器（Elastic Compute Service，简称ECS）资源虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到云服务器池中。

SLB负载服务具有功能强大、无限扩容、动态扩容、Session保持、健康检查、RS权重六大特点；SLB服务会检查云服务器池中ECS的健康状态，自动隔离异常状态的ECS，从而解决了单台ECS的单点问题，同时提高了应用的整体服务能力。单台服务或者服务器离线检修完全不影响前端用户的任何功能体验。

（二）应用级部署容灾模式

容灾模式具备冗余的网络、存储、数据库及应用部署，当一套链路出现异常通过网络切换用户能够访问灾备中心的一套链路。容灾模式最大的特性在于一套在线一套灾备。应用级灾备包括两个方面：数据同步和应用接管。数据同步是应用接管的前提。应用级灾备要求提供冗余的网络线路和设备。正常情况下，用户通过生产中心的业务网络访问生产中心的应用服务器；在发生灾难时，通过网络切换，客户端能 3 够访问到灾备中心的备用服务器。通过手动的访问目标端切换可以实现不停运检修的操作。

（三）部署链路双活模式

双活模式，又被成为Active-Active工作模式，即两套工作链路都处于激活状态，可并行处理来自用户的服务请求，一旦某套链路出现故障、离线或检修，另一套链路将及时接管其工作，且不影响自己现有的任务。该工作模式在通过互为冗余备份来确保系统高可靠性的同时，还具有均衡业务量、充分利用资源和提升系统性能等诸多优点。

双活包括：网络双活、存储双活、数据库双活和应用双活；双活模式处理层面上实现了完全冗余，区别于容灾模式，最大特点是两套网络、存储、数据库及应用都是在线运 行的，如果离线了一套链路任一环节，另外一套链路还是在正常运行，对用户来说是不可感知的，业务几乎不受影响。因此一套网络、存储、数据库和应用完成链路中的任一环节检修，信息系统对外输出功能可用率依然保证100%。

（四）DevOps平台模式

DevOps平台实现了持续集成与部署，所有服务都必须通过代码静态检查、代码构建、集成测试、部署等一系列自动化检测过程，确保了服务的可靠性。DevOps提供灰度发布功能，确保新旧服务平滑过渡的发布。检修人员可以根据灰度用户反馈，决定是否回滚，期间用户不会有所感知。另外，服务本身以集群方式部署，保证了服务的高可用性，当集群中的一个系统发生故障时，集群会迅速做出反应，将该系统的任务分配到集群中其它正在工作的系统上执行。

（五）其他参考模式 除以上模式可进行不停运检修外，满足以下信息系统部署模式均可参考进行：分布式应用多节点集群部署、应用服务模块化拆分冗余部署、数据库RAC模式部署、SAP三架构标准部署、检修发布采用直接推送方式及阿里云EDAS分布式服务。

三、不停运检修典型场景

（一）硬件/网络故障类

硬件/网络类不停运检修包括：服务器硬件故障、网络故障，此类不停运检修多为不可预见性检修，突发性较强。

检修作业步骤: 1.结合已有管理系统，详细记述故障情况； 2.下发操作权限，配置操作人员；

3.手动离线故障对象，监控存活服务器性能； 4.手动导流分压，避免故障冲击最大化；

5.检修完成后手动上线对象，回收操作权限，记录处理结果及遗留问题。

（二）产品补丁升级

产品补丁升级包括：中间件、数据库、操作系统等产品补丁升级，产品补丁升级在多数情况分为补丁上传覆盖、配置文件更新和服务、服务器重启两个步骤，数据库产品还可能涉及多次重启。

检修作业步骤： 1.制定不停运检修方案、评估冲击范围、配置责任人员；

2.发起方案审核，结合已有管理系统详细记录检修内容，保留检修痕迹；

3.下发操作权限，监控操作过程；

4.手动离线产品补丁升级对象服务器，监控存活服务器性能；

5.人工升级产品补丁，重启服务器； 6.手动上线检修完成对象，轮询下一个检修； 7.测试验证补丁升级结果，回收操作权限； 8.结合已有管理系统反馈补丁升级结果及遗留问题。

（三）应用变更发布类--程序包小版本升级发布 应用变更发布类主要涉及程序jar包、数据库脚本、jsp/xml等配置文件更新调整，检修可能涉及三类操作，或只涉及其中任一类或者任一两类操作，因此检修以服务是否启停划分。

检修作业步骤： 1.针对服务无启停类

应用变更发布服务无启停多数情况下为数据库脚本类和jsp配置文件更新检修，此类发布即时生效。

（1）记录不停运检修详细内容存档，发起不停运检修审核；（2）配置不停运检修专员，下发操作权限；

（3）手动执行数据库脚本或依靠数据库脚本批量执行工作完成脚本升级，使用配置文件自动更新工具配合人工审核完成配置文件更新调整；

（4）测试验证升级发布结果，回收操作权限；（5）反馈升级结果，归档检修流程。2.针对服务启停类

应用变更发布服务启停多数情况下涉及jar包更新与XML类文件调整。

（1）记录不停运检修详细内容，发起不停运检修审核，评估冲击可能性；

（2）配置不停运检修实施专员，下发操作权限；（3）手动离线服务单个节点，阻断负载均衡请求分配；（4）使用自动化工具完成批量脚本升级、jar覆盖和配置文件调整，更新至所有节点；

（5）人工重启离线服务节点，测试升级结果；（6）手动上线检修完成后的服务节点，轮询下一节点；（7）测试验证升级发布结果，回收操作权限；（8）反馈检修结果及遗留问题，归档不停运检修流程。

（四）中间件服务配置调整

中间件服务配置调整多为中间件控制台服务参数配置，中间件参数调整又细分为重启生效和即时生效两类。检修作业步骤： 1.针对即时生效类

（1）利用已有管理系统记录参数调整详细内容；（2）配置不停运检修实施人员，下发操作权限；（3）即时操作调整，监控调整效果；（4）测试验证调整结果，回收操作权限；（5）反馈记录调整结果及遗留问题。2.针对重启生效类

（1）记录参数调配详细内容附件说明参数功能；（2）审核配置调整方案，配置不停运检修实施专员，下发操作权限；

（3）手动离线调整服务对象，阻断前端用户服务请求分配；

（4）人工调整参数，记录操作过程；

（5）上线操作对象恢复服务请求，轮询下一对象；（6）测试验证调整结果，回收操作权限；（7）归档不停运检修流程。

（五）资源池检修

1.针对系统中需要调整的部分，编写检修方案； 2.审核检修调整方案，配置不停运检修实施专员； 3.做好备份，人工调整系统参数，记录操作过程，监控服务器性能； 4.检查操作结果，保持系统能顺利登陆使用，保证系统内业务主机正常；

5.测试验证检修结果，回收操作权限； 6.反馈检修结果及遗留问题并归档检修流程。

（六）端口整改

1.针对需整改的端口编写检修方案；

2.审核检修调整方案，配置不停运检修实施专员； 3.待修改的节点在F5上离线，更换端口测试正常后再在F5上启用该节点；

4.检查操作结果，确保端口整改成功； 5.测试验证检修结果，回收操作权限； 6.反馈检修结果及遗留问题并归档检修流程。

（七）DevOps模式下检修 1.新服务上线

（1）租户管理员／普通成员，在工作区下新建流水线，配置持续集成与持续部署；

（2）持续集成成功运行后，若选择推送至镜像仓库，可在镜像仓库中找到成功推送的镜像；

（3）持续部署成功运行后，服务将被部署到对应测试环境中；

（4）测试人员对测试环境的服务进行测试；

（5）测试通过后，检修人员可以一键将服务部署到生产 环境。

2.产品补丁升级

（1）产品补丁加入后，触发持续集成持续部署，部署到测试环境；

（2）测试通过后，检修人员可以选择，灰度发布到生产环境；

（3）检修人员根据灰度发布情况，选择是否回滚服务。

四、技术要求

（一）信息系统应用部署程序包要有效“瘦身” 为发挥不停运检修发布实施“快”的特点，信息系统应用部署程序包要求控制在300M以内，最大不超过500M。程序包超过1G必须整理剔除第三方、版本重复及无用备份包，无法有效“瘦身”建议进行服务化拆分。

（二）不停运检修实施时长要短

不停运检修实施期间单节点的长时间离线或将对存活节点造成流量高压，因此不停运检修单节点启停应严格控制在10分钟以内。

（三）要充分利用自动化发布工具

为规避人工可能出现的误差性批量操作，应选择安全有效的自动化发布工具或使用已有中间件的自动化检修功能。