为应对日益复杂的业务系统运维工作，降低信息中心的运维管理压力，参照IT服务管理（Information Technology Service Management，ITSM）标准，上海数慧构建了“数慧IT运维管理整体框架”，建立了包含运维服务内容和运维服务管理两大部分的运维服务体系，来帮助客户保障政务系统的长治久安，降低在零散运维中的成本。

上海数慧IT运维管理整体框架

一、运维服务内容

业务系统因为各种各样的问题，有可能会导致服务暂停，例如磁盘空间不足、CPU超负荷运转、数据库表空间满等问题，这些问题都需要通过日常运维来解决。

同时，在“互联网＋政务服务”的要求下，全国不少省、市都明确了业务系统向云上迁移的要求，强调了政务安全的重要性，这也需要更加专业的运维服务。

基于此，上海数慧推出了包括自动化监控、系统安全加固、政务云迁移、容灾建设等内容的运维服务，具体将帮助用户解决以下关键问题：

1.自动化监控

实时对业务系统的网络、CPU、内存、磁盘、数据库表空间、数据统计及性能指标进行监控，出现异常情况时通过邮件、短信等方式进行警告，为问题的解决提供准确情报。

2.系统安全加固

以国家信息安全等级保护制度第三级为标准，对基础设施、网络数据传输、操作系统等进行安全加固，防范病毒入侵、黑客入侵，保障数据安全。

3.政务云迁移

响应国家政策要求，将业务系统从本地迁移到政务云，实现迁移期间业务不暂停，迁移后数据不丢失。

4.容灾建设

通过同城或异地灾备环境建设，实现数据和应用的同步容灾，保障业务系统出现灾难时，可在极短时间内将用户访问的系统切换到灾备环境，使灾难的影响尽可能降到最低。

二、运维服务管理

要做好运维工作，还需要一套管理制度，用来衔接问题处理的各个环节，使运维工作标准化，主要从运维流程、运维人员管理、运维管理平台三个方面，来建设运维服务管理能力。

1.规范化的工作流程

服务台：运维流程的入口和出口，与各个环节联系密切。

用户通过它来提出问题，运维人员通过它来反馈问题及进度。

事件管理：在发生故障事件时，需要尽快恢复服务并减少对业务的影响。

事件管理主要提供服务台和事件管理者对于事件的记录、处理、查询、派发等功能。

工单管理：主要是工单的创建、变更、查询、派发、监督等，它是运维工作的载体。

问题管理：针对已处理事件的遗留问题或处理事件形成的方案只是治标不治本等问题，根据事件及处理方案，经过调查、诊断后提出最终解决方法，预防问题和事故的再次发生。

变更管理：记录所有基础设施和应用系统的变更情况，并进行分类。

配置管理：将所有资源统一管理，包括所有的IT资源和业务系统的参数配置，如型号、版本、位置、相关文档等。

知识库管理：汇集了在运维中遇到的典型案例及相关的技术资料，支持搜索以便于运维人员快速解决问题。

上海数慧运维流程

2.专业化的服务团队

人员管理是对运维人员进行人员配置、职责划分、培训、考核等的管理。

运维人员包括运维经理、一线运维工程师、二线运维工程师。

其中，运维经理负责人员管理、个性化运维方案落地、任务分派等；一线运维工程师负责日常的巡检、系统安装等；二线运维工程师负责系统故障排查解决、安全加固等。

3.简单易用的运维管理平台

运维管理平台能够将运维流程电子化，使运维工作可追踪、可回溯，并提供知识库功能，以收集各级运维人员日常工作中积累的经验。

在运维体系的实践上，2018年我们整合了自动化监控、安全加固和运维管理平台服务，保证了多个智慧规划协同服务平台项目全年的稳定运行，充分说明良好的运维体系可以保障业务系统日常运行的稳定性，提升政务服务的满意度。

三、自动化监控平台

随着信息技术的迅速发展，整个IT系统架构的复杂度在不断提升，面向业务使用的系统服务内容、质量也在与日俱增，传统 “离散化”运维方式已经无法满足当前的运维要求。

多方挑战

为应对这些挑战及行业需求，上海数慧建立了一套自动化监控系统。

通过主动式监控对服务器、数据库、网络、应用等进行监控分析，并根据规则对监控数据进行实时检测，以及时发现系统问题，并进行告警。

自动化监控系统还能帮助用户掌握业务系统整体运行情况，为未来系统和业务的升级改造提供依据。

一般来说，一套业务系统通常由基础设施（服务器、网络、路由器等）、操作系统、中间件（WAS、Tomcat等）、数据库（Oracle、MongoDB等）以及业务应用自身组成，任何一项出问题，都会导致整个系统出现异常，因此这些内容将全部纳入到监控范围。

