基于商业银行应用系统主动运维规范分析

项伟

（中科软科技股份有限公司 北京市 100080）

随着商业银行信息化的深入，商业银行的应用系统数量逐渐增加，功能越来越强大，越来越复杂，以满足不断激烈的市场竞争中持续的业务需求。各种应用程序系统会产生大量的大型日志。这些日志主要用于记录用户操作，系统操作状态，业务交易处理等，并且是应用程序系统的重要组成部分。因此，商业银行应用系统的操作和根据维护日志特征的操作，从维护日志中提取和提取有价值的信息，综合指标评估系统的概述和提取，以及整体评估预测，因此，应用程序系统审核的所有方面都很重要。

1 商业银行应用系统优点和不足

商业银行应用程序系统的主动运行和维护是一种先进的管理概念，指的是一种主动处理所有紧急故障和紧急情况的运行和维护模式。与传统运维模式相比，它可以在技术和管理两方面实现商业银行应用系统的运行。同时，通过完整的运维流程和合理的运维计划，可以提高主动运维水平。同时，通过构建用于大规模运维的智能自动运行平台，大大提高了工作效率。另外，现有的操作和维护支持工具不是高度自动化的，无法监视所有操作和维护对象，这些对象将完全自动过滤掉大量警报信息。现有的运维程序不规范，导致运维工作混乱，另外，运维人员的积极意识相对较弱。同时，一些商业银行缺乏积极响应的动力，运维人员的积极运维意识不高，无法完全预防突发事件[1]。

计算机在数据和信息的高速处理中更快且更准确，并且不可避免地导致信息的传输和反馈更快。使用计算机软件作为计算机应用程序的一部分，用于商业银行的日常操作和维护可以满足检查，转换和其他操作的需求。根据自动执行维护工作的需要，可以增强控制功能并设置技术规格，以准确控制操作和维护的主要工作区域。结果，减少了人为操作的失败，并且提高了应用系统的可用性。

商业银行运营和维护服务系统具有一些特定的缺陷，日常操作和维护涉及许多技术上复杂且危险的操作程序，这使其高度依赖熟练的劳动力。为了解决这些问题，将为商业银行的运营和维护服务建立一个高效，准确并且更加完善自动化系统中去。

2 商业银行应用系统的变更

根据项目组织变更后的要求，部分或全部根据项目组织的变更管理和实施项目，以适应与项目相关的各个要素的变更，并确保项目目标是在项目运营期间实现并处理的。作为软件开发生命周期每个阶段的重要元素，它对变更管理系统的操作和维护至关重要。通过从系统变更管理日志中提取指标，可以充分体现应用系统的特征。

图1

图2

2.1 商业银行日志变更系统

变更管理系统日志记录每个应用程序系统的所有变更和变更时间，并且可以每月或每季度计算一次变更的频率或次数。如果更改的频率或更改次数过高，则表明应用程序系统经常修复错误，因此就会要求立即添加功能，优化性能或升级版本，这表明应用程序系统的功能设计和框架反映出设计不够完美，系统版本的稳定性存在问题，此度量标准可用于从三个方面表征应用程序系统：功能设计，框架设计和版本稳定性。

2.2 商业银行日志研究内容

日志规模大：以国有银行为例，网上银行系统（企业，个人，手机等）每天生成的日志数量已达到71GB，这是一个简单的应用程序和事务日志，添加系统日志后，对于数据库日志和网络日志等数据，我们正在被动地估计每天何时生成大约100 GB 的日志数据。网上银行系统只是商业银行信息系统，核心业务系统，信贷系统和资金管理系统的一部分。每天都会针对系统类型生成大量日志数据。传统的日志分析方法，例如使用grep 和awk 等Linux 脚本,它不能满足这些大型日志分析需求[2]。

