实时警报通知:微信告警通知的重要性解析
865
2023-01-15
本文目录一览:
其实在一线运维工作中,常常是福不双至,故障不单行。每有运维问题发生的时候,往往会密集发生多个告警。当这些告警来袭的时候,一线运维人员要针对它的类型、等级、告警对象和内容等进行检查并选用合适的方法来应对。
告警等级较高时,比如持续出错的应用告警,在查验后会立即分派通知相关的负责人在第一时间开具事件工单,做对应的流程追踪;而遇到低等级或次要的系统告警,则可以暂缓处置,留作观察。
传统的处置方式需要用经验来判断问题的影响范围和严重性,再通过人工进行派单以及通知下游处理人员,这样效率低下,无法满足现今业务响应速度的要求了。
究其原因,有些周期性发生的高频问题,往往并不是最棘手的,是可以延后处置的。反而偶发的问题,比较需要特别关注(如果这是原始定级较高的故障,更应该第一时间关注)。
所以,在告警发生的时候,可以使用告警优先级推荐算法来分析处理问题。根据规律特征进行判别,看是否需要立即关注。再配合自动化工具,将推荐等级与原始等级都高的告警加上筛选规则,进行自动化开单处置。发现推荐等级与原始等级有背离的部分,可以筛选出来做复盘,对告警原始的等级进行优化,或者转化成升降级的规则逻辑来处置告警等级。
互联网时代的网络自动化运维
互联网上有两大主要元素"内容和眼球","内容"是互联网公司(或称ICP)提供的网络服务,如网页、游戏、即时通信等,"眼球"则是借指海量的互联网用户。互联网公司的内容往往分布在多个或大或小的IDC中,越来越多的"眼球"在盯着ICP所提供的内容,互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。为了保障对内容的访问体验,互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务,并为业务模块间的通信建立IDC内部网络、城域网和广域网,同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。因此随着业务的增长,运维部门也显得愈发重要。他们经过这些年的积累,逐步形成了高效的运维体系。本文将结合国内互联网公司的经验,重点针对IT基础设施的新一代自动化运维体系展开讨论。
一、运维的三个阶段
● 第一个阶段:人人皆运维
在早期,一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模),不一定有专门的运维人员或部门,运维的工作分担在各类岗位中。研发人员拥有服务器权限,自己维护和管理线上代码及业务。
● 第二个阶段:纵向自动化
随着业务量的增长,IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模),开始有专门的运维人员,从事日常的安装维护工作,扮演"救火队员",收告警,有运维规范,但运维主要还是为研发提供后置服务。
这个阶段已经开始逐步向流程化处理进行过渡,运维部门开始输出常见问题处理的清单,有了自己业务范围适用的自动化脚本,开始利用开源软件的拼装完成大部分的工作。
具体表现为:各产品线有自己编写的脚本,利用如SVN+puppet或chef来完成服务器的上线和配置管理等工作。
● 第三阶段:一切皆自动
在互联网化的大潮中,越来越多的黑马团队应运而生,都曾有过短时间内用户访问量翻N倍的经历。在流量爆发的过程中,ICP的互联网基础服务设施是否能够很好的跟进,直接决定了业务内容能否满足海量用户的并发访问。
与此同时,运维系统需要足够地完善、高效、流程化。谷歌、腾讯、百度和阿里等规模的公司内一般都有统一的运维团队,有一套或多套自动化运维系统可供参照,运维部门与开发部门会是相互平行的视角。并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。
图1.大型互联网公司IT基础设施情况概览
二、BAT(百度、阿里、腾讯)运维系统的分析
国内的互联网公司百度、阿里、腾讯(以下简称:BAT)所提供的主要业务内容不同,IT架构不同,运维系统在发展过程中有不同的关注点。
1.腾讯运维:基于ITIL的运维服务管理
预计到2015年腾讯在全国将拥有60万台服务器。随着2012年自动化部署实践的成功,目前正在进行自动化验收的工作。在网络设备方面,后续将实现从需求端开始的全自动化工作:设备清单自动生成-采购清单自动下发-端口连接关系、拓扑关系自动生成-配置自动下发-自动验收。整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。
图2.腾讯基于ITIL的运维服务管理
2.阿里运维系统:基于CMDB的基础设施管理+逻辑分层建模
CMDB(Configuration Management Database) 配置管理数据库(以下简称:CMDB),将IT基础架构的所有组件存储为配置项,维护每个配置项的详细数据,维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库,CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时,CMDB与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中,CMDB常常被认为是构建其它ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。
3.百度自动化运维:部署+监控+业务系统+关联关系
百度主要面临的运维挑战包括:突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为,当服务器规模达到上万台时,运维视角需要转为以服务为粒度。万台并不等于"百台*100";机器的运行状态,也不再代表业务的工作状态;运维部门为研发提供前置服务,服务与服务之间关系也随着集群的扩大逐渐复杂起来。
图3.百度自动化运维技术框架
百度的自动化运维技术框架,划分为部署、监控、业务系统、关联关系四大部分,整个框架更多突出了业务与IT基础设施的融合,注重"关联关系"的联动。所谓关联关系,主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系,分别对应到任务调度、数据传输、资源定位的服务流程中,形成了多条服务链。
关联关系的运维与业务较强相关,需要有一套系统能够理清楚关系的全貌,从而在复杂的服务链上,定位运行所在的环节,并在发生故障时预估影响范围,及时定位并通知相应的部门。在这样的一套系统中,自动化监控系统非常重要。百度的技术监控框架,主要通过数据采集、服务探测、第三方进行信息收集,进行监控评估后交给数据处理和报警联动模块处理,通过API接口进行功能扩充(如图4所示)。
图4.百度自动化技术监控框架
其实无论是BAT等互联网企业还是其他行业的企业,在IT建设中都会遵循IT基础架构库(ITIL)或ISO20000服务管理的最佳实践,采用自动化IT管理解决方案以实现重要的业务目标,如减少服务中断、降低运营成本、提高IT效率等等。随着ISO20000、ITIL v3.0的发布和推广,两者已经成为事实上的某种标准。在当今企业IT管理领域,对两个标准有着很迫切的需求。特别是ISO20000的认证要求,已经成为企业越来越普遍的需求 。ITIL v3.0包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理,相关方案往往覆盖了多个领域和多个产品,规划实施和工具的选择会比较纠结。如果选择开源的工具,从CMDB开始就会遇到很多的开发工作,对于很多注重成本收益比的企业,可以参考,但由于无法保证性能与效果并不一定适用。因此,成熟的商业方案会是更好的选择。
最新的iMC V7版本,围绕资源、用户、业务三个维度进行创新,发布了SOM服务运维管理(基于ISO20000、ITIL标准)等组件,增加了对服务器的管理,能很好的满足更多互联网化的场景需求。
通常认为,一个高效、好用的配置管理数据库一般需要满足6条重要标准,即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。企业IT基础架构的元素类型、管理数据的类型往往有较多种,如网络设备、服务器、虚拟机等,因此对于多种信息的存储需要有合适的联合的方法。虽然 iMC智能管理平台在网络设备、服务器设备等方面已经能够较好的的满足,但是随着服务器虚拟化技术的发展,虚拟机正越来越多的成为IT基础架构的一大元素。因此,针对这一需求华三通信基于CAS CVM虚拟化管理系统,对服务器CPU、内存、磁盘I/O、网络I/O等更细节的重要资源以及虚拟机资源进行全面的管理。与BAT不同,华三通信的网管软件面向全行业,目前虽然没有对域名管理等特殊资源的'管理,但是能够通过API接口等方式与特有系统进行联动,进而满足定制化运维的需求,尤其是在互联网化的场景中,针对不同的业务需求,可以实现很多定制化的对接需求,例如,iMC+WSM组件与国内某大互联网公司自有Portal系统进行了对接,打通了iMC工具与用户自有运维平台,很好的实现了架构融和。另外,与阿里的逻辑分层建模相似,H3C "iMC+CAS"软件体系在上层也做了很多的逻辑抽象、分层,形成了诸多的模块,也即是大家看到的各种组件。
三、网络自动化运维体系
"哪怕是一个只有基础技术能力的陌生人,也能做专业的IT运维;哪怕是一个只有初中学历的运维人员,也能够带队完成中小型机房节点的建设,并负责数百至上千台服务器的维护管理工作"--这是一些公司对自己IT运行维护水平的一个整体评价。看似有些夸大的嫌疑,但实际上依托于强大的IT运维系统,国内已经有不少互联网公司能够达到或者接近这一标准。
这些企业都经历了运维发展过程中的各个阶段,运维部门曾经也是被动的、孤立的、分散的"救火队"式的团队,在后来的发展过程中,IT系统架构逐渐走向标准化、模型化,运维部门建立了完整的设备、系统资源管理数据库和知识库,包括所有硬件的配置情况、所有软件的参数配置,购买日期、维修记录,运维风险看板等等,通过网管软件,进行系统远程自动化监控。运维过程中系统会收集所有的问题、事件、变更、服务级别等信息并录入管理系统,不断完善进而形成一套趋向自动化的运作支撑机制。按照云计算的体系架构,在这样一套系统中,主要的IT资源包括计算、存储、网络资源,近些年随着网络设备厂商的推动,网络设备管理方面的自动化技术也得到十足的发展。
总结来看,一个企业在进行互联网化的建设初期,就需要考虑到随着用户访问量的增加,资源如何进行扩展。具体可以细化为规划、建设、管理、监控、运维五个方面。
1.规划模型化
为了确保后续业务能够平滑扩容,网管系统能够顺利跟进,互联网企业一般在早期整体系统架构设计时便充分考虑到标准化、模型化,新增业务资源就好比点快餐,随需随取。
标准化:一是采用标准协议和技术搭建,扩展性好,使用的产品较统一,便于管理;二是采用数据中心级设备,保证可靠性、灵活性,充分考虑业务系统对低时延的要求。
模型化:基于业务需求设计网络架构模型,验证后形成基线,可批量复制,统一管理,也适宜通过自动化提高部署效率、网管效率。
图5.常见互联网IDC架构
2.建设自动化
互联网IT基础设施具备批量复制能力之后,可以通过自动化技术,提高上线效率。在新节点建设过程中,3~5人的小型团队即可完成机房上线工作。例如某互联网公司某次针对海外紧急业务需求,一共派遣了2名工程师到现场进行设备安装部署和基本配置,而后通过互联网链路,设备从总部管理系统中自动获取配置和设备版本,下载业务系统,完成设备安装到机房上线不超过1周时间。
要达到自动化运维的目标,建设过程中需要重点考虑批量复制和自动化上线两个方面(如图6所示)。
批量复制:根据业务需要,梳理技术关注点,设计网络模型,进行充分测试和试点,输出软、硬件配置模板,进而可进行批量部署。
自动化上线:充分利用TR069、Autoconfig等技术,采用零配置功能批量自动化上线设备,效率能够得到成倍提升。
图6.批量配置与自动化上线
○ Autoconfig与TR069的主要有三个区别:
○ Autoconfig适用于零配置部署,后续一般需要专门的网管系统;TR069是一套完整的管理方案,不仅在初始零配置时有用,后续还可以一直对设备进行监控和配置管理、软件升级等。
○ Autoconfig使用DHCP与TFTP--简单,TR069零配置使用DHCP与HTTP--复杂,需要专门的ACS服务器。
安全性:TR069更安全,可以基于HTTPS/SSL。
而H3C iMC BIMS实现了TR-069协议中的ACS(自动配置服务器)功能,通过TR-069协议对CPE设备进行远程管理,BIMS具有零配置的能力和优势,有灵活的组网能力,可管理DHCP设备和NAT后的私网设备。BIMS的工作流程如图7所示。
图7.H3C iMC BIMS工作流程
3.管理智能化
对于网管团队而言,需要向其他团队提供便利的工具以进行信息查询、告警管理等操作。早期的网管工具,往往离不开命令行操作,且对于批量处理的操作支持性并不好,如网络设备的MIB库相比新的智能化技术Netconf,好比C和C++,显得笨拙许多。因此使用的角度考虑,图形化、智能化的管理工具,往往是比较受欢迎。
智能化:使用新技术,提升传统MIB式管理方式的处理效率,引入嵌入式自动化架构,实现智能终端APP化管理(如图8所示)。
图8.消息、事件处理智能化
● Netconf技术
目前网络管理协议主要是SNMP和Netconf。SNMP采用UDP,实现简单,技术成熟,但是在安全可靠性、管理操作效率、交互操作和复杂操作实现上还不能满足管理需求。Netconf采用XML作为配置数据和协议消息内容的数据编码方式,采用基于TCP的SSHv2进行传送,以RPC方式实现操作和控制。XML可以表达复杂、具有内在逻辑、模型化的管理对象,如端口、协议、业务以及之间的关系等,提高了操作效率和对象标准化;采用SSHv2传送方式,可靠性、安全性、交互性较好。二者主要对比差异如表1所示。
表1 网管技术的对比
● EAA嵌入式自动化架构
EAA自动化架构的执行包括如下三个步骤。
○ 定义感兴趣的事件源,事件源是系统中的软件或者硬件模块,如:特定的命令、日志、TRAP告警等。
○ 定义EAA监控策略,比如保存设备配置、主备切换、重启进程等。
○ 当监控到定义的事件源发生后,触发执行EAA监控策略。
4.监控平台化
利用基本监控工具如Show、Display、SNMP、Syslog等,制作平台化监控集成环境,实现全方位监控(如图所示)。
; 近年来,税务行业在信息化建设上突飞猛进,信息化服务能力也有了更进一步的提升,在建设逐渐完善的业务系统过程中,伴随而来的是信息的安全、有效、合理的监管问题,怎么管理好与业务系统相伴的安全问题,是关系到整个税务行业信息化建设进一步发展的重要因素。
某省地税局作为税务行业信息化建设的领先者之一,近年在安全建设上取得了一系列重大突破,各地市征管系统顺利完成了由地级市集中处理模式向省级集中处理模式的转换。省级大集中系统的全面上线,标志着江苏地税税收管理最重要的省级一体化信息平台初步建成。随着征管系统的管理机构、工作模式、岗位职责、人员分工等变化,征管系统面临的安全风险也发生了变化。从以往各地的风险仅仅是局部影响,到现在的互动影响,各地问题相互交替,范围扩大,继而影响全省;出现了各地小风险会导致全局大风险,甚至可能演变成全省灾难性风险。为了能够系统地研究分析各地自身终端信息安全,从而达到保证省级大集中系统安全的目的,依据目前安全规范要求,更需要重点关注大集中后各地终端运行安全和信息安全管控,关注应急防范处置,解决安全认识不到位、技术手段的管控力度低、信息资料的定密不清、外来人员的监控不力等问题,而基于人工方式对出现的问题和风险进行排查和处置,已无法解决人手少、范围广、事件多的困难局面,更无法适应面对全省征管大集中新形势下的终端安全需要。
为解决出现的安全管理问题,某省地税计划建立终端安全管理体系,建设终端安全防护平台和终端安全管理平台,逐步形成具有地税特色的功能成熟并能切实发挥作用的终端安全防护和管理平台,促进业务与安全的协调发展,满足省级大集中后全省信息安全有效管控的需要。 在安全教育培训、技术防范、规章制度建立、安全检查评估及整改等方面做了大量的工作,在一定程度上提高了终端安全管理水平。但是,终端系统数量大、应用多,加之安全管理人员少,缺乏完备的技术手段,无法掌握终端安全风险状况,安全管理人员难以对真正紧急的事件进行快速响应。
因此,该地税系统需要建立终端安全管理体系,通过完善相关管理制度、流程、规范组织机构职责、构建终端安全防护和安全管理平台实现以下终端安全管理功能:
实时对内网终端的软硬件、移动介质、接入访问、补丁更新、病毒防范等状况进行统一监控; 实现对终端资产全生命周期的管理; 采集终端安全相关安全事件和日志信息、进行整合和关联分析,提供终端安全态势展示; 评估终端安全风险,实现终端全生命周期的安全风险管理; 审计终端用户行为,重点实现对第三方接入终端的用户行为审计; 产生安全事故和告警,提供自动告警和响应手段; 接收并处理相关单位发来的终端相关的安全预警; 生成各种安全报告并及时进行应急响应; 进行终端相关安全知识管理; 为相关部门的信息安全审计和考核提供技术手段和依据,实现全内网终端系统的安全集中监控、审计和应急响应,全面提升该系统内网终端安全管理能力,提升该系统整体信息安全保障能力。 终端安全防护和安全管理平台将是该系统信息安全管理团队非常必要的技术支撑系统之一。 基于终端安全防护和安全管理平台的建设落实在该终端安全管理体系内,实现终端安全管理工作的信息化,为全省终端安全管理提供技术手段,提高终端安全管理、维护的水平,优化终端安全工作流程,缩短终端安全事件处理的响应处理时间,进而保障全省税务业务网络、支撑网络、业务系统以及整个信息化系统安全高效的运行,系统有如下的建设方向与目标:
搭建终端安全防护和安全管理平台,实现三级机构终端管理; 建设终端安全管理体系的基本组织框架,确保终端安全管理相关工作的有效落实; 推进内网终端安全管理标准化:对内网终端的安全访问、非法内联、非法外联、补丁更新、桌面管理、病毒防范等安全策略进行标准化管理。 推进安全事件管理规范化:对安全事件的采集,汇总及处理规范化管理,规范安全事件的响应措施。 终端安全策略框架和策略脚本建立,构建符合安全策略的基本运作流程,结合终端安全防护和管理平台实现内网终端安全维护管理流程化:对终端安全实施设备及使用的全生命周期管理、风险全过程管理和重要风险系统管理,并配合行政管理,实现终端安全管理流程化管理。 终端安全态势可视化:对各类安全事件进行统一展现,从各种不同角度进行分析,针对不同的安全事件,提供安全预警分析。 推进内网终端运行管理自动化:增强终端管理的自动化,事件响应自动化,安全告警管理和安全工单自动派发。Oslash; 实现内网终端运行管理指标化:对终端安全事件量化处理,实现终端运行监测点及相关考核指标标准化。 该系统安全管理平台建设从三个层面考虑:终端安全防护平台、终端安全管理平台、终端安全防护体系。
终端安全防护平台负责终端信息的采集和维护、终端安全风险的管理和防护、终端安全事件的监测和控制,为管理平台提供所需要的各类数据的采集和传输。实现各类安全事件的“事前防范、事中防御、事后处理”的立体化、流程化防御。是构建综合的、完整的内网终端安全防护体系的基础。
终端安全管理平台在终端安全防护平台提供的数据基础上,提供安全管理人员(系统管理员、安全主管)所需要的管理、监控、风险分析功能,各类管理报表的制作,同时满足省、市、县分布式环境下的行业安全管理要求。是构建完整的终端内网安全管理体系的技术支撑平台。
终端安全管理体系由终端安全组织体系、终端安全运作体系、终端安全策略体系和终端安全技术体系构成。其中终端安全技术体系主要由终端安全防护平台和终端安全管理平台构成。
终端安全防护平台是核心组件,是终端安全管理体系的基础部件。
终端安全管理平台在采取集中监控管理的方式,在更高层面上接收来自终端安全防护平台的安全事件和安全风险监测数据,负责对这些事件进行深层的分析,统计和关联,提供处理方法和建议。
防护平台和管理平台采用联合部署的方式,可以通过同机或者双机的方式进行部署,联合实现终端安全风险管理的有效控制。由于江苏地税的行业特性和网络结构,决定了在不同的网络类型上采用不同的部署方式和部署要求。在部署方式上,同机部署适用于小型网络(区县级网络),双机部署适用于中型网络(县市级网络),多级联合部署适用于大型网络(省市级网络),因为不同的网络级别安全性保障要求也不同。
该终端安全管理体系平台的总体结构如图所示。系统由3个层次组成,包括省局、地市局(园区)和县局(保税区)终端安全防护与安全管理平台。
3个层次组成树形结构,从逻辑上看,省局中心节点只有1个,地市局节点共15个(其中包括13个地市局、省局自身管理和苏州园区),县节点共68个(其中包括67个县和1个保税区);各地市局节点连接到省局中心节点,各县节点连接到所属地市局节点
图13-3 该终端安全防护与管理系统总体部署示意图
省局中心节点:最顶层是省局终端安全防护与安全管理平台,其中省局终端安全防护平台管理全省统一安全策略,省局终端安全管理平台不仅基于省局终端安全防护平台管理省局内网终端,而且是全省终端安全管理平台的总中心,负责全局终端安全策略的管理和下发,接收全局上报信息,具有全省数据综合分析和与其他系统协同联动的功能。
地市局节点:负责本地市内终端的安全防护和安全管理工作,同时对所管辖的下级县局安全防护平台和安全管理平台有监管功能,具体包括接收省中心策略配置或进行本地配置,收集监控信息并产生事件并上报,同时具有数据分析的能力。
县局节点:负责本县内终端的安全防护和安全管理工作,包括接收省中心和地市局中心策略配置或进行本地配置,收集监控信息并产生事件并上报,同时具有一定的数据分析的能力。
认证授权策略中心:负责全网所有的认证、授权、策略信息,所有服务器的管理角色集中在一起,由省级配发区域管理权限,区域根据自身情况进行使用者信息的管理,并且对于所有使用者信息进行区域化限定。既满足全网管理要求的统一性,又兼顾了本地管理的灵活性,统一性保障终端信息与使用者信息,以及风险信息在全网是一致的,灵活性保障管理角色和使用者具备本地管理属性。对所有节点的认证进行统一维护和备份,当任意节点的服务器出现故障,可以直接从认证中心恢复认证信息。对所有节点的策略信息进行集中管控,可以保障全省安全策略的统一,也支持全省策略的地区差异化,并且上级可以掌握下级差异化的管理详情。
所有节点都与它的父节点、中心节点以及所有的子节点进行通信。中心节点用于统一安全策略,所有节点根据策略的性质配发适用的范围,父节点能够对所有的子节点进行管理和查询,包括策略应用情况、终端安装情况、补丁安装情况查询和报警信息等,如果下级有选配管理中心,还可以对其进行在线考核。每个节点的认证和策略都是本地配置,这些本地配置将只影响本地的终端安全防护,不影响上级或者平级部署的平台,同时由于这些信息都在中心节点备份,所有可以实时进行同步和恢复。
在管理上漫游属于特殊情况,分为两种:资产漫游和人员漫游。
人员漫游比较常见,在现有的部署方案中,人员漫游可以采用人员的管理链接方式,即人员的管理属性不变,还是由其直属上级进行管理,但是资源属性支持共享,即漫游地的上级也可以查看他的属性,并且可以对其的认证和授权信息进行分配。
资产漫游分为两种:借用和设备调拨。借用时,保持资产的原有信息借用到另外区域,终端在两地的信息都会汇总到上级,而上级进行统计和分析的时候,该终端发生的所有事件都是前后关联在一起的。设备调拨时,根据规定会结束原有的生命周期,重新按照流程入网。 通过该税务系统单位与我国信息安全领先厂商天融信共同构建的终端安全管理系统,按照终端安全防护平台、终端安全管理平台、终端安全防护体系三层结构模型的建设,达到了终端风险可管、可控,安全状态可视的效果:
实现内网终端的“全程全网”安全状态可视化(Visualization)。体现在三级机构的内网终端系统相关安全状态信息可以非常直观地可视化监视,安全策略执行情况可感可知,有能力进行事后的分析和追查,提供可以“呈堂”的证据。
内网终端的安全风险处于可管理、可控制状态下。对内网终端系统安全风险的不间断的评估和控制措施调整,使得全内网终端的整体安全状况和风险情况以定性或半定量的形式及时展现出来。帮助安全管理层和终端安全管理维护人员清晰、准确、及时的了解终端所处的风险状况。
使全网的安全保障能力处于国内领先地位。在病毒爆发、违规操作以及其它不可预见的威胁出现时,内网终端安全防护和管理系统有能力及时发现,并迅速的进行响应和恢复,保障业务工作的正常运行。
保证内网终端相关业务活动在网络安全方面的法律法规符合性。规范、管理和审计内网终端安全状态和用户的行为,在整个体系中将建立法律法规符合性审核制度,保证终端系统安全管理工作的有效性,终端系统合法合规的使用。
通常智能运维中的告警收敛场景,以机器学习算法为驱动,对海量的告警事件进行降噪和关联分析,辅助根因定位并可沉淀故障处理的知识,从而提升企业的运维效率,降低运维成本。 告警产生后,AIOps系统通过算法甄别 内容相关性(重复性、相似性)、时序相关性和拓扑相关
性 事件来进行告警事件的自动化抑制。这类收敛抑制,往往能得到99%的告警压缩率,极大地提高了告警有效性。
在一个完整的智能运维告警产品里,除了告警收敛,还可以基于故障传播链及拓扑信息 ( 可选 ), 智能发现突发故障场景;基于告警“熵值”算法,实现告警的动态优先级推荐;通过时序以及拓扑关系定位故障场景根因,并进行根因标记。当这些都可以完成时,由告警事件一步步引导的根因定位和排障,才是真正智能运维发挥了作用。
发表评论
暂时没有评论,来抢沙发吧~