上海数慧自动化监控平台

网络监控：监控网络设备（交换机、路由器、防火墙）、DNS解析、网络链路及服务器的连通性。

操作系统监控：监控Linux、Windows等系统服务器的CPU使用率、内存使用率、磁盘空间使用率、网络流量等操作系统指标。

数据库监控：监控Oracle、MongoDB、MySQL等主流关系型及非关系型数据库的连接状态、表空间使用率、缓存命中率等数据库性能指标。

数据库性能指标监控

业务系统监控：基于系统的多样性，具体监控内容将根据自身需要进行定制。

如对BPM系统内存、线程池、业务使用情况等进行监控。

通过一段时间的监控数据累积，可以利用监控系统提供的报表功能对数据进行统计处理，帮助用户做系统升级决策，如是否需要采购新硬件、是否需要新增系统节点等。

另外，还可以利用系统的监控大屏功能，对系统的整体健康状况做到一目了然，做到资源、业务的可视化。

四、灾备演练

灾备（容灾和备份）演练是检验系统是否具备良好的高可用性的一个重要手段，为保证灾备演练不对系统造成破坏，起到真正的检验作用，需要在事前、事后做好充分的规划准备工作。

1.制定灾难预防制度及方案

在演练准备前依据系统架构梳理清楚所有应用组件之间的调用关系，制定演练计划，明确演练的时间花费、数据丢失量、步骤、各步骤的输入输出、相关负责人、应急措施等。

2.明确灾难演练工作内容

为避免正式演练时碰到的意外情况导致演练时间延长，正式演练前将先进行沙盘模拟，使各个相关负责人对任务操作步骤做到了然于胸。

在系统恢复后，一方面，要对系统功能进行完整性测试，特别是对于涉及到很多参数配置的组件之间调用的功能模块，要更加留意；另一方面，对数据也要做完整性测试，主要涉及到文档或案件等的数量、数据库中的索引、表的数量等，并确保文档或案件可以打开编辑。

3.及时总结灾难演练成果

演练后要及时对演练过程进行总结，找出可以优化的环节，不断缩短系统恢复所需的时间，以保障在真正遇到灾难时可以快速地恢复系统和数据。

五、容器化探索

随着以Docker容器技术为典型代表的容器化理念的逐渐兴起，众多企业和单位已经开始考虑对原有系统进行容器化升级。

上海数慧也在容器化方面进行了一些深入的探索。

1.部署篇

在容器场景下，开发人员只需要提交Dockerfile，通过Dockerfile文件将程序运行需要的操作系统基础环境、环境参数和代码关联起来，再通过Dockerfile创建镜像，在容器平台运行后应用服务也随之启动。

简单来说，在容器场景下，开发人员的交付物不再直接是代码，而是一个Dockerfile。

Docker支持部署在物理机和虚拟机上。

对于非生产系统，可以将容器部署在虚拟机上；对于生产环境且运行高IO业务，以及对网络延迟要求很高的场景，可部署到物理机并配置SSD固态硬盘，以缓解系统延迟对使用者的影响。

2.管理篇

Docker容器需要进行统一管理，以及时了解容器的健康状态。

为此我们采用了Kubernetes容器管理平台。

Kubernetes提供了容器级别的资源调度、均衡容灾、服务注册、动态扩缩容等功能，利用它可以方便的管理跨机器运行的容器化系统。

容器化是未来的趋势，通过容器可以标准化部署流程，提升部署效率，同时在动态集群扩展方面也有着传统部署方式所不具备的优势。

Kubernetes架构

六、开发运维一体化DevOps

上海数慧的客户遍布全国各地，为给大家提供更及时、高质量的技术服务，我们在多地增设了分公司、办事处，加上项目的驻场开发实施，异地研发带来的管理效率和质量问题让我们对异地研发协同和效率提出了更高要求。

同时，随着行业变革的日渐剧烈，为应对用户业务需求的频繁变更，我们将目光转到了更敏捷、更高效的DevOps开发运维一体化，在保障产品研发快速迭代的同时更好地支撑公司云战略的推进。

DevOps示意

DevOps的落地不是一蹴而就的。

从实践经验来看，它主要包括2个方面的落地，一是流程上，要尽可能自动化；二是组织文化上的转变，要有足够敏捷的团队。

两者缺一不可。

流程上的DevOps落地，我们经历了“持续集成-持续交付-持续部署”这三个阶段，从最初的7日迭代频率发展到了如今的每日多次迭代，并打通了开发环境到生产环境的壁垒，实现了自动化的部署。

