运维可视化自动化作业平台及实现方法与流程

本发明涉及互联网运行维护技术领域，具体涉及一种运维可视化自动化作业平台及实现方法。

背景技术：

随着互联网多年发展，运维技术逐渐为大众所关注，更有影响全球范围的运维大会等组织多场技术分享，使行业内技术不断迭代升级，运维相关的工具产品日趋完善和甚至商业化，市场比较知名的有蓝鲸智云，但由于其为商业产品涵盖到运维功能更广，而且是基于公有云实施，更适合基础架构层系统管理员使用。

运维是负责互联网科技公司的业务生产系统的运行维护工作，而对于运维本身的核心价值就是系统运行的长期稳定，限制变更发生次数越少越好，而业界数据表明故障发生概率超过70％都是来自于业务系统本身的变更导致，所以管理变更是运维工作的重中之重。

因此要确保每次变更计划的整个生命周期都在运维掌控范围内，其包括：变更窗口、具体操作内容、变更环节的各个角色、过程和实时输出、状态反馈以及风险控制等。

互联网行业竞争发展迅猛，每家公司的系统几乎是天天都在迭代更新，周周发布到日日变更，运维人员的工作强度非常大，如果一直是在手工劳作，除效率低下外，团队内每一个人的经验和能力不同，处理手段也会有差异，不能形成标准更容易引发人为事故，给公司和个人带来不必要的损失。

技术实现要素：

本发涉及运维变更作业的管理和执行，更适合业务和应用层面维护人员使用，解决了现有技术存在的下列两个技术问题：

1、在变更实施的过程中运维可以掌控每一个环节的详细内容，并能依据风险判断作出人工干预，让整个周期的操作透明化，数据可视化。

2、将简单和重复的工作变成自动化流程作业。

本发明采用的技术方案是：

一种运维可视化自动化作业平台，包括任务处理模块和接口控制模块；

任务处理模块包括组件、任务和任务组；一个任务组包括至少一个任务，任务组控制组内的每一个任务的执行过程以及执行过程中的任务入口参数传递；一个任务包括至少一个顺序执行的组件，任务控制每个组件的执行，并将前一个组件的组件输出参数传递给下一个组件；

接口控制模块包括请求接收接口、执行接口、消息推送接口、日志接口和状态处理接口；请求接收接口获取任务组执行的名称和参数，创建任务组数据并生成任务组id，将任务组数据存储到存储db，并将任务组id推送到消息队列中；执行接口实时从消息队列中取出任务组id；状态处理接口与执行接口和消息推送接口连接，记录任务组执行过程中的执行状态变化；消息推送接口接收执行接口发送过来的执行日志，同时推送消息更新信息到消息队列中；日志接口取出消息队列中的日志，并实时推送到web控制台中。

一种运维可视化自动化作业平台实现方法，包括作业平台变更操作，作业平台变更操作包括任务处理模块操作和接口控制模块操作，任务处理模块包括组件、任务和任务组，接口控制模块包括请求接收接口、执行接口、消息推送接口、日志接口和状态处理接口；

任务处理模块操作具体步骤如下：

编写作业平台变更操作所需要的原子操作集；

组件封装n个变更所要执行的原子操作集，n至少为1；

任务将m个组件进行编排，m至少为1；

任务组执行任务，并将任务组执行的名称和参数发送到请求接收接口；

接口控制模块操作具体步骤如下：

请求接收接口获取任务组执行的名称和参数，并发送到执行接口；

执行接口执行、重试或者暂定原子操作，并发送到状态处理接口，同时将执行日志发送到消息推送接口；

状态处理接口记录任务组执行过程中的执行状态变化，并将状态信息推送到消息推送接口；

消息推送接口接收状态处理接口推送的状态信息和执行接口发送的执行日志，同时推送消息更新信息到消息队列中；

日志接口取出消息队列中的日志，并将任务状态进行实时展示。

