当前位置: 亚洲城ca88 > 计算机网络 > 正文

智能运转正是,新一代运行管理平台建设的三种

时间:2020-03-25 10:59来源:计算机网络
听了有关AI运维之后有很多人感到比较焦虑,我所从事的运维或开发将来会不会被AI给替代掉呢? 讲师介绍 前言:IT监控运维系统,起源于各设备厂家的网元网管等监控工具,伴随着信

听了有关AI运维之后有很多人感到比较焦虑,我所从事的运维或开发将来会不会被AI给替代掉呢?

讲师介绍

前言:IT监控运维系统,起源于各设备厂家的网元网管等监控工具,伴随着信息化的发展而升级换代,经历了大数据、虚拟化、云计算等技术革命的考验逐渐完善成熟。IT监控运维系统从最开始的解决故障,到提供高效的运维服务,已逐渐成为IT运维部门日常运维工作中必不可少的工具。

现在新技术发展的特别快,各种语言、技术、理念让大家确实感到自顾不暇跟不上趟,但是有一点,在这里我要特别重申一下,AI在目前这个阶段还是一种辅助大家来进行判断和学习、定位处理问题的工具,就像无人驾驶,现在可以做到完全没有人驾驶吗?肯定不行,未来无人驾驶是完全可以替代人的,但它还有很长一段路要走。AI运维就像无人驾驶一样,未来前景很光明,但任重道远。

宋辉

随着企事业单位IT系统规模不断扩大,构成IT基础的设施呈现出规模庞大、结构复杂、品牌众多的特点,为实现信息资源合理配置、有效管理,确保系统安全可靠运行,IT集中监控系统的建设成为企业信息化运维工作的重点之一。同时,运维活动也缺少管控,如没有构建服务台、知识库、CMDB、事件管理等基本流程。此外,监控运维并不是简单的“监控 流程”,两者的有效结合也是一个难点。

大部分的智能运维还没有完全落地,我所在的企业也是处在一个探索的阶段。在一个传统的企业它的运维该如何走?从以前的脚本到工具、自动化,再到现在的智能运维,中间这个步骤该怎么走?今天就从下面五个方面给大家分享下:

轻维软件CEO

传统运维面临的问题

一、构建一个全面科学的IT运维管理体系第一个IT部门的整体认可不足。虽然说IT在任何单位现在都是一个比较重要的部门,但是还有很多领导仍然认为它是一个成本中心,不是一个利润中心,认为这个部门是花钱的,而不是像业务部门创造业务价值和创造利润的。第二个对于运维工作人员负荷比较大,工作模式不被员工认可。在没有自动化运维和平台之前,整个运维团队只有八个人,如果每个人一天处理六到十个故障,基本上没有时间去研究别的东西了。传统运维压力很大,疲于奔命和救火,必须要寻求改变,走向自动化、平台化、智能化。第三运行的态势相关信息掌握不足。监控是多维度的,不同的业务会有不同的指标,所有加起来有上万个指标,但却没有整体态势变化图、很难成体系,不能实现智能感知和态势预测,整个运维态势就很难保持平稳。第四依据业务需求调整服务和设置资源的能力不足。在业务故障处理的时候需要很长的过程,中间涉及到很多的相关技术部门,需要和业务方进行交互,仅靠较少的人力几乎做不到。

Oracle认证大师,15年以上运维管理经验、Oracle数据库技术支持,支持过的数据库超1千套长期为大型企业核心业务系统数据库提供方案设计,在性能优化、故障处理、应急容灾、安装配置等技术领域有独到的见解和丰富的实践经验

错综复杂的IT元素难以有效监控

我们希望在现有的业务体系里面,运维部门要实现这样的运维目标?

大家好,我叫宋辉,目前在新炬网络旗下轻维软件负责运维平台的研发。从03年毕业到现在在IT行业混了有14年多了,其中有12年是在从事运维相关的工作,应该说见证了整个IT行业十多年的大发展,也经历了许多的技术及产品的兴衰起落,感触良多。

从宏观上看,IT设施种类各异,组成复杂,从最基础机房动力环境->基础网络->存储->X86(小型机平台)->系统->应用;从硬件到软件;从后台应用支撑服务到前台页面服务,这些错综复杂的IT元素很难有效整合监控。

第一个全面的性能管理。能够提供对现在所有的设备和服务质量进行实时监测,并且提供动态阈值的告警。第二个统一的资源管理。很多企业业务都上云了,需要有统一的监控平台,可以把所有业务相应资源视图抓取出来,便于我们对整体资源有一个合理的预估和分配,并从整体角度评估各个业务部门对资源的使用情况。第三个及时的故障告警管理。我们发现有很多产品还不能做到完全及时的告警,告警发生后总是延时才能知晓,需要实时的准确的告警,减少延迟和误报。第四集中统一展现管理。把很多不同的监控子系统集成起来,这个在现在的企业里面需求是很大的,借助于各种工具,采集数据之后自动合成一个报表统一展现出来,方便管理。

今天主要跟大家分享一下新一代运维管理平台的建设思路,选这个主题,一方面是因为运维在整个IT生命周期中作用越来越重要,另一方面新的技术及架构给运维带来了新的方向与思考。如何做好运维,成为更多企业及运维人员关心的重点,在这里结合个人在这个行业的一些经验,跟大家做个探讨。

