IBM谭健:当运维管理遇上认知计算

2018-06-11    来源:

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

      IBM的认知计算在IT运维领域,它遵循三个指导原则:

          一是持续学习,通过对海量的运维数据进行洞察分析。

          二是介入纠正,对正确的数据行为,指标行为进行建立模型。并跟踪指标发生的变化或数据发生的变化,及时找到异常。

          三是建议动作,最终通过IBM的一些自动化解决方案,对问题进行修复

      谭健,IBM混合云IT服务管理技术支持工程师。

      2001年加入Micromuse,2006年被收购加入IBM ITSM中国技术团队,专注Netcool和IT监控分析技术与支持,超过20年企业级数据中心运维经验。

      众所周知,认知计算就是指它是新的计算模式,包括信息分析,自然语言处理,机器学习等众多领域的新技术和实现。助力于决策者从海量信息中提取,去洞察,协助我们决策。认知计算的一个重要目标,就是让计算机系统像人类大脑一样去学习、思考,并辅助做出决策。学习计算机系统相对人脑来说有一个优势之一,就是能够做到不间断学习。所以它的进步也是一个累积的过程。学习什么?海量的数据,结构化,非结构化的,语音,图像的。

      光有数量够不够?肯定是不够的。比如说这两年比较火热的阿尔法狗,打败韩国围棋界泰斗李世?,今年四五月份又打败世界排名第一的柯洁,如果阿尔法狗天天学习的对象就是一群业余一二段小学生,它也不可能最终能够打败众多世界高手,成为领军者。说明数据的质量也非常重要,总而言之,实现认知计算,大数据是非常重要的基础。

      认知计算运用于众多领域,IBM已经在气象、医疗等诸多领域,开始进行尝试。在运维领域也不例外,IBM推进路线如下:因为IBM认识到大数据的重要性,她率先要解决的就是海量数据的处理能力,在运维过程中,相当大的一块内容是非结构化或者结构化的日志数据,IBM借助自己的引擎,实现海量日志数据的收集、整合、索引、搜索、可视化等能力。

      当运维管理遇上认知计算,IBM的做法是这样的:

      首先,IBM结合自己的运维平台,解决方案,加入机器学习能力,开始对事件进行分析。

      其次,运维中还有很大一块数据是性能数据,基于时间序列的指标行为分析,IBM推出了一款产品,专门用于洞察预测指标行为的变化。目前,WASTON FOR ITSM 项目还处于研发过程中。WASTON技术用于IT服务管理,其实,除了已知的气象、医疗领域,IBM内部早已经开始使用WASTON技术了。比如:IBM内部的HR系统,WASTON已经开始受理IBM员工的人事福利相关问题。此外,WASTON已经开始着手处理IBM 800技术支持工作,读取用户问题,并尝试给出解决方案。

