作业是一系列运维操作的抽象定义，任何一个运维操作都可以分解成一步一步的操作步骤和操作对象，不论是发布变更还是告警处理，都是可以分步骤的。
命令： 一个可以独立的操作，最简单的如关服、开服、执行 xx 脚本等；
文件分发： 把指定的文件分发到目标机器的目标路径；
作业： 一系列命令、文件分发的有序组合，作业的步骤可以由 “命令”、“文件分发” 以及 “执行对象” 组成；
作业这个概念的提出，即可以将运维工作的各种“变更”、“发布”、“故障处理”等零碎操作分解成一个个可复用、可扩展、可执行的独立操作命令，那么最终平台化的自动调度将成为可能。
作业管理
上面这些是作业管理系统的主要功能，当然想要实现整个作业管理系统还会有一些其他的子功能，比如：
1）任务结果记录跟踪系统。
2）任务重做，重做任务子步骤是否重做控制。
3）脚本内容安全审核功能。
4）其他暂时未想到功能。
脚本执行 支持shell，python 快速批量执行 任务结果管理
文件分发 基础文件分发 P2P技术 文件一致性校验
定时任务 物理机的定时任务管理 定制任务均可设置定时执行 适用于在夜间或执行时间执行 重复执行的任务
灰度计划 支持按照任务步骤灰度/支持按照服务器个数灰度
定制任务 复杂任何通过简单任务组装得到 可以控制子任务的执行结果对整个任务的影响 支持任务顺序调整 可以实现较为复杂的运维任务
批量执行 支持选择一组服务器执行 支持服务器组定制化 快速实现大批量服务器任务执行功能
1. 脚本执行：
服务器选择分为两种模式：本地/远程执行
1）脚本管理功能；用于管理用户上传的脚本和常用的基础脚本。
2）账户管理功能；用于管理具体的执行用户。
3）服务器分组功能；用于基于资源管理系统的物理机管理数据按照某种方式划分成一定的服务器组。
1）SSH远程执行；可以通过封装ssh和paramiko的方式实现，python中的ansible和fabric包也都支持远程SSH执行的功能。Shell就用ssh命令即可。
该方式对中心节点要求比较高，每一个远程执行命令都会在中心节点启动一个进程（线程）来执行，对中心机的压力较大，同时由于是基于SSH的原理，故命令执行的效率较差，命令执行时间长。
2）Agent执行；在每台服务器上部署一个Agent，用户执行管控系统发送的脚本。这种方式的优点是可以采用拉的方式，由各个子节点订阅分给自己的任务，执行完成后再讲结果推给中心节点的数据；当然也可以像SSH方式通过推的方式由中心节点将任务发给远程的Agent，然后Agent去执行，并将结果反馈给中心节点。这种方式的执行效率会比较高，可扩展性强，将来甚至可以通过该Agent进行配置或运行数据上报，对于配置管理也比较方便，缺点是需要开发Agent，Agent需要支持异步非阻塞模式，且需要维护每台服务器的Agent，包括部署和管理。
3. 批量执行：
在使用SSH方式情况下并发的速度会较差，可能控制在单机30-50个任务同时进行。
在使用Agent的方式情况下，任务本身是异步下发的，可以实现同时1000+任务同时进行。
由于服务器数量较多，且分机房的模式，整个后端架构是京东云的分布式架构，一个中心任务下发节点，每个机房一个任务中转节点，每台服务器一个Agent（或者中转节点SSH的方式）。
4. 定制任务(原子任务组合(文件/命令),任务编排(串行/并行))
5. 定时任务(crontab job)
6. 灰度计划：
对于非周期性重复执行的任务，都可以加入灰度计划功能，该功能又结合定时任务实现。
灰度计划可以有两个维度体现：(步骤/个数维度)
2. 文件分发：
文件分发功能分为以下两个子功能，相关文件和模板的管理工作放到配置管理中去实现，这里只介绍如何实现文件分发：
1）普通文件分发，如代码包，镜像文件，软件包等。
2）模板文件分发，如配置文件等。
模板文件分发与普通文件分发不同的区别是模板文件中存储变量替换的逻辑，这里普通文件的管理和模板文件的管理以及配置变量的管理都放到配置管理系统中去实现，用户选择文件下发的时候可以选择是普通文件还是模板文件，如果是模板文件就会自动去加载配置管理中的变量管理生成临时的普通文件并下发。
具体的下发方式也分为两种：
1）管理机文件下发到普通的业务物理机上。
另外文件的传输会提前进行文件md5的对比判断，如果文件的md5值相同，那就没有再传输文件的必要，在稍大文件情况下可以节省较多的时间。
文件传输，可以使用ansible的copy模块，或者salt的文件file模块，当然也可以自研方式中封装rsync的方式，rsync支持文件md5值校验以及断点续传等方式。
2）物理机之间的文件互传。
用来P2P的传输较大的文件，比如几百G的镜像文件。
物理机之间的文件互传使用rsync即可，由于文件较大，且可能出现断点，rsync是比较方便的解决大文件传输的方法，需要在每台服务器上的Agent上对rsync功能进行封装，支持Agent之间的rsync文件互传。
物理机文件中需要管理的文件列表，可以通过Agent汇报到配置管理系统中，用户选择文件分发的时候，可以选择配置管理系统中的点对点大文件传输功能，配置管理系统中可以自动选择传输源，针对被传输物理机的个数，实现真正的点对点传输，不需要用户自己去选择源文件服务器，可以节省大量的人为运维操作。
3.3 配置管理
配置管理具体的实现方式可以有两种实现方式：
基于过程的实现方式（主动）
基于过程的实现方式，就是所说的的配置变化，通过中心触发的方式实现，服务器上所有的配置变化都是主动的而不是被动的，可以通过SSH的方式，也可以通过Agent的方式来实现。可以使用Ansible、fabirc的API或者salt的daemon，也可以自研daemon的方式实现。
基于结果的实现方式（被动）
基于结果的实现方式是指整个操作并不关心过程，也不是主动触发的，而是被动触发的，这种方式是基于Agent的实现方式。 运维人员对某台服务器的某个配置设置一个最终的状态，Agent获取这个最终状态后执行相应的操作，只要Agent满足条件需求，那么这台服务器最终所呈现的结果就是我们配置的结果，Puppet就是这种理念设计的，当然也可以自研。
账户管理 作业系统使用账户管理
文件管理 管理机上的文件管理
脚本管理 基础系统脚本管理 用户上传脚本管理
分组管理 服务器分组管理
服务管理 服务运行状态管理
软件管理 软件版本管理
模板管理 模板管理和变量管理结合使用
变量管理 和模板、分组管理结合 基于变量和模板生成文件
1）账户管理：
root用户/业务用户
2） 文件管理：
代码版本，脚本文件，软件包文件
3）脚本管理：
基础脚本/自定义脚本(文件管理)
4）分组管理：
单个选IP/分组(静态/动态(服务器资源某种匹配自动添加))
5）变量管理：
变量管理主要是配合分组管理和模板管理使用，
所谓的模板就是在不同的情况层显不同内容的文件，而如何呈现不同内容就是在模板中配置了相关的变量名称，而变量的具体赋值则需要在变量管理里面体现。
变量管理建议使用yml语法格式来编写，
变量管理细分可以分为几个维度：
全局变量
全局变量指的是那些在任何场景下都只有一个的变量，可能会改变，但全局只有这一个变量，它一变会影响到所有的使用它的模板。
组变量
组变量是指和分组管理结合后对某个分组设置的变量，组变量的使用场合比较多，而且不同的分组之间可能还有优先级的问题，因此需要在分组的时候设置组的优先级。
建议将组的优先级分为如下几类：
全局组（级别最低）
IDC组（级别次之）
Set组（级别次之）
自定义组（级别次之）
主机变量
主机变量是主机级别的动态变量，具有较高的优先级，建议结合资源管理系统使用，可以给每一台物理主机（虚拟主机）都设置一组相应的动态变量。
任务变量
任务变量是具有最高优先级的变量，这个变量只有任务执行的时候，通过输入的参数来控制，该变量实际并不进行管理，使用用户在使用的时候输入而已，一次性的操作。
6) 模板管理
模板引擎jinja2
7) 软件管理
rpm或yum，npm，pip等安装的软件包，压缩包或目录格式的代码版本(MD5)。
8）服务管理
都是通过Agent定时上报的机制获取最新的数据，就是讲每一台服务器上所运行这些进程进行管理，当然不是全部进程，而是我们所关注的服务进程
另外服务管理可以和作业管理相结合，实现服务的重启，停止，启动等功能。