混合云认知IT服务管理

白凡

讲师 | 黄卫 - IBM
编辑 | 白凡

大家好我是IBM混合云的工程师黄卫，今天介绍一下IBM的混合云认知IT服务管理。

1. 传统架构转型虚拟化和云平台的背景

IBM这几年两个重点方向：是云和认知。云这一块IBM重点关注的领域主要在混合云，现在企业都在做转型，尤其是金融单位。前段时间看过一个报道，今年中国金融单位，尤其是一些商业银行离柜业务率已经达到百分之八九十了。其中有10多家商业银行，包括民生银行离柜业务率已经超过99%。说明现在大多数业务越来越多的通过自助、手机、网络和终端，而不是通过柜台来做的。我们把它称之为数字化转型。

今天主要谈运维，从运维这个角度来看，数字化转型给运维带来最大的挑战就是数据量膨胀。现在处于混合云数字化转型阶段企业面临的数据量平均一天1.3T这样一个水平。很多传统基础架构在往虚拟化方向转，不管是计算资源、存储资源还是网络资源，要求会越来越多的灵活多变，资源分配通过代码来实现。所以混合云对运维来说带来最大的挑战主要在于敏捷、多变，要不断地适应用户前端的要求，同时后端支撑系统相比传统的基础架构处于不稳定、敏捷、变化，随需应变的过程。

1.1 传统运维经验的痛点

从运维这个角度看传统的经验，到底哪些已经过时了？而从监控的角度，通常我们会去做问题、定位，会依赖一些配置信息，一些业务到基础架构中间的依赖关系。很多金融单位会想到需要有一个类似配置管理数据库，相对来说比较稳定，不是快速变化的流程来帮我们定位问题、解决问题。但是在云化的环境下我们很难去确定一个相对固定不变的配置关系。
所以当遇到一个问题去排查，会发现需要去关注的头绪非常多，从基础的物理架构到虚拟化层，到Paas，如果有微服务器的上线还要关注Paas的系统。甚至很多前端面向互联网化的业务运营在公有云的平台上，还要看公有云平台会不会有些问题。

上面图片中报告超过2/3新的集成业务的数据流会延伸到企业的防火墙。虽然提供承载的资源并不为我所管控，但是我的业务运行在它之上，比如说公有云、阿里云，或者托管、租用的数据中心，业务运转、应用到底是不是满足我的要求？如果出问题了能不能拿到数据，能不能定位，帮我排查这个问题到底是企业内部造成的还是第三方托管平台所造成的，甚至可能是应用本身代码造成的。
这也是为什么越来越多的金融单位用户开始逐渐需求，更主动的，有前瞻性的、预防性的管理方式，来定位复杂环境下的问题。

这也是今天想跟大家分享的，IBM在混合云环境下，在运维上如何去利用最新的一些认知技术来帮助我们从数据当中，而不是从传统经验去分析、去定位。

2. 什么是认知？

现在谈得比较多的话题是AI人工智能，包括类似阿发狗。认知在AI领域相对来说比较特殊，它是应用人工智能的技术，但是更接近于非监督式的学习。阿发狗或者相对来说能够确定变化的一些场景，是有目标的，我要追求的是成功率最高，或者盈利最大。

但是在运维领域，没有一套IT系统会告诉你怎么做稳定性最高，它只会客观的反映一些数据给你，能够怎么样分析？只能去学习它。就像一个婴儿一样，这个世界是我不能够左右的，我不能够设定一些目标的，但是我可以学习，我可以去理解这些变化到底有哪些规律。

在暴雨来临之前风速会下降，温度会下降，经历过几次之后就知道，很大概率上雷阵雨就要来临了。通过软件，通过算法去学习就是模拟人的思维方式、行为学知，一边走，一边去观察，去提炼数据，内在反映出来一些客观的规律和特征。这些客观规律和特征会帮助我去建一些模型，这些模型替代原来相对固化的，类似业务依赖关系的梳理。
就类似大人一样，我可以给婴儿，给小孩一些指导，提前告诉他什么情况下应该怎么去做，怎么去分析。本身算法不断地演进。然后学习、掌握，形成我的模型以后不是一个相对静态的，仍然是在不断变的，因为数据不断地进来，每天一点几T，大型银行一天交易的量就要超过10个T。

这些数据一定会对模型和分析方法有影响，我要有能力跟踪这个模型，刷新到模型当中。这是强调的重要性。学习出来的模型，反映出来的特征和规律并不只是给管理员和用户去看，来呈现整个IT架构从底层一直到上层的应用是什么样的规律。更重要的作用是要去做匹配、预测和调整。怎么样匹配？模型出来以后，新的数据再进来有没有遵循我之前学习到的模型，还是违反了某些我总结出来的规律和特征。