IBM的认知计算在IT运维领域,它遵循三个指导原则:

      一,持续学习,通过对海量的运维数据进行洞察分析。

      二,介入纠正,对正确的数据行为,指标行为进行建立模型。并跟踪指标发生的变化或数据发生的变化,及时找到异常,最终通过IBM的一些自动化解决方案,对问题进行修复。另外IBM WASTON 虽然是内部的项目,也欢迎外部企业参与,共同进步。

      三,建议动作,最终通过IBM的一些自动化解决方案,对问题进行修复。

      在传统运维管理领域,IBM Tivoli Netcool 解决方案,广泛应用于全球大中型金融,电信、政府、制造等众多领域。现在IBM把该解决方案和大数据融合形成一个新的解决方案Netcool Operations Insight,简称NOI。

      这是另一个例子,某Web容器线程池使用率在下午3-4点通常会到达99%,早上9点前及晚上8点后从未发生,且每周一到周三发生频率最高,周四到周日负载逐级下降。同样了解到这个规律以后,IT人员可以跟业务人员一起来分析到底什么造成了这种情况。经过分析,发现这个业务确实在周一到周三特定时段之内,交易量非常大。针对这类信息,IT人员就可以调优、分配资源,以保证在这个时段内,系统业务能够稳定正常的输出。也就是说,了解告警发生规律,对优化我们的运维策略,对于调配我们的应用资源都是非常有帮助的。

      很多企业都有自己工单系统,都会制定相关运维策略,比如,某一类型、某一告警级别发生后,产生工单,交由相关领域专家处理。可能会经常碰到这种情况,十个专家处理十条告警,最后大家发现解决的是同一个问题。实际上,这种情况非常容易理解,在我们现在的IT环境里,经常会有当某一个业务服务发生中断的时候,产生了众多条告警,这些告警可能根源只有一个,其他告警则是相关告警,也可以叫衍生告警。NOI能够做到识别根告警,并且针对根告警开工单,把相关告警关联给根告警。这样的话,我们就可以分配最少的人力资源去排除故障,从而达到提高我们运维使用效率,降低运维成本的目标。

      在运维领域还有很大一块数据类型是基于时间序列的指标数据。在很多企业里,尽管已经有这样或那样的性能管理工具,对基础设施,应用,服务指标进行监控。但是指标行为分析却很难去开展,因为对于指标行为分析,如果用人工分析,难度很大,效果也不会好。比较常规的做法,通常是定义静态的门限,但是定义门限往往是根据管理员应验来的,定义门限过高,导致指标已经积淀,由于门限故障没有报上来。如果门限定得过低,造成很多告警,管理员也会忽略掉真正的问题。事实大量试验证明,当某一个业务应用甚至一个服务器,网络设备,当它出现问题前面一段时间之内,可能会在一个或者多个性能指标上有所反映。

      如果用户尽早的发现这些指标异常行为,就越能够争取更多的时间去补救。IBM专门研发了一款产品叫预测洞察(Predictive Insights,简称PI)。通过PI可以对指标数据进行跟踪和分析,经过一段时间的机器学习以后,PI系统能够识别到某一个指标在过去的一周,它的正常运行规律是什么,PI再比对实时上收的性能指标数据,去查看有没有异常,有没有偏差。如果有偏差,它认为未来某一个时间点可能会出现问题,它会及时把这个告警送出来,让管理员关注。现在业界这种工具也有很多,尤其这两年,有些客户自主开发,有些是购买厂家的套装软件,都可以做到单指标分析。

IBM的PI系统到底有哪些优势呢?

• 第一,它是支持异构平台,也就是说,我这套系统不用重复采集现有管理工具的指标数据,而是跟现有工具集成,从这些性能工具中获得指标数据,然后通过机器学习,自动建立正常的数据基线。最终实现实时跟踪性能指标数据发现异常。

• 第二,PI系统吞吐能力非常大,单个引擎可以分析跟踪50万个性能指标,而且PI的引擎可以横向扩展的,以适应任何企业规模的要求。