从微观上细究,特定IT设施种类各异,品牌繁多。以存储为例,品牌涉及IBM、HP、EMC、Netapp 日立、华为、浪潮等,监控对象指标包含磁盘阵列的各个组件,指标包括风扇、电源、电池、控制器、硬盘的状态、实时性能,以及交换机的各温度、电池、主机映射关系等,获取这些指标并非易事。

我们关注的核心问题有:

一、运维平台的重要性

传统运维工具单一,无法集中管控

第一我们是一个跨地域的平台,是多数据中心,我们希望有一个IT的综合运维平台,来统一管理。第二是深入监控并进行集中统一的可视化管理,提高效率。第三就是有效的预防问题的产生,降低运维成本。另外就是问题出现后,能够快速跟踪定位,降低人力成本。第四多维的报表为决策提供有力支撑,科学预判趋势。第五全局业务服务视角和平台化扩展以及大数据分析的融合,满足企业对于业务高效和快速迭代的需求。第六保护和优化IT资产。以前各个业务都是自己的一套系统,有自己的开发和运维人员以及监控系统,这对企业来说是重复造轮子了。现在上云后,把原有的系统集中整合到云上,通过统一的监控和资源管理最好的保护和优化资产。

随着信息化建设的不断发展,企业的IT已从原来的一个后台管理职能,转变成了生产营销中心,IT越来越多地渗透到企业生产运营之中。同时IT技术架构也在逐步朝微服务、容器、云化、开源等方向演进,在新的架构规划体系下,IT系统将变得更加复杂,对于平台的运维支撑能力、资源支撑能力等带来更高的要求。

企事业单位用户可以通过厂家提供的管理工具,如vmware 的VC客户端,存储的管理客户端,硬件服务器的web管理控制台,或者通过查看日志/硬件设备的指示灯等方式查看运行状态和性能指标。显然,这些零散的方式会增加运维工作量,影响故障发现的及时性,IT运维人员迫切需要一个统一集中的平台将以上监控任务有效整合。同时,由于缺少有效的流程管控机制,运维工作总是处于“救火式”状态。事前无准备,事中无跟踪,事后无法追溯,运维经验无法沉淀积累与复用。

要做好智能化运维之前,我们经过深入的分析,提了四个要求:

在当前的IT系统建设及数据中心规模扩强的速度下,没有一套合适的运维管理平台,运维工作将举步维艰,因此建设一个更可靠、更智能的运维管理平台就显得尤为重要。

运维过程无流程或流程不成体系

第一个是规范化。规范化就是尽可能的把操作规范下来,比如模板里是什么基础配置和安全基线,有一个规范化的标准。第二个是可控性。就是能够通过云监控平台发现各个业务存在的瓶颈,包括资源瓶颈和性能瓶颈,对可能产生的问题可控可分析。第三个是数据化。基于海量数据的决策分析,才能方便作出准确的判断和科学决策。第四个是主动性。从被动响应变为主动服务,主动发现问题,把问题消灭在萌芽中,在业务发生问题之前及时告知,这个感觉就不一样了。

二、运维平台发展历史

随着信息化及互联网 普及推广,企事业单位已经从大规模的信息化建设向信息化运维转变,运维团队不断扩大,信息化管理流程日益复杂,之前的纸制化审批流程效率低,难以适应新环境下的流程管理,需建立统一、规范、层次化的服务管理流程和服务管理体系。面对复杂的IT环境,缺乏规范化、自动化的运维处理流程,缺乏完善的故障处理和快速修复机制。

我们希望构建现代化和智能的运维管理模式,主要是以下5个方面,如下图:

广义上的运维平台发展经历了三个阶段:

看OneCneter如何破局?

二、全景业务服务管理

第一个阶段,以专业化网管工具为代表,包括网络设备、主机、数据库、中间件、存储等进行专业监控管理的各种专业化工具。第二阶段,以ITIL流程化管理为代表的综合网管,通过事件、服务、流程等贯穿监控、变更、资产管理等一系列IT运维管理。第三阶段,以敏捷、DevOps为代表的运维管理平台,主张开发运维一体化、自动化,强调需求、资源的服务化。

勤智运维磨砺多年,深刻理解IT运维“建设易,管理难”的特点和ITaaS背景下的服务转型阵痛,结合多年运维实践及对ITSS国家标准的制定与理解,推出OneCenter一体化智能运维管理平台,将“监控、管理、治理”三方面有机融合。

在互联网大爆炸时代,国家层面上也在提互联网 、数字化转型、智能化等等。我们的系统能不能快速响应,为业务保驾护航?

目前第三阶段还在迭代演进中,随着人工智能的新起,AIOps的概念开始盛行,因此结合敏捷及智能,成为新一代运维管理平台的建设的核心目标。

OneCenter一体化智能运维管理平台可以让IT监控运维智能、高效、简单、统一,帮助运维团队实时、全面掌握IT运行态势,及时响应和处理IT故障,为各企事业单位业务提供强有力的IT支撑和质量保障。

面向业务的IT服务管理主要有这几个特点:

三、建设原则

一体化IT设施监控体系

