浅谈智能运维
现在智能运维很火，很热门，大家都在研究这个课题项目。在国内学术界，清华大学裴丹教授已经
研究此课题一年有余，也在APM大会上进行了相关落地的阐述。在国外工业界，SIGCOMM 2016大会，
微软提出基于数据中心的故障定位方案，先用实验床把所有可能故障都模拟一下，同时收集各类监控
指标，然后通过机器学习建立模型，这个模型可以根据实际发生的监控指标的症状， 推断根因的
大致位置，以便加速止损。 在相关文献中用到的基础算法包括随机森林，故障指纹构建，逻辑回归，
马尔科夫链，狄利克雷过程等方法来进行故障定位。
智能运维的目的
这是很重要的问题，运维，一个老生常谈的词，不管是互联网系统或者是通信信息系统，运维始终是避免
不了的话题以及项目问题。智能，最近很火的概念，包含了数据挖掘的最新学术和工程成果，通俗的
说就是 分布式运算平台 + 数据挖掘算法。
之前看到过很多说法，跨领域的合作会产生意想不到的效果，那么 运维 + 数据挖掘 + 分布式计算
三者结合会产生什么样的化学反应？答案是 智能运维。因为运维包含了一系列人工经验判断，对新手
来说，运维是大量的经验知识的学习以及后期不断的运用与实践，而对经验丰富的人来说是枯燥的，
除非有新的异常故障的挑战才能激发起斗志。那么这种工作的特色显然很适合计算机，前期的学习
很“高效”，后期也能“高效”地根据前期的经验直接给出根因以及解决方案甚至自修复。那么学习和推断这对于计算机
而言是很难直接来的，它不像人脑可以神经化的思考，只认识0和1，所以这时候的数据分析算法就成了
大脑神经系统，多台分布式的计算机运算资源就成了大脑本身架构和运算载体。用机器直接替代经验化
的人力，不单单是回答如何解决故障问题，重点是做到快速应变，提前预测警告，消除突然间的服务
宕机下线，影响客户体验和业务，除此之外还能进一步做到系统运行状况反馈，对业务系统的改进提供辅助功能。
智能运维的初步探索与初步实践
初步探索
刚开始的时候也是无从下手，只能从简单的协议入手，先去找出故障然后进行展示，这个阶段是
初步了解协议以及对协议故障进行显示，算是业务的了解和熟悉，期间也出现很多的坑，比如远程登陆设备
通过display命令查看信息，通过固化运维步骤形成脚本，事实证明这不是一个有效的手段，因为在通过
远程查询之后发现，得出的结论已经反映在日志的reason和subreason当中，也就是说远程查询费力
不讨好比如远程登录很慢、很多信息简单的display是无法得出的，所以我们很快就放弃了远程登录查询
采用对日志进行分析的方案，早期的日志只是针对固定协议日志进行筛选然后展示出来。
初步实践
探索之后方向已经很清晰，需要进行下一步实践，紧抓日志这个信息点，然后向四周扩散，那么问题来了，
如何才能很好，全力的挖掘出日志的内容？
压缩or根因
有了日志，也就是有了数据如何才能得出根因，这是智能运维的目的，确切的说得出根因很难，
首先没有完整的故障传播链（也就是故障树），其次是没有历史定位问题的记录，也就是没有可以学习
的信息。在和公司一位做数据挖掘的博士同事进行过交流后计划采用随机森林的方法进行故障的根因
分析，很巧合的是同时又有另外一个小组提前对日志做了简单的聚类（这里感谢公司强大的资源），这时候
我们才意识到压缩也许是根因前的一步，简单而言就是退而求其次。
分析故障or提前预测
由于没有历史kpi指标，虽然可以根据snmp去采集但是现阶段没有去做，没有kpi指标也就是没有大量
有价值 的数据，就是说无法做到提前xx小时预测，现阶段主要做日志压缩和及时根因分析，预测是
后面要做的事情。在裴丹教授APM2017的那篇演讲中其主要突出KPI指标(ps:这里值的一提的是裴教授在演讲里面讲到其实验室与百度系统部合作研究的项目是交换机故障预测，正符合我们的场景)，围绕KPI指标进行预测，首先是异常检测，先收集KPI指标然后预测（这里裴教授说了三种机器学习方法）其属于哪种KPI异常模型，然后再由挖掘出的事件与KPI关联
关系找出对应的事件，再由事件关联关系和故障传播链找出根因，这是一条清晰完整的思路。基于裴
教授的研究报告的启发，再结合微软提出的实践论文，我想我们可以做下面的步骤，模拟实验床，然
后产生学习数据，然后进行人工标签，接着进行预测，结果进行反馈，算是一种半监督学习模型。
由于KPI指标数值可以预测，所以可以进行故障的提前预测，但是根因分析却是一个事后分析，不过我们可以实时的分析。
系统雏形
系统雏形很简单，对各种数据源做适配，然后根据聚类出的关联关系去除无用告警并压缩，
及时根因分析则在过滤出警告信息后实时进行。