进一步地，所述任务状态通过web控制台进行实时展示，一个任务组包括至少一个任务，一个任务包括至少一个组件，每一个组件在web控制台中有一个下拉按钮，通过web控制台查看任务的进度和需要执行的组件，通过下拉按钮查看组件执行的日志情况。

进一步地，所述原子操作集为指令或者脚本。

进一步地，任务将m个组件按顺序或者并发方式进行编排。

进一步地，任务组执行任务按时间、范围或者顺序执行。

一种公司内部it服务管理自动化平台对接方法，包括以下步骤：

将公司服务管理中产生的变更编辑成任务组；

用户发起服务流程请求；

接口控制模块处理服务流程请求；

触发任务组；

完成服务作业任务推送消息；

完成服务流程。

一种监控中心故障监控自动化平台对接方法，包括以下步骤：

将常见故障编辑成任务组；

监控中心发出告警信息；

接口控制模块处理告警信息；

监控中心建立事件，自动触发任务组执行任务；

完成告警处理推送信息；

监控中心告警恢复。

一种运维云资源管理自动化平台对接方法，包括以下步骤：

将运维云资源管控和变更编辑成任务组；

请求运维云资源服务；

接口控制模块处理运维云资源服务请求；

通过运维云资源接口触发任务组；

完成运维云资源处理推送消息；

完成运维云资源服务。

本发明的有益效果如下：

1、解决就了运维变更管理的痛点，确保在变更实施的过程中运维可以掌控每一个环节的详细内容，并能依据风险判断作出人工干预，让整个周期的操作透明化，数据可视化。

2、通过标准操作规范变更保障每一个人的工作被快速替代，大大提供了运维变更管理的效率。

附图说明

图1是任务处理模块结构图。

图2是接口控制模块结构图。

图3是运维可视化作业平台变更流程图。

图4是服务管理自动化平台对接方法流程图。

图5是监控中心故障监控自动化平台对接方法流程图。

图6是运维云资源管理自动化平台对接方法流程图。

图7是作业平台可视化示意图。

图8是应用发布的任务具体过程示意图。

图9是日志执行情况示意图。

具体实施方式

下文中，结合附图和实施例对本发明作进一步阐述。

图1为本发明任务处理模块结构图，包括组件、任务、任务组三个功能模块。各个功能模块说明如下：

组件：用于封装特定的运维操作，比如一个脚本、或者一次接口调用，每个组件只负责一次单一的操作过程；组件的组成部分如下：

组件id，全局唯一；

组件所属任务id，全局唯一，用于关联任务；

组件状态：特定关键字

组件内容：执行所述组件的实体，如果组件是类型是调用脚本，则内容就是脚本本身；

组件输入参数：一个组件执行所需要的参数，例如：一次ssh(secureshell，安全外壳协议)远程连接，需要host(主机)、user(登录账户)、password(登录密码)；特定类型的组件可由默认参数和自定义参数组成；

组件输出参数：标记所述组件执行后需要导出的变量参数，用于后续组件执行；

组件执行模块：执行并通过管道方式存储执行日志，更新执行状态；

组件分类：在程序设计中，可以将组件划分如下几类(如表1所示，非必须，用户依据设计可自行扩展)。

表1组件分类

任务：用于创建组件执行流，一个任务包含多个顺序执行的组件，任务控制每个组件的执行，并且将前一个组件的执行结果(组件输出参数)传递给下一个组件，除此之外，任务还可以控制后续组件的执行、暂停等操作，当其中一个组件执行错误，组件状态会直接返回至任务。

任务的组成部分如下：

任务id，全局唯一，用于关联任务组及组件；

任务所属任务组，用于关联任务组；

组件索引：一组顺序排列的组件id，用于关联多个组件的执行；

任务入口参数：用于接收并发送任务中第一个调用组件所需要的参数；

任务执行模块：用于控制组件执行，更新任务状态。