1、监控的粒度要细,能通过一个曲线捕捉到异常点。2、面向业务管理和面向用户管理。这块要区分开来,在企业里用户权限分的是比较细的,什么人可以操作什么样的业务,管理员可以管理哪几类业务都有清晰的定位。3、数据的全面和扩充性。数据只有全面才能进行科学的决策,很多时候如果看到的日志不全,或者拿到的监控数据不准,在做决策的时候肯定就会比较贸然。比如数据中心某业务链路出现问题,是不是要切换?数据是不是还能保持一致?这个时候在没有确定的数据来支撑你决策之前,你做决策时都会感到比较忐忑,犹豫不前。

IT运维管理是一个非常宽泛的范围,整个IT生命周期都跟运维有着关系,运维难做,运维管理平台更难做,这个领域缺少标准和规范,目前也就Gartner对ITOM/ITOA有一些功能范围上的定义。

图片 1

建立以业务为导向的综合监控平台,主要目的就是要统一展现、统一管理和统一调度。全链路监测,这个目的就是从访问入口进来后一直到数据出去,每一个过程都要能监控到感知到。

运维管理平台包括监控、ITSM、CMDB、自动化运维操作、日志分析、用户体验、APM、数据库管理、云平台管理、网络管理、业务监控、拨测、运维大数据等这些类别,有些企业建设了很多项目或购买了许多工具,但仍觉得用不上、不好用、用不起来,为什么?

勤智OneCenter的ITManager监控模块,可对业务系统及支撑业务系统的所有IT资源进行7*24小时全面监控,提供性能监控与分析、资源可用性监控与分析、资源拓扑关系管理、故障监控、故障分析及定位,帮助IT运维人员提升工作效率。

从业务的视角进行IT基础资源的管理与维护,一旦某个资源发生故障或问题,都可以从业务视图中直观地了解到这个资源的故障将影响什么业务影响哪些服务,进而了解到影响哪些用户。

个人觉得包括几个方面原因,如管理思维的问题、技术架构的问题、组织文化的问题等。我们今天重点讨论技术方面的问题,个人认为要建好一个运维管理平台,应该遵循如下的原则:

开放式的一体化运维平台

数据库慢了,CPU突然飙升了,这些地方这些资源突然发生变化了之后,影响到哪些业务呢?这时候就需要将监控资源视图和业务关联起来,这样才能准确定位影响了哪些业务。

(1)运维管理平台包括非常多的功能和模块,不可能一步到位,建议从整体的思路构建,考虑数据上的融合和各子系统之前的协同,一个模块一个模块构建,架构清晰、稳定、方便扩展。模块多了就必须要考虑数据标准的问题,其实跟现在企业各系统之间的数据孤岛是同样一个问题,各平台之间很难产生联动的价值。这个具体的做法,会在后面讲到。

平台将机房环境、IT基础资源、应用系统情况进行统一展示、告警和管理,告别不同资源的离散管理模式。

这个是问题的整体诊断和分析。

(2)运维平台的建设和落地应该由运维来驱动。运维是个非常专业的工作,虽然DevOps的理论已经非常深入人心,但真正解决和提升的更多是在持续集成和交付上的能力,对于专业的运维,渗透得并不是那么成功,如很多互联网公司也尝试过由开发团队来做运维,但也仅限在应用运维这一层,同时导致各自为政,工具建设泛滥的问题。阿里的DevOps也经历了几个阶段,最终成型落地也是让运维带一群开发进行运维平台的建设,提升运维的工具化能力。因此运维平台还是要由运维来主导建设,虽然运维不管业务,但需要站在业务的视角来构建运维平台。

多维度可视化视角

任何问题都需要采集相关的日志和数据,才能科学全面的分析问题。

(3)以业务为中心来进行构建,打通业务与设备的关联。随着微服务及分布式架构的兴起,在运维管理中,会逐步淡化系统的概念,各种微服务通过流程编排组成了各种面向用户的业务。传统的分层架构逐步往网状架构转型,对于运维平台提出了新的能力上的要求。

平台通过网络拓扑、业务系统、机房环境、虚拟化结构等多维度视角进行可视化展现,使资源全方位信息一目了然。

采集层需要把不同数据源的数据采集过来,中间层做一些性能分析,配置管理和预警分析、告警处理。展示层将分析的结果展示出来,也就是各种图表,建立综合的业务指标分析,方便根因定位和解决问题。

(4)分阶段实施,先看到成效,再进行能力扩充,不要想着一口吃个胖子,很多企业连基础监控都还没做好,就想着要搞人工智能,有点不切实际。因此充分考虑未来的方向,预留发展空间在平台建设整体规划时,需要充分考虑数据分析能力及运维大数据能力,AI是运维的未来。

基于业务级运维

三、基于大数据平台的日志分析和多维报表

四、建设思路:7大核心模块

支撑企业运营的是各个核心业务系统,所以IT组织的视角逐步从资源级运维向业务级运维转变,从业务角度出发,在可视化的业务视图上业务架构、服务和所依赖组件一目了然。

基于大数据平台,提供日志的采集和聚合处理,通过日志关联分析帮助准确全面定位提升效能和满意度,智能预测和预警,为科学决策提供量化依据。

新一代运维管理平台,主要是以业务为中心,通过问题快速发现与修复、运维批量操作与自动化,保障业务系统高效稳定运行为目标,实现运维的可视化、自动化及智能化。IT业务系统的软硬件设备及之间的依赖请求关系,组成了一个巨大的多维立体网络,中间的任一个节点出现问题,都可能引发业务系统的异常。

