去哪儿智能故障预测与应用健康管理实践

本文根据张岩老师在〖2019 Gdevops全球敏捷运维峰会北京站〗现场演讲内容整理而成。

（点击“阅读原文”可获取演讲完整PPT）

讲师介绍

张岩，去哪儿运维开发总监，现带领运维开发团队，负责去哪儿网运维自动化平台、监控平台、管理平台的建设，长期关注并亲历AIOps发展。曾就职于方正、淘宝、Tripadvisor等。

分享概要

1、OPS的目标 & 工作

2、Qunar运维演进

3、故障预测与健康管理（PHM）简介 & 方法论

4、Qunar的实践

5、前景与问题

大家好，我是去哪儿的运维开发张岩。今天分享的主题是“智能故障预测与应用健康管理实践”，会根据我们公司的现状、所处的环境来提出一些思考，并利用这些思考产生一些方法，以及我们基于这些方法的实践。

一、OPS的目标 & 工作

1、OPS的目标

在去哪儿网中，OPS是一个大团队，这个团队里面有SA跟office的运维，包括我所在的运维开发，和计算APC的运维都属于OPS的团队。

针对故障这一部分我们OPS的目标有两个：第一，减少故障的产生；第二，快速修复这个故障。

1）减少故障的产生

在业务场景里面，有一种概念叫做“应用的有效性”，这个有效性指的是，当某一个组件出现了一个问题的时候，通过降级或者备份重启使用，包括一些冗余故障的上线，使这部分功能继续产生效能。

对于OPS来说，“何为有效性”的说法弹性非常大，也严谨。

举个例子，在路上开车时，如果踩了一脚刹车，这个车最终停下来了，此时拿这个情况跟业务的有效性比对，车停了说明刹车这个事情是有效的。

但对我们来说轮胎失效了，这是一件非常危险的事情，所以我们不认可这个有效性，我们认可的是可靠性。

因此，我们减少故障的产生，主要是要减少失效的产生，我们需要明确这个概念。

2）快速修复故障

如果细分的话，可以分为快速定位功能，控制故障的发散，最后再恢复故障。

2、OPS的职责

我们经常看到这个公式：可用度 = MTBF / (MTBF + MTTR)。

所谓可用度，就是我们常说的可用性的可度量的名词，比较严谨的说法就叫可用度。

可用度平均无故障工作时间除以平均无故障时间和平均修复时间的总和，计算出来的值是几个9，通过这个我们可以知道：要让平均无故障工作时间尽量长，让修复故障时间尽量短，这样一来我们的可用性自然就会越高，可能达到4个9，5个9，6个9。这就是我们公司OPS在故障方面的主要职责。

3、如何应对故障

故障无非分为两种，一种是已发生的故障，一种是即将发生的故障。

1）已发生的故障

 ① 精准定位

如何定位故障，是修复故障过程中最难的点，也是最重要的点。

因为众所周知，软件包括互联网的复杂度越来越高，复杂度体现了软件硬件的结合，各种中间件，包括一些数据库、一些消息队列、网络上的东西，甚至还包括一些人为的操作，都有可能造成故障。

在这么复杂的环境中定位故障点，是非常困难的，也是非常有挑战性的。

 ② 有效隔离

定位故障之后应该隔离，出现故障的第一反应是不让这个故障继续扩大。

我们在实践中经常出现一种情况，为了解决一些故障而产生新的故障，新产生的故障比之前产生的故障影响面还要大。

所以我们首先要做的是，定位好故障后，先把这个故障隔离开来，不让它扩散。

 ③ 快速解决

下一步才是如何快速解决故障，解决故障需要一系列工具，后文会介绍。

大部分已发生的故障，其实是我们日常工作中经常要面对的。

运维人员的重要工作不是快速解决故障，即使解决速度再快，也会把大家从睡梦中揪起来。