任务组：将多个任务组织在一起构成一个任务组，任务组根据预设的执行策略，对任务进行分组执行，任务组控制组内的每一个任务的执行过程以及执行过程中的入口参数传递。

任务组的组成部分如下：

任务组id：全局唯一，用于关联任务；

任务索引：一组包含在所述任务组中的任务id列表；

任务组执行策略：控制任务并发执行策略；

任务组入口参数：用于接收并创建任务，任务组可根据获取到的参数，生成对应的任务。

任务组执行模块：用于控制任务执行，更新任务组状态。

图2是本发明接口控制模块结构图，包括请求接收接口2、状态处理接口7、执行接口4、消息推送接口5、日志接口6等模块。

接口控制模块包括请求接收接口2、执行接口4、消息推送接口5、日志接口6和状态处理接口7；请求接收接口2获取任务组执行的名称和参数，创建任务组数据并生成任务组id，将任务组数据存储到存储db8，并将任务组id推送到消息队列3中；执行接口4实时从消息队列3中取出任务组id；状态处理接口7与执行接口4和消息推送接口5连接，记录任务组执行过程中的执行状态变化；消息推送接口5接收执行接口4发送过来的执行日志，同时推送消息更新信息到消息队列3中；日志接口6取出消息队列3中的日志，并实时推送到web控制台1中。

图3是运维作业平台的变更流程图，从图中可知，运维作业平台变更操作包括任务处理模块操作和接口控制模块操作。

任务处理模块操作具体步骤如下：

编写作业平台变更操作所需要的指令或者脚本等原子操作集；

组件封装n个变更所要执行的原子操作集，n至少为1；

任务将m个组件按顺序或者并发方式进行编排，m至少为1；

任务组按时间、范围或者顺序执行任务，并将任务组执行的名称和参数发送到请求接收接口2。

接口控制模块操作具体步骤如下：

请求接收接口2获取任务组执行的名称和参数，并发送到执行接口4；

执行接口4执行、重试或者暂定原子操作，并发送到状态处理接口7，同时将执行日志发送到消息推送接口5；

状态处理接口7记录任务组执行过程中的执行状态变化，并将状态信息推送到消息推送接口5；

消息推送接口5接收状态处理接口7推送的状态信息和执行接口4发送的执行日志，同时推送消息更新信息到消息队列3中；

日志接口6取出消息队列3中的日志，并将任务状态进行实时展示。

接口控制模块和任务处理模块是本发明最重要的两个功能模块。

通过接口控制模块，可以使公司每一位技术维护人员所编写的指令和脚本通过接口实现远程调度和执行，脚本文件可以批量分发，且接口设计上有统一的技术要求的参数和规范，多接口的不同功能设计，除维护人员不用登录到具体主机服务器执行操作，且操作过程和结果也会通过接口消息和日志实时推送回平台，从而实现操作的规范化和全程可视化。

通过任务处理模块，技术维护人员可以把指令和脚本编写的能力在web控制台上完成和存储，并实现实现版本化管理，从而是每一位维护人员的命令和脚本透明化，即操作内容可被审计和复用，也使日常工作变成指令或者脚本集固化下来，这些脚本集通过任务设计被封装成组件直到任务组，通过控制任务组，实现不同操作之间的关联与衔接，并按预先设定的规则执行，使之可以被串联执行或者并发执行。这些任务组被多次验证和改进后，将会变成维护工作中的一项专题事务，可以被安排定期或者在某一条件被满足的情况下触发执行，在一定程度上实现半自动或者全自动操作的系统行为，减少人为干预，最终达成提升运维效率。

实施例一，公司内部it服务管理自动化平台对接方法。

规范化与公司内部平台对接，只要涉及到对公司业务系统会产生任何变更，包括对于业务数据的增删改查、程序的持续集成等都可以变成标准的作业任务组操作，任务组强大的策略功能可以使流程适应多种需求场景。对接公司内部的it服务管理平台如图4所示，步骤如下：

