想不到！智能运维的正确姿势：从临场救火到淡然饮茶

晶少 2020-06-08 11:27:50 来源：量子位

一直以来，企业运维如临场救火乃是常态，如今喝着茶水做好运维倒有望成为“一件小事”，说到底还不是智能运维赶来帮忙？

啥是智能运维？如此神奇？

谈及“智能运维”的概念，洋气一些可被称为AIOps，正好是人工智能技术与基础运维能力的完美集合，一句话概括，运用机器学习的方法来提升运维效率。

稍微回顾下运维发展我们就能发现，在历经千锤百炼达成的传统自动化运维体系中，重复性、低效率的工作伴随着人力成本的消耗已经被得到有效解决，但复杂场景下的故障处理、容量管理等问题，依然需要人来参与；这种情况下AI的加盟无非让完全意义上的自动化果断进入快车道，加速没商量！

但不少技术小伙伴可能抱着这样的想法，AIOps不就是自动化运维与机器学习的强强联合吗？

话说哪有如此easy！

关于这两者，我们通常会将智能运维与通用人工智能拿来类比，“此智能”更倾向于事先预测，即了解错误数据马上会引发重要故障时采取有效措施避免或者减弱影响。

而针对这类预测性动作所涉及的数据处理，也正好发挥了机器学习处理海量、高速以及多样数据并带来高价值的专长。

如果从全球范围内AIOps产品的技术侧重点来分析的话，无外乎两种，即侧重AI方向与偏Ops一些。

很容易理解第一种。无非是将数据放入具体场景中测试判断AI技术是否可以更好的解决实际问题，在算法实验的过程中挑选合适的采用即可。

相比第一种，第二种则需要在整体的运维流程中预先判断瓶颈障碍，进而得出AI 技术是否可以将问题解决，可见这都不是两者单纯相加那么容易。

说完技术点再聊聊数据。

换个探讨角度，从运维数据出发，例如对于常规的硬件设备，包括开源基础软件在内，日志数据应该是最能展现当时其运行状态。

常见的关键词warning、 error、critical 等或多或少都可以反映出平常不太留意甚至少见的系统情况，进而发现潜在问题。

但如今现实中很多用户的运维业务与系统中的代码并不都是自己的研发人员写成的，更多的外采设备如果出现问题并不能及时得到解决，造成了“日志到手绝非想用就用”的状态，肿么办？

一般在这种不知道具体源码的情况下，通常利用无监督聚类的方式完成反向推导，就可大致获悉日志在实际中的代码操作情况，尽管不能做到百分百还原，但也会最大限度预测出发展逻辑，只需目标明确再加额外关注即可在故障预判中做到事半功倍。

目前无论是智能运维中的监控指标还是在日志分析，运用AI技术最简单的方法就是使用一些非监督学习的算法，例如聚类算法，即Cluster Analysis，也被称为群集分析（将相似对象通过静态分类的方法分成不同的组别或者更多的子集（subset），这样让在同一个子集中的成员对象都有相似的一些属性。）

尽管在具体的运维场景中，仅凭如今的机器学习水平暂不能将每条路径都做到灵活使用，但异常检测方向还是落地频次较高的。只要具备足够的运维数据支持，在调用链基础上的拓扑与图谱推导都会被华丽丽的实现。

高屋建瓴一下，在神奇的AIOps场景中，数据已然成为中心资源，将运维各种状态信息转换为大数据的过程中，机器学习在基础上完成相应的分析，全流程就ok啦！

在智能运维的大盘中，机器学习技术与各类运维数据，都不可缺。

深入分析运维数据的那些事儿，我们发现其实在实际操作过程中，运维数据主要分动静两态，以运维大数据平台为例，通常部分静态数据可直接加载在内心数据库中，并保存在结构化数据库或者Hive平台。

相反，主要包含各类监控指标数据、日志数据以及第三方扩展应用所产生的动态数据，一般是实时生成并被获取作为基础数据，过程中需要通过数据清洗转换成可使用的样本数据。

其中日志数据概念尤其广泛，机器产生的文本数据与具体数值都算；但涉及到场景的细分，用于监控的指标数据才会被经常使用到，例如调用链数据等。

以日志为代表的动态数据一般按不同的使用场景保存在差异性的大数据组件中，例如用于分析的数据会优先保存在Hive数据库，用于检索的日志数据可保存在ES（即Elasticsearch）中，当然业界也有进行ES改造或者替换的情况，例如日志易Beaver。

Beaver作为一个由C++语言编写的高性能、分布式、时序数据库，对包含日志及指标在内的各类时间序列机器数据采取分词索引、列式存储等方式，实现实时全文检索、时间范围查询和统计分析功能，同时也支持时序数据特有的滑窗函数、关联查询等功能。

 聚焦具体的采集过程，以日志易为例，数据类型不太会影响具体的采集过程，只是会对采集之后是否用于异常检测或者根因定位的算法加以区别，数据能否在合适的位置产生恰当的作用才是重点。

“我们的智能运维更多是定位与分析，利用日志数据指标去定位故障并进一步驱动相应的自动化运维工具来修复，这也是业务运维的重点。”智能运维领域资深技术人，也是日志易产品总监的饶琛琳说道。

以运维排障解释，排障关注的并不是每个设备的情况，而是顶层业务运行的概况；简单来说得到一个总告警是无用的，更多是深入底层不同的模块系统加以判断。

比方说将不同的平台日志拿来进行快速查询，但如果采取对查询结果的一一尝试所消耗的时间成本就很巨大；相反若将搜集数据聚集，通过性能强大的搜索引擎过滤，再进一步凭借AI算法完成结果分类的几种模式，如此一来上千万条日志就会被“萃取”成几十条结果，时间成本大大降低。