更加聚焦故障管理

将采集到的网络监控数据、机房数据、服务器和云环境监控数据以及摄像头报警数据集中起来,数据汇集之后生成PMDB性能管理库,在根据业务应用的特征,建立不同的模型进行相应的算法分析。

对于运维管理平台的目标,一方面是在系统出现问题时能找到真正根源的节点,同时也能分析出其内在的深度的原因(如除了定位到某个应用出了问题,还要能定位到是哪段代码或某条SQL),并进行自动有效的处理;反之要能通过所有节点蛛丝马迹的指标变化,预测系统的运行走势,在出现问题前能采取有效的措施进行处理。

平台通过极简的界面和简单的操作结合系统强大的后台算法和分析能力,提供专业简单的智能化故障处理引擎。

根据不同的资源类来定义KPI指标,建模目的就是方便快速分析,为资源管理、告警管理、集中化展现等其他模块提供数据分析模型的支撑。

为了达到这个目标,结合现在市面的工具,我们将其总结为7个能力的建设,包括:

自学习的运维知识库

数据采集有两种类型,一种是被动的,一种是主动的。

问题发现及自愈能力(监控告警)自动运维操作能力(自动化运维)资源配置管理能力(CMDB)用户体验管理能力(业务监控、用户体验管理)组件深度性能分析能力(如数据库性能分析、应用性能分析等)运维大数据分析(如大数据日志、AIOps)门户及场景集成(数据分析、Portal,运维场景集成)。

帮助运维人员建立更加快速、高效地构建丰富的知识库,利用知识库快速对运维管理中发现的故障给出解决方案,恢复系统,确保业务正常运行。

采集业务相关指标,可以对数据进行预处理,做一些有效性的标签识别,比如这个信息和指标是不是你关注的,对不友好的日志进行格式化处理。

这7模块各就其位,相互协助,构建新一代运维管理平台的核心。

图片 2

性能指标的计算,要跟业务进行协同,从业务的角度来定义。设置的阈值,有些场景是固定的,也有的场景是动态的。固定阈值就相当于资源使用率,肯定有一个上限的。动态阈值像一些性能曲线,CPU的利用率、页面响应、图片加载等这些是可以使用动态阈值的,根据历史数据来计算出这个动态阈值,某一时刻的历史峰值,根据这些合理计算出在那个时刻到底需要多少资源。

下面分别介绍每一个平台模块的建设思路:

一体化运维平台大数据分析能力

根据上面的阈值会有一个报警的事件,任何事件产生都是基于时间的,故障的定位肯定也要基于时间找到相关的日志和发生的事件。

模块一:构建统一的监控告警平台,实现集中采集和告警,更快速地发现和发析及处理问题。

ITBA运维大数据分析系统是大数据技术在IT运维领域的应用。该系统运维内部整合了Hadoop、Spark、Kafka、MongoDB、Solr、Flume等多种大数据架构技术,提供多种类型数据接口的采集方式,实现多平台/多业务的监控、流程等运维工具的数据整合和统一管理。同时,提供对于第三方业务平台的数据展现、数据统计、告警分析和业务分析功能,可以将多个系统在门户内进行统一登录展现;也可以与其他系统对接,从第三方系统登录至运维系统平台。一方面ITBA大数据作为统一运维监控的工具,可以采集各家数据,将非标准数据变为标准数据;另一方面可以提炼数据,进行检索,做海量日志分析。

事件诊断一直是运维领域一个很重要的工作,事件和时序的相关性不仅可以为事件诊断提供很好的启发,而且在帮助我们进行根因分析时也能提供很好的线索。某个时间段出现的故障,都会产生一些相关的事件,对它们进行筛选和过滤是能够详细捕捉到故障和定位到根因的。

统一监控平台的能力要求包括:

图片 3

在事件诊断和处理中,是不是需要引入算法,我觉得是有必要的,如果能提高效率和提高解决问题的能力,一切探索都是值得的。

覆盖全面,具备统一数据采集的能力。对于监控告警平台的建设,这个是老生常谈了,为什么还要来说?因为很多的监控平台没有用好或用不起来。相对于传统的监控系统,我们更强调设备覆盖的完整性和指标覆盖的完整性,强调统一集中采集平台的能力,而不只是用来做监控和告警,更重要的是用于整个运维数据的采集中心,为后面所有运维决策、人工智能等提供方便的数据来源。对于已经有了许多专业网管的企业,建议进行统一数据采集的融合,提升或新建一个专业网管做为一级网管,其它下沉为二级网管。

丰富的监控模型库

也有一些运维界的朋友们花了很多时间和精力,去学习和研究算法,我认为不必过于纠结算法, 简单了解一下开源的这些算法,知道这些算法的输入和输出是什么,能解决运维中哪些实际问题,以及组合起来又能解决什么问题,方便我们合理的应用它就可以了,这样会对更快落地智能运维起到事半功倍的效果。

对于采集回来的指标,一般可通过阀值等配置告警,但现实系统基于阀值的方式存在一定的弊端,无法对指标的异常波动做出准确的预警,如CPU使用率从20%,突然上升到70%,虽然没有触发告警阀值,但实际上系统性能可能已经发生了比较严重的恶化,需要引起关注。我们给某些企业建设的统一监控平台,指标量已达到200多万,我们需要有从这200多万的指标进行异常波动检测及快速预警的能力。一般会利用一些大数据算法进行智能基线的计算及预警。

