金融科技引领运维痛点的六个方面！
发表时间：2023-09-07 17:00:58
文章来源：炫佑科技
浏览次数：142
菏泽炫佑科技
金融科技引领运维痛点的六个方面！
1.背景和痛点
随着我行业务的快速发展，金融科技领先效应不断增强，业务系统数量不断上升，相应的软硬件基础设施也越来越庞大。 各个系统对应的运维难度和复杂度也相当，随着快速增加，标准化、精细化运维无法有效落地金融科技引领运维痛点的六个方面！，越来越多的运维痛点不断涌现，同时带来各种运维风险，影响业务连续性。 其痛点主要体现在以下六个方面：
1、信息资源数据的痛点是管理难、使用难、准确率低。
（1）使用多个EXCEL表维护数千台服务器和100多个应用系统的软硬件资源信息。 信息无法及时同步共享和更新。 数据错误率较高，很容易导致运维工作的误判。
（2）为了保证EXCEL表格数据的准确性，需要经常盘点信息资产，费时费力。
（3）无法体现数据之间的相关性，数据无法灵活运用，更不能被信息系统利用。
2、基础监控盲点较多，覆盖不全。 信息系统故障无法及时响应，报警信息无法正确匹配软硬件资源，导致误报。
（1）信息资产多，信息更新快，监控部署和清除跟不上变化，需要经常检查和填补漏洞。 未及时监控的系统风险极大。
（2）不受自动化运维系统控制的计算实例无法自动采集信息、批量查询、操作和检查，需要人工整理和发现。
（3）非监控、自动运维的计算实例无法通过有效手段通知运维人员。
3、运维人员忙于复杂的软件、硬件和运行环境的部署、安装、创建和配置。 整体运维效率较低，精细化程度不高。
（1）运维人员的大部分精力都花在了运维环境的部署上，尤其是新系统上线频繁、上线量和环境部署量较大的情况下。 由于时间不够，他们无法接受具有较高运维价值的培训。 运维视野和思路无法扩展。
(2)单个系统都是手动一一部署、安装、创建和配置的，容易出现遗漏、不匹配或者多个需要一致的计算实例的配置存在差异的情况。
（3）监控、备份等运维服务没有得到重视。 运维人员完成大量应用环境准备后，没有精力部署监控和备份，导致系统上线后无法进行有效监控的问题。
4、存在直接运维风险。 运维人员水平参差不齐。 不可能调动更多运维人力参与运维工作，释放更多操作人员的主观能动性。 集团运维的价值和力量严重缺失。
(1)运维人员少，工作压力大，操作人员较多，但工作范围比较单一。 但由于运维技术的专业性，操作人员无法更好地融入到运维团队中。
(2)人工巡检直接登录系统。 通过超级用户检查，存在很大的风险和隐患。 检验人员素质参差不齐。 需要依靠运维人员实时跟踪他们的巡检，既消耗精力，又让其他事情搁置。
（3）每次人工巡检的结果没有归档和保留，无法查询，导致运维巡检数据丢失，无法有效积累，无法通过历史运维挖掘深层信息数据。
5、日常运维巡检过程中可能会因巡检操作不当带来衍生风险。 需要巡检的软硬件设备数量日益增多。 检验效率低下，漏检、漏检现象严重。
（1）检查点、类别多，覆盖面广，人工单次检查不可能面面俱到。
(2)人工巡检直接登录系统。 通过超级用户检查，存在很大的风险和隐患。 检验人员素质参差不齐。 需要依靠运维人员实时跟踪他们的巡检，既消耗精力，又让其他事情搁置。
（3）每次人工巡检的结果没有归档和保留，无法查询，导致运维巡检数据丢失，无法有效积累，无法通过历史运维挖掘深层信息数据。
6、资源和环境的申请不断被申请，导致运维人员花费大量时间进行环境部署和审核。 没有及时审核、不符合配置和基线规范的系统往往存在系统、数据库、中间件庞大、高可用性等隐藏的安全风险。 随着系统运行和业务激增，只有在业务出现故障后才发现配置不合规。
（一）基础设施标准规范不能有效落实，形成一纸空文。
（2）系统上线前基础环境配置与基线不匹配，不匹配、漏配置导致的运行风险急剧增加。
（3）上线前依靠人工检查和基础环境审核的点太多，难以面面俱到。 同时，审核的程度也与运维人员的能力有关，隐藏配置不合规风险的问题依然存在。
2、总体规划
为切实解决我行当前痛点，按照我行夯实基础、提质增效的工作总体要求，我行在经营领域坚决创新，坚持自主经营和科技创新推进运维领域工作。 向信息化、数字化、自动化、智能化、场景化转型。 因此，基于我行现有的基础监控、动力环境监控、网络监控、硬件监控、业务绩效监控等监控子系统，以及集中监控平台、运维大数据平台、运营维护等统一平台，维护流程平台，进一步拓展和拓展运维系统架构和覆盖范围，如终端性能监控、应用性能监控、网络性能监控等监控子系统，统一CMDB平台、自动化运维等统一平台平台、IT可视化平台。 总体规划架构图如下：
1、监控系统架构介绍：满足业务系统端到端监控的需求。 建立用户APP、WEB、客户端等终端的终端性能和体验监控系统，通过不同方式收集各种终端的行为或体验数据，接入后端运维大数据，对不同用户的行为进行画像。 提供精准营销或风控项目消费，进一步指导业务运营和管理； 从业务层、网络层、应用层三个层面、三个角度建立专业的监控体系，输出各级监控和统计指标，满足故障排查和定位根源的需求，从不同角度提供监控支持，替代传统监控只发现现象，却找不到根源和原因； 结合现有基础监控子系统，可以全面实时掌控业务系统各级指标状态，及时定位故障。 根源并提高业务系统的连续性。
2、自动化运维系统架构介绍：构建自动化运维系统、自动化批量调度、自动化投产三个维度的自动化系统。 与上层结合，可以集成一体化的自动化运维平台，满足生产系统端到端的自动化运维。 需要。 加速端到端运维交付的质量化和标准化，降低运维工作成本，释放运维动力。
3、智能运维系统架构介绍：智能运维需要数据来产生输出。 基础配置数据来自CMDB，分析数据来自不同角度的监控子系统。 通过建立运维大数据平台，获取基础性能数据、用户终端性能数据、网络性能数据、业务性能数据、应用性能数据等所有指标数据，事件报警数据、应用日志数据、系统日志等日志数据产生数据，甚至网络消息数据等。例如，将报警事件与指标数据进行关联，并进行智能分析，以确定可能的原因并定位报警源。 运维大数据不仅仅是简单的数据集中和展示。 更深层次的目标是对多个数据源的挖掘和分析。 需要与人工智能技术相结合，深入探索智能运维的实施和效果。
4、多系统、平台间联动系统介绍：统一CMDB为各系统、平台提供统一的配置基准数据，提高联动的数据质量和效果； 自动化运维平台自动收集和发现有价值的数据和数据关联性，供其他系统与平台使用，与各种资源建立自动化关系，并提供不同的自动化运维场景调用API供其他系统和平台调用； 集中监控平台连接所有监控系统和平台，实时收集所有事件和报警，并结合CMDB配置数据，**时间匹配和丰富事件报警内容，并以丰富的通知方式和详细信息通知相关负责人和真实的警报详细信息； 运维大数据通过多元化、不同渠道整合各系统、平台的实时或历史数据。 结构化和非结构化数据被过滤、清洗、处理、集成、分析、输出和数据持久化； IT架构可视化系统使用三种类型的架构图：业务系统部署架构图、业务逻辑架构图、业务网络拓扑图。 这样把运维大数据中不同数据源的数据结合起来，包括智能运维输出的建议，进行实时展示，让数据和图表联动起来，更直观地展示业务系统的整体运行状况。 运维以IT架构可视化为主，智能运维为辅，强调人在运维中的不可替代性。
3、自动化运维系统实践
在上述总体规划的基础上，我部全面启动集自动化运维系统、批量调度自动化、自动化生产于一体的自动化运维平台建设。 通过上述项目的建设，可以很好地满足端到端的运维需求。 自动化工作任务。 由于整体文章篇幅较长，笔者将重点关注其中之一，即基于开源软件和软件独立部署的自动化运维系统。 我部门通过Shell脚本，成功开发了友好的窗口界面，实现了多项实用功能和批量运维的自动化，并独立建设了CMDB（配置管理数据库），方便对软硬件资源进行集中管理和控制。 系统大大提高了运维工作效率，进一步减轻了运维人员的工作压力，规范了运维操作，同时避免了人工直接运维带来的操作风险； 系统覆盖生产交易和管理系统内近2000个计算实例的批量运维。 自动化运维系统整体架构如下图所示：
下面详细介绍其主要功能、实际解决方案和实际效果。
1、理顺两个数据中心的软硬件资源及关系，将数据纳入自主研发的信息系统管理（CMDB），结合自动化运维平台，自动采集软硬件资源和数据计算实例中的软件版本并连接未来RFID射频定位数据，自动准确识别软硬件资源的信息数据。 消除当前信息资源数据难管理、难使用、准确率低的痛点。 练习计划：
（1）CMDB及环境搭建：通过开源搭建CMDB配置管理系统，建立自上而下的数据表及表间关系，导入并整理现有软硬件资源及配置数据； 环境搭建请参考作者另一篇文章：生产环境自动化运维系统实践（11步快速搭建）
关联：
(2)自动获取CPU和内存大小：通过设置模块获取每台主机的事实数据，并筛选出CPU数量和总内存大小； 编辑-cmdb的TPL模板，使用-cmdb模块输出主机IP、CPU数量和内存大小列表，处理列表的格式，将其转换为适合进一步处理成SQL语句的csv格式文件，*后运行SQL语句将CPU和内存数据更新到对应的CMDB表中。 程序逻辑流程如下图所示：
(3)自动获取硬盘容量和操作系统版本：通过设置模块获取每台主机的实际数据，并筛选出每台硬盘的容量和操作系统类型。 编辑cmdb的TPL模板，通过判断操作系统类型（AIX或Linux），当操作系统为AIX时，调用该模块，将脚本注入各主机执行，获取所有VG的总大小，或者获取AIX 通过调用模块 然后根据模板格式计算并输出操作系统的详细版本； 当是Linux操作系统时，直接使用设置过滤后的值。 这些指标*终通过-cmdb模块输出为主机IP、硬盘总容量、操作系统版本的列表，并对列表的格式进行处理，转换成适合进一步处理成SQL语句的csv格式文件，*后运行SQL语句将硬盘容量和操作系统版本数据更新到对应的CMDB表中。 解决方案的逻辑流程如下图所示：
(4)自动获取软件组合及版本：调用该模块，将脚本注入各主机执行，获取主机安装的标准软件及对应版本等数据； 编辑-cmdb的TPL模板，根据模板格式输出软件组合和版本； 通过-cmdb模块输出主机IP、软件组合和版本信息的列表，对列表的格式进行处理，转换成适合进一步处理成SQL语句的csv格式文件，*后运行SQL语句来更新软件组合和版本数据到相应的CMDB数据表中。 解决方案的逻辑流程如下图所示：
(4)同步流程平台数据：调用该模块获取流程平台软硬件资源申请、应用系统上线等工单数据，涉及新增应用系统、计算实例等数据记录的自动同步和硬件； edit-cmdb TPL模板按照模板格式输出新增的数据记录列表，并经过数据格式处理后，转换为适合进一步处理成SQL语句的csv格式文件，*后运行SQL语句插入相关数据到相应的CMDB数据表中。 解决方案的逻辑流程如下图所示：
实际效果：
（1）构建CMDB，将数据信息纳入信息系统进行管理，统一数据查询和更新接口，实现数据共享，运维统一在同一个数据使用接口中，保证运维有相同的数据基础。
(2)无需频繁盘点数据资产。 通过自动化手段采集数据信息+同步资源申请表数据+枚举数据，保证数据的准确性。
（3）与监控和自动化运维平台自动联动，加上频繁的人工查询和使用，数据得到充分利用，进一步保证了数据的准确性。
2、独立实现监控点和自动运维节点的自动发现，并实现与CMDB的联动，直观地展示未监控且纳入自动运维系统的计算实例。 消除当前基础监控盲点多、覆盖不全、无法及时响应信息系统故障、报警信息无法正确匹配软硬件资源而导致误报等痛点。 练习计划：
（1）监控自动发现：调用该模块获取监控平台所有监控点的数据信息，包括操作系统、数据库、中间件、日志、PING、关键端口等，并提取CMDB数据的记录桌子; 通过判断CMDB软件组合和操作系统类型来检测主机的监控点是否全覆盖。 CMDB中的软件组合信息需要结合各个软件的运行状态来判断是否确实需要该监控点； *后通过进一步的数据处理，生成SQL语句，运行SQL语句将相关数据更新到对应的CMDB数据表中，完成监控自动发现功能逻辑。 其逻辑流程如下图所示：
（2）自动运维发现：调用该模块获取CMDB中所有需要自动运维的主机信息； 调用该模块验证主机是否满足自动运维条件，如SSH互信、版本等； 如果满足，则验证通过，如果不满足，并行执行两个逻辑，一是记录验证结果中的主机IP和状态值，进一步处理成可执行的SQL语句，并更新CMDB； 另一种是配置主机互信，验证互信，通过模块获取操作系统类型。 如果是AIX操作系统，则需要通过Raw模块（标准Linux自带）安装环境。 其逻辑流程如下图所示：
实际效果：
（1）对于录入CMDB的所有信息资产，可以及时找到未被监控的点，并自动列出相关信息。
(2)能够自动发现自动化运维系统无法识别的计算实例，运维人员能够及时将其纳入自动化运维系统中。
（3）自动发现监控点和自动化运维节点后，信息直接同步到CMDB，并产生报警事件，提醒运维人员。
3、独立实现批量自动化运维一键部署、批量监控一键部署、批量备份一键部署、批量用户一键创建、常用软件批量安装配置。 将运维人员从原来复杂的部署、安装、创建、配置中解放出来，更高效地完成既定的工作任务，将工作重心转移到更深、更精细的运维上，让运维人员忙碌起来但并不混乱。 实践计划：
软件和运行环境的自动化运维部署是对我行PaaS云平台的补充。 首先，资源申请者通过流程平台申请软硬件资源，并填写资源需求。 架构师根据资源需求将需求格式化为可实现的需求。 标准信息，经过层层审批，*终落实到运维人员实施阶段； 通过PaaS级云平台，自动布置需要部署的资源和软件平台，并检查是否需要自动化运维平台补充软件运行环境的安装，如监控、备份、用户、其他标准化数据库、中间件等软件； 如需补充，运维人员登录自动化运维界面选择相应菜单，批量输入IP地址，后续批量部署将由自动化运维自动完成平台，包括自动化运维检查、未通过后自动化运维部署、软件及运行环境的安装配置等； 其他通过PaaS云平台和自动化运维平台无法实现的额外软硬件安装和配置任务均由运维手动执行，*后由专门的基线配置审核员通过自动化操作选择对应的基线配置自动审核和维护菜单。 其逻辑流程如下图所示：
实际效果：
（1）通过菜单式的一键部署界面，运维人员只需批量输入IP地址即可完成部署，释放了运维人员的压力，减少了工作任务。 腾出更多的时间来细化运维工作。
（2）批量部署，自动安装配置相关运维环境，配置一致。
(3)部署只需简单的菜单操作。 所有新上线的系统都可以及时部署运维环境自动化软件开发，未部署运维环境的系统也可以及时发现。
4、常用运维批量查询、常用批量操作菜单化，方便运维操作。 同时，通过菜单背后标准化的运维命令，降低了直接运维操作的风险，调动更多的运维人力参与运维工作，释放了操作人员更多的主观能动性体现了集团运维的价值和力量。 实践计划：
我行将运维人员分为一线和二线。 一线运维人员在收到报警或流程工单时，会结合报警事件中的自动匹配（匹配报警关键词或场景）报警处理方式，并通过知识库记录来判断是否自身能力可自行处理或协助二线人员远程处理。 如果没有，则通过流程平台升级事件，交给二线运维人员处理； 如果可以的话，登录自动化运维界面，直接登录需要维护的主机。此时，通过在界面中选择20多个常用的运维操作，批量输入IP地址，可以实现以下模块：自动调用 、 、 Raw 、 Shell 对主机执行运维操作，执行结果和文件直接在界面的 中，处理完成并确认无误后，可以报警事件和流程被关闭。 其逻辑流程如下图所示：
实际效果：
（1）通过将简单的运维查询和操作做成菜单，交给一线操作人员，可以融入到运维团队中，更好地体现个人价值。
(2)批量查询、批量主机操作简单、快捷。
（3）菜单式操作维护，无需登录，消除操作风险。
5、独立实现故障日志一键采集、运维一键巡检、巡检报告生成、集中归档查询等功能。 巡检人员无需登录各个系统进行一一巡检。 通过自动化运维平台的操作菜单，批量输入IP地址，立即开始自动检查其上可能存在的数据库、中间件、操作系统、高可用架构软件。 并生成检验报告。 检验报告可以通过该平台集中归档和查询。 通过该功能，降低直接登录巡检误操作可能带来的衍生风险，同时提高巡检效率，避免巡检遗漏。 实践计划：
目前我行需要人工巡检的主机数量和软硬件运行环境不断增加，严重占用了银行维护和运维人员的大量宝贵时间，无法集中精力专注于更有价值的运维任务。 因此，我行将自动化巡检纳入自动化运维平台。 首先，通过模块获取CMDB中所有需要巡检的主机信息，并结合自动收集的软件组合、版本、操作系统等进行分类； 其次，定时自动调用该模块，将各种巡检脚本注入到不同批次的下一台主机上执行，获取巡检结果并归档； , the are for , and into SQL and into the data of the CMDB, so that the and can view the data table to the the value of the and the value/range; in order to the in a more , and can log in to the and to view and , the of the of each host. Its logic flow is shown in the below:
:
(1) , , , and high- on it, and , and the are .
(2) the and one-click menu, and input IP in to start , there is no need for , and there is no need to log in to the super users one by one, the risk of human .
(3) can be for by in , or can be CMDB. are and for easy later, and can even be to and big data for data and .
6. , , and batch . and to flow, and to spend a lot of time on and . that have not been in time and do not meet and often have large , , , and high-level . and other risks, as the runs and , non- is only after . this , the goes , the the and the can be , and can be out to the . :
the table data of and sort out , such as AIX and Linux , VIOS , HACMP, TSA, GPFS high , - , WAS, MQ , DB2 ,, MYSQL , etc.; users a among the 12 types of the and menu, and enter the IP to be in ; the and Go to the CMDB and the and in the CMDB; the , into each host to and files and other ; the and the and , and it is a range , to and . If it is a range , and . If it is not a range , the value and the value are ; the has the , or list which have . , the .
:
(1) are from text into , which is to and save, and to be by and to .
(2) the of the and , with can be with one click, and risks can be the goes .
(3) are with the of high-level and and into . There are no blind spots in the , and the is wide, and .
of the of this :
