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

彭小阳

苗宏涛:来自去哪儿网站运营中心技术保障部，今天我和大家分享的是《智能故障预测与应用健康管理实践》。

一、OPS的目标

首先对OPS来说，应用的运维工作目标有两个，一个是减少应用的故障产生，另外就是让应用尽可能长处于有效状态。

应用有效标准基本是由业务线制定的，需要注意的是有效性和业务线的定义中通常包括服务降级或者启动备份、冗余系统后仍能提供有线服务的状况。这种情况在业务线定义中还是认为有效的，对于OPS来说这种情况非常危险，距离故障只有一步之遥。
举个例子，一辆汽车在紧急制动下爆胎了，虽然车停住了，但是轮胎失效了，OPS应该就识别、控制、修复这种失效。作为运维方不应该采用这个概念，以及这个概念下的指标，应该制定故障标准，明确失效边界，便由此明确可靠性不良方法。
明确故障定义以后当发生故障以后要快速修复故障，使得应用恢复到标准能力输出，恢复故障包含定位故障、隔离故障和解决故障的步骤。

如何完成上述目标呢，这个公式就能说明，运维工作的根本使命就是提高系统和应用的可靠性、可用性。
如何计算可用性呢？我们引用可用度这个指标，就是常说的几个九的问题，为了方便我不用可用度、可靠度这种学术词语，统一用可靠性大家熟悉的名称。可用性主要是通过公式计算出来的，通过这个公式大家就可以直观看到提高可用性是围绕两个指标。
第一个是平均无故障工作时间，这个很好理解，就是正常工作越久越可靠，对于运维人员也是越轻松的。第二个是修复时间，故障不可怕，可怕的是长时间不能修复故障，修复时间越短对于提高可用性越有帮助。所以OPS的日常工作就是尽量延长无故障工作时间，尽量缩短修复时间。
说点题外话，关于应用可靠性应该达到几个九，问题比较复杂，各种说法都有，其实我们勤劳祖先已经告诉我们，一九二九不出售，一个九、两个九的指标拿不出手，三九四九冰上走，达到三四个九还是非常危险的，特别小心失足可能性。五九六九河边踏青，达到五个九六个九就可以去踏青了。
对故障我们可以分为已发生故障和未发生潜在故障。首先说一下已发生故障，这就是我们通常意义上的故障，面对已经发生的故障，刚才说过OPS两个职责，延长无故障工作时间无论如何达不到了，能做的就是快速修复故障。

如何达到快速修复鼓掌能力呢？经验就是这三点：首先，精确定位是关键。互联网应用复杂度非常高，主要体现在软件、硬件的结合，系统间的依赖、中间件、数据库、网络以及认为操作失误等等。
故障定位的关键是梳理出这些关系，从而从故障的表现追溯到故障的根源，精确梳理出这种关系是十分困难的，但是一旦理清这些关系，带来的利好也十分巨大。
为了能精确快速定位故障，我们采用一系列手段，监控和报警是基础，即时有效、准确报警，能给故障解决争取到很多时间。去哪儿的监控包括系统指标监控、业务指标监控、日志采集和分析。
定位故障首先做的是隔离故障，不让故障扩散开形成更大的故障，降低损失，保证正常业务正常使用。
什么是最重要的业务呢？对于去哪儿来说就是影响订单、支付、转换率以及会引起客诉的业务，故障隔离一般采取服务降级、限流、熔断等业务开发方的手段。同时OPS也有一些手段，主要是硬件隔离、网络隔离等等。最根本的还是要快速解决故障，出现了故障要快速动员相关人员。
去哪儿根据故障等级确定动员规模，一般来说QA开发产品都是要被快速召集起来的，我们有基于去哪儿内部及时通信QTalk，通过QTalk工具开发自己的故障机器人，故障机器人根据上访人员快速拉群，将相关人员快速召集起来进行沟通，并且定时搜集故障，直到故障解决。
对于故障在规定时间内没有解决的，我们会升级到更高的管理者，以便动员更多人员处理故障。然后就是要有故障预案，在去哪儿工程师入职的时候就要进行工程师处理培训，做到故障流程的周知，同时日常也会定时进行一些有关故障处理活动，业务线也会对故障进行演练，基础服务会有值班制，制定了SOP保障任何人可以做到依靠文档就可以处理大量已知问题。