日志格式不规范，并且存储格式分散。商业银行系统的组成很复杂，包括自我开发，外包，外包二次开发和开源转换。除了这种复杂的系统结构之外，没有适当的日志格式的明确写规范，并且出现了商业银行各种日志的各种不规则记录格式。此外，每个应用程序系统日志主要以各种格式分发和存储，应用程序日志被写入数据库或文本文件，系统日志具有不同的存储路径和格式，具体取决于平台。各种各样的日志分布在各地，没有集成的收集和管理平台。

2.3 管理规范的变更

我们将首先审查管理标准，审查支持标准，最后完善一些机制以达到主动的运营和维护标准。对于研究规范，主要包括确认操作和维护要求的规范以及操作体系结构研究规范。换句话说，有必要考虑运维管理者收集和总结的运维保证的规格，以确保运维要求在项目需求的开发阶段的适用性和合理性。当然，也有必要修改和改进正在考虑的运维经理提供的解释。业务架构审查由科学技术部门组成，与项目团队合作进行架构设计和架构审查。应用程序体系结构侧重于三个方面：数据体系结构，基础结构和操作体系结构。支持规范适用于变更管理规范，并包括测试技术支持规范。应用变更管理规范可以增强将变更应用，考虑作为关键集成原则和标准化操作系统的意识，并控制变更风险。而且，商业银行的操作在生产和修改应用程序系统期间经常发生，因此它是在生产阶段执行变更管理的风险防范的重要组成部分。安全生产办公室进行收集，记录和分析，以从根本上减少此类事件的发生，确保应用程序系统的安全稳定运行，并改善对这些问题的意见和行动。有效避免调查事件原因却忽略了整改现象的总结。

3 系统需求分析

在分析需求的阶段，应根据系统研究和开发的重要性以及实际应用的目标，根据功能设计概述和实际应用目标，提出系统设计中要实现的功能，提供下一次运行的能力。

在生成各种类型的事件中，如应用程序系统正在运行的应用程序错误或异常、服务请求、环境、系统、网络等。计算应用程序系统在特定事件中生成的事件数，根据事件类别作为维度的分类可以反映与事件类别相对应链接的系统的缺陷，发生系统事件时，它将对系统产生特定影响，事件的严重性反映在影响的大小和持续时间上。如果影响对应用程序系统在至关重要的服务的事件上，具有很长的影响时间，则意味着需要对应用程序系统进行重点监视。

参考商业银行的运行维护状况，以及应用系统运行维护评价指标和应用系统特性的对应关系，从三大运行维护管理系统中提取应用：变更管理系统、事件管理系统、问题管理系统与系统的运维相关的数据，数据的预处理以及将数据存储在运维日志数据库中。基于运维日志数据库，我们使用分析，统计，挖掘等方法从运维日志中提取指标。比较系统功能的数据库使用系统评估模型对系统进行抽象和评估，最后提取最接近系统特性的功能集。使用这些功能可以评估应用程序系统的运行和健康状况，提供操作和维护的方向以及操作和维护人员的关注点，降低操作和维护人员的难度，并制定目标和安全管理措施。可以提前防止系统中可能出现的危险，防止生产事故，并确保应用程序系统安全可靠地运行。

商业银行运维服务自动化系统的用户包括系统管理员、维护人员、操作员和管理人员。

（1）系统管理员：负责系统初始化管理核心参数的配置，用户管理和权限管理。负责开发检查脚本（包括创建消息分析规则）和检查脚本的版本控制。

（2）维护人员：权限范围内每个应用程序系统的服务器配置负责分配每个服务器的测试项目，以及每个测试项目的检查点，负责启动或停止每个服务器的扫描过程，监视管理服务器上的调查。

（3）管理人员：从宏观层面（系统层面：体重保险一等，二等，三等）到微观（检查点）检查状态，提供相关的统计报告和图形查询显示[3]。

3.1 应用系统运维功能评价

