自动化运维中的脚本管理和工单管理

能够参加分享分享充斥自动化运维群的分享分享，一篇短文整理出去。

先来张图，这是我在去年的时候规做的一个数据库方向规划。

紫色的部分是我们已近的部分，另外的部分是我们当时做得不好的地方。当然这个过程说过来大都辛酸。都是一滴滴汗水的再改进。

本次分享分享里听完的脚本管理和工单管理其实这是里面的两个模块，至于，我们还做了很多的模块。所以才先来简单啊说下目前系统的使用情况，这是我做的一个看板，早就做了前后端分离，这个可以做统计调用API的次数，布署实例的次数等，这些大都一些业务属性。

下面也有平台的一些使用频率的统计，方式这些我也可以明白目前系统的使用情况。

我还做了一个功能的统计表，看的到差别功能的使用情况，那样的话也能清楚一些功能的使用情况，是否修真者的存在明显的问题。

这是近一阵子的统计数据，如果前端率先发动了一次跪请，都会有记录过来。

简单啊能介绍完，我来说说看脚本管理和工单模块的建设思路。

运维平台的发展逃当然了几个步骤，脚本化，工具化，可视化和自动化，注意在自动化的阶段前，有一个阶段是可视化。

可是看来在有些时候我们的脚本化做得够好，例如代码里很有可能会有这样的基于的代码：

这种可是能够实现程序功能，可是这对平台的维护来说，应该是无数的钩子，不可控的钩子。

如果没有脚本的路径发生了什么变化或是要对脚本做变动，全都是一件不可能成功的事情

所以我随着脚本的引入，突然发现了更多的问题，最大的问题那是保证的脚本没有办法就用。要用起来，诸如要适应适应一定会的规则，然后把比较大的隔阂就回来了，变更土地性质不太懂运维，运维不太懂开发，这样的情况会让问题异常激烈。

因为这对脚本的管理很有用，不过缺少一些规范依先生的方式。

我做了:的总结：

1）替能够快速光洁的接入，脚本管理中的脚本语言不过不是瓶颈，都应该要各个支持，比如在用perl,不使用shell,SQL等，如果脚本本身很很稳定，那你已经这个可以接入进来，其实那是这个环节要开放，不必须得彻底是python脚本。平台的开发功能是python,但脚本管理不是有是python。

2）在脚本管理中，脚本和菜单如何能映射，这是个关键，我们是可以把脚本属性参数化，例如脚本名，脚本的类型等这些也以及一种元数据来管理呀。这样就会是一个统一的接口的方式，况且具体的连接方式，比如树状结构也可以其他可行的方式。

3）平台方向上是可以提前规划，不过对于开发和业务同学来说，不需要配置大量的url，就可结束一些基础的或奇怪功能的扩展。

4）可以做到的基础架构和功能，脚本化是对它来说也是起到进一步促进作用。要提前规划和均的基础功能是否需要有可衔接性的地方。

5）脚本管理支持文件的上传和脚本内容编辑时。这个就是偏具体技术的利用了，诸如ACE编辑器。

6）脚本的参数管理，有的脚本是1个参数，有的是2个，总之对此后台来说，那就是取得脚本来去处理，咋做标识和自动分配。

7）脚本管理中，有些脚本是通用的，假如如果能也能坚持了不使用，要要提前规划好范围和类别。有些脚本是具体详细的一些业务场景是需要的，要明确是需要的参数和权限。

脚本不光用通用和公私混合的范围，而且还要明细化到具体详细的作用域范围。

上面的内容虽然篇幅也很大，我们再做一层提炼。

脚本管理模块要注意做这些工作：

目标：大致了解实现脚本的递交，脚本审核和脚本栏里点功能

任务细则：

l实现方法脚本信息的可配置化管理

l实现程序脚本的信息一栏

l脚本类别和信息的管理

l脚本信息提交后由脚本管理员审批

l脚本审核后可以统一发送中通知邮件

所以才这就是我们工作中需求和设计之间的一个转化，我们这个可以才想到很多要做的事情，但是我们也要先做减法，哪些是除外再做的，哪些是锦上添花的。

这是一个脚本信息的列表。这里应该注意我们在数据库中会能维护这个数据结构，数据库中也会存储位置不对应的脚本内容，而在文件系统中也会必然随机的文件，那你我们是变更手续就会是两个层面，数据库层面和文件层面。