最后就是要有一系列工具支撑，运维自动化是一件需要持续进行的事情，没有自动化一切运维都是空中楼阁。自动化一定是全自动的，是一键触发的，中间无需人工干预，自动上报状态，自动触发动态切换。
比如IDC网络故障，我们会侦测网络故障并自动将流量切换其他机房，并且侦测网络恢复以后将流量也是自动切换，比如快速扩容、请求突增的时候，我们可以做到数分钟就扩容以及发布，有了这些工具的支持，才能快速解决故障。
以上三点是处理已发生故障的重要步骤，本身也是有递进和依赖关系，想要介绍处理故障时间，做好这三点是非常关键的，也是我们付出很多心血的。
故障发生了，无论准备多么充分，都是被动的，根据可用性公式计算，解决得再快也会对可用性计算有影响。如果能在故障发生之前就把故障扼杀在萌芽中才是最好的，常见的故障预测包括容量预测，这也是最简单的，并且在基础运维中已经有了很好的实效。
比如对磁盘空间、ST卡寿命、带宽占用、预警等等，故障预测和健康管理是这个演讲的主题，也是我具体要讲的。具体讲之前我要阐明一下我的观点，故障预测是复杂的，同时也是需要很多前提条件和技术经验积累。
现在大家都知道，大家都在谈人工智能、机器学习，运维也进入AIOps时代，但是从互联网这几十年运维实践告诉我们，一步一个脚印，踏踏实实工作才是运维人员应有的品质，弯道超车大部分情况下是危险，实现AIOps没有捷径也不能跳过。

二、Qunar运维演进

下面我要讲去哪儿运维路径也是想给大家提供思路和例子，希望大家认识到实现AIOps要经历什么。

去哪儿运维演进经历三个阶段，第一阶段是人工半自动阶段，主要是业务方为提工单、/邮件方式进行人工审核。从事OPS主要是人工处理夹杂自动化脚本，最后是通知业务方检查，过程效率低，沟通成本极高，知识无法沉淀。
第二部分进入运维自动化阶段，统一公司资源，建立CMDB叫OPSDB，建立自己监控平台，这个监控平台搜集全公司机器系统指标以及各业务部门业务指标，建立了自己独立的自动化工具和平台，并且有自己各个审批工作流以及内部沟通工具QTalk。
第三部分建立去哪儿Portal平台，将资源、CICD、监控、日志进行集中管理、统一入口、统一认证授权。建立appcode对应用全局唯一标识，对应用进行全生命周期的管理。

基于去哪儿运维的现状，我们总结了针对故障处理不同阶段的处理，故障结束后要对故障进行review，最主要是找到故障原因，作出整改措施，保障不被同一块石头绊倒两次。
有了整改措施还要监督实施，不能只停留在纸面上，并且要在限定的期限内完成整改，同时要把每个故障入库，以便后期统计和信息学习，随着故障的积累，我们可以分级哪些业务线故障率高，在什么地方容易出问题，以及能从这个故障中产生什么提高系统可用性的需求。
同时甚至可以发现哪些人更靠谱，对于人员培养也是有一定的参考。去哪儿目前主要运维重点还是在于处理已发生故障，对照前面说的，对于已经发生的故障主要是定位，定位主要靠监控和日志分析。
此外，我们会汇集公司范围内的运营实践，比如应用发布、配置发布、数据库变更等等，这些运维事件对加快处理故障恢复有十分重要的作用。举个例子监控发现订单量下降，这个时候订票系统依赖的某个服务也发生异常，不需要定位原因直接回到刚才的发布就可以恢复故障。
这种处理还是建立在之前说的完全梳理清楚应用依赖关系基础之上。根因分析需要更多数据支持，尤其是在复杂的系统中，故障原因往往不是一个，而是一种连锁反应，根因分析比较依赖日志分析。
去哪儿系统调用主要是HTTP和double，去哪儿也是double的用户，我们可以清楚分析出远程服务调用的依赖关系。除此之外我们中间件、QMQ进入所有的关系，有了这些数据分析定位故障源清楚很多。利用机器学习模型才会是如虎添翼。

三、故障预测

故障预测是目前正在尝试和准备重点攻关的部分。说到正在大力攻关的应用故障预测以及健康管理，这个概念不是我发明的，也不是现在才出现的。这个概念从提出到现在也有将近30年，如果从雏形出现到现在应该有半个世纪了。

PHM在工业界已经应用得非常广泛，这里简单给大家介绍一下历史沿革，又是美国，又是NASA，90年代初NASA提出飞行健康监控概念，主要面对的是飞行器，这个时候没有预测只是监控。
到了90年代中，监控上升到管理，而且也是综合系统的管理，这时候意味着处理的系统更复杂了，关联性也更强了，同时也不仅仅是监控，要对监控结果作出判断和管理。

