特别申明:本文根据生产变更编写,所有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台应用和一台数据库服务器,根据变更实施步骤,手动在每台服务器上敲命令执行,这是传统的变更方式。这样做有几个弊端:
变更手册大小步骤几十项,根据功能和关联性,抽象合并为16步,并分为实施准备、变更实施、变更收尾3类。
模板对应变更的16个步骤,相应的模板分为准备工作、变更实施和变更收尾3个大类。
变更实施准备的模板
变更实施的模板
变更收尾
登陆堡垒机,搜索分发服务器172.16.5.150,通过浏览器方式登陆
在浏览器地址栏输入http://172.16.5.150/或者直接点击历史窗口
输入用户名密码,登陆系统
在执行任务栏选择主机和执行模板
选择主机,3台应用服务器和数据库服务器都执行
选择模板
执行命令
数据库执行结果,有5个定时任务被注释,右上角的对号表示执行成功
应用服务器有3个定时任务被注释
定时任务注释条数:1号机4条、2号机3条、3号机3条、数据库5条
3台应用执行该操作,停止后台进程和java程序
执行反馈
‘the process is killed’代表后台进程停止,‘the java is killed’表示java程序停止运行;若脚本正常执行,返回的界面右上角会有对号√
跑批脚本:
执行结果:
数据库上执行抽壳操作
执行结果:
3台应用上执行
执行结果:
依次检查执行结果,正常的返回如图
应用程序替换是一个关键的步骤,集成了scp文件获取、文件解压、文件上传和移动文件到指定目录、赋权以及执行sql等。
备份响应的表,并将xx启动方式调整为手动
该操作数据库服务器上执行
执行结果:
变更前update所有发送步骤,致不用发送,测试完成后恢复,数据库机器执行
执行结果:
变更完恢复发送时注意比对sql执行结果的条数
执行sql,在PL/SQL内根据变更手册执行对应sql
自动化平台spug内也可以直接通过数据库服务器的console执行sql,不过返回结果没有PL/SQL直观。
3台应用服务器上执行应用启动脚本
执行结果:
应用启动会启动后台程序和java进程,也会重新装载共享内存映射
跑批有两种方式,一种是直接复制变更文档跑批命令在分发平台console上执行;一种是将跑批命令拷贝后上传自动执行。本文采用第一种方式,第二种方式适用于批次很多的情况。
进入console
执行批次
可以三台一起比对,也可以单独比对:
执行结果:
获取结果:
比对结果会上传到数据库服务器的/yssfgs/result目录,通过文件管理器可下载至本地电脑分析查看
比对这个也是关键步骤,之前跑批完每台服务器手敲命令执行比对,比对完然后登陆堡垒机通过ftp工具下载比对结果,劳时费力,而且批次越多花的时间越长,现在自动化了不受批次多少影响,所有的比对工作自动化完成。
在1号机上通过执行日初批次验证变更有效性
开始执行:
执行结果:
查看跑批是否有Skipp步骤,正常结果为空,数据库上执行本步骤
执行结果:
如不为空需逐一排查原因
3台应用和数据库服务器都执行
执行结果:
变更准备工作被注释的定时任务都被解开
恢复并修改发送,数据库上执行
执行结果:
恢复有效并将启动方式调整为手动
数据库上执行本脚本
变更执行完成
自动化变更优势:
后记
运维自动化是每个运维人绕不开的话题,现在没有哪个公司不做自动化运维的。公司内也有很多工具和产品,之前也试用过很多开源的自动化平台。结合生产实际,无论是自研的还是开源,选哪个平台用什么产品不是问题,关键是如何切实的减轻工作量,提升工作效率。
目前私有云上的统一运维管理我选的是ansible,变更选择spug。这两个平台都很精准的解决了运维的痛点。一个简单的例子,之前生产环境改密码,100多台服务器至少需要两个小时才能改完,还出现过改错了的情况。每次改密码至少需要登录3次crt,一次是开着窗口防止密码改错了可以及时改回来,一个是修改密码用的,再一个是复核密码。光登录系统就让人崩溃,使用ansible一个yaml脚本统一执行,秒级完成且不会出错。
自动化运维平台不在乎高大上,好用是王道。
如果想了解spug自动化平台,请移步:自动化运维平台Spug测试