运维人员希望这个故障不要再发生，就要在故障发生之前或者有征兆的时候把它处理掉，在正常工作时间内把故障隐患解决掉，晚上就可以安稳地睡觉了。

2）未发生的故障

处理未发生故障，基本上要遵从以下几点：

 ① 容量预测

这是最简单的一步，也是绝大部分公司都会进行的一步。比如说，我的磁盘到了80%，可能要预警，要么提前把它释放掉，要么加新的硬盘；我的带宽到哪儿，肯定要扩容；虚拟机满了，要加机器。

 ② 故障预测

我们公司近一段时间内极力想要做好故障预测，要做到在故障没有发生的时候就去干预它，不让故障发生。

 ③ 健康管理

这是比较长期的策略。我们可以把健康管理理解为体检，我们每年都要做体检，体检的时候多多少少都有一些毛病，但是我们可能不会体检完了后立马进行治疗，可能会过两个月之后再去治疗。

这就相当于如何统筹管理应用的健康度，让它既不会发生故障，又能保持消费比较平衡的情况。

二、Qunar运维演进

我加入去哪儿有大概五年多的时间，至今，运维人员SA的人数保持在五六个，网络运维人员是两个，IDC网络工程师在大概三年的时间里保持一个人的数量，后来扩展到两个人。整个运维的一线团队控制在十个人左右。

我们处理的虚拟机有五万多台，实体机将近七八万台，利用这些人去维护机器，一开始是半自动的阶段。我们会提供OPS一些工具、脚本去做，并且会形成标本参考或者快速处理。

一开始业务方会提工单，进行人工发邮件，效率比较低。后来持续的时间很短，大概半年后，我们发现业务量提高了，这些人完全没法做这些事情。

我们自主开发了CMDB系统，内部称为OPSDB，同时开发了一个自由监控平台Watcher，统一了审批工作流，所有的流程都会在工作流平台内汇总。同时我们公司还自研了IM软件Qtalk。

在自动化运维部分，出现了一个比较大的问题：我们的工具平台非常多，而且会越来越多。工程师可以跳到不同的平台去操作，而且越到后来越发现，操作平台也是一个新的技能，一个新的工程师完全不了解这个公司，是无法熟练地操作的。

后来想到把所有的东西集中在一起进行管理的方法，也就是我们现在所处的阶段Portal。就是说，在一个入口里面做资源的分配，CI/CD、监控、日志、基础服务集中管理，统一入口、统一认证、统一授权。

另外我们还会应用全局的唯一标识，我们称之为AppCode，其用处如下，一开始出现问题后，我们会通过机器识别所在的应用，这样操作是非常零散的，而且只有使用者才知道是什么情况，其他领域根本不了解，而且相互之间完全没有变化关系，我们所有的资源，包括监控，全部都跟应用全局的唯一标识关联起来，公司里的所有基础服务全都可以跟应用产生联系。

最后是应用全寿命周期管理，随着业务的发展和变化，有些应用可能过了一段时间就没有了。

在之前的情况下，这种应用是没有人去管的。但是作为运维的机构服务，这种事是不能不管的，我们也不知道这些应用还有没有用，因此会耗费大量的资源和人力去维护一些不产生价值的东西。

后来我们对这些应用进行全面的清理，明确管理寿命周期，当它失效了，也就不会浪费资源，浪费人力。

手段和策略

1）故障事后处理

去哪儿网的故障事后策略做得相当不错。我们在每一个故障事后会进行故障review，相关责任人、相关责任方会找到故障的根源。

而且我们不是只进行故障review，在review之后还会提出整改措施，由专门的部门和人来追踪整改措施的情况，确保执行完毕。

最后把这个故障录入知识库。大家都知道，故障会产生耗费，所以我们要把这些故障保存起来，作为我们一个重要的财富。

2）故障实时发现

如果故障实时发现，要做事件关联，事件有很多部分，可能是运维的事件、BIS的迁移事件、发布事件和主机宕机事件，主要是报警事件。