随着90年代末GSF项目启动，PHM理论正式形成，并且从航空领域迅速延展到整个工业界。目前我们知道已经在是使用PHM包括军工、航天、高铁、桥梁、民网航空。
我国在50年代初已经有了可靠性工程专业，一直服务于航天领域，对我国航天几十年来一直没有掉队起到了非常重要的作用，同时高铁、高架桥是我国近几十年特别拿得出手的工程，PHM在里面起到非常重要的作用。
PHM已经在工业界运用十分成熟和广泛，我们就想能不能直接利用这种理论指导我们的实践呢？我们知道工业和互联网领域还是有很大差别的，能不能直接拿来为我们所用。

我们从三点考虑，首先是我们的目标是一致的，都是避免失效，提高应用可靠性，只不过工业界面临更多的是装备，我们多的是软件。工业装备发展到现在其中软件成分也是越来越多，这一点我们目标是一致的。
第二是理论完备，互联网领域往往注重实践、理论不够完备，问题也随之而来，最佳实践只是在某些特定条件和环境下才是最佳的，一旦脱离环境就不一定适合，而理论之所以称之为理论就是放之四海而皆准。看到我们现在具备的技术是否足以支撑把理论转化为实践。
PHM的基本原理就是使用大量传感器采集数据，再进行加工计算预测故障，看一下我们现在的技术积累，大数据流处理已经很成熟，机器学习也开始普及，技术上我们判断也是具备条件的，基于以上的判断我们开始了自己的实践过程。

这是一个工业领域的典型故障预测模型，首先简单介绍一下，大量的传感器搜集数据，进行数据预处理，进行数据传输，再从数据中进行一些特征提取，对状态进行监测，最终会根据故障诊断的一些预测故障点，结合历史统计数据、产品参数和模型，最终形成故障决策。

故障预测有几个典型模型，有基于状态的，我们监控和报警就是明显的基于状态的。有基于异常现象的，通过历史监控和当前指标的对比，采取异常模型，可以识别异常的出现。还有基于环境的，我们运维实践是针对环境信息的。还有损伤标尺信息的。我们主要用硬件厂商给的可靠性参数。
结合这些模型就可能预测出故障即将产生，并且采取相应措施避免故障的出现。
实施故障预测是否有效，要进行评估，评估可以从这三方面着手。

首先是及时性要求，我们最期望就是在故障发生前，识别出故障风险加以修整，至少也要在故障发生的1分钟之内识别故障，否则就失去了预测的意义，这个我们还在探索。
另外是经济性要求，也就是花费在故障预测成本包括人力设备要小于故障带来的损失。第三个是最重要的，对故障预测要可评价、可验证。一个显而易见的逻辑上的问题，没有发生故障怎么能确定避免了故障呢？这是难点。
目前我们只能采用回访和用户反馈的模式，其实效果并不是太好，这一点我们也还在探索，希望在座各位能提出一些自己的看法。

四、Qunar的实践

首先讲一下去哪儿故障预测流程。

第一个是指标采集，这一块主要采集的是机器指标、机器报警、业务报警、日志等。
第二个是对数据进行预处理，主要做一些平滑、去毛刺的处理，对报警的闪报进行过滤，对玻璃报警进行过滤，总之保留重要特征，去除杂波。
第三个阶段是故障诊断，通过对数据的分析，主要分析出哪些指标是故障指标，也就是说，这些指标失效马上会产生故障，这些指标才是我们重点关注的指标。第四是故障预测。故障诊断会定位到多个潜在点，得到故障只是故障的表现，根因在哪里并不知道，这个步骤就是分析出故障根因，从而定位到故障的根源。
下一步就是通过各种手段通知到相关的应用负责人，这里主要是通过内部的及时通讯QTalk做，紧急的时候也会用到短信。
最后一步，在处理完成以后，我们要搜集用户反馈，对这次预报的准确性、及时性都要有评价。