如此说来，刚刚提及的“萃取”理念倒是与日志易Lynxee系统技术初衷如出一辙。

有资料称，Lynxee系统应用其实是基于日志易强悍的数据检索平台功能，再结合前期丰富的自动化运维经验“锻造”而成的智能运维系统，目前主要应用在各类金融行业的用户群体中。

在Lynxee中，由于多种智能算法被提供用来自动判断运维指标的监控效果，就无需手动设定监控阈值，其中的异常检测会自动给出监控项目的健康分数，帮助用户主动发现和排查平常难以发现的问题。

但更多人认为，实践中的异常检测就像预测股票大盘走势一样，概念貌似不大，但实际难度却不小。面对这样的判定，日志易采用了“不断加定语”的方式来循序渐进降低应用的难度。

所谓“加定语”其实是更好地运用专业的运维知识，不断缩小异常检测的场景应用范围，指标细致到是请求量的异常还是响应时间异常等，从而进一步明确预处理的工作内容。

比如性能瓶颈被检测出来后，就可以对这部分进行代码优化或者定向扩容；如果预测出来是设备故障，就可以着手更新设备；而故障预测可以帮助进行动态流量切换或者硬件替换等。

坦白说这种理念有点儿类似于“庖丁解牛”，从起初的目中全牛且无从下手，到后来的目无全牛，根据经脉切中要害并游刃有余，不困扰在某个具体的技术细节上。

“我们实操中的智能运维不单单是一个算法平台，而是基于成熟的运维知识构建的流程体系化，其中涉及服务设备概念、监控来源常识等，从发现故障到加持检测算法，然后定位故障全流程一栈式，用户并不需要过多挂心来源于算法本身的种种技术问题。”

对于经验与未来，不可否认，智能运维依旧存在很多令人惊喜的可能性。例如在成熟日志处理的基础上，提升算法的交互融合程度以及更多实际应用场景的拆分等，都是亟待完善的地方。

谈及前景，我们留意到，一直在IT圈以“权威”著称的Gartner的报告也曾作出预测：智能运维于2020年将在一半以上的企业中落地并贡献生产力。

作为传统运维与新兴AI技术的高度结合，且一度被誉为“朝阳产业”的智能运维，看起来前景一片大好，不错；但在技术成熟度上还有很大的提升空间，亟待被重视。

尤其是近年来得到云原生微服务架构的技术洗礼，不知不觉也产生了诸多新变化！

或许小伙伴们多少有些了解，过去大家考虑的是如何达成或者提升自动化运维水平，快速部署上线才是王道。

如今更多精力则集中在保证规模与满足微服务架构的运维监控方案的高可用性，简单点儿说就是可观察性。

毕竟在全面云化的条件下，因为体量规模增大，业务细分的颗粒度也随之提升，过程中难免会涉及到上百个接口的调用，这就意味着仅仅依靠单纯的性能监控指标远远不够。

而可观察性就是为了达成包括指标日志、调用链、变更数据等不同角度运维数据在内的统一，从各种维度观察服务运行的状态是否良好。

本质上可以算是传统监控概念的智慧升级，简单说就是用智能运维的方式解决微服务架构的基础运维问题。

正如饶琛琳所言，其实对于运维数据来说，架构创新只会带来写入介质的更改，比方说从本地磁盘过渡到对象存储。

这一点不像网络抓包，自身依赖的环境发生改变，整体的基础设施也就随之变化了。

据了解，日志易做的是“造福”业务运维团队的事儿，不同于传统数据中心基础运维，对于云原生微服务等一揽子创新架构上的应用支撑，其实早早就做好了打算。

但他也表示，就算门槛不高、本质未改，但适当的技术调整依旧是需要的。

毕竟新架构下的存储机制以及输出方式有了改变，迫切做好的是接入方式的合理适配与改造，以此确保动态调度的时候，不会影响数据采集的准确性。

过去在采集过程中，可能只需要一两个数据标签完成具体业务应用来源某台主机的区分。

但在弹性的云原生、微服务以及容器环境下，需要配合pod确保映射管理以及数据采集完整等细节，尽可能降低底层架构改变带来性能的差异。

目前除了像日志易一样的IT企业入局智能运维领域外，突破运维的智能化也成为有关科研机构的攻坚热点。

其中不仅出炉了有较为先进的科技成果，从算法层面上支撑发展落地；更重要的是已经与工业界展开了密切合作，例如卡内基梅隆大学与Netflix公司联手。

另外类似于以专业大数据搜索与可视化见长的Splunk，也将智能运维管理平台的研发视为帮助用户实时了解IT架构现状的利器之一，通过将机器学习的数据加以转化形成有价值的运维建议广泛传播，同理还有科技巨头IBM以及华为等。

当然，在高利润、高技术含量的驱动下，互联网巨头与金融行业也争相参与其中，比方说阿里巴巴针对智能故障管理平台的研发以及各类银行对于运维大数据平台的建设等。

尽管多方入局，但与之关联的企业级智能运维建设，除了具备全栈式运维数据的刚性条件外，更重要的是寻找颇具痛点的场景来入局尝试，避免直接使用标准的算法通过黑盒方式解决问题，目前来看异常检测绝对是首当其冲的应用场景。

这样来看，无论企业从运维数据中台建设还是从规模较小的场景化切入，运维数据的治理能力与质量提升以及机器学习技术的合理应用，都是加快智能运维发展的一系列必备因素。

谈及智能运维的将来，饶琛琳认为AIOps早已声势浩大，让运维更加智慧便捷，没什么不可能……