通过这些事件的关联分析根因，获悉这个故障的产生地点，这就是前面所说的快速定位。

定位完毕后会快速地止损这个故障，我们手段有很多种，有业务方的止损方式，把它降级或者熔断，也有基础运维的手段，还有物理隔离，直接把它隔离开。

3）故障预测

这是我们一直在着力做的事情，下文会具体讲。

三、故障预测与健康管理（PHM）简介 & 方法论

故障预测与健康管理（PHM）是工业演进非常成熟的方式。

其历史演进如下：90年代美国宇航局NASA提出这个概念，最早叫飞行健康监控，90年代初是飞行监控，90年代中期变成综合系统监控管理，有多个系统进行监控，并且配合关系管理法。

90年代末JSF项目启动，大大推动了PHM的发展，PHM成为工业界中最有名的存在，战斗机的研发必须遵循故障预测与健康管理，PHM在工业界成为一个事实上的标准。

PHM已经完全应用于航空航天装备领域，不光是美国，中国也是如此。在中国，高铁和桥梁是把PHM应用得最成功的范围，尤其是在高铁这方面，大概在十年前，中国出过一次非常严重的高铁事故，但在那次之后，中国的高铁就再也没有出现过事故。

1、PHM应用于互联网领域的探索

现在我们在思考一个问题：把工业界的标准PHM引入到互联网这个领域到底行不行？

我们从各个方面进行对比：首先，互联网跟工业界的目标一致，都是避免失效，提高应用可靠性。

其次，要看给我们提供理论是否完备，理论是否能指导实践，我们可以看到理论非常完备，至少在一些主流的研究里面理论是非常成熟的，而且在中国比较著名的院校里都有专门的学科和专门的研究者，这些理论也已经在工业界被充分验证过了。

另外，要看我们的技术是否能满足，目前对大数据的处理技术已经足够了，尤其是实施计算、流式计算，现在也已经普及了。有了这些东西之后，机器学习和人工智能已经进入应用阶段，这个时候已经实现技术满足，所以我们准备尝试一下PHM在互联网的应用。

2、PHM方法论

1）流程

PHM在工业界的应用相当于传感器，采集完数据后进行特征提取，这是数据分析的流程，再进行状态监测和故障诊断，故障诊断是指，检测采集到的数据是反映出正常状态还是异常情况，再加上历史监测数据和产品模型（预测数据），就可以交给平台诊断。

2）模型

PHM的模型比较简单。

 ① 基于故障状态信息

对应的就是我们的监控报警系统。

 ② 基于异常现象信息

异常现象并不是指具体指标的好坏，而是指异常的表现。举一个例子，我们发现一台机器PCP连接数保持在100，这是正常的，突然之间连接数又上升到130、140，其实这个连接数不大，但是突然上升代表内在可能存在一些原因，这种情况则称之为异常。异常会不会造成故障，是我们以后需要研究的，所以需要采集异常信息。

 ③ 基于使用环境信息

使用环境信息是指在运行时间内发生了一些运维事件，比如说网络切换，有可能造成全局性质的故障。

 ④ 基于损伤标尺信息

这是工业界的说法，在工业界，零件出厂的时候需要告知零件损伤的信息，如，这个零件寿命周期是多长，零件可靠性怎么样。

做过服务器维护的话就知道，服务器有保修期，过保的意思不光光是指过了那个时间以后机器就没有人管了，更是指过保之后可靠性大幅度降低。

我们有一些服务器标出来的可靠性是有6、7个月，生命周期最顶峰1-2年，过了这段时间后可靠性就会大幅度下降，这个是针对硬件的信息，我们所做的软件也是有承载的日期的。

3）要求

 ① 及时性要求

要保证我们的预测能够在短时间内完成，预留足够的维修保障时间，保证以我们经验可以完成，否则故障拉长了，故障都已经过去了，预测就没有意义了。

 ② 经济性要求

