拿什么解救你我的脚本？

随着云计算的不断发展，从最初的互联网初创企业，到现在的政府机关、金融和证券等行业，都在往云上迁移。在建设运维平台的过程中，大部分企业对于自动化运维能力非常重视，期望平台能管理好运维的批量作业以及日常运维操作，而且对于效率、安全和审计等方面的要求特别高。织云作业平台，正是为了解决当前用户对于自动化运维的种种迫切需求而产生的。

本文介绍了织云作业平台的设计初衷，发展历程，以及如何采用作业平台逐步地将日常运维工作规范化、标准化。

起步—工具建设

日常的运维工作中，存在着大量的重复度高的工作需要被执行，经常会出现需要打开很多个终端执行一个脚本的场景。

小H的故事

以某个公司的运维同学小H为例。小H平时会将见的业务处理流程中按照步骤和对应的命令记录在笔记中。需要上去处理问题时，小H是这么做的：

1. 在笔记中找到对应的处理方式

2. 打开终端，登录对应的机器

3. 按照步骤，粘贴代码、执行、查看执行结果。

小H觉得，这种方式足够应对平时的工作。

直到有一天，小H在执行A服务的迁移时，突然B服务反馈了一些问题，需要协助排查，于是，在已经打开了好几个终端的情况下，小H再打开一个终端，登录了服务B的机器。解决完B问题之后，刚好又遇上临时开会，小H走开了一下，之后回到工位上继续操作。

刚刚A服务的迁移执行到一半，小H从当时的步骤，继续操作，复制命令，继续粘贴到终端，没想到，刚刚服务B的终端没关，误将一条重启服务的命令，粘贴到了B服务器的终端上并执行，导致B服务短时间内无响应。

从成本和安全的角度出发，小H的工作方式中存在着这些问题：

• 人肉上机器执行，执行效率低，没有做好审计，同时也存在极大的风险；

• 管理混乱，大量脚本/工具无处安放，无法很好地整合；

• 运维各自建设工具，存在大量重复建设的问题；

• 学习成本高，使用脚本/工具的人往往需要了解整个脚本后才可以放心使用。

为了解决用户存在的这些问题，织云作业平台也就应运而生。从使用者（运维人员）的角度出发，我们将工具作为我们整个系统的核心进行建设。围绕着工具做文章，将工具从创建、编辑到执行以及执行记录的整合纳入我们系统的能力中。

在作业平台中，工具作为最小的操作单元，将常见的运维操作从日常的运维场景中抽离出来，独立为一个最小的原子性操作，赋予相应的描述信息和基本特征（比如执行环境、超时时间等），像编程语言中的函数一样，具备最基本的获取输入参数以及返回值的能力。

• 工具的详细信息

• 工具的参数配置

作业平台提供多种的内置参数类型，满足用户在定义输入输出时的需求。

• 工具的代码内容

通过以上对于工具的基本信息，对用户一个个的脚本进行包装，对于使用者来说，再也不需要过多地了解脚本的内容，可以从工具的描述以及输入参数的描述中了解该工具的功能以及参数的作用。

作业平台提供了一个简单的界面供用户执行工具使用，执行工具时，只需要传入工具所需要的输入参数，并指定工具的执行机器，剩下的工作，包括将工具分发到指定机器上，发起执行，收集执行结果等，都交给作业平台来解决。

• 执行工具的界面

可以看到，前端可以根据工具采用的参数类型展示相应的输入框，并做基本格式校验，很大程度上简化了对参数的处理。

同时，在选择执行机器上，采用了业务设备选择器，方便用户选择设备，尽量避免手动输入可能造成的误差。

• 执行结果的展示界面

支持根据机器查看执行的日志和返回结果，也可以批量导出所有数据。

进阶—编排整合

在完成了对于工具的封装之后，用户对我们作业平台的能力又提出了新的要求，即解决工具间的执行顺序的依赖问题。

前面我们讲到，工具在我们系统中的定位是一个最小的操作单元，即专注于完成一项特定的任务。而实际的运维场景中，往往需要多个工具组装起来一起解决一个特定的问题。

比如我们下面提到的例子，用户需要做一个机器日常的巡检，需要将工具顺序执行，后面三个步骤的数据依赖于第一步的工具获取到的机器列表。

从上面的图中可以看出，用户对于作业执行的要求有这么几点：

• 支持按照定义好的执行顺序执行相应的工具；

• 支持引用其他工具的返回值作为当前工具的输入；

• 支持将执行顺序、参数映射关系“包装”成模板重复使用；

• 只暴露一部分执行时需要用户输入的参数供用户手动指定。

为了满足这种需求，织云作业平台中，采用了编排的方式来解决工具间的依赖关系，编排的模板包括了如下信息：

1. 编排基本信息：包括编排名称和描述；

2. 编排的参数：当前编排需要用户输入的参数列表；

3. 编排步骤：

1. 每一个步骤都对应一个工具，步骤与步骤之间是串行执行的；
2. 工具所需要的参数可以从其他工具的执行结果或者编排参数中获取；
3. 可以指定当前步骤执行完成后是否需要用户确认后再继续执行。

上述需求在作业平台中体现为如下的编排模板：

在这个例子中，用户只需要输入相应的模块 ID 即可完成对模块设备的巡检工作：

这种方式，满足了绝大多数的应用场景，比如扩容、初始化设备等操作。

通过编排的方式，我们让更多的工具有序地组织起来，通过不同的搭配，满足用户各种需求场景，让工具发挥出更强大的实力。

扩展—融入更多模块API

在前面讲到的日常的设备巡检例子中，有一个工具的作用比较关键——根据模块 ID 获取机器列表，因为需要用它将用户输入的业务模块 ID 转换成机器列表，作为后面一系列工具的执行对象。

这个工具的实现思路，一般来说，就是发起http请求织云CMDB的API接口，传入业务模块 ID，获取设备列表，设置到返回值中。但是，直接让用户在工具代码中构造一个个http请求调用后台API接口，有这么几个弊端：

• 构造过程比较繁琐，需要用户反复调试；

• 代码不好复用，容易造成大量重复劳动；

• 在工具中发起对后端的http请求，不利于安全审计，存在隐患。

从另一个角度再来看这个工具。我们的织云CMDB、包系统以及监控等都是围绕着自动化运维能力去建设的，作业平台作为一个子系统，在织云的体系中的定位，是对于各个平台所提供自动化运维能力的整合和扩展。因此，在我们的体系中，工具不可避免地会大量调用到其他系统提供的接口，实现数据查询或者自动化操作处理等作业。

考虑到以上的这些问题，作业平台对于其他系统提供的API开始了封装和整合。

以上面提到的这个工具为例：

可以看到，在实现这个工具的过程中，用户不需要了解太多的API接口相关细节，只需要使用我们提供的CmdbService中的方法并传入参数即可。原来繁琐的http接口调用，变成一个个简单的方法调用，对于用户来说，创建工具的难度大大降低，效率和安全性也得到了大幅度的提升。

同时，作业平台作用也得到一个很好的体现：我们不提供系统功能，但我们是一个尽责的搬运工。

总结和展望

作业平台从早期的简单功能，到后面逐渐的整合了编排能力，到现在开始融入了其他系统的API作为内置操作供用户使用，满足着用户对自动化运维能力的不断追求。后续将继续发展，作为一个调度中心，与其他自动化运维模块更加密切地配合，为用户提供更强大的自动化运维能力。