这些违反或者偏差对我的业务会造成什么样的影响？会不会导致重大的业务停顿，导致用户投诉我？这些规律和特征都需要去学习，并且融入到新的模型当中的。脱离数据明显会导致我的IT系统，我的应用，乃至我的客户体验发生重大的偏差，会在第一时间预警出来。至少从它的结果上会有一个预期，希望你提前修正的提示。

2.1 如何修正？

我有人工的经验，我有一些工具、自动化的手段，我们都可以去把它融入到认知学习反映出来的一些结果，然后再做进一步的响应，并且形成闭环不断优化、提升的过程。

3. IBM解决方案

IBM是怎么做的？围绕两方面的数据和大家分享一下：

• 非结构化数据。这也是我们经常接触到的，从运维部门来说事件、告警、设备，包括一些日志、应用、软件，甚至包括硬件管理系统都会发出各种日志。体量最大的是一些交易类的日志。这些都是学习的对象，我们称之为处理前是非结构状态，虽然中间会经过结构化处理。

• 相对结构化的数据，日常会通过工具软件获取CPU内存、流量、交易的响应速度，它有一个特点，它可以基于时间序列形成一个曲线变化。

这两种数据为什么要做区分？因为IBM用于分析这两类数据的算法是完全不一样的，包括建立的模型也是不一样的。

首先看针对事件告警和日志这类非结构化数据，我们需要去学习、挖掘哪些内容：当收到设备的告警，或者用户部门打电话跟我说遇到什么样问题的时候，第一时间头脑里边会反应出这个问题我以前有没有遇到过？这个问题曾经遇到的时候前因后果是什么。

3.1 上下文规律排查

任何问题出现的时候IBM会在不断学习过程当中总结的规律建立一个预设，选定任何一个问题，可以上下文打开这个问题，在历史上曾经出现过的各种从时间到空间上的规律和特征，来帮助我们对特别关注的，或者是影响非常大的一些问题，能够在最短时间找到问题背后的原因，并且以最好的方式来解决它，有效的缩短我们的MPTR（平均修复时间）。这是上下文规律的缩影和排查。

3.2 周期性规律预警

有很多问题发生背后一定是有原因的，这个原因有可能相当比例周期性的会出现这样一个特征。所以会发现表现在事件告警日志上面，有相当比例的数据是呈现周期性规律的。所以去学一天10个T这些数据当中到底有哪些事件告警日志是周期性的特征，出现的概率、比例有多大。以及未来再次出现的信心指数有多高，并不是所有周期性的问题都需要关注，可以去挑，可以去看，结合对业务系统运维的经验去筛选哪些是最关注的把它激活，算法就会持续跟踪，一旦再次出现立刻会打标签和预警。

3.3 相关性规律

另外还有相当比例的特征和规律是在问题的相关性上，无论是事件告警和日志，一定极小概率是孤立的出现，一定有大量的派生或者根源、因果这样的关系导致了当某个业务出问题，或者某一个IT元素出问题的时候会引发一连串的问题。这一连串的问题内在会有那些成对关系，甚至构成因果关系，这是算法学习很重要的部分。

案例1

这里展示几个例子。这个图有4个时间，反映这个问题在4个时间维度上的特征。某个应用端口在0—60分钟时间维度，以及一天24小时，以及一个星期7天，包括一个月30天左右，4个不同的时间维度上。很容易就可以看出来这个问题周期性规律体现在日这个维度，几乎在历史上近百次的出现发生都集中在早上6点，并且6点到6点半之间高频率出现。并且在月维度上是平均的分布。

以很自然的就会思考为什么早上6点到6点半高频率发生应用端口，一定区别于其他时间不一样的背后原因导致的问题发生。所以可以快速的去做问题的挖掘。

案例2

这个问题是一个蛮典型的，使用率到达99%一定会有告警发出来。这个问题基本上集中在下午三四点钟，并且周一、周二、周三是相对高频率的出现。是不是有一些措施能够优化一些资源调配，让容器支撑这个业务在周一、周二、周三可以有更充裕的支撑。

事件告警日志相关性规律排查，稍微有一点运维经验都会知道这是对我们帮助非常大的地方，其实最直接的帮助就是从海量的事件告警当中能够定位尽可能小比例的工单派发给相关处理人员，而不至于大量的资源最终诊断发现处理的都是同一个问题。