持续集成：从研发人员提交代码的那一刻起，代码的打包、测试环境部署以及测试都通过自动化的手段进行，加速了产品研发的迭代速度。

但受操作系统版本、参数配置等因素影响，测试环境通过却无法证明在生产环境一定可以通过，因而产品发布时，运维人员经常遇到产品在生产环境部署出现问题，为此我们引入了持续交付。

持续交付：是在持续集成的基础上增加了生产环境部署，这部分工作通常由运维人员手工操作。

在研发过程中，产品在测试环境通过测试，会马上通知运维人员进行生产环境的手工部署，不通过则返回修改。

这一阶段的缺点就是未能打通测试环境通过测试后到生产环境的自动化部署，不能保证部署的标准化，且只能在生产环境无人使用时才能进行部署。

持续部署：为解决生产环境的自动化部署及标准化，引入持续部署。

因部署时不能出现宕机情况，因此采用了主备互相切换的方式，在主环境做自动化升级部署时，用户访问的系统自动切换到备份环境，待升级验证完毕，用户访问的系统再逐步切回主环境。

在实践过程中，通过采用Docker容器技术、以及Kubernetes等工具进行主备切换和容器编排，保证了部署的标准化及业务的连续性。

组织文化的转变是我们在实践DevOps过程中发现的非常重要一点。

由于DevOps的实施主体是人，人是有包容心或私心的。

DevOps涉及到了研发和运维两个团队，必须要打破筒仓思维，使两个团队形成合力才能真正让DevOps运转起来。

为此，我们在公司内部倡导免责文化，建立起明确的责任制，防止“背黑锅”事件出现，增强合作效能；我们以价值交付和客户满意作为目标，倡导对事不对人的工作态度，充分调动大家的积极性，投入DevOps的持续建设中来。

在移动互联网、云计算、大数据转型的背景下，上海数慧积极引入DevOps，增强了开发与运维团队间的协作水平，提升了产品开发效率和交付效率。

在落地实践过程中，我们从各个环节的子流程入手，逐步实现自动化，最终实现了整个价值流的快速交付。

七、性能优化

随着服务群体的与日俱增、服务规模的逐步扩大，近年来我们发现用户系统的应用场景、业务规则越来越多样化、复杂化，数据规模也越来越大，随之而来信息化系统运行压力逐渐上升，系统性能问题也日益突出。

为此，上海数慧研究出一套性能测试方法，通过模拟实际用户的操作行为、实时进行性能监测，发现系统性能问题，并通过分析对系统各方面进行调优，以保障系统运行中的性能稳定。

性能测试工作由专业的性能测试工程师承担，具体分五个步骤：需求调研->制定测试计划->测试用例设计与开发->执行测试->结果分析。

需求调研：需求调研是准备工作，需要与需求人员确定好待测产品的性能指标和业务场景。

业务场景的选择一般遵循最常用、逻辑最繁琐的原则，保障测试结果更贴近用户的真实场景，测试结论也更加准确。

制定测试计划：测试计划需要明确测试周期中各个阶段的里程碑、测试人员安排、测试环境准备、针对业务场景设计的测试方法和策略等。

测试用例设计与开发：依据业务场景，将各功能点进行拆分，通过性能测试工具对功能点进行测试脚本的录制，再将脚本进行参数化，以满足普适性和模拟的真实性。

执行测试：先准备一定的存量数据，对系统进行相应的优化。

例如为数据库创建索引，增大缓存等。

再通过压力递增的方式寻找系统的饱和点，确定系统的最大吞吐量，随后依据测试策略调整用户数量，验证系统的响应时间，扩展能力以及稳定性。

同时，在测试运行过程中要注意收集系统的资源使用情况。

结果分析：测试结束后，需要对测试结果进行分析和诊断，查看响应时间是否平稳、是否满足预期，吞吐量和CPU是否随着用户数量的增加呈现线性变化，系统日志是否出现错误等，通过分析，为开发人员提供相应的优化建议并输出测试报告。

业务系统上线后，在后续持续使用中依然离不开系统性能优化，需要通过不断调整环境变量参数、优化SQL质量、优化系统架构等，保障系统能够持续提供高效的服务。

系统的运行速度和稳定性，体现出一个企业产品的质量。

为真正发挥投入巨大的产业价值级别系统的优势，把性能的优化提升作为整个数慧服务体系中不可或缺的重要环节。

如广州市国土资源和规划委员会审批系统上线前，通过开展性能测试，发现很多操作并发响应时间超过10秒钟，经过问题定位，优化SQL，最终使响应时间降低到3秒钟左右。

性能测试过程

更多精彩内容，敬请持续关注“DIST上海数慧”。

标签：系统测试服务