**特别申明：**本文根据生产变更编写，所有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测试