其实在国内有非常多的例子，无论是几大行，包括电信、移动，在使用IBM相关的产品其实都经历这样一个过程，从场景化的关联性分析和根源定位逐步的过滤到通过数据动态实时的跟踪学习、分析，提炼出这样一个问题特征。
亚洲最大的本地化上百万台设备，每天的事件量平均在1500万—2000万，但是它只有很少的10个人左右在做问题的运维。每天的工单数只是在两位数甚至更少，从1000多万到两位数。而且它是一个持续的过程，不是一个事后的分析，因为它是需要直接指导运维、监控的。所以这当中工具、算法、软件需要发挥相当大的作用。

3.5 单KPI认知分析和预测

类似重要的指标KPI，对于这样的一些指标有着类似非结构化事件告警、日志变化的特征，只是分析的方法、算法有所区别。整个理念的设计也是相类似的，我们需要不断学习，因为每个指标变化和波动，无论是自己也好还是他和相关联的其他指标一定都是存在，或者表现出某一些特征和规律的。

我们需要去不断地建立模型，这些模型反映的是过去，反映的是从当下到最近的半年、一年，甚至更长时间的规律。这个规律帮助我去建立一个观察点，这个观察点用于匹配当下正在发生指标的变化来看这些指标变化有没有脱离，甚至违反曾经学习到的特征和规律。并且这个违反的情况会不会导致重大的问题发生，而不至于等到最后所有的指标变成一条直线停板我才去处理这样的问题。一定要在观察点立刻把这个问题提前暴出来。

指标的学习跟刚才讲到事件告警和日志的学习是相类似的地方，它有两方面，一方面是针对每个单指标，单个KPI去学习本身的变化和波动规律。通过基线的分析，通过标准方差，也是很重要的算法。

任何指标在业务稳定顺行的时候波动一定是围绕平均值上下波动，形成正向分布的特征，波动的区间可以通过标准化来定位。产品本身可以设定三倍的标准方差，也就是99.7%的概率，所有的波动应该会落在三倍的标准方差范围内。但是即便在三倍标准方差范围内仍然会出现一些运维领域相当严重的一些问题，比如说原来是个波动态，突然变成一条直线了，或者以前是大区间波动，突然变成小区间的波动。我们在里边用到10多种不同算法来帮助我去定位在运维领域各种可能会导致业务出问题的蛛丝马迹。

3.5 多PKI认知分析

大比例的算法分析落在多KPI的认知分析，就是去理解指标与指标之间，类似人跟人之间的关系，会从行为上去识别出来，你跟他是不是很熟，还是第一次见面，还是跟他一直是固定的关系。

指标之间也是一样的，很多指标会呈现一个跟随关系，当某一个指标上升的时候另外一个指标必然会下降，而且几乎是在同一个时间呈现出这样一个规律。这是跟随，伴随的关系，但是不构成因果。我的原因可能是其他原因导致的，只是从行为特征上有一个跟随关系。

通过因果关系测试方法来定位的一些因果关系，去识别哪些跟随关系，其实构成因果。因果关系测试用的是Granger，里边有其他的算法来辅助。其实道理很简单，我们看两个指标，A和B指标，如何断定A指标和B指标构成因果关系，用因果关系预测指标未来走势，有理由断定A指标变化一定对B指标构成影响，只是影响的权重不一样。这是通过算法计算的。
并且影响不是单方向的，当B指标受A影响，导致未来发生变化以后会反过来会影响A指标的变化。只是权重不一样。类似这样一张神经原图式一样，每个节点是一个指标的话，红色的箭头代表影响的方向，粗细代表影响的权重。

3.6 运维方面的匹配

在运维上我们会有什么样的匹配呢？几乎所有的业务系统，像网银都呈现这样一个特征，它依赖的IT元素非常复杂，从物理设备、裸机，还有一些核心的数据库，需要高性能计算的这样一些能力在逻辑上。还有虚拟化、存储和网络，上面还构建了不同的应用和数据库存中间件等等。
每个IT元素内在都有一些反映本身健康与否的指标，而且经验告诉我这些指标跟其他IT元素或专业之间的指标一定构成影响，或者跟随。只是很难去细密度的把这些影响关系罗列出来、梳理出来。所以软件干的事就是帮我们细密度的定位，当然前提要有数据。