将公司服务管理中产生的变更编辑成任务组；

用户发起服务流程请求；

接口控制模块处理服务流程请求；

触发任务组；

完成服务作业任务推送消息；

完成服务流程。

将服务管理中常规化的服务全部打包编辑成作业任务，形成从请求到审核到工单到操作到处理完成全流程平台化，而用户在流程中只需要关注发起申请、判断合理合法性的审批，从而逐步减少人为劳动，真正提高流程效率。

实施例二，监控中心故障监控自动化平台对接方法。

业务系统稳定除了变更导致意外，其次就是各类基础故障，比如服务器过载、应用日志过多导致磁盘写满、服务器硬件损坏、网络抖动等，在第一时间发现故障是监控中心的职责，但第一时间响应和处理，就能在最短的时间内修复故障，恢复稳定，而人的响应和处理都是需要时间永远会比系统自动化处理慢上十个分钟级，因此被平台和监控中心打通，将处理常见故障的任务组实现编辑好，等到告警触发发出警告信息后，监控中心会建立事件然后系统对接到作业平台自动触发匹配的故障处理任务执行，就能在无人值守的情况，修复该故障。具体流程如图5所示，包括以下步骤：

将常见故障编辑成任务组；

监控中心发出告警信息；

接口控制模块处理告警信息；

监控中心建立事件，自动触发任务组执行任务；

完成告警处理推送信息；

监控中心告警恢复。

实施例三，运维云资源管理自动化平台对接方法。

公司数据中心越来越多的会转向云计算技术，公有云的普及和私有云技术的成熟，使得运维资源管理变得更加的方便快捷，因此对于资源管控和变更同样可以对接作业平台来实现，从而让资源管理变更越发可控和高效，不过其需要云资源平台也提供相关操作接口方可对接，具体如图6所示，包括以下步骤：

将运维云资源管控和变更编辑成任务组；

请求运维云资源服务；

接口控制模块处理运维云资源服务请求；

通过运维云资源接口触发任务组；

完成运维云资源处理推送消息；

完成运维云资源服务。

同样的运维作业平台作为基础工具可以连接一切需要操作业务系统的场景，使之更标准、更合规、更高效。

实施例四，运维作业平台可视化。

对于一些比较重大的操作任务，比如大版本发布、应用扩容和迁移、重大变更计划等，就非常需要全程监视确保任何环节按计划执行，且又在执行窗口期内避免再进行人为操作，从而耽误整个过程出现差错导致时间拉长甚至计划失败。

任务组设计为提供了任务编排的能力结合web平台可以事先编辑好任务计划，通过web平台实现运维作业平台的可视化，具体如图7所示。

任务组会包含多个任务，即可以事先把要做的事务提前编辑好工作脚本，并在操作前准备好了各个工作流顺序形成工作计划，同时每个任务中会有多个组件作业，可以控制任务的执行，并全程关注任务的进度和具体过程的日志输出。图8是一个已经编排好的发布计划中的一个应用发布的任务具体过程。

可以在任务栏中关注当前应用发布的总体进展的进度条，并且可以获知任务下面需要执行的组件作业，每个组件作业负责的具体工作和其当前的状态，并对于每一个组件作业点击下拉按钮看到具体执行的日志情况，如图9所示。

从具体数据上知道组件作业执行每一个步骤和状态，如果发现问题即可马上定位到具体问题的细节之处，而且组件任务状态上也会马上反馈出失败的状态，确保问题第一时间被捕获和展示。

本发明优选通过python语言开发编写，并运行于linux系统，对于计算机硬件没有特殊要求。

本发明虽然已以较佳实施例公开如上，但其并不是用来限定本发明，任何本领域技术人员在不脱离本发明的精神和范围内，都可以利用上述揭示的方法和技术内容对本发明技术方案做出可能的变动和修改，因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化及修饰，均属于本发明技术方案的保护范围。