全面灵活的监控方式(SNMP、WMI、SSH、TELNET、SHELL、IPMI、HTTP、Agent、syslog、SMI-S 、JMX、GB/T28181、SDK、TCPDUMP等),使得系统具备全范围的监控能力。OneCenter一体化智能运维管理平台能够监控各种操作系统、服务器硬件、网络设备、各种WEB应用、数据库、中间件、存储、虚拟化、WEB站点等IT资源,还支持灵活的自定义脚本监控。

数据的汇聚处理就是把采集到的数据有机的关联起来,压缩、过滤形成标准化的信息。数据导入则可以通过全量的HDFS和增量的Kafka来实现。

对于监控系统来说,有一个非常重要的能力,就是进行告警,但许多人都觉得告警太多,导致许多人对传统的告警失去信心。

图片 4

基于大数据平台的多维报表,根据自己的需要,按照日、周、月来生成运维报告,发送给管理层的领导,这些数据是他们比较关心的,比较清晰的图示出在这些时段发生了哪些问题,造成了多大面的影响,然后决定相关的资源是否进行扩充,相应的业务部署是否需要调整。

我们的经验是,一方面降低对低级别的告警的关注,只对致命或严重级别的事件进行短信通知,这些告警发送给相应专业的维护人员。另一方面,通过技术手段,建立告警依赖和告警关联分析,只对根因告警进行通知,对被影响的告警进行屏蔽。目前基于规则的告警依赖这个实现起来复杂度非常高,而且严重依赖于CMDB的能力,基于算法的告警关联分析准确度有待考验,我们更希望在基于算法的方向,来解决这个问题,目前已取得初步成效,后面有机会可以跟大家做进一步的分享。

告警集中展现

综合展示比较关注的则是性能分析、容量分析和自动化配置。比如今年采购了500TB存储,我用了多少,明年还需要扩容多少,业务增长量会有多少,这个都影响到企业的采购计划。根据业务的实际进行评估,来推算出明年大概需要买多少TB的存储。

提升了问题发现的能力、预警通知的能力后,接下来就需要构建问题自愈的能力,这里需要引用关联我们另外一个模块的能力,就是自动化运维平台,通过调用自动化运维平台的脚本或流程平台,实现问题的快速自愈,即通过事件与自动化运维操作的关联,构建IT系统的自愈能力。

OneCenter 一体化智能运维管理平台提供统一的告警管理,通过性能指标采集轮询、调用厂家网管告警接口、网元Trap/Syslog主动推送、第三方系统轮询获取等多样化的来源方式,获得整个网络系统中各种事件、设备故障、网络异常等告警信息。当出现故障后,OneCenter一体化智能运维管理平台能通过预置的报警方式,以邮件、短信、电话自动拨打等“告警必达”方式及时通知指定用户,并能生成告警分析统计报告,提供主动式的故障解决方案。

四、IT监控管理平台发展

这样我们基本上就能构建起一个非常智能和敏捷的监控系统,实现初步的机器管理机器的目标,达到自动的事件闭环管理。

图片 5

IT监控管理的发展大概有三代,从上世纪九十年代至今,第一代是以网络为中心,在这个时期咱们提供比较多的都是基于网络的监控和故障发现,带宽管理和服务水平协议。

模块二:建立自动化运维操作能力,以操作及流程或场景为闭环,构建集中运维操作平台。

图片 6

第二代监控就是以监控IT基础设施为中心,看到比较多的就是主机、存储、操作系统、中间件、数据库等各类基础资源的监控。

集中运维操作平台的能力要求包括:

统一的运维管理平台,规范日常处理流程

第三代监控以IT应用为中心,针对比较高度复杂的交易,需要实现面向用户体验和面向应用高可用性的实时监测和故障的智能诊断,运维人员必须高屋建瓴、全面谋划,有能力提供一个全局性、高效健壮、标准规范、自动化的监控解决方案并加以实现。

以集中操作中心为目标,覆盖对数据库、中间件、主机、网络设备、存储、云平台、硬件甚至应用程序接口的操作管理、批量调度、作业任务管理能力。当后面该平台成为整个运维的操作调度中心,这样做的好处就显而易见了,打通所有系统软硬件的操作能力后,将非常容易构建起基于任何流程的运维自动化的业务场景,通过技术手段贯打通原来的组织的壁垒。

OneCenter 一体化智能运维管理平台 基于ITIL标准形成了一套结合服务台、知识库、CMDB、事件管理、问题管理等流程的统一运维管理平台,可以和监控系统做无缝衔接,日常告警事件可直接触发工单运维,提高工作效率。OneCenter系统采用多层架构及模块化的设计,系统功能全面,模块功能独立,可根据不同需求自由组合。同时,OneCenter 一体化智能运维管理平台具备良好的扩展性,通过第三方数据接口和数据总线以及门户Portal,与第三方产品可进行无缝集成。

五、故障管理及自治自愈

