盘点准时播|想不到！智能运维的正确姿势：从临场救火到淡然饮茶晶少发自凹非寺量子位报道|公众号QbitA

晶少发自凹非寺量子位报道|公众号QbitAI
一直以来，企业运维如临场救火乃是常态，如今喝着茶水做好运维倒有望成为“一件小事” ，说到底还不是智能运维赶来帮忙？
啥是智能运维？如此神奇？
谈及“智能运维”的概念，洋气一些可被称为AIOps ，正好是人工智能技术与基础运维能力的完美集合，一句话概括，运用机器学习的方法来提升运维效率。
稍微回顾下运维发展我们就能发现，在历经千锤百炼达成的传统自动化运维体系中，重复性、低效率的工作伴随着人力成本的消耗已经被得到有效解决，但复杂场景下的故障处理、容量管理等问题，依然需要人来参与；这种情况下AI的加盟无非让完全意义上的自动化果断进入快车道，加速没商量！
但不少技术小伙伴可能抱着这样的想法， AIOps不就是自动化运维与机器学习的强强联合吗？
话说哪有如此easy！
关于这两者，我们通常会将智能运维与通用人工智能拿来类比， “此智能”更倾向于事先预测，即了解错误数据马上会引发重要故障时采取有效措施避免或者减弱影响。
而针对这类预测性动作所涉及的数据处理，也正好发挥了机器学习处理海量、高速以及多样数据并带来高价值的专长。
如果从全球范围内AIOps产品的技术侧重点来分析的话，无外乎两种，即侧重AI方向与偏Ops一些。
很容易理解第一种。无非是将数据放入具体场景中测试判断AI技术是否可以更好的解决实际问题，在算法实验的过程中挑选合适的采用即可。
相比第一种，第二种则需要在整体的运维流程中预先判断瓶颈障碍，进而得出AI技术是否可以将问题解决，可见这都不是两者单纯相加那么容易。
说完技术点再聊聊数据。
换个探讨角度，从运维数据出发，例如对于常规的硬件设备，包括开源基础软件在内，日志数据应该是最能展现当时其运行状态。
常见的关键词warning、error、critical等或多或少都可以反映出平常不太留意甚至少见的系统情况，进而发现潜在问题。
但如今现实中很多用户的运维业务与系统中的代码并不都是自己的研发人员写成的，更多的外采设备如果出现问题并不能及时得到解决，造成了“日志到手绝非想用就用”的状态，肿么办？
一般在这种不知道具体源码的情况下，通常利用无监督聚类的方式完成反向推导，就可大致获悉日志在实际中的代码操作情况，尽管不能做到百分百还原，但也会最大限度预测出发展逻辑，只需目标明确再加额外关注即可在故障预判中做到事半功倍。
目前无论是智能运维中的监控指标还是在日志分析，运用AI技术最简单的方法就是使用一些非监督学习的算法，例如聚类算法，即ClusterAnalysis ，也被称为群集分析（将相似对象通过静态分类的方法分成不同的组别或者更多的子集（subset），这样让在同一个子集中的成员对象都有相似的一些属性。）
尽管在具体的运维场景中，仅凭如今的机器学习水平暂不能将每条路径都做到灵活使用，但异常检测方向还是落地频次较高的。只要具备足够的运维数据支持，在调用链基础上的拓扑与图谱推导都会被华丽丽的实现。
高屋建瓴一下，在神奇的AIOps场景中，数据已然成为中心资源，将运维各种状态信息转换为大数据的过程中，机器学习在基础上完成相应的分析，全流程就ok啦！
在智能运维的大盘中，机器学习技术与各类运维数据，都不可缺。
深入分析运维数据的那些事儿，我们发现其实在实际操作过程中，运维数据主要分动静两态，以运维大数据平台为例，通常部分静态数据可直接加载在内心数据库中，并保存在结构化数据库或者Hive平台。
相反，主要包含各类监控指标数据、日志数据以及第三方扩展应用所产生的动态数据，一般是实时生成并被获取作为基础数据，过程中需要通过数据清洗转换成可使用的样本数据。