预测的成本必须小于数据的损失，预测才有价值，否则花了很大的价值预测一个损失很小的故障就不划算。

 ③ 可评价验证

这里面有一个悖论，如果我预测到一个故障，怎么知道预测到底准不准，或者故障有没有发生，这是一个比较关键的点，就是结果有效性必须可量化验证。

四、Qunar的实践

1、故障预测流程

我们的流程如下：产生指标，采集业务指标、机器指标、报送信息、日志等做数据的预处理，再取出无效的信息，把一些突发指标钝化，后面进行故障诊断，我们会分析这些异常的信息到底会不会造成故障，排除外部因素对监控数据的干扰，最后进行故障预测，故障预测需要靠一系列的关联关系和一些模型去计算，最后得出一个健康的状态，把它通知给具体的人。

在这个过程中，通知是一件重要的事情，有时候我们会发现通知的人不是应用的负责人，发现发了很多通知之后没有人管，因此我们存在这样的机制，要保证收到通知的人一定能处理。最后得到用户反馈，形成一个闭环，然后再去预测。

2、预测指标的选择

这里面有个重要的部分，就是指标的采集。选择指标时有一个标准，中间一定是完整的，而且是客观、真实、有效的。

我们采取的是基础监控指标，比如CPU、内存、磁盘使用率等，还有一些业务指标，反映业务健康情况，我们公司主要是订单量还有转化率。

另外我们收集一系列日志，包括系统日志、中间件日志、业务日志。接着是报警信息，报警显然被认为是有问题的。再梳理信息的关联关系，有些关联是静态的，有些是动态的，静态的关联关系是业务方提供的，动态的关联是实时采集到的。

3、故障预测

我们的故障预测策略有以下四项：

1）策略和阈值的设置

我们应用静态阈值设置，这是最传统的报警设置方式，需要在里面放一个经验值。

另外还有动态阈值，动态阈值特别适合波动的情况，这种指标随着时间的推移会有周期性的波动，但是这种波动比较平稳，比如，我们应用的人比较少，白天人多一些，静态阈值不合适，肯定是用动态的阈值去调整。

另外还有一些指标检测，我刚才所说的异常的指标中，有些是长期出现的或者是不平稳的，或者处于长期波动的状态，与常规情况不符，就有可能引起故障。

2）历史数据对比

历史数据对比策略特别适合周期性、趋势性的东西。

举个例子，旅游行业的订单大概有几个，五一、十一、寒暑假，这一段时间订单量是最高的，平时的订单量会低一些，我们需要拿历史数据做一次对比，也就是说，预测出我们的业务在今年和去年没有发生大的改变的话，那趋势就是一样的。如果发现不一样的话，就有可能出现异常。

这里有件很有意思的事情，在五一前一个月发出了休三天假的时间，机票的购买和查询量没有那么大。

但是在今年发布五一要放四天假的时候，我们所有的搜索量和订单量都提高了，当时我们有些措手不及，我们认为那不是正常的业务高峰期，所以我们并没有准备那么多机器。

我们也是第一时间发现比较大的波动后，再扩容机器，顶住了五一的订单量。

3）预测模型

接下来利用前面的数值进行预测，用到以下几点：第一，指标趋势预测，我们会计算趋势，如果超过趋势的上下阈值的话肯定有问题；第二，时序异常检测，如果时秩数据短时间跟正常的数据发生比较大的波动的时候，我们就会认为这是有问题的；第三，事件关联分析。

4）故障知识库

所有的故障都要入库，入库之前要进行场景匹配，看看当时是哪里报警，或者哪些指标有异常，要复盘清楚，这些东西入库之后可以用来学习。还要积累运维经验，有些时候靠计算不能把运维计算好，需要靠人的经验，这是很重要的部分。

接下来看几个示例：