构建用于商业银行运营和维护服务的自动化系统的检查过程的总体目标，是详细定义自动化检查的总体功能，并指出自动化检查的总体设计原理和性能要求。如果系统较复杂，则可以按层次进行描述。

商业银行运维服务自动检查流程是一种自动检查工作流程，它是通过对每个商业银行业务系统的检查计划进行调查和分析而设计的，并与系统的流程设计平台相结合。目标是解决商业银行日常检查工作的自动化问题。该过程具有自动检查，收集检查数据和检查结果分析等功能。检查过程满足性能要求，例如跨平台执行，7*24小时自动操作和个性化需求定制。商业银行和维护服务的自动切换主要描述双机转换功能的设计，尤其是指导系统编码阶段的开发以及用于提供该技术的整体转换功能，并解释了总体设计方法，联机后维护银行卡正面系统的基础[4]。

3.2 应用系统功能的实现

在功能实现阶段，必须以编码形式实现先前完成的设计。它能够将设计应用于系统的设计内容。根据相关银行经理的工作习惯，自动检查的总体界面设计简洁大方，对相关人员进行检查和查看检查报告很有用。检查过程在过程开始时仅注册一次参考时间，运维自动化服务根据参考时间和下一次检查时间比较设备的检查频率，并创建当前检查周期中需要检查设备的所有检查项目和检查点，用于准备过程中后续功能单元的数据。

当前，大数据领域中最前沿的研究热点是用户的肖像。所谓用户图，是基于一些基本信息和用户行为数据的分析。用户使用从标签中抽象出的标签集合，这些标签可以在各个维度上反映用户的特征。换句话说，用户的关键是标签的集合。根据不同用户的标签为不同的目的定义不同的营销策略和促销策略，并根据不同的应用场景定义不同的标签，用户认为是大数据领域就是一种典型应用。

4 运维需求评审规范

商业银行要在项目需求的开发阶段中制定运行和维护需求，并参与检查运行和维护需求。运营，维护和管理员收集，总结改进运营和维护支持框架以及运营和维护支持的要求，估算运营和维护要求的工作量，并计划运营和维护要求的测试和批准。才能决定运维需求的制定完成后，运维高级工程师主要根据确认需求的计划对运维进行运维，以检查运维的完整性，适用性和合理性。需要考虑需求。最后操作维护和管理员会根据审阅期间创建的意见进行更正和改进。

商业银行操作事件发生在大多数应用程序系统的生产和修改期间，因此它们是防止在生产阶段进行良好变更管理风险的重要组成部分。为了使运维过程中各种应用程序的变更活动标准化，增强对变更注意事项的认识并控制变更风险，基于相关系统开发了变更管理流程。变更管理过程以变更审查为中心，并基于“集成管理，职责分类，标准化操作和严格的风险管理”[5]。主要包括应用更改、审阅、实施、验证、特殊控制、审阅、紧急响应和信息共享。

运营和维护部门负责创建，审查和跟踪问题，而开发部门负责解决和报告问题。解决发现的问题，以使每个问题都消失并得到正确有序的解决。同时进行问题跟踪通过一系列以问题为中心的推广会议，例如每周会议，每月会议和季度交流会议，我们加强了对问题解决过程的跟踪和协调，分析和评估了解决问题的方法，并更新了分析结果。在制定适用于项目的运营和维护需求的过程中，形成了优化和改进的闭环，从而逐步实现了针对应用系统问题的集中、复杂和主动的管理。

5 结论

随着商业银行的不断发展，对主动运行和维护规范的研究更加全面，主动运行和维护规范的优势也在增加，不仅可以预防突发事件，而且可以提高运行效率和维护工作。商业银行应用系统的主动运行和维护规范主要是三种，技术、组织和管理规范。日志分析应用系统的画像应该朝着商业银行调查日志分析的更有意义的研究方向发展，但是仍然存在一些问题。预期未来有效的运营和维护规范将为商业银行带来更大的发展空间。