特别申明：本文根据生产变更编写，所有ip、用户名、文件路径和文件名等敏感信息已做替换删除或打码处理。

服务器列表

ip	主机名	备注
172.16.5.111	app01	1号机
172.16.5.112	app02	2号机
172.16.5.113	app03	3号机
172.16.5.200	db01	数据库服务器
172.16.5.150	ansible	spug自动变更服务器

执行生产变更时会登陆3台应用和一台数据库服务器，根据变更实施步骤，手动在每台服务器上敲命令执行，这是传统的变更方式。这样做有几个弊端：

• 重复性工作多。生产变更少则十几步，多则几十步，很多步骤会在全部或部分服务器上执行。比如注释定时任务，4台服务器都要手敲注释命令；停应用操作会在3台应用服务器都执行。
• 失误多。由于所有的步骤都是通过手敲命令方式执行，敲错命令在所难免。另外由于执行步骤多、执行的服务器也多，很容易发生漏执行或者重复执行的现象。
• 文件传输不方便。生产环境一般通过堡垒机登陆，传文件也是通过堡垒机的ftp工具来执行。在变更时会多次涉及文件上传下载，这样就显得非常不便。
• 耗时长。这点是前三点的延续。由于都是手动执行，执行步骤多，还涉及堡垒机的登陆，整个变更做下来想快都很难。

变更步骤抽象

变更手册大小步骤几十项，根据功能和关联性，抽象合并为16步，并分为实施准备、变更实施、变更收尾3类。

模板

模板对应变更的16个步骤，相应的模板分为准备工作、变更实施和变更收尾3个大类。

变更实施准备的模板

变更实施的模板

变更收尾

自动化变更流程

• 1.将所有变更抽象为16个步骤；
• 2.每个步骤对应1个或多个脚本；
• 3.将脚本转化为spug平台的模板；
• 4.每次执行变更步骤时选择对应的模板和执行主机；

登录系统

登陆堡垒机，搜索分发服务器172.16.5.150，通过浏览器方式登陆

在浏览器地址栏输入http://172.16.5.150/或者直接点击历史窗口

输入用户名密码，登陆系统

一、变更前准备工作

第1步--注释定时任务

在执行任务栏选择主机和执行模板

选择主机，3台应用服务器和数据库服务器都执行

选择模板

执行命令

数据库执行结果，有5个定时任务被注释，右上角的对号表示执行成功

应用服务器有3个定时任务被注释

定时任务注释条数：1号机4条、2号机3条、3号机3条、数据库5条

第2步--停应用

3台应用执行该操作，停止后台进程和java程序

执行反馈

‘the process is killed’代表后台进程停止，‘the java is killed’表示java程序停止运行；若脚本正常执行，返回的界面右上角会有对号√

第3步--数据库跑批

跑批脚本：

执行结果：

第4步--数据库抽壳

数据库上执行抽壳操作

执行结果：

二、变更实施

第5步--应用程序替换

3台应用上执行

执行结果：

依次检查执行结果，正常的返回如图

应用程序替换是一个关键的步骤，集成了scp文件获取、文件解压、文件上传和移动文件到指定目录、赋权以及执行sql等。

第6步--日初日终改为手动

备份响应的表，并将xx启动方式调整为手动

该操作数据库服务器上执行

执行结果：

第7步--修改发送步骤

变更前update所有发送步骤，致不用发送，测试完成后恢复，数据库机器执行

执行结果：

变更完恢复发送时注意比对sql执行结果的条数

第8步--执行sql

执行sql，在PL/SQL内根据变更手册执行对应sql

自动化平台spug内也可以直接通过数据库服务器的console执行sql，不过返回结果没有PL/SQL直观。

第9步--启动应用

3台应用服务器上执行应用启动脚本

执行结果：

应用启动会启动后台程序和java进程，也会重新装载共享内存映射

第10步--跑批

跑批有两种方式，一种是直接复制变更文档跑批命令在分发平台console上执行；一种是将跑批命令拷贝后上传自动执行。本文采用第一种方式，第二种方式适用于批次很多的情况。

进入console

执行批次

第11步--比对

可以三台一起比对，也可以单独比对：

执行结果：

获取结果：

比对结果会上传到数据库服务器的/yssfgs/result目录，通过文件管理器可下载至本地电脑分析查看

比对这个也是关键步骤，之前跑批完每台服务器手敲命令执行比对，比对完然后登陆堡垒机通过ftp工具下载比对结果，劳时费力，而且批次越多花的时间越长，现在自动化了不受批次多少影响，所有的比对工作自动化完成。

三、变更收尾

第12步--日初验证

在1号机上通过执行日初批次验证变更有效性

开始执行：

执行结果：

第13步--查看是否有跳过步骤

查看跑批是否有Skipp步骤，正常结果为空，数据库上执行本步骤

执行结果：

如不为空需逐一排查原因

第14步--解注释

​ 3台应用和数据库服务器都执行

执行结果：

变更准备工作被注释的定时任务都被解开

第15步--恢复发送

恢复并修改发送，数据库上执行

执行结果：

第16步--日初日终改为自动

恢复有效并将启动方式调整为手动

数据库上执行本脚本

变更执行完成

总结

自动化变更优势：

• 执行效率高。传统变更大概需要2到3小时，如果遇到批次多的情况时间会更长。自动化后变更时长缩短到1个小时不到，并且不受批次影响，即无论批次多少都不影响变更时长。
• 失误少。由于所有执行步骤都封装成了脚本做成了模板，杜绝了手动敲错命令的现象。
• 界面友好。各步骤执行完后结果反馈的界面很直观，很容易判断执行结果。
• 集成度高。通过spug自动化变更平台，可以方便的登陆各服务器并执行命令，轻松的进行文件的上传下载。

后记

运维自动化是每个运维人绕不开的话题，现在没有哪个公司不做自动化运维的。公司内也有很多工具和产品，之前也试用过很多开源的自动化平台。结合生产实际，无论是自研的还是开源，选哪个平台用什么产品不是问题，关键是如何切实的减轻工作量，提升工作效率。

目前私有云上的统一运维管理我选的是ansible，变更选择spug。这两个平台都很精准的解决了运维的痛点。一个简单的例子，之前生产环境改密码，100多台服务器至少需要两个小时才能改完，还出现过改错了的情况。每次改密码至少需要登录3次crt，一次是开着窗口防止密码改错了可以及时改回来，一个是修改密码用的，再一个是复核密码。光登录系统就让人崩溃，使用ansible一个yaml脚本统一执行，秒级完成且不会出错。

自动化运维平台不在乎高大上，好用是王道。

  

如果想了解spug自动化平台，请移步：自动化运维平台Spug测试