上图是动态阈值的示例，时间拉得比较长，如果时间比较短则是类周期的指标。

上下两条红线是我们根据波动的指标算出来的阈值，如果有一个旅社的线出来了，那就会触发一次报警。

上图是静态阈值，下面是两根红线是我们做的动态阈值，这个动态阈值是根据历史数据来做的差分值，用纯统计的方法来判断。大家可以看到中间有一些绿色的小尖出来了也会产生报警。

上图是趋势图，绿色反映的是真实的情况，红色是我们预测这一段时间的情况。

这里面还有几条线还没有画出来，表示的是红线预测时间的上下阈值，绿线表示的实际情况如果超出阈值，也会产生报警。

根据历史数据判断，这个时间范围稍微短了一些，如果拉到一年的话，实际上呈现整体向上的趋势，我们公司觉得至少业务是往上走的。

5）故障反馈

这是很重要的部分，我们要保证机制健全，渠道畅通，响应及时，反应迅速，最终反馈到我们模型上。

6）健康看板

上图的健康看板是我们系统当前的健康情况，我们有43个看板，红色的表示当前比较危险，但并没有产生故障。

7）健康档案

这是某个应用在这一段时间内健康的变化度，基本上处于比较健康的状态，但是在某个阶段里面小红点健康弱化，这个时候我们会点进去查看当时是什么情况，查看当时的调用情况。

8）运维事件时间轴

我们会有很多运维事件，将这些运维事件罗列起来，放在看板上就能知道整个公司运维的情况。

9）关联拓扑图

这张关联拓扑图是实时采集下来的。

10）基石

这些事情并不是我们凭空做出来的，而是靠很多积累才能做到的。比较重要的是应用分级，我们把有限的资源用到关键点上，业务分级也非常重要。

除此之外，报警有效性也很重要。

有些公司在做报警这件事时，很大的问题出在报警设置混乱，导致报完警后没有人管。

这个时候可以把问题归结为工程师的责任心，还有一个问题是我们没有给他提供很好的工具，这正是我们接下来要去做的事情，我们会提供各种各样的报警设置方法，有单指标，有多指标，做同比、环比的计算，函数的计算，不用工程师自己计算，我们帮他算。

还有故障记录，我们会收集坏的记录，才能对其进行学习。

五、前景与问题

1、PHM在互联网行业的问题

PHM在互联网行业存在以下问题：

• 业务变化非常快。具体表现为商业形态变化快，技术更新快，人员流动快，很难积累；

• 互联网行业缺少理论支撑。问题有：重实践轻理论，不能形成总结，不能持续改进，方向选择随意，可能十个人有十个的做法；

• 缺少交流。表现为：不知道怎么交流，不愿意交流，没渠道交流，相互之间没有契合点，形成成果困难；

• 技术治理缺乏。体现在：高层缺乏规划，主要看业绩，对于健康治理方面重视程度不够，中层缺乏决断力，基层缺乏数据分析能力。

  
  

2、与工业界的关系和互动

我们的愿景是希望跟工业界结合，毕竟工业界有非常好的东西，这其中有很多是我们不知道的，因为现在我们是在创造新东西，而人家都已经有十几年的经验了，我们要和工业界理论相结合，形成适合互联网业务形态的方法论，再把这些东西勇敢地应用于实践。

我们还要不断试错，提炼有效理论，结合技术发展，持续改进方法，最终这些东西反哺工业界。

Q & A

Q1：张老师，你好，我想问一下，能不能详细介绍一下预测的结果验证这一部分？

A1：我们是这样进行结果验证的，先跟业务方复盘，如果我们预测出来一个东西且认为这个东西是有效的，这个有效应该体现在两个方面：

第一，预测到这个东西导致了一个故障，另一方面，我们会提供故障报告，你拿这个报告跟这个应用进行比对，如果可以对上80%，那么你的现状就是这样的。这样的话，双方预测的复盘有些指标可以对上，有些指标则对不上，对不上的可能就是无效的指标.

