传统的监控工具能够定位问题，缩短平均修复时间；而认知功能则能更进一步，缩短实现“了解”所需的平均时间，找到问题的根源，确定问题出现的位置，并预测问题再次出现的时间。 本次分享将探讨如何将认知计算与运维管理有效结合，达到如下目的： 1、快速搜索 TB 级的结构化和非结构化数据，缩短平均修复时间 2、更快地诊断问题，并缩短问题查询周期时间 3、了解环境中的异常行为，避免服务中断；并在服务中断之前，主动收到全新运营问题的通知 4、利用高级故障单分析、热点洞察力和故障单分类所需的决策支持，进而提高IT运营效率

做运维其实是在做一些应用方面的应用，是把理论进行应用。日常工作中，还是不要放弃对理论的了解，这样才能让我们的日常工作保持有序或者良好的结果。

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

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

认知计算运用于众多领域，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 虽然是内部的 project，也欢迎外部企业参与，共同进步。

在传统运维管理领域，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的告警通知微服务。