中文 | English
最新动态
新闻中心 最新动态
首页 > 新闻中心 > 最新动态
im体育运动平台:打造周密的金融业监控系统用Zabbix + Grafana绰绰有余
发布时间:2023-02-07 07:30:59 来源:im体育账号 作者:im体育直播

  随着证券金融市场的高速发展,各证券经营机构对信息技术的投入显著增加,业务开展严重依赖各类信息系统。因此,各业务信息系统的安全稳定运行就显得尤为重要,也是证券经营机构运行维护团队的首要职责。如何提前发现问题、快速定位并解决问题,减少运行风险,降低运行维护成本,保证业务的连续性是每个运行团队必须要面对的挑战。

  运维行业有句话:“无监控、不运维”,可见监控系统在“运维人”心中的地位。监控系统是运维的基础,也是持续改善运维工作的重要数据来源。构建一套完整的监控体系,能够最大程度的降低信息系统异常给业务造成的影响,提升运维效率和运维水平。笔者认为监控管理的重要性体现在以下三方面:

  首先,监管部门对证券经营机构的监控管理有明确的要求,《证券期货业信息系统运维管理规范》中明确指出“证券期货机构应采取监控措施,配备监控和报警工具,对影响信息系统正常运行的关键对象,包括机房环境、网络、通信线路、主机、存储、数据库、核心交易业务相关的应用系统、安全设备等进行监控。报警方式可包括声光、电话、短信、邮件等。”同时,对每种监控对象的监控内容、监控系统的日志保存、监控日志评估也进行了规范。每年证监会派出机构会对辖区内证券公司进行信息技术专项现场检查,如果发现证券公司信息技术管理工作存在较大疏漏,可能受到监管处罚措施。

  其次,一套合适的监控管理工具和监控管理流程,能够有效保障业务的SLA(服务级别协议),让运维团队全面、深入掌握信息系统的运行状态,提早发现系统异常情况,定位故障原因,缩短业务恢复时长。《证券期货业信息安全事件报告与调查处理办法》中对“较大事件”进行了定义“证券公司、期货公司集中交易系统或者网上交易系统全部中断、部分中断,影响交易时间累计在5分钟以上的;第三方存管系统、融资融券系统全部或者部分停止运行,影响业务时间累计30分钟以上”。故障的恢复时间直接决定了信息安全事件的级别,进而影响证券公司的分类评价评分情况。

  最后,监控管理与事态管理、事件管理、可用性管理、容量管理、变更管理等多个IT服务管理流程相关,上述IT服务管理过程中很多基础数据都需要通过监控系统提供,是IT服务管理持续改善的基础。

  很多公司为了监控信息系统不同的组件,部署了多套零散的监控系统,比如网络用一套监控、操作系统和基础设施用一套监控、数据库用一套监控、应用系统又用一套,各监控系统监控的颗粒度和重点不同,监控管理责任人也不相同,这样做不但导致告警分散,还会因为操作界面多,提高了管理难度,需要花费很多的人力、物力去维护,增加了运维成本,运维效率也比较低下。

  监控存在盲区:部分公司监控系统未实现对监管要求的监控项进行全覆盖,存在监控盲区。比如数据库表空间、连接数、日志、存储设备的电池状态,磁盘交换延迟等;

  缺少关键业务指标监控:部分公司缺少关键业务指标的监控,很多情况下服务器网络联通性,端口,进程都正常,但业务已经中断,如果不从业务角度进行监控很难及时发现系统发生异常。

  缺少基于业务流向的监控展示:目前有很多证券公司已经实现上述监控指标的全覆盖,对关键配置文件及关键业务指标也进行了监控,但比较少有基于业务流向的监控展示,虽然能够第一时间发现异常情况,但解决起来仍然很慢。现在很多开源监控工具已经可以实现从用户下单到最后成交的一整条业务数据流向的监控,监控系统可以快速的定位影响业务连续性的设备或组件,极大的缩短系统故障恢复时长。

  缺少对系统监控的全生命周期管理,从系统的上线到下线缺少必要的环节对监控设置进行管理。同时,对各个系统的监控项的增、删、改没有流程控制,运维人员可以随意增加、减少监控项,或变更监控阈值,导致监控系统中存在很多废弃监控项或为同一类型的监控指标设置不同的监控阈值。

  《证券期货业信息系统运维管理规范》监管中要求“应至少每季度全面评估监控日志和操作记录,分析异常情况,形成评估报告”。部分公司对于监控的评估形式大于实质,起不到真正的作用。笔者认为针对监控系统的评估可以通过三个方面进行:一是对系统的容量评估;二是对系统的可用性评估;三是对已有的监控项和监控阈值进行评估。

  通过实践摸索,笔者认为做好证券信息系统的运维管理,首先要构建一套集中监控体系,实现对信息系统的所有部件重要运行指标的集中统一监控、预警、处置和跟踪。

  所有部件,指能够覆盖到系统运行管理的所有组成,包括机房物理设备(空调、UPS)、网络设备、安全设备、服务器设备、存储设备等,同时除生产机房,同城机房、灾备机房都应涵盖在内。

  重要运行指标,指能够监控系统运行过程中可能会导致服务可用性下降或业务中断以及监管发布的规章制度中必须监控的相关指标;

  笔者认为监控对象从上至下可分为四个层级,即:业务数据层、应用服务层、系统平台层和基础设施通讯层:

  主要针对各业务系统的业务数据进行收集。因为业务间存较大差异,个性化的需求和业务逻辑也不尽相同,其监控方式一般是由Agent通过数据库语句或Python脚本在业务系统的数据库中进行数据读取,并将读取结果发送至监控平台,实现业务指标的监控。

  主要针对操作系统上的应用系统进行监控。由于是对应用系统进行监控,需要对应用系统的配置文件信息进行抓取,所以此部分的监控思路是以在终端部署Agent为主,由Agent通过执行特定命令,搜集目标软件的信息和状态,并搭配监控平台或其他监控站点对目标业务所在服务器指定服务端口、进程状态判定服务的可用性。

  主要针对操作系统层面的指标进行监控,比如系统版本、CPU内存利用率、磁盘使用空间等。在监控方式上,Windows、Linux系统平台上支持通过SNMP协议传输一些基础指标信息;此外,也可通过监控平台下发查询指令获取监控指标信息或者在终端设备上部署Agent(监控客户端)获取监控指标信息并上传至监控平台。

  主要针对信息系统基础设施的监控,包括物理服务器、网络设备、空调、UPS等基础设施,对其状态进行监控,判断其可用性。此层设备特点是支持SNMP协议,所以监控平台可直接通过SNMP协议主动抓取或被动接收数据来实现监控。

  随着国内证券金融行业的不断发展,新业务、新技术推陈出新,为每一个层次的监控指标选取并设计一套基于最佳实践的监控模板会极大的提高运维效率。可以针对Windows、Linux、MySQL、SQLServer、Oracle结合企业实际情况创建标准化模板,当遇到新业务上线时,可以批量添加监控对象和监控指标,提升工作效率。

  笔者认为好的监控管理体系不光要有功能强大的监控平台工具,还应该对监控指标的设定、告警策略、告警事件处置、以及评估和改进等过程建立一整套的管理机制,形成可执行的落地文件,能够指导运行团队有效做好监控管理的方方面面。

  监控系统是系统运维管理持续改进过程中的重要一环,通过对系统容量、可用性等关键指标的评估,能够使运维团队发现当前运维管理工作中的不足,通过量化的数据更有针对性的改进,形成PDCA(Plan、Do、Check、Ack)的闭环管理,持续提升运维管理水平。

  为达到上述集中监控与展示的目标,笔者经过对比多款开源监控工具,推荐采用Zabbix+Grafana作为集中监控及展示平台并集成其它专用监控软件的方式实现。其优势是开源、高效、易上手、功能组件丰富、可扩展性强。

  Zabbix是分布式监控系统,采用多层设计将系统分为数据采集层、数据处理层、数据展示层。支持多种采集方式和采集客户端,有专用的Agent代理且消耗低,对监控主机基本不构成安全风险,支持SNMP、IPMI、JMX、Telnet、SSH等多种协议。Zabbix将采集到的数据存放到数据库,然后对其进行分析整理,实现数据的采集、存储、分析、展示、预警,当达到条件时触发告警。

  对于Zabbix目前无法完成监控的部分,如业务监控,可通过行业专业监控软件的采集业务运行状态,将监控结果集成进Zabbix,实现业务监控的集中处置。

  Grafana是一个跨平台的开源分析和可视化工具,支持的数据源类型广泛,可视化插件也非常丰富,配合Zabbix可以将采集的数据进行集中可视化展示。

  如何选择监控指标做到有的放矢是评价监控系统是否有效最重要的标准。在监控指标的选择上笔者认为可以借鉴《Google SRE》一书的方法,将监控指标分为四大类,分别是:错误类指标、延迟类指标、流量类指标及饱和度类指标。

  每种类型中又可以针对业务数据层、应用服务层、系统平台层、基础设施层进行细化。需要注意的是很多情况下,基础设施层、系统平台层和应用服务层的监控指标并不能完全代表系统真实的运行状态(如CPU、内存、磁盘、端口、进程等),必须辅以业务数据层的指标(也叫业务指标,如业务量:从特定时间开始计算的累计业务笔数、吞吐量:单位时间内发生的业务笔数、响应时间:一笔业务的处理时间,异常业务的笔数:业务处理异常或业务处理失败的事件等)才能最大程度的实现对系统运行状态的监测。

  错误类指标就是指在信息系统运行过程中的异常错误,包括错误请求、错误率等。该类监控指标的选择一般从硬件报错、状态异常、日志报错、业务请求报错、业务处理报错等影响业务正常处理等方面考虑。

  业务数据层错误指标:“集中交易三方存管签到状态值异常”,“集中交易系统投保报送数据异常,异常客户代码为XXXX”等;应用服务层错误指标:“数据库1521端口访问异常”,“kcbp.exe(业务中间件)进程不存在”,“kcxp(通讯中间件)集群不可用节点大于1”、“生产、灾备应用软件版本不一致”等;

  延迟类指标是指,信息系统处理某种请求的响应时间。这类指标的选择一般围绕是否影响终端用户的体验为准则。需要注意的是,在选择此类指标的时候应该区分正常请求的延迟时间和可能影响用户体验请求的延迟时间。

  比如业务数据层中应包括:“集中交易单笔成交时间大于1s”,“ElasticSearch的索引、搜索延迟大于5s和慢查询大于5次”,“某网站页面响应延迟时间大于3s”等;

  应用服务层中包括:“Oracle主备数据同步超时5s”,“Oracle数据库的慢查询时长大于5s”等;

  这些指标会不同程度的影响终端用户的流畅体验,因此,从用户延时体验的角度逐层分析定位指标,可以更合理有效的形成技术对业务的驱动作用。

  流量类指标是指,对一个系统所承载的服务在单位时间内所形成负载的度量。对于一个WEB系统来说,它所承载的是服务请求,那么它的流量指标就是对每秒处理请求数量的度量;一个网络系统,它所承载的是电信号,那么它的流量指标就是对每秒处理电信号数量的度量;对交易系统而言,就是委托或回报的请求数量等。流量指标的大幅波动常常代表系统的内部或外部环境发生变化,需要运维团队排查诱因。

  比如业务数据层的“业务笔数”应包括:集中交易系统单位时间的成交回报数和累计成交回报笔数(就算所有监控指标都正常,在交易时段内如果一定时间没有成交回报,有极大概率集中交易系统出现了异常)。“客户量”包括当日手机APP活跃客户数、开户数等、三方存管的证转银、银转证笔数等;

  在实践的过程中我们可以通过读取数据库,获取当日委托笔数、当日登录客户数、当日交易客户数、当日开户数、密码输错锁定客户数等数据,这些指标能够协助运行团队更准确的掌握系统运行的状态。

  需要注意的是流量指标有时候并不会像错误类、延迟类指标直观的反映出故障(毕竟对券商来说,业务笔数激增并不是一件坏事),但事实上大流量的背后可能隐藏着恶意的攻击或其他异常行为。因此,流量指标一般情况下作为协同判断指标,这样可以提前发出预警,最大程度的规避信息安全事件的发生。

  饱和度类指标是信息系统对于流量、数据、业务等的承载能力。该指标主要反映影响服务状态或受限制资源的使用情况,可能是应用本身性能、处理能力存在上限,也可能是磁盘I/O速度存在瓶颈,总之当系统资源超过其处理能力最大上限而影响业务正常受理时,都应进行监控。

  通过对饱和度指标的监控,可以帮助运行团队预测未来的资源使用情况,提早做出扩容决策,避免因容量不足导致的系统性能下降,发生信息安全事件。

  为了确保监控指标完整、有效,阈值定义准确、合理,笔者建议运行团队在系统上线前先召集系统的研发人员、业务人员、安全管理员进行头脑风暴,去繁化简,确定对监控指标的预警阈值、监控时间段、监控的预警级别,形成监控列表;已上线的系统可以根据每次系统故障进行分析,避免漏项或通过新增监控指标提前发现系统异常。也可以结合历史经验,将监控指标汇总成Check-list,定期或在系统上线、监控告警的设定

  监控是对目标数据的获取和展示,而告警是对监控采集的数据进行分析与处理,对影响系统安全稳定运行的情况,发出告警信号。大量的无用告警会极大的增加运维团队的工作量,造成运维人员怀疑告警的有效性甚至忽略重要告警信息,最终产生“狼来了”效应,影响运维效率,甚至导致运维事故。因此,确保告警的有效性,减少无用告警的产生,对运维团队来说至关重要。笔者认为在设定监控告警时,应从以下三个方面进行考虑:

  笔者建议将告警根据影响范围和重要程度分成3个级别,即重要紧急(High)、重要不紧急(Warning)、信息提示(Info)。

  运维人员经常会遇到一种情况,即监控平台产生一个CPU使用率超过阈值的告警,运维人员还未登录设备查看原因告警就已消失,通过查看日志也未发现异常。其实这些都是属于监控频率或阈值设定精度出现了问题。

  将监控对象的数据采集设置为实时监控能够提高监控的精度,但其对监控平台、被监控对象的性能以及运维人员后续的管理会造成较大考验。笔者认为可以根据系统的SLA和指标对系统影响的敏感程度综合考虑。如系统的可用率为99.9%(年停机时间小于9小时,约525分钟),每1分钟检查一次硬盘剩余空间或实时监控系统的CPU利用率是没有必要的。但如果系统的可用率为99.99%(年停机时间要小于1小时),则监控频率一定要控制在1分钟以内。

  阈值的设定也是保障告警有效性的重要因素。在上面中笔者将监控项划分为四类(错误、延迟、流量、饱和度),其中错误类指标的阈值很好设定,就是一个状态,出现即告警;但流量类、延迟类和饱和度类的阈值通常没有固定的模板,笔者建议可以根据监控对象数据的平均值、最大值(最大流量、最大饱和度)、业务增量等多种因素设置合理阈值。比如一个1T硬盘容量超过80%的告警,产生告警时,硬盘的剩余量实际还有200G,但此硬盘的每日数据增量只有1G,还够使用半年,这种情况下根据硬盘的每日增量与剩余容量的比值设定告警阈值,其可参考性更高。

  有些监控指标在不同时间段里,其是否告警以及告警的触发条件上都有不同。各个公司应结合各自业务的实际情况加以区分,更为准确的捕捉真正对系统运行产生影响的告警。比如生产环境和灾备环境机房之间的网络专线,在交易时间内为保障业务数据传输稳定,阈值可设置为超过50%即告警,但在非交易时间此类网络线路大多用于数据备份或数据的异步传输,因此即使带宽满载也无需进行告警,或者设置为较低级别的告警。

  上述指标的监控实现方法主要分为三类,分别是Agent监控方式、Trapper监控方式、SNMP监控方式。Agent方式是最长用的监控方法;Trapper一般用于自定义指标监控;SNMP方式主要用于网络设备的监控。这三类方法结合Zabbix的宏又可以实现灾备场景切换的监控。

  需要在客户端安装Zabbix-agent。Zabbix-agent会主动收集本机的监控信息并通过TCP协议与Zabbix-server传递信息。Zabbix提供了大量的内置监控项,可以直接配置使用,比如端口、进程、日志等。对于一些自定义指标可以通过编写脚本把返回值传给Server端再进行处理,比如当日的撤单委托数,可以利用Python脚本通过连接数据库执行SQL查询返回撤单委托数量,然后传给Server端根据设定的阈值进行预警。

  Trapper监控方式使用Zabbix-sender程序主动向Zabbix-server发送数据,不需要安装Agent,发送的信息采用JSON格式,遵循Zabbix-sender协议。该方式无内置监控项目,需要自定义发送的信息。

  例如上级有指示想要在监控大屏幕上显示我们的集中交易系统安全运行天数,这时就可以使用Zabbix-sender方式,利用本地执行脚本获取“安全运行天数”,然后利用Zabbix_sender命令传值给Server端,实现“安全运行天数”的展示。与Agent方式相比,这样就省去了配置Agent、重启Agent的过程,更加快捷高效。

  SNMP作为通用的网络管理协议被广泛的应用于各种交换机、路由器、服务器等硬件设备。Zabbix可以根据MIB库直接获取目标监控项的数值并展示出来,包括CPU利用率、内存使用率、端口状态、接口流量、电源状态、设备温度、磁盘状态等。

  针对灾备环境的监控可以利用Zabbix 自定义宏功能(也可以理解为自定义变量)结合正则表达式实现。灾备环境的监控应从两个维度考虑,一是当生产环境正常运行时,对灾备环境相关系统基础运行指标的监控;二是当灾备环境转生产环境后,其各项基础指标和应用服务状态的监控。

  以集中交易系统生产和灾备切换为例,当生产环境正常运行,从手机APP端发起的交易的业务流为:手机APP发起买入指令→KCXP队列→KCBP处理请求→写入Oracle数据库→报交易所→成交回报。正常情况下,生产环境的“变量开关”设置“开启”状态,此时,灾备环境的变量设置开关为“关闭”状态,那么生产环境应用服务器的进程均为启动状态是正常现象,灾备环境的应用服务器进程未启动状态是正常现象。当生产环境切换到灾备环境后,与前者相反,其生产环境的“变量开关”需要设置为“关闭”状态,灾备环境的“变量开关”要设置为“开启”状态,这样灾备环境整个应用服务进程启动且有成交回报才会被监控系统视为为正常情况。

  基于上述工具与方法,开源的监控系统一样可以实现很多商业监控工具才具备的可视化“全链路”监控功能。通过对多个系统或组件的关键指标进行监控,并预先设定系统(组件)之间的关联关系绘制系统拓扑图,使运行团队能够在故障发生时快速定位故障发生点,缩短故障处置时长。

  首先,需要利用Zabbix Maps工具绘制系统拓扑图(Maps的工作原理是对Zabbix已有的触发器、图标、连接线进行绑定,使系统拓扑图告警后通过颜色的变化反映系统的运行状态),再使用Grafana Status Panel插件制作系统模块展示图,把每个系统作为一个模块进行前端展示。图3是某证券公司融资融券系统的监控拓扑展示,当展示面板变成橙色以后,只需点击就可以看到融资融券的系统拓扑,快速定位发生异常的组件,并根据应急预案进行技术处置。

  前文已经对Zabbix监控系统的构建做了介绍,本章主要是对系统监控管理的重要环节进行讲述,使监控系统搭建完毕后,能够在日常工作中真正为运维团队所用,提高系统运行维护管理水平。

  笔者发现在进行监控管理的过程中,很多公司容易忽视监控设置和告警处置流程。当人员发生离职或调转的时候,很多监控项、监控阈值任谁都说不清为什么这样设置;当告警触发后,也不清楚是否有人处置,容易造成疏漏导致信息安全事件的发生。因此,笔者认为非常有必要对监控设置及告警处置过程进行管理。

  笔者建议在OA或者运维服务管理平台中,针对监控项的增、删、改创建专门的流程,当需要进行操作的时候通过流程去管理,这样做的好处是任何时候都可以回溯相关的事项,也可以避免因个人操作导致监控项、监控阈值设置不合理的情况。某证券公司监控项变更流程及审批节点如图4所示:

  所谓的告警处置流程,就是通过系统地观察服务和服务组件,管理整个生命周期中的事件,最小化或消除其对业务的负面影响。笔者认为告警处置流程的几个关键过程应包括告警发现与记录、诊断、处理和关闭四个阶段。

  容量管理的目标主要是为了通过合理配置资源,确保信息系统有足够的容量满足当前和未来的业务需求,使IT投入能按计划进行,减少资源的浪费。因此,通过监控系统的数据进行趋势分析是容量管理中行之有效的方法之一,评估内容主要包括如下四方面:

  证券公司网络架构相对比较复杂,除了要监控公司办公网出口外,还需要对业务网络、主备中心间网络、主备中心到交易所、结算公司等各类网络带宽进行监控。同时,证券公司带宽受市场行情影响,而网络运营商对带宽进行扩容一般都有一定的实施周期,因此,需提前进行规划,以免影响业务。

  系统层面主要针对操作系统的磁盘空间、CPU、内存使用率进行评估。部分证券公司通过私有云构建了生产系统交易环境,需要对整体的云资源使用情况有充分的了解。笔者之前所在证券公司每月会对私有云的上述指标进行评估,当达到70%使用率时就会提前启动扩容项目。这样即使有新项目上线或业务激增的情况,也能够从容应对。图5是某证券公司私有云的部分评估内容:

  业务层面的容量评估主要针对核心交易系统的关键业务指标,包括行情、日均委托、日均开户、存管转账等,确定目前系统是否能够支撑未来一段期限内的业务发展,根据量化的数据模型提前做好扩容准备工作。某证券公司业务指标评估样例如图6所示:

  针对监控项和监控阈值的评估笔者认为可以从完整性和准确性两方面进行评估。完整性就是通过对异常事件的分析以及日常运行监控过程中发现的问题,判断每个系统的监控阈值是否完整,是否有因监控项缺失导致未能及时发现的故障;准确性就是通过分析回顾当月/季度的报警数量,筛选出误报的报警,对监控策略模板或者单个系统的报警阈值进行调整,已符合运行管理要求,减少因误报导致的工作量。

  每日对监控系统自身运行状态进行巡检,保证监控系统正常可用。如有一线值班人员,可由一线值班人员纳入值班管理,统一监控;

  随着中国证券金融行业的高速发展,金融业务种类推陈出新,在行业内也掀起了技术驱动业务的浪潮,国内各大券商信息投入占比逐年增加。金融科技的创新正在改变证券行业商业模式,即从传统的收费模式向通过互联网技术提供专业服务的模式转变,以便在竞争激烈的市场中通过金融科技快速推进金融产品与服务创新,抢占市场先机。

  与互联网行业不同的是,由于证券公司对系统的安全稳定性要求较高,系统从架构设计到选型中大多采用成熟的商业产品,以获得更好的服务与技术支持。但近几年,A(AI人工智能)、B(Blockchain区块链)、C(Cloud云计算)和D(BigData大数据)飞速渗入证券公司的各个领域,随着开源社区的不断发展,越来越多的公司和运维人员开始“拥抱开源”,并且在实际应用中让这些开源技术与商业软件协同工作,使信息技术更好的支撑业务发展。此外,开源工具还具备以下优势:

  商业软件大多需要付出额外的采购费用以及持续的维保费用,对中小券商来说无形增加了公司整体运营成本。而开源工具大部分都可以免费使用,如果想获得更好的质量也只需要支付商业软件的一小部分成本,且开源技术解决方案通常会有蓬勃发展的社区,全世界爱好开源技术的人们共同维护和改进开源工具,完全可以作为企业的技术资源支撑。

  近年来开源社区发展飞速,能够实现快速创新和迭代。由于开源解决方案的代码都是公开可见的,任何人都可以在此基础上进行免费开发,因此,众多开发者在持续改进功能、提升用户体验。

  采购商业软件必然在功能、价格、开发周期、维护等方面受到供应商的制约。如采用开源技术,所有需求都可以结合企业实际情况量身定制,甚至进行二次开发。由于证券行业本身技术趋同,采用相同技术架构的公司可以方便的将成果分享给其他公司,既实现了知识资源共享,又能促进行业的交流与共同进步。

  随着《中华人民共和国网络安全法》的颁布,国家越来越重视网络安全和个人信息保护。开源工具的每一行代码对用户都是可见的,无需担心商业软件后台留有后门程序非法获取企业信息等安全问题。

  综上所述,开源技术这一概念已从幕后走向台前,建议行业在非核心交易系统–尤其是运维管理工具中可以加大开源技术的使用,如监控系统(Zabbix、Zenoss、Nagios)、自动化运维(Ansible)、运维流程管理(Itop)、堡垒机(Jumpserver)等,更为高效的提升运维管理能力,降低运维成本。当然,这也需要证券公司有足够的技术能力作为支撑,这也对行业信息技术人才提出了更高的要求。

  感谢大家抽出宝贵时间阅读,希望本文能对证券公司的监控管理工作有所启发。由于水平有限,文中不够完善之处敬请谅解。随着信息技术的发展,目前也出现了很多监控系统与运维管理平台、自动化运维管理工具结合的案例,能够实现智能定位、故障自愈等功能,实现运维一体化的管理,极大的提高了运维效率,如果大家有好的经验欢迎随时与笔者交流、分享。


上一篇:网络安全攻防:概述
下一篇:广州市应急管理局2022-2023年度信息系统运维及安全服务项目招标公告