面向云原生系统的智能运维技术

一、云原生与智能运维的背景

云原生技术近年来愈加受到IT界的广泛关注，在权威机构Gartner发布的报告中，云原生已经位在未来十项趋势性技术之中。云原生来自于早期的云计算平台，而云原生与智能运维相结合也是近几年提出的一个新理念，目前发展正处在化茧成蝶的过程。但当前云原生系统智能运维领域的实践，还远远没有达到我们所期望的状态。

1. 云原生技术发展

回顾云原生技术的发展轨迹，云计算从Dev+Ops时代开始，就一直朝着粒度更小的方向在发展，从裸机Bare metal、到虚拟机Virtual Machines、到容器Containers、到人工智能AI，到函数功能Function、再到未来更加细粒度的计算，云计算也在经历着DevOps-AIOps-NoOps的时代演进。溯其根源，新技术新能力的诞生，都是为了实现开发速度越来越快，交付速度越来越快，业务响应越来越快的目标，真正提升运营的敏捷性。

但与此同时，云计算发展带来了一些问题：开发与运维的压力不平衡。

运维在云原生快速发展下压力越来越大，如何平衡运维与开发？如何在运维端加强云相关能力？如何保证二者共同发展？这是智能运维亟需解决的问题。

2. 云原生面临的挑战

现阶段的云原生面临着什么挑战呢？在此之前，我们首先了解一下云原生有什么样的特征。在云原生系统中，存在着几个比较关键的技术：

• DevOps
  开发运维一体化。
• 连续交付
  主要是为了从软件、代码，到产品、软件服务市场等的速度实现显著的提升。
• 容器技术
  加速开发和部署软件系统的速度。
• 微服务
  使得软件易于开发、交互和维护。

简言之，云原生的特征核心在于：唯快不破，唯快不赢！对效率的极致优化和追求，使得云原生系统在基于以上技术进行构建的过程中，呈现出以下显著的应用特点：

在多种应用特点下，云原生所面临的难点：

系统复杂度高

举一个例子，在某软件中可能有3000多个微服务，但是实例的数量远远不止这些，如果每个微服务对应5个实例，那么将大约有15000个实例，在如此海量的实例中，如何去理清其中的相互依赖关系、精确地捕捉微服务、查看某系统运维状态，管理各个微服务之间的关系等等，都将面临着巨大的挑战。同时对于一些巨型企业，微服务成千上万，带来的系统复杂度和运维难度也远超想象。

软件系统的动态性

在DevOps提出以后，软件交付的周期越来越短，与此同时，软件逐步采用容器微服务架构，这两种技术的结合使得系统难以找到一个稳态，这对于传统的运维方案是一个巨大的挑战。我们无法通过训练一个常规的静态模型来进行异常检测、根因定位等工作。另外，容器本身生命周期从创建申请、扩展、销毁等都是一个动态的过程，频繁的动态变化使得智能运维难度急剧加大。

软件多样的增加

如上图，在云原生知名社区CNCF上，开源软件的数量是十分庞大的，面对如此海量多类型的软件，运维又该如何统筹管理，如何精确捕捉其性能和状态呢？软件多样性增加环境下，运维模式和方式的复杂度呈指数级增加，难以形成统一解决方案。

软件故障的增加

系统规模小的时候，可能只有几十台服务器，由此带来的故障依旧人为可控，但随着系统规模的不断扩大，故障发生的概率也在并不断的增加，造成的影响也逐渐难以控制。在此之前，我们也能在各种场景中见到各种类型的宕机、各种类型的故障，某社交巨头企业曾经发生过罕见的长达6小时的故障的宕机时间，这对于业务系统的影响几乎是毁灭性的。因为这6小时的故障宕机，该企业可能丢失了几十亿美金。

运维数据复杂

与软件规模扩大同步带来的问题，就是数据的复杂度，实际上运维数据的种类恰好符合大数据的定义标准：种类多、体量大、速度快。如何从多种类的运维数据中发现问题，快速的解决问题，让运维工作变得更加棘手。

3. 解决思路

新技术必然带来新的困难，为了克服这些难题，又会衍生出相应的技术手段。早期在面临故障时，我们考虑的是如何减少平均失效时间MTTF，再降低MTBF、MTMF平均失效间隔时间，这也是智能运维的基础解决思路。在应对云原生系统时，AIOps作为算法驱动的运维，就成为了解决这类问题的高级手段。

AIOps可以从算法、数据、场景三个维度去分析处理，通过数据驱动运维，最终实现从数据中发现信息，从信息中挖掘知识，形成解决问题的知识库，最终实现数据融合分析，也即是AIOps的发展路径。

二、面向云原生系统的智能运维技术

1. 可观测性

可观测性通常在企业运维中也叫做监控。也是智能运维的首要目标，对现有的资源，实现统一的监管、控制，并且能够根据实时变更进行动态响应。但传统的运维缺少了广度、宽度上的监控，我们希望能够更深层次的观测，包括系统真实状态活动，数据源之间的关联，多数据的统一接入等等。

在此方面，基于eBPF的性能监控以及全链路的上下文监控通过多种新技术手段的融合，能够汇聚更细粒度的监控数据，同时形成指标，便于其他运维工作的快速开展。

2. 异常检测

在异常检测方面，目前很多场景都有各种各样的方法，可能有成千上万种方法，本文仅根据个人总结，对异常检测方法进行分类，如：通过数据是否具有数据标签，选择有监督、无监督或半监督的方式进行处理。同样的，在数据类型、数据维度、数据模式上，也可以进行相应的处理，从而选择更为合适的方法进行处理。

3. 根因定位

作为AIOps的核心工作难点，根因定位在运维工作中是最为常见的场景，但也是最耗时，最复杂的一个阶段，如何追踪微服务的请求信息，如何合理利用trace提供有价值的信息，如何根据分析数据、图谱找到故障真正的源头，这也是我们正在努力研究的一个方向。目前我们已经在基于调用链、因果关系、云原生知识图谱的根因定位中获得了显著的成效。

未来技术展望

事实上以上的各类研究方法或处理手段，依然还有很大的优化和进步空间。

关于可观测性，基于eBPF的细粒度行为监控，我们可以减少一些可以直接观测到的过程，例如文件的读写、网络状态等，不需要基于算法去处理，对监控进行更进一步的优化。

在全链路上下文关联方面，已经有一些走在前列企业实在实践了，但并不够完善，例如Metric这类指标并没有做细粒度的关联，数据分析上，仅仅提供了可视化么能力，缺少关联数据的分析。

最后是基于交互式、主动式的智能运维，学术界与企业界都在进行不断地探索着智能运维算法未来的发展。许多团队都在这方面进行着大量的投入，同时我们也能看到智能运维也在随着底层架构的调整而不断的发展和调整。谷歌最早提出的SRE的理念如今也在不断的被各类“后起之秀”实践并改进着。

面向云原生系统的智能运维过程，我们可以总结为：在运维的数据中找到知识，在这一过程中，如何获取数据，如何分析处理数据，如何总结出可用的知识经验，例如故障种类，发生时间，规律，修复方式，解决过程等，如何沉淀统一知识库、形成解决方案等等，实际上就是我们通常在写的Postmortem，也是智能运维发展中正在不断探索内容，如何推进Postmortem的文化，在未来也将会有一席之地！