第二，可能存在误导的指标，达到这些指标之后，去做模型建立的时候，把它的特征值做一些传值调用或者降低，不断地迭代我们的模型。

Q2：不太理解这个复盘建立类似的环境。

A2：主要是靠人工，不是自动的，需要两个团队一起对照这个东西，看看我给出的这个报告和你当时自查的情况是否是吻合的。

Q3：张老师，我也问一下关于故障预测的问题，大家都知道故障方面的预测主要跟业务相关，现在发现出来一个业务的高峰，从这个角度上是正常的，不知道咱们做这些模型也好，或者规则也好，业务的突增导致的指标变化？

第二个问题是，如果这样做的话，我们业务变化的指标需要考虑哪些方面，怎么样获取业务变化？

A3：预测结果不是强制要业务方认可的，于是我们跟业务方一起合作。业务发生变化时，这个东西相当于是提醒，而不是强制性的指标，会认为出现业务变化有问题。

一般这种情况有两种：第一种，这个吻合指标上去了以后，对它的应用是没有任何损坏的，流量是够的，调整成模型状，其实这个调整的权利在于业务方，也就是说，业务方其实是可以进行调整的。

第二种情况偶尔发生，它的容量是够的，但是存在代码有bug，导致容量上去了之后处理不了的问题，这种情况是存在的。

如果是一个孤立的事情，我们不会太关注，但这不是一个孤立的事件，所以这种情况我们一定会反映到具体的业务指标，或者叫商业指标，我们每一个产品都会有几项老板关注的指标。

举一个例子，他会关注订单、支付、转化率，有可能只有影响了这些指标，我们才会认为出现了比较大的故障，如果没有影响这些指标的话，就属于比较健康的故障，不是需要重要解决的问题。

第二个问题，我们每一个重要的指标是由业务方来敲定的，他来告诉我们哪些指标是重要的，因为每一个团队关注的东西不一样，有些关注订单，有些关注应用容量的指标，我们要把这些指标全部收集起来。

刚才提到我们这些指标是需要分级分类的，不会一视同仁，一视同仁会造成大量的bug出来，导致一些莫名其妙的情况。

Q4：谢谢老师的分享。我有一个问题，这个预测是基于现有的指标和一些数据来进行统计分析的，在统计分析的时候，可能基于以往的数据来做比对。生命周期收集过很多数据，随着数据的增长，生命周期管理是什么样的，数据增长很大的时候，会不会给预测性能带来一定的影响？

第二个问题，历史监控数据量对于预测非常重要，保存如此大量的历史监控数据，存储上市是如何处理的？如果预测基于以前的数据预测，随着数据的增长，预测的时效性是不是会打折扣？

A4：首先我们有两部分的数据，第一部分的数据是一种算是知识库的数据，我刚才所说的故障的成因，如果数据不是非常大的话，是会一直保存的。

还有一种数据，就是刚才所说的跟历史缓比的数据，有些历史的数据是不保存的，它们没有太大的价值，主要判断它的周期是什么样的。

比如说有的时候数据周期以年为单位的，只要保存前几年或者两年的数据就足够了。有一些周期却是以周、天为单位的，保存的数据就更少了。

而且我们会对数据进行统计压缩，我们现在几乎所有的指标保存的数据都是实时指标保存一年的数据，但是对之前的数据会做一些压缩，我们的指标分时间段保存，一年以后压缩到5分钟的采集，5分钟的数据做一个加权，算一个数据，这个数据的量很小。根据我们的经验，这个数据超过一年以后，它的数据时效性不是就很强了。

了解更多智能运维落地

来Gdevops听听名企大厂的实战亲历

↓↓扫码可了解更多详情及报名↓↓

2019 Gdevops全球敏捷运维峰会-广州站

↓↓↓ 点这里下载本文PPT