数字化浪潮之下,运维能力也逐渐成为现代企业的竞争力之一。
在过去的数十年间,运维发展经历了数个阶段。从早期的手工运维到标准化运维、自动化运维,再到DevOps、AIOps,追溯整个历程不难发现,运维方式随着技术的不断发展,逐渐迈向智能化。
2016年,Gartner面向运维提供了一个新概念——“AIOps”,中文释义智能运维。即其是以AI等手段为核心,为运维提供更为智能和数字化的支撑。也就是说,把运维从“人”的要素抽离出来,更多的放到“数据”一侧。其中包含的场景更加丰富,包括异常告警、告警收敛、故障分析、趋势预测、故障画像等等。
所谓的AIOps,简单理解就是基于自动化运维,将AI和运维很好的结合起来。
AIOps的落地在多方面直击传统运维的痛点,AI算法承担起分析海量运维数据的重任,能够自动、准确地发现和定位问题,从决策层面提高运营效率,为企业运营和运维工作在成本、质量和效率方面的优化提供了重要支持。
市场方面,全球IT研究机构Gartner预测:“到2022年,将有40% 的大型企业部署AIOps(智能运维)平台。”
可见,AIOps 在企业中的作用正在进一步放大。但事实上,很多企业对于AIOps 能解决什么问题并不清晰,今天我们就以博睿数据的AIOps 的三大场景和算法说起。
博睿数据的AIOps 实践
作为中国领先的智能可观测平台,在AIOps实践方面,多年来博睿数据积极拥抱人工智能、机器学习等新技术变革的浪潮,并基于AI和机器学习技术,自主研发了“数据接入、处理、存储与分析技术”核心技术体系,全面布局智能基线、异常检测、智能告警、关联分析、根因分析等丰富且广泛的智能运维功能,并将AIOps能力融入端到端全栈监控产品线,可为传统企业提供强大的数据处理、存储和分析的软件工具,帮助客户整合各类IT运维监控数据,实现数据的统一存储和关联分析,打破数据孤岛,构建统一的IT运维管理平台,让企业的IT运维更加智能化、自动化。
在此基础上,博睿数据还依托完整的IT运维监控能力,利用大数据和机器学习技术持续构建先进的智能运维监控产品,2021年先后推出了搭载了AI能力的新一代APM产品Server70和新版的统一智能运维平台Dataview,不断落地智能异常检测、根因分析、故障预测等场景。基于人工智能的能力实现运维监控场景的信息整合、特征关联和业务洞察,帮助企业确保数字化业务平稳运行,并保障良好的数字化体验。
所谓知识沉淀说的是前期运维工作中发生的成功案例,失败案例等没有进行有效盘点和总结并输出文档材料,没有知识复用是指在新的运维工作开展过程中没有参考或借鉴过往经验教训。明白这两个点要义那针对性的改善计划就可以顺势而出了:
1、知识沉淀:一是每个运维项目每个月(或季度)必须输出盘点报告(巡检报告);二是每个运维项目结束必须输出总结报告,总结在此过程中发现的好的建议或不足之处;三是将沉淀工作落实到人,每个运维工程师每个月(或季度)必须输出一份运维工作心得报告;
2、知识复用:一是在新的运维项目开始前必须对照过往同类型项目做必要的风险评估和预案制定;二是顾虑员工提案新的运维方案或运维技术。
之所以要不断的沉淀和复用,就是因为在内审或外审体系认证中,运维质量是可以,也是必须不断循环改善的,不能依赖于某一次重视或强抓,也不能依赖于某个领导或运维工程师。
先说国有银行。国有银行也是银行,银行就得办业务,现在的银行办业务就靠信息系统支持。只是国有银行往往企业文化和企业治理没有那么的自由,普遍有官僚机关习气和均等化倾向,这种国企氛围未必是每个人都喜欢的。另外在管理层级和运营效率上,国有银行也是有很多痛点的,这些方面不比内部竞争激烈的股份制银行或者民营银行,确实不太适合有巨大才华和野心的人奋斗。不过好处也是很明显的,就是如果没有很强的事业心,也不想赚很多的钱,那么混个安稳安逸的日子是很不错的地方。这个可以作为背景写在这里。其次说下总行后台。中国的银行业是信息化程度相当高的行业,目前国有银行的IT系统基本都是总行集中开发和运营的。所以题主说到的IT运维,虽然说是后台,但也是总行的啊。结合前面的国有背景,这个总行就直接是层级管理的核心了啊,当然要比分行好了啊。再说下后台,以前呢是后台不比前台,银行靠着前台业务人员赚钱所以当然就前台业务人员更好升迁更好发展更有职业前途了。可是现在银行是靠着信息系统支撑着才可以运营的,没有IT支持,几乎没有什么业务还好办理了。关键是广大消费者已经习惯了各种电子渠道的银行服务了,甚至广大消费者们都被银行培训的已经接受了网银上的那些相当银行视角的产品栏目。而且从发展趋势上看,未来会越来越依靠信息系统支持金融业务发展,甚至主要靠信息系统支持业务发展。看看现在如火如荼的互联网金融就知道了,未来的金融业务很大程度上是依靠网上的,毕竟消费者如你我基本都住在网上。这就是说,未来IT将越来越作为业务发展的力量出现在银行的管理架构里,而不是现在作为成本中心出现。相对应的,随着互联网应用的加深,这个“后台”也将越来越没有后台的意义了,大家以后恐怕都是主要靠着后台来运营业务的。没有前中后台之分才是未来的银行业务发展趋势。所以那这个后台也就不是劣势了,何况是总行的后台呢。对吧!
IT运维管理发展成熟,目前较为普遍应用的为ITIL流程管理。有人将ITIL比喻成IT管理中“黑夜航行的灯塔”,这光芒万丈的词汇吸引了无数个企业或是准备、或是已经开始在IT运维服务管理中实现标准化运维。而我们知道,在ITIL强大的流程管理面前,其核心组件之一的CMDB(配置管理数据库)却往往耗费了大量的人力和时间收集各类IT基础架构信息后,竣工而成的却是一个几经失去生命力的ITIL运维管理组件CMDB。
CMDB在IT服务管理中的驱动力
面对复杂多变的业务需求与IT预算的不断紧缩,企业的IT部门在为企业整体运营目标提供可靠服务时都面临空前的挑战。想要解决这些问题就非得拥有一个良好的组织管理策略,因为我们必须要先了解环境中的各个对象的特点,才能对它们予以控制、维护和改善。为了达到动态IT运维服务所追求的目标,我们必须将ITIL指导真正落实为明显的、可衡量的,变成可以整合的实体,而这承载这些实体的容器就是CMDB。
作为ITIL实施成功的关键与保障,CMDB相当于整个“网络列车”前行的动力源泉。由于它可以代替以往手工存储和管理企业IT架构中设备的各种配置信息,因此更多的企业开始考虑采用自动获取的方式存储IT基础设备的各种配置项信息,然后将其与ITIL的所有流程都紧密相连,提供有效数据支持ITIL其他流程的运转,
CMDB配置库可以被比喻成企业网络中的“眼睛和大脑”,这个特殊的动态数据库作为ITIL标准流程里一个核心的组成部分,记录了ITIL流程运转的过程,从开始启动、发现事件、问题处理、变更管理、版本发布,到最后的关闭,中间的所有的过程都会被自动的记录到CMDB中,并实时、真实地展现出来。
错误的CMDB就如大脑记忆力出现混乱
ITIL运维管理组件CMDB存储与管理企业IT架构中设备的各种配置信息,那么如何运转、发挥配置信息的价值,就要依赖于数据的准确性了。试想如果CMDB对故障设备的关键性指标提供了错误描述,事件能够得到及时解决吗?如果没有配置管理的同类故障统计分析支持,如何实现主动的问题管理?如果没有配置管理提供CI(配置项)之间的关系作为依据,如何针对将要进行变更的CI以作风险评估?
曾经一位资深表示:“前几年,我所任职的几个企业中对于IT建设虽然重视,但当时苦于没有IT管理工具作为辅助,所以我们都是采用自下而上的方法,也就是从底层开始,利用手工把资料录入到开源的CMDB中。
这个阶段的问题可能谁都清楚,历时两、三年,不但时间长久,而且还存在录入错误的问题。而现在我更换了公司之后,已经放弃了自行建立CMDB的想法,也不想让IT人员花大力气梳理、搜集这些信息,并且在日常工作中耗费人工保持其时效性。但我考察了一些案例,这些公司采用厂商所提供的IT管理工具建立的CMDB在实施后,仍旧发现了设备配置项录入不规范、不全面的问题,资源之间的关联关系缺乏等一系列的问题,这就必然会导致领导决策人参考这些错误的信息做出错误的决定。
唯一比较让人满意的是人力资源与社会保障部,他们采用的CMDB和IT资源库进行了互联互通,底层监控工具自动采集数据汇总到IT资源库RDB,定时和ITIL运维管理组件CMDB进行审计,确保CMDB的数据库准确无误,有效保证了数据的精确性,为领导的决策提供了最基础的保障。”
那么,人力资源与社会保障部是如何保证数据质量,使系统成效发挥出来,避免功亏一篑呢?
在许多基于ITIL的ITSM项目中,实践者虽深知CMDB对于企业IT服务管理能力的重要性,但在部署过程中却往往被CMDB构建所涉及的庞大工作量所困扰,感觉困难重重,不得要领。CMDB出现问题一般会存在三种情况。首先,是由于配置信息设置过于精细,会导致数据负载压力过大,性能下降;其次,由于资源信息、配置信息设计过于粗框,没有将必要的CI信息设计进去,没有建立CI之间的相互关联关系,导致系统因配置项到期罢工之后,找不到需要的配置项以及配置项依赖影响信息,导致运维效率降低;另外,一些IT管理项目也出现了RDB(资源库)信息与CMDB配置信息未能建立良好的同步审计机制,导致故障产生时,两者信息不一致,混淆了运维人员的’眼睛’。
以上就是关于如何看待AIOps的发展全部的内容,包括:如何看待AIOps的发展、内审小组进一步访谈it运维团队发现运维团队无知识沉淀分享和复用的意识针对问题编写一份可行的改进计划、国有银行总行后台IT运维的发展前景怎么样等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)