我们对预测指标的标准有四点，完整性、客观性、真实性、有效性。
基础指标和报警通常是客观的，有问题就是有问题的，关键业务指标也会很直观反映出故障，比如订单量、支付、查询量，这些指标可以直接使用，还有一些指标容易受到影响，比如一个业务的逻辑修改导致某个指标变化很大，对OPS来看这种变化属于异常，业务看了是正常变化，不是异常，这就很难办。
对于业务监控主要看业务的报警信息，因为报警阈值和策略是业务方自己定义的，他们很清楚什么情况下是有问题的，应该报警。
各种日志也是重要的指标来源，在去哪儿我们主要通过NG的日志和double日志就能分析出系统目前的可用状态以及响应时间等重要指标。
后面就是要明确应用的关联关系，这种关系包括静态和动态的，静态关系主要通过服务治理系统获得，但是光有静态还不够，我们还要看在故障发生时故障动态。还有运维事件需要在统一的地方看到全公司现在有哪些运维事件正在发生，比如网络切换、数据库变更等等。这些对判断故障来源也是有非常重要的作用。

故障预测方法有四点，第一个是策略和阈值，静态阈值主要是根据经验值设定的，我们还可以通过周期性的计算动态调整阈值，还可以根据个人指标的综合策略进行判断。同
时对周期性指标进行同比和环比检查，要做一些平滑、去毛刺处理，排除历史故障时期指标，要对这些指标进行补齐。
故障预测模型使用的机器学习模型主要是以趋势预测算法和异常检测算法为主。
最后故障预测要沉淀到知识库，在故障完成检查后，还要对现在故障进行匹配，现阶段我们需要验证检测出的故障是不是真的故障。

故障预测之后还要进行故障预测反馈，没有反馈就不知道预测是否准确，必须对反馈形成反馈的闭环，反馈这里面主要是总结的四点，第一个是机制健全，要自上而下建立规范和制度，提高全员对可靠性的认识，同时我们要保持渠道畅通，通过技术手段建立多种方便的反馈渠道。同时要对反馈反应及时和迅速。

这是我们运维实践平台其中一个健康看板，报告出来的就是我们预测出来有问题的应用，同时我们会把相关联的报警以及运维实践全部整合在一起。从健康看板看，就可以看到应用相关信息，看到这个应用以及其他服务之间的调用关系。
在运维实践平台，我们会把所有发生的事件包括报警、发布、变更全部汇集运维事件时间轴，以先后顺序展现出来，通过运维事件时间轴可以看到去哪儿当前发生的所有事件。

这个图是我们通过对NG日志以及double日志实时计算做出来的关联拓扑图。我们不是凭空实现的一个PHM系统，而是在现有系统上实现的，没有这些基础工作就如同沙滩上建城堡。

首先我们建立appcode，appcode是全局应用唯一标识，无层级关系，统一标识各种资源，可以做到对应用全生命周期的管理。我们会把运维事件、监控指标、报警全部关联到appcode上面。

下一个是没有分级的话，我们就不能把有限资源利用到有价值的地方，我们对业务、应用、报警、运维事件进行分类分级，其中对应用和运维事件根据其对业务的重要性以及对应用健康的影响做了1-4级的分级。

报警作为预测的重要指标必须是准确和独立的，但是现实情况我们会遇到的滥设报警、无效报警、报警规则不更新，这主要是业务发展和技术迭代后没有及时做更新报告规则，还有报警接收人不清楚报警来源等等。
解决的方法就是做关联appcode，明确报警来源、明确报警接收人，明确报警管理者，对长时间没有结束的报警要做一些阈值的调整以及人员的及时培训，提供各种报警设置方法，比如单指标、多指标聚合、同批、环比、函数、组合，在内部进行不定期教育培训活动。

我们也对故障进行制度和流程，在建立故障的时候，建立管理制度和流程，包含发现故障、申报故障等等。
对故障上报做了标准化表单，通过故障机器人实现自动化，对故障级别进行相应的制定，在故障结束也制定了REVIEW原则和制定，将每个故障进行存档，以便后期的统计和分析，业务部门可以根据已经发生的故障做一些故障演练和培训。

五、前景与问题

最后和大家讲一下我们的前景和问题。

PHM在互联网行业遇到的问题总结有四点：业务变化快、缺少理论支持、缺少交流、技术治理等问题。业务变化快体现在互联网商业形态变化快，技术更新快、人员流动快。
缺少技术理论支撑主要体现在互联网有一定重实践、轻理论，不能很好形成总结，也不能持续改进，方向选择随意。缺少交流，不知道、不愿意、没渠道。

根据这些问题，我们的思考是，与工业界理论相结合，形成适合互联网业务形态的方法论，并且大胆应用于实践，不断试错提炼出有效的理论，结合技术发展、持续改进自己的方法，最终希望能够反哺工业界。