Ansible 在性能测试中的价值：让机器干重复劳动，让人专注分析

一、前言：为什么在性能测试中引入 Ansible

Ansible 是一款基于 SSH 的自动化运维工具，主打无 agent、上手简单、批量执行。相比 Chef、Puppet 这类重型工具，Ansible 更像是“把日常运维命令脚本化、规模化”的利器。
在实际工作中，性能测试往往不是一次性的工作，而是伴随着系统版本的不断迭代反复出现：

• 一个大版本上线前要测
• 中间引入新功能要测
• 性能优化后要回归测
• 架构、参数、硬件变化也要再测

久而久之你会发现：
性能测试的核心思路没怎么变，变的是版本；真正重复的是执行过程。而这类“流程固定、执行重复、但涉及多台机器”的工作，天然适合自动化。 人则可以专注于把控质量和解决性能测试过程中遇到的问题。

二、性能测试到底在干什么？

很多人理解的性能测试只是“压一压，看 QPS、RT”，但在真实工作中，性能测试往往包含一整套流程。

1. 性能测试的典型工作内容

以一个服务端系统为例，常见的性能测试工作包括：

• 压测工具启动（wrk / jmeter / 自研压测工具）

• 被测系统多机部署、启动

• 关键指标监控采集：

  • CPU、load、context switch
  • 内存、page fault
  • 磁盘 IO、网络吞吐

• 关键进程级别监控数据（pidstat）

• 业务性能日志

测试结束后：

• 停止监控、停止系统
• 汇总所有机器的数据
• 对比不同版本的测试结果

2. 性能测试中的“重复劳动”

性能测试所做的大部分工作几乎每次都一样： 每台机器都要：

• 手动 ssh 上去
• 启动监控软件
• 启动业务系统

测完以后：

• 一个个机器停掉
• scp 把日志拷回本机

机器一多，操作就开始失控，容易犯错：

• 少开一台
• 忘关一个进程
• 日志丢了、时间对不上

这类工作没有技术含量，但极其消耗精力，也是性能测试中最容易出问题的地方。
于是一个需求自然浮现出来：这些重复性的事情，能不能一次写好，以后每次测试直接用？

三、Ansible 能做什么？为什么它适合性能测试？

Ansible 本质上做的事情只有一件：在多台机器上，批量、可控、可重复地执行命令。
但恰恰这件事，完美契合性能测试场景的需求。在性能测试中，Ansible 主要解决四类问题：
（1）多机一致性操作
所有被测节点：

• 用同一套命令
• 在同一时间窗口
• 做同样的事情

这是人工操作几乎不可能保证的。 （2）操作流程标准化

• 启动监控
• 停止监控
• 收集数据

全部固化成脚本，新同事也能直接用，避免“口口相传”。 （3）低侵入、低成本

• 不需要在目标机装 agent
• 只要能 ssh，就能接管
• 对线上/准生产环境友好

（4）为自动化留接口 一旦用了 Ansible，你的性能测试流程就具备了继续演进的基础：

• 后续接 CI（持续集成）
• 接压测平台
• 接结果分析平台

四、实战：自研 Ansible 脚本自动化性能监控

为了展示ansible脚本的自动化能力，我自研了一套极简的 Ansible 性能监控脚本，目标如下：

1. 把性能测试中性能监控的“体力活”彻底自动化
2. 展示ansible的实用性

1. 设计原则

这套脚本的设计原则非常明确：

使用者不需要进行代码开发，只需要配置必要信息即可对多台目标机器及所进行的进程进行监控，只配置以下两样信息就能用：

• 目标机器 IP

• 本地结果目录

2. 能做什么？

这套脚本可以做到：

• 一条命令在所有目标机器上启动监控指令：sar / pidstat / top

• 一条命令在所有机器上统一停止监控

• 一条命令把所有机器的监控结果自动拉回操作机指定目录

3. 使用方式

安装包解压完名称是monitor，进入此目录，编辑hosts配置文件，如下： 使用者只需要：
（1）在hosts文件中配置机器信息，包括独一无二的名称，如machine-1，机器IP，alias与机器名称相同即可；
（2）登录这些机器的用户名、密码，建议统一，比如为性能测试单独建立相同的账户和密码；
（3）配置本地结果目录local_backup_folder，远程机器上的性能监控数据会被拉到本地的此目录下

执行三个脚本：

sh ./start.sh      # 启动监控
sh ./stop.sh       # 停止监控
sh ./fetch_log.sh  # 收集结果

前提：目标机器上需要提前安装sysstat、top、pidstat工具，安装的过程也可以使用ansible进行自动化，本脚本默认目标机器已安装这些软件。后续会考虑加上自动化安装的功能。

4. 带来的改变

这套脚本上线后，性能测试过程发生了明显变化：

• 测试准备时间从“十几分钟”降到“几十秒”
• 多机监控不再遗漏
• 数据统一归档，方便版本对比
• 人可以把精力放在分析结果而不是收集数据

5. 脚本的获取

此脚本是本人自研的小工具，可免费使用，版权所有，请匆传播发放或用于商业用途，为了更好地维护、更新和支持使用者，目前采用 私密发放 的方式。
📌 获取方式如下：

1. 关注我的微信公众号：Hankin-Liu的技术研究室
2. 发送关键词：auto monitor
3. 获取脚本
4. 发送关键词：”性能调优群“，加入技术交流群，可免费解答和交流性能调优相关技术问题。

五、扩展：还有哪些性能测试工作适合用 Ansible？

当你把 Ansible 引入性能测试后，会发现它的适用范围远不止“开监控”。

1. 环境部署

• 一键部署被测系统
• 回滚历史版本
• 切换不同编译参数

2. 配置分发

• 下发压测参数
• 调整系统参数（sysctl、ulimit）
• 切换不同配置组合做对比测试

3. 环境启停

• 启停服务
• 清理现场
• 初始化数据

4. 日志与结果收集

• 自动打包日志
• 按机器 / 版本 / 时间归档
• 汇总到统一分析节点

5. 多机协同类操作

• 多机同时压测
• 多机对同一目标报单
• 多角色节点联动测试

一句话总结：

只要是“多台机器 + 重复操作”，都值得用 Ansible脚本进行自动化、流程化。

六、总结：性能测试工程师，非常值得掌握 Ansible

在性能测试这个领域，真正拉开差距的，往往不是你会不会用某个工具，而是：

• 能不能把流程工程化
• 能不能把经验固化成工具
• 能不能让“人”从重复劳动中解放出来

Ansible 正好是一个投入小、收益极高的技能：

• 学习成本低
• 立竿见影
• 对测试、运维、开发都通用

如果你正在做性能测试，或者经常和多机环境打交道，强烈建议你把 Ansible 作为必备技能之一。
它不会替你分析性能问题，但它会帮你把时间留给真正有价值的事情。
📬 欢迎关注公众号“Hankin-Liu的技术研究室”，收徒传道。持续分享信创、软件性能测试、调优、编程技巧、软件调试技巧相关内容，输出有价值、有沉淀的技术干货。