举个例子,按照原来的流程,如果需要新上线一个应用,需要涉及云平台划分虚拟机资源、安装配置系统软件、开通网络防火墙、进行应用部署、进行安全扫描及加固、部署接入监控等事项。在传统企业当中,往往涉及多个部门或多个团队,如基础平台、数据库、中间件、网络、开发、安全、监控等,按照现有的基于流程的方式,需要提N个工单,花上1-2个月的时间才能搞定这个事情。但如果基于集中操作运维的平台的能力,把应用上线做为一个业务场景,把所有步骤能编排成一个大的流程,自动去执行,中间的关键步骤前可加入审批的控制,这样一个流程可能1-2天就跑完了。这就是技术的价值。

图片 7

这是我们每天收到的告警情况统计,在没有自动化和智能化之前,我和大家一样心态是焦虑和崩溃的。

相对于业务化的场景,对于平台的建设,我们要提供的就是构建这些场景的基础能力。一方面是兼容各种软硬件设备的操作能力。如能对防火墙执行一个策略下发,能对云平台执行一个新建虚拟机的操作。目前有很多的开源工具,如Ansible、Saltstack等,在自动化运维领域做得很好,但这两个工具核心的能力还是在对于主机的脚本执行管理能力,需要通过自建或扩充对于各种软硬件设备的操作支持能力。

另外,OneCenter 移动终端运维管理,提供移动服务台、告警列表、工单待办列表、工单查询及处理操作、设备巡检、系统公告接收和知识查询等功能,为运维工程师提供了一种便捷的运维模式,有效提高IT部门整体运维能力。

如何从错综复杂的运维监控数据中得出我们所需要的信息和结果,一句话就是分辨和精炼,提取真正需要关注的信息,从而减少每天的告警信息量。

平台的基础能力除了兼容各种设备的操作能力,还包括文件上传、下发、脚本执行、配置管理、软件包管理、流程编排等基础能力。前面提到的对各种软硬件设备的操作能力在平台上就体现成一个个的原子操作,通过流程编排,可以快速将各种原子操作编排成一个一个的业务场景,如上线部署、安全扫描、健康巡检、安装部署、故障诊断、资源开通等各种能力。

图片 8

目标就是简、智、深。

在此基础上,我们可以将自动化运维平台上集成的各种操作、流程、场景封装成API,对外系统提供调用及操作。如可以提供给监控平台,进行故障自愈;提供给CMDB进行配置及关系自发现等。

IT监控运维系统已逐渐成为IT运维部门日常运维工作中必不可少的工具,并在很多已建成的运维项目中发挥着不可替代的作用。如国家核电统一运维项目,实现了统一监控、统一运维、统一展现等“七个统一”;湖北省公安厅智能IT统一管理平台项目,实现全网上千种IT资源的统一管理和IT资源故障告警自动流转进入服务流程;湘潭大学一体化运维项目,支持复杂环境的大规模监控,有效提升IT运维管理和服务能力。

简就是要确保业务和SLA服务级别,出现问题要及时响应、自动分析和优化,把处理的流程精简和高效组合起来,让问题匹配正确的场景,找到正确的人,在第一时间正确处理。

对于自动化运维平台,需要非常关注安全的管理,因为基于此平台基本可以对整个IT系统环境执行任何操作,这个具有很大的安全隐患。当然有许多互联网公司的运维管理理念是用人不疑,充分授权,这种方式对于效率是非常大的提升,但在传统行业不一定能行得通。因此平台需要有安全管理能力,能对原子操作的执行、执行的对像、时间进行权限控制,另外支持对整个操作过程的审计,对于敏感操作能进行二次授权等。这样安全和效率才能兼得。

机器学习主要就是突出智,这个需要大量的数据来训练,故障出现的形态是千奇百怪,对故障的历史数据进行场景分类和标注,不断用模式识别和数据来训练机器识别和分析,然后让机器自动准确判断。

模块三:构建统一资源管理能力,成为整个运维平台的资源中心、配置中心。

当然标注不能完全靠人,也需要通过机器来自动进行关键词标注,而标注的合理性就需要人为进行判断,然后再利用到机器学习上,这样才能真正辅助我们做一些决策。

要求具备的能力包括:

基于架构、工程师的经验和概率来做到收敛告警事件,基于规范和分工产生告警事件发送到对的人,基于数据和模型来提高事件的处理能力。很多事件有的工程师处理的特别快,反之如果对这个故障不熟悉的人可能花费的时间就很长。这就需要构建一个策略知识库,让其他人来参考和学习,提高同类场景事件处理的能力。

CMDB其实也是个老生常谈的问题,各大企业做CMDB的项目非常多,但成功的不多,最主要的原因就是把CMDB当成了excel在管,搭个平台、建个模型把各种配置数据统一录入到系统里面就结束了。这样的CMDB当然会失败。另外CMDB要以业务为中心,更多的关注在资源管理,能提供资源的整体视图,很好的展现业务及应用与资源的关联关系,除了系统视图、逻辑视图、物理视图外,需要增加业务流程视图,管理业务流程各节点与各服务之前的关系。

智能运维的终极,实现的目标就是减少对人的依赖,逐步信任机器,实现机器的自判、自断和自决。