简单的道理只是有两个指标：业务平均响应时间和用户的并发请求数。对于自助银行，用户并发请求数越高，业务端到端响应时间会有变慢的趋势。这是很容易总结出来的。同时也知道当用户并发请求数并没有上升的时候业务响应时间是没有理由往上走的，甚至持续向上走的状态。算法会学到这样一个规律，是一个图象变化的规律，这个规律当某一个时刻被打破，连续6个采样周期里边超过3—4次都呈现背离状态，会立刻把预警异常发出来，而不是等到业务响应时间一直慢到业务人员或者客户投诉才去处理这个问题。如果走到中间就掉下来了，会自己去修正模型，并且去排查历史上是不是有同样类似的规律。

案例3

这是国内商业银行真实的例子，基于IBM结构化数据的认知分析来反向验证，在双11之前，包括双11之后所有相关指标的行为特征和规律。双11阶段有大量的指标脱离了平常的规律，这是很正常的，因为双11交易量非常大，但是在11月13号之间也有大量的异常，对用户来说没有办法理解。从各个不同的维度，从运维角度，从业务人员角度最应该关注的是哪些异常，或者体现异常的规律。

点击下去看到11月13号几乎所有异常指标都是集中体现在贵金属营运系统这样的业务，并且会直接给出指标的因果关系。最关注的失败交易数作为目标指标，首先这个指标是怎么样异常的变化？如何打破历史的波动规律，并且背后由哪些指标促成了它出现这样的异常。其中很重要的指标，一个是并发交易数以及交易总时长和交易时长，都在异常升高。并且还有两个NQ的交易队列，升到上面变成两条直线。

通过这一张图就可以定位失败交易数异常升高一定是交易量异常升高，从而导致了数据库，包括交易队列没有办法承受，达到极限。我们看短时间内又下降，经过几个小时以后又回落。回落的原因是大量的用户交易失败就不做交易了。

从银行本身排查发现，当时确实碰到这种问题，而且这个问题报出来是早上8点到8点半，而真正银行紧急事件是十点之后报出贵金属交易阻塞，反映出交易严重超时，相关应用全部重启，然后做限流。8点到8点半之间收到异常指标的变化后是不是可以有更从容的时间来通过一些紧急变更手段避免掉。从一些动态的数据，事件告警预知包括指标KPI可以做认知分析之外，其实IBM也在研究如何配合相对来说比较静态的一些数据，比如说依赖关系、承载关系等等。

4. 混合云端到端服务拓扑管理

所以基于此，今年是新推出基于OS17层拓扑实时跟踪。我们去管控IT基础架构到应用，有各种手段可以自动发现，可以跟踪、描绘出端到端的拓扑。7层拓扑会记录它的变化，当前一旦一个问题出现以后打开7层依赖关系，会再往前追溯，这个关系在什么时间点发生了变化，它会告诉你，也许是三天前，我的交易路径本来应该是走这几个节点，结果现在发生了变化，这个变化跟我当前遇到的问题到底是不是有关系。这个都是我们在认知分析当中结合的状态。

所以当异常出现的时候，可以上下文调出异常的路径特征跟历史变化的情况。这儿有一个历史跟踪，所有这些能力都是基于容器微服务设计和部署，所以速度和伸缩性都非常快。现在有越来越多的用户，尤其像金融的数据中心，包括运营商，他们会把很多管理云化。这也是IBM推出任何功能或者产品的要求，必须要能够微服务化的快速部署。

能够融合事件告警日志，整体的相关性分析，能够给出任何数据当中的关系，包括这些关系被打破前后，我们动态的事件告警和指标的异常跟我的依赖关系到底变化有没有一些关联性。

这是IBM总体的认知型IT服务管理路线图，这个路线图前面都提到了，从最早构建运维大数据平台，这个大数据平台不具备智能、算法和主动分析能力的，但是提供了认知分析最重要的基础，它能够帮我尽可能实时的拿到分析所需要的这些数据。

逐渐往上走越来越多的会融入AI的算法、分析，认知方面的技术，通过软件而不是通过人工或者其他工具提供的经验。这是结构化的，最终目标是希望能够帮助用户提供类似机器人一样的，它是一个专家，任何问题都可以问它，可以咨询它，可以给出最佳的答案，这个答案是依赖于背后的算法分析，包括实时对接的知识库，无论是IBM自己的知识库还是第三方的知识库，都可以形成一体化的调用和上下文的关联。

这个平台交互性很强，去问答，给出一些答案一定都有一些排名，跟所遇到问题的耦合度、紧密程度，关系程度，包括能够匹配答案的排名。以后IBM整个全球有一个跟用户紧密合作的项目，会把用户实际的经验、需求结合到IBM，在认知运维这个项目当中。