数据库层面的那就是脚本的再提交，都差不多通过前端的输入，需要提供了脚本内容，脚本的状态那是“等待审核“

这个阶段的意义那是递交脚本的时候压根儿不需要声明脚本的路径，这个工作是在需要审核的时候来做的。

而有用的工作那是脚本核审阶段，脚本二次审核通常是能完成两件事情，一个是脚本的路径规划，别外一个是脚本在中控服务器上能生成。

这样一来我们就有了一个初版的脚本管理结构，目录都是统一规划建设的，不是什么所有的脚本都要融入进来。

我们做了一个初版的脚本提示，假如创建战队了一个脚本会你的邮箱你所选的邮件，这样一来这那是一个开始的过程。

有了消息提醒，这是一个相对于求下载的审核过程了。

然后来说下工单管理模块的建设。

运维工作不过确实是一种服务，所以对此运维提供的服务来说，你甭管你是在用了逼格高的方式也可以规范的流程那就手工处理，如果高效安全结束，那这对应用来说应该是大家的赞。

只不过，很多公司里面的工单基本是会和两类属性岗位职称，一类属性是部门预算，或者说是工时，例如全面处理一个问题，是需要最少2个小时，那就这个服务就可以方式工时的方式来评估服务的结算费用，第二类属性是服务质量，例如工单的处理结果是否需要满意，是否是有一些规范的操作流程等，这些是不需要做工不错单可以反馈的。

至于工单模块和运维模块的建设，哪个应该的？总之这是一个相互提升的过程。早期的工单绝对没有自动化运维的辅助，所以绝对是有工单模块，但是早期的工单模块建设那肯定太差完善系统，基本操作和备案审批是脱节的，那肯定要结束工单的自动化处理。互相促进之后，这那就是另一个完备的链条了。

所以我简单的说，工单系统和运维系统需要对接下来，直接对接之后就能各自参与自己某种特定的业务范围，把每一个环节都能够做到了可调控和可考核。

我补个图来那就证明帮一下忙。

这个是一个初版的工单处理流程图，这个阶段是成功一个初步的系统对接。

第一步是去申请工单系统的接口权限，即工单的审批应该在均的工单系统中成功，而工单的信息是有有一个流水编号，是一个唯一的ID值，我必须的就是依据这个任何的编号能够从工单系统中能得到一个JSON数据串，换取这个数据串之后我来推导它把它拆细为符合国家规定业务属性的工单。因为所做的工作会统称以下几个步骤：

1）解析工单信息，依据什么流水号信息题工单的格式

2）工单表格合并，把原来的一个工单word文档合并为多个业务工单，这个过程对应用同学来说是透明的。例如数据库权限开通的工单，会自动word文档合并为两个工单，数据库权限工单和系统权限工单。

这个阶段的意义只在于，两个系统又开始对接起来了，虽说不是一种很肯定的对接方式，可是彼此打开了一扇窗。

第二个阶段就可以更近半步，这个时候我们这个可以对工单系统开放接口，让他们把数据定时推送过去，就你不我们去拉取了。这将是一个自动启动的推送过程，可以不可以省掉很多的检查和刚开始最后确认环节。

这个阶段的工作的一大亮点就取决于人我们这个可以在工单word文档合并为业务工单，如何处理能够完成之后，最后确认工单完成，让工单系统开放两个中写入接口，我们把工单的状态回传过去。那样业务操作就不能形成了一个闭环。形成闭环是这个阶段最最重要的一件事情，这样备案审批的关注审批环节，业务操作的关注业务操作环节，各司其职。

第三阶段是相当大的一个阶段，例如我们的工单可以和外部的系统是从接**互，那你我们就是可以和其他系统又开始封锁住这个链路。这是一个相当大更新华考资的过程，会有更多的事情和接口需要对接。

这个阶段的意义就取决于人，这是一个全链条的过程，我们这个可以在这个阶段更多的挖掘运维数据的价值，诸如工单的处理效率，工单的数据统计分析，工单的委托，业务工单拆细逻辑等。这些都可以不逐步降低的细化和设计改进。

因为逐渐地产品迭代，结束系统的对接，能够完成业务支持，不知不觉，运维工作已然不可能发生了很大的变化。

这又是我给大家彼此分享的初衷处。