CMDB应该成为整个运维管理平台的资源及配置管理中心,成为运维的第一入口。如监控、自动化运维等均涉及大量的资源管理,不允许各自建设一套各自的资源体系,监控和自动化运维操作的资源应该来源于CMDB。整个大的流程是应该在设备上架开通后,录入CMDB,再从CMDB接入监控或运维;设备下线后,先从监控及自动化运维的平台进行监控及运维操作下线,再从CMDB进行下线。在设备没有录入CMDB时,不允许接入监控及自动化运维。这样就可以避免CMDB数据更新不及时的问题,按照CMDB管理上的经验,如果都不需要接入监控和自动化运维的设备,肯定是属于三不管的设备,上面也不会有什么重要的业务,就算CMDB里面没有数据,也无关紧要。当然这些管理上的要求,必须通过技术手段上的限制去落地。

技术都是在不断的进步,AI技术将来会解决很多的一些需要花费大量人力和时间才能解决的事情,但是AI不是一个很纯粹的技术,它也需要结合具体的企业场景和业务,通过计算驱动和数据驱动,才能产生一个真正可用的产品。

通过把CMDB做为整个运维管理平台资源的入口(其实这也是CMDB数据消费的非常大的一个场景),可以解决CMDB设备数据不完整的问题,甚至说不费吹灰之力。CMDB的配置数据及关系数据,可以通过监控或自动化运维平台去进行自发现,确保数据的完整性。

智能运维技术在企业的落地,不是一蹴而就的,是一个渐进和价值普及的过程。

对于CMDB数据的完整性,需要除了管理上的要求,需要构建自发现的能力,对于配置项的属性及关系,大部份可以通过自发现来实现。CMDB应该与监控系统及自动化运维平台保持非常好的联动关系,监控及自动化运维的资源数据来源于CMDB,同时监控及自动化运维作为CMDB配置项属性及关系数据自发现的最主要的来源。这样无须独立为CMDB构建复杂的自发现模块。

我们可以看到,智能运维技术已经成为新运维演化的一个开端,可以预见在更高效和更多的平台实践之后,智能运维还将为整个IT领域注入更多新鲜和活力,在未来发展和壮大下去,成为引领潮流的重要性力量!

CMDB关系数据不完整,另外有很大一个方面的原因是,设备量太多,维护团队很难知道哪些配置项关系有问题,无从下手。平台应该提供业务视角的数据校验的能力,如一个业务系统,包括应用、数据库、中间件、主机、存储、网络等很多设备,这些设备构成了一个拓扑关系,但如果数据不完整,这个拓扑关系就是不完整的,我们很容易看到哪里出现了中断,去把这个关系补上就好了。所以我们虽然很难发现一个完整的业务系统拓扑,但通过数据校验,能发现拓扑关系的缺失,再提供快速便捷的修复能力,这样关系就能慢慢完整了。这也符合CMDB的数据众包修复原则。

作者:

关于CMDB的数据消费,数据越完整消费价值越大,把资源数据提供给监控、自动化运维平台进行接入,把关系数据提供给监控平台进行基于规则的告警关联分析、根因分析等。与监控数据结合进行维保分析,对于低频使用的机器,可以降低维保级别等。对于低频使用机器,结合上线时间,进行设备下线、退网提醒等。CMDB结合监控、自动化运维等平台,可以不断完善数据,也可以构建更多更有价值的消费场景。

孙杰,国内一线运维专家,从业十几载的IT老兵,专注于系统、运维、云计算和数据中心管理,先后在外企、互联网、电商、大型企业任职,参与实施数据中心建设、私有云架构规划及运维管理、大数据挖掘等相关工作,在若干大中型项目的建设和部署运维中,积累了丰富的架构设计、项目实施和一线经验。凭借丰富的技术经验和乐于分享精神,先后受邀出席全球云计算峰会、可信云大会、GOPS全球运维大会等全国性技术会议并发表热点主题分享,受到广泛好评。不仅是技术分享的推崇者,也是IT行业的实践者、布道者。

CMDB一半是技术,一半是管理,成功的CMDB需要重视CMDB看不见的能力与价值。

原文来自微信公众号:高效运维

CMDB数据消费场景(基于规则的告警根因分析)

模块四:关注用户体验,运维需要重视和关注业务及用户。

之前很多企业的运维是不关注业务的,只是在业务反馈用户投诉或系统出现故障时,才会响应分析系统平台的问题。这种方式是非常不合适的,往往只能做到被动响应,无法做到主动预防。用户体验包括以下几个部份的内容:

浏览器、APP上终端用户的真实体验,这部份数据可以通过流览器插码及APP SDK收集。如现在比较流行的APM for APP及Browser模块。通过应用拨测的方式,在各IDC部署拨测终端,模拟用户对系统平台进行拨测,对响应时长,错误率、成功率等进行分析。业务系统平台数据侧的统计与分析,如基于流程数据的统计、基于应用日志的统计,对系统业务量及响应时间等用户体验数据进行统计与分析。利用抓包解码的方式,对网络流量数据进行解码,分析与统计终端用户的体验数据。

实际落地时需要结合企业使用的技术架构进行选择,也可以采用多种技术手段结合的方式进行。在这个领域互联网公司有非常成熟的经验值得借鉴。

模块五:新一代运维管理平台,需要引入对用户体验数据的监测与分析,结合系统平台数据,真正做到端到端的监测与分析能力。

应用组件深度分析能力,通过监控或智能告警等一般可以定位到一个软硬件设备的状态出现异常,但异常的真正原因是比较难排查的。重启、扩容应用或许可以短期内解决问题,但真正的原因可能是代码的缺陷或低效的SQL语句或数据库本身的资源争用导致的。

