基于事件驱动的自动化运维平台

作者：李森

部门：技术中台/PaaS平台

一、前言

随着公司规模的增长，业务越来越复杂，运维的场景越来越多，对运维自动化的要求也越来越高。事物的发展不是孤立的，运维也不例外，运维的发展过程大致可以分为：手动运维->自动运维-> DevOps ->智能运维。我们希望在已有的 OPS 运维平台的基础上再向前迈进一步，构建基于事件驱动的自动化运维平台。

发展图：

本文将介绍基于事件驱动的自动化运维平台（Whale）的系统设计、实践以及未来的展望。

二、整体设计

系统运行分为两大阶段：编排期和运行时

编排期：

• 平台研发负责将各种平台功能封装成原子任务接入到系统中
• 用户根据业务场景，组合已有的原子任务（或者自定义开发），构建对应的处理流程
• 用户将需要监听的事件接入事件中心
• 用户在规则匹配模块配置事件与任务关联（基于规则匹配关联）
• 用户根据事件内容组装任务参数

运行时：

• 当对应的运维对象发生状态变更时，产生相应的事件进入事件中心
• 规则引擎接收到事件之后，根据事件类型和内容，生成规则匹配结果
• 接着触发对应的 Workflow 去处理
• 原子操作最终会触发运维对象的状态变更，然后再进行对应的操作，直到达到目标状态
• 向管理员反馈任务处理结果

系统流程：

2.1 事件中心

事件中心作为整个平台事件的入口，主要的职责是：

• 承担对外事件的标准化接口，校验事件合法性
• 提供用户配置事件的能力
• ES存储，支持用户对所有接收事件的检索

使用预定义的事件类型，可以标准化事件，更好从全局视角了解事件接入情况。ES的使用让事件中心的存储和索引更加强大，便于用户可能需要的问题排查以及事件重现。

2.2 规则匹配

规则匹配模块是事件驱动的大脑，是事件到任务的决策单元。整体分为3个模块：规则特征匹配、任务参数组装、任务触发限流。

2.2.1 规则特征匹配

规则特征匹配是通过对事件本身内容进行匹配，对用户使用DSL配置的匹配规则予以放行，反之会被丢弃。目前特征支持常用关系如：等于、不等于、大于、小于、正则匹配等。用户配置的特征组成一个特征管道，事件需要经过特征管道来判断匹配结果。比如：我们想根据某个事件的某个指标的大小来决定是否触发任务，这个阈值的设置，可以增加一个特征规则；或者我们的任务只针对生产环境的资源，可以增加一个环境特征规则。

2.2.2 参数组装

为了让事件内容与任务解耦，所以抽象了参数组装层。让事件和任务都具有流动性，同时一个事件也可以触发多个任务。任务参数组装需要用户使用 DSL 来配置一个任务参数模板，系统会根据事件内容以及参数模板渲染出执行这个任务所需要的全部参数。

例如事件消息为：
{
  "event_type": "opsst2_stone",
  "detail": "{"msg": ["test1", "test2", "test3"], "code": "1"}"
}
则转发参数可以为：
{
  "messages": "{{.detail.msg}}}",  #指定引用事件detail字段的msg字段
  "default1": "ok",  #指定固定的默认值
  "default2": [1,2,3]
}

2.2.3 任务限流

事件具有重复性，但是任务理论上不应该被重复创建。为了避免这种情况，对下游的任务执行引擎进行保护，此模块实现了一个基于缓存的令牌桶限流器。每个规则都可以配置一个限流策略：

• 指定限流标识 key
• 单位时间可触发任务数量

限流标识 key 同样需要 DSL 来创建模板，根据事件内容渲染出真正的 key 。如：

{{.detail.app}}_{{.detail.host}}

2.3 执行引擎

执行引擎作是一个“真正干活”的模块。根据已有的一些运维系统的痛点，我们需要的是一个有状态的、可编程的、支持 Workflow 、带容错、可扩展的分布式任务编排框架。目前有很多成熟的开源任务编排框架，对比了一些开源软件后我们选择了 StackStorm 。基于 StackStorm 提供任务编排 DSL ，用户可以通过编写 Yaml 轻松对原子任务进行组合，像搭积木一样完成数据自己的任务流。

在此基础上，为了更好管理多个集群（根据业务的优先级隔离出单独集群），满足跨机房高可用、用户无感知升级等需求，我们实现了一个多集群的Proxy做流量隔离控制。

2.3.1 任务管理

任务管理模块可以对任务执行状态进行管理

• 执行状态
• 执行日志
• 执行干预：重试、暂停、恢复等

2.3.2 集群变更发布

为了应对原子任务日常迭代发布，我们抽象出共享 Pack 的概念（若干个 Pack 组合体，Pack的体现形式类似一个 Git Repo），发布过程中会把这若干个 Pack 构建成一个 Docker 镜像，替换老的 Worker 节点的镜像。

2.3.3 多集群管理

我们对底层的 StackStorm 集群进行了屏蔽，用户不需要感知我们下层集群的情况。有了这一层的存在，后续可以很方便对集群的滚动升级、维护、甚至替换其他开源方案。

不仅如此，这里我们还可以在用户无感知的情况下对不同的业务路由不同的集群，实现业务层面的集群级别的隔离。

三、实践

利用事件驱动的自动化运维平台，与监控同学合作实现两个小场景的告警自动处理：

• 虚拟机磁盘容量告警企业微信自动处理
• Dmesg 出现之后企业微信直接查看，并且直接可以清理

处理流程：

集成企业微信：

四、后续展望

1. 目前的场景的自动执行还需要人为在企业微信授权，后续基于数据的分析场景成熟可以不需授权直接处理，只需要同步处理结果即可。
2. 尝试更多场景，如将告警事件和预案结合打造故障自愈产品，通过打通企业微信和 OPS 平台，让开发同学享受 ChatOps 的快乐。
3. 目前用户构建 Workflow 和编写任务只能通过编写代码提交到仓库，后续会提供更成熟的产品，让用户可以在界面编写脚本和拖拽就完成自己的 Workflow 。
4. 平台更多数据的沉淀，通过数据来分析出规则，更远期的设想通过将人工智能的能力与运维能力点结合，让运维更智能。

‍

‍‍

‍