• 第三,除了单指标的相关性以外,PI系统还能识别学习多指标系统的相关性。经过大量试验证明,对于一个完整的业务系统,有30%—50%指标之间,在统计学里是有数学相关性的。比如说有些指标和另外的指标,他们运行行为总是保持正向一致性。指标A增长,指标B也跟着增长。也可能是反向一致性,指标A增长,指标B下降。这种关系是可能人的肉眼看不出来的,需要成比例的放大一千倍,甚至反转以后,才会发现它们的变化规律。还有指标A和指标B平时都是离散状态,但是它们总在某一时刻同时产生异常。针对众多的数据行为关系,在PI系统中内置多种算法,用来识别指标之间的数学规律,当这些指标数学关系规律一旦被打破,往往也预示着业务系统马上要出现健康的状况,PI会随即产生告警。

      在PI系统有一个核心算法叫Granger causality算法,它是由诺贝尔奖获得者,经济学家CliveGranger提出的,是一个中立的算法。这个算法原理,通这个算法就是来界定多指标之间是否有因果关系。如果利用指标A的变化,去预测指标B未来的变化,比利用指标B自身推测指标B变化准确度高的话,我们就认为指标A和指标B之间有一定因果关系。在一个IT环境里30%—50%指标之间都有可能存在各种算法的数学关系,针对这些数学关系,PI系统可以自动发现并建立模型,而且后续数据可以帮助其不断的修正模型,如果用人工去维护整个模型,是非常困难的,但是对于计算机系统来说是非常容易做到的。

      接下来举个例子,这是一个网银系统,我们有众多IT组件支撑,有网络存储、数据库、中间件、核心应用等等。假定我们有多种运维管理工具,对各个IT组件指标值进行全覆盖收集时序指标数据。PI系统经过一段时间学习后,它会掌握单指标的变化规律,以及多指标正常的行为关系。另外值得一提的是,PI系统对某一个指标,到底使用单指标算法分析还是多指标算法分析,这也不需要人去控制。如果PI发现某个指标和其他指标之间没有任何关系,他就会用单指标算法对这个指标进行追踪和分析,如果发现该指标与其他指标存在符合某种算法的数学关系时,则用该关系算法来跟踪和分析。如果从某个时刻开始,比如说,我们队系统做了某些变更之后,PI发现某个指标,原先和其他指标不存在行为关系,现在突然产生了行为关系,PI会重新计算调整模型,用多指标行为模式对指标进行分析,反过来也一样。

      对于多指标行为分析,现在举个简单的例子,经过一段时间学习以后,PI系统发现网银业务的响应时间指标与用户请求指标有正向因果关系。也就是说,当用户请求数增多,业务响应时间指标会成比例增加。假定在某一刻这个规律被打破,比如我的用户请求数量在减少,但是我的业务响应时间却变长了,这个时候,PI系统会及时把这个告警发送出去。即便在这个时段内,业务的响应时间指标数据没有劣化到业务不可用的状态,但是我们会把这个信息尽早发送给客户,为运维人员争取到更多的时间去分析问题并补救。我们曾经在一个大型银行做过一个测试,我们让用户提前准备了一月以上的历史数据,这包括了当年10月到11月的数据,然后,我们把这些数据贯入给PI系统,让它进行学习,这个学习速度会非常快。学习完毕以后,我们观察到PI系统在11月13日这个时间节点,产生了大量异常告警。视图下钻后,可以看到异常情况的细节,最终我们发现有两个指标,一个失败交易数,一个是交易总时长,这两个指标关系存在异常,发生时间是八点半。我们拿着这个结果和用户核实。该行运维人员经过检查后告诉我们,他们在11月13日十点钟确实有贵金属业务出现问题,最终他们通过限流和重启方式,把这个问题解决掉。这是当月比较大的运维事故。我们再回到刚才这张图,不难看出,浅色区域,代表PI系统在八点半时,就已经分析出指标关系异常而预警,也就是说,如果用户当时使用PI系统的话,可以早于事故1个半小时识别到问题,也就能争取到更多时间进行补救。

      在运维自动化方面,配合敏捷运维的目标,IBM也开发了一些小的微服务,部署到IBM公有云上。操作手册微服务提供了一个工具平台,可以将运维知识和经验,与特定类型的告警进行关联,并执行预定义的修复动作。

      另外还有一个小工具叫告警通知微服务,告警通知微服务已经打通了跟各个通知软件协议的接口,比如短信网关接口,邮件服务接口,都已经帮你建立好了,你只需要利用统一的界面来定义你的告警通知策略就好了。如果您有多套运维管理工具,很难实现告警一致的通知策略,可以考虑IBM的告警通知微服务。

标签: 大数据 服务器 公有云 金融 排名 企业 数据库 搜索 网络 问题 用户

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:Elastic与阿里云达成合作伙伴关系 提供“阿里云Elasticsearch”

下一篇:戴尔机架式基础设施为用户带来更优的总体拥有成本