目前大多数的应用还是属于数据密集操作型的,也就是重数据库的,对于这些应用、应用本身代码级的诊断和数据库的深度诊断分析能力要求更高。应用组件深度分析能力主要体现在:

应用端的深度分析,利用应用探针技术或应用日志埋点,对应用代码级的方法、请求进行分析,实现代码级的诊断,在应用请求量、成功率、响应时间等出现异常时能快速定位问题节点及代码。这个在当前的微服务和分布式架构下显得尤为重要,蜘蛛网式的应用架构,在出现性能问题时,如果没有明确的调用链路分析手段,将是非常致命的。数据库的深度分析,对于目前企业大多数应用来说,数据库仍处于非常核心的地位,对于数据库的维护管理显得尤为重要,一条SQL语句搞跨一个系统的事经常出现,不管是Oracle,还是DB2、MySQL,SQL Server,这些数据库都需要最高级别的深度监控和分析,包括数据库低效SQL的分析、一键式的性能诊断、SQL语句的自动优化、SQL上线前性能审核、SQL版本比对分析等。许多企业都有好几种关系型数据库,构建一个有强大SQL性能管理为核心的数据库统一管理平台非常关键。我们在为许多大型企业构建新一代运维管理平台时,都会重点考虑构建数据库的深度分析管理能力。

一键式的数据库深度分析

模块六:大数据日志分析及运维大数据能力

前面已经提到AI是运维的未来,任何现象都可能跟某个隐含的数据有密切的关系。因此依赖于大数据、人工智能等新型的技术,将人对问题、故障分析的经验移植到代码上,甚至在不久的将来,对于运维,机器干得比人还要出色。当然对于真正的AIOps我们还处在很初级的阶段,但必须从现在开始准备。

第一步先要把数据集中起来,建议先构建大数据日志分析平台,形成大数据分析能力,把设备日志数据、应用日志数据集中起来,提供基本的关键字搜索、统计、告警、趋势分析等能力。这些是对于传统监控告警一个非常重要的补充。

依据日志数据中的标签、埋点及关系,构建基于日志数据的场景分析能力。应用场景包括业务指标分析、业务链路分析、接口性能分析、用户体验分析、故障隐患分析、故障根因分析等。

接下来考虑基于大数据日志分析平台构建运维大数据分析能力,将统一监控平台的海量指标数据同步到日志分析平台,构建成运维大数据平台,一方面,基于这些数据可以进行大量主题的分析,如容量分析、性能分析、事件分析、隐患分析等。另一方面,利用监控告警事件、CMDB资源关系、设备及应用日志,进行关联分析,同时利用各种人工智能、机器学习算法,进行基于人工智能的运维分析与诊断。

模块七:集成平台构建运维场景集成能力

如前面的架构图所示,整个平台分为三个层次:监控及运维操作、运维大数据分析及门户与集成平台。集成平台主要用于下面两层能力的自定义构建与场景化,通过下面两层的服务化接口,构建面向不同维护人员的运维场景,以支撑更多的个性化应用。利用各种报表工具,进行多维度的自定义数据分析与运维能力集成。通过集成平台,构建运维一体化PaaS平台,提供面向业务的运维监控、运维操作及决策分析平台。

集成平台通过调用平台服务化API接口,提供自定义场景集成能力,快速构建各种应用场景。如下图所示,通过CMDB的数据查询接口在平台自动构建一个系统拓扑,通过采集监控模块的API接口把系统运行指标数据、告警事件映射到拓扑图上,通过自动化运维模块API,把常见的运维操作能力集成到拓扑图上,这样可以快速构建一个可视化的智能运维场景,这些都无须运维人员有任何开发能力,大大降低运维开发的难度。

五、小结

建设一个具有先进性、扩展性及未来性的新一代运维管理平台非常重要,但同样难度也不小,个人认为整体上的规划至关重要,有了清晰的战略才能有良好的落地与效果。7种能力就像7种武器,互相搭配,各舞所长,才能发挥最大作用。

今天给大家讲的主要是思路,很少涉及具体的技术,里面包括了许多的内容,每个企业的实际情况及IT发展阶段、甚至管理模式都不太一样,大家可以选择性的参考与借鉴。运维是企业IT的基础,未来运维的挑战只会比现在更大,及早构建一个新一代的运维管理平台意义非凡,我们在此方面积累了许多成功的经验,也具有了一定的产品体系,欢迎大家与我们进行更深入的探讨。

QA

Q1:目前运维自动化实践在哪个行业和客户落地的比较成熟?A1:自动化运维来说,在互联网落地成熟度较高,因为互联网行业的设备标准化能力较好。但传统行业随着云的普及和落地,标准化程度不断提高,自动化运维大有可为。

Q2:中间都会用到哪些软件?

A2:这个是一个大的方案,里面有很多的平台模块,形成合力。里面具体的一些点,可以有很多开源的解决方案,如监控的Zabbix、自动化运维的Ansible,CMDB也有开源的。但开源的方案一般较难打通和基于企业业务情况构建场景。

直播链接回放

?topicId=2000000218877425null

原文来自微信公众号:DBAplus社群

编辑:计算机网络 本文来源:智能运转正是,新一代运行管理平台建设的三种

关键词: 亚洲城ca88