越简单重复的事情越要自动化做

最新推荐文章于 2024-11-12 23:15:59 发布

weixin_47143210

最新推荐文章于 2024-11-12 23:15:59 发布

阅读量151

点赞数

文章标签： python java 大数据 linux 人工智能

原文链接：https://mp.weixin.qq.com/s/8tBBg55Exd8NICciEdVkcw

版权

最近一次性能测试自动化脚本过程思考

我不记得跟我的客户提过多少次，DevOps&工程师文化成功的一个最佳实践就是自动化一切，但往往事情落到自己身上，有时又不断后退后退到不能再退的时候才想起来要实现自动化，尤其这件事情手工做一次又不算太复杂的情况。

比如最近，团队张罗着做云主机的性能测试这件事情，大多数的反馈就是用 Sysbench 跑下，本身脚本很简单，起个机器啥的技术上也没啥含量，人工完成几个机型的测试，对于个人来说，不会有大多工作量；

那需求来了：

如果需要测试多家云厂商，工作量直接跟覆盖的云厂商成正比
测试机型的数量受到小组人力资源数量限制
云主机是不断迭代更新的，后续怎么保障性能数据持续更新？
如果客户需要测试方法，提供什么方案给客户？
测试结果分析能否自动化对比产生报告？

怎么办？再来一遍~~~[图片上传失败…(image-cf0a07-1587539157911)]

单机测试的简单与重复

跑 Sysbench 虚机性能测试有多简单呢？参考如下脚本：

sysbench --time=20 --threads=4 --report-interval=5 cpu runsysbench --threads=2 memory run

再加上 Sysbench 安装呢？也两行 Shell 搞定：

# For Unbuntu Linuxcurl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bashsudo apt -y install sysbench

那我们回到单机测试，需要做哪几个步骤来完成？

根据规格参数启动一个云主机，比如相应的操作系统，实例类型和大小
登陆云主机
安装测试工具，并跑测试命令
等测试结束，保存测试结果
关闭云主机

我相信这个任务交给一个小组成员，完成几个不同机型的测试，一般还是非常欣然的接受的。

如果测试任务输入变量有变化的时候，这个时候多人协作做重复的事情，效率还是蛮高的：

测试的云厂商数量变多
测试方法增加
测试机型增加

人工重复劳动到全自动化脚本之路

什么阻碍了大家第一时间去实现自动化？我想到几个阻碍我自己的：

该事情本身手工不复杂
自动化的代码工作量超过该事情简单的一次手工操作
偷懒

就比如云主机性能测试这个任务来说，哪怕一次测试 3个云厂商，涉及 10个机型，总计 30次手工任务，如果仅仅执行 Sysbench 测试，相对每次执行时间短，出结果快，每次任务假设 30分钟，顺序做完，总计需要 30 x 30 = 900 分钟 = 15 小时，再偷懒，一个人一个正常的工作周（每天3个小时）就可以完成，这中间还有些手工操作并行优化的空间。

自动化这个任务有多复杂呢？

首先，有大量的单机类性能测试要求，远远不止 CPU/内存这一类，哪怕就这个领域，类似 Sysbench 这样的 CPU 性能测试工具和不同测试用例就有若干种，比如 geekbench，bonnie++，namd,x264/x265,7-zip,openssl,povray 等等；延伸开来，比如内存，磁盘，数据库等等，就会有更多的测试用例，要覆盖如此多的测试需求，哪怕安装和测试命令再简单也要重复无数次啊；哪有没有一个 All-in-One 的框架呢？后来就发现在 AWS 白皮书里面提到一个 Phoronix Test Suite 框架，该框架很有意思底层用 PHP，包装了很多测试用例，比如所有针对 Linux 操作系统的测试用例，直接一行命令解决：

./phoronix-test-suite batch-benchmark pts/linux

研究到这里，核心的测试脚本基本搞定，剩下的一个小问题就是，如何把测试结果统一保存到一个集中的地方？因此对象存储桶就是一个完美的选择，任何可以访问互联网的机器，都可以比如借助 S3 命令行，把测试结果（通常是文本或json格式文件）上传到一起。

也就是说，对于某种特定的操作系统，我们利用类似 phoronix-test-suite 这样的工具可以只生成一个测试脚本；

其次，测试脚本有了，剩下的任务就是自动化启动虚机，并找到一个合适的方式远程执行该测试脚本。

这就是前面提到的，单机测试任务的支撑域要求，这部分比测试脚本本身的代码量要大，只有在云上才能比较容易实现这样的基础设施即代码，因为云API 是新的IT基础设施，需求里面提到我们要能测试不同的云厂商的云主机，最好的一个办法就是找到一个统一的方法可以支持多家云的自动化任务。

在我的实验里面，很容易就选择了 Terraform，因为以前用过，而且支持所有主流云平台；

启动一台云主机，最简单的方法是，所有的参数都默认，这样通常该主机会放置在默认的 VPC的一个公有子网中，可以访问互联网，各自平台的差异点在于，主机的机型类别，操作系统镜像，磁盘类型等等。

自动执行测试脚本的方法每家云厂商可能有些差异，比如 AWS 就可以将脚本注入到 User Data，在机器启动后即可自动执行，其他主流云平台虚机通常都支持 cloud-init 在主机启动后执行相应的脚本代码亦或者利用 SSH 远程登录并执行指定的脚本。

最后，就是完全自动化销毁所创建的测试资源，这里遇到一个难题就是测试脚本或虚机如何通知脚本已经成功执行完成？简化策略就是要求所有测试在 6个小时结束，启动后6个小时，利用 Terraform 命令一键销毁所有的资源。

架构扩展性及效果

自动化之后，跑一个测试就简化成如下一次调用，以 AWS 实例为例，输入参数为区域，机型以及AMI ID，还有一个必要的参数是最后结果保存的 S3 存储桶名：

launchPhoronixTest ap-northeast-1 c5.large ami-03344c819e1ac354d

这个架构满足所有单机类测试的扩展，测试脚本本身和云平台主机独立演进，按需增加新的云平台，测试脚本一般跟操作系统相关，可以独立开发调试后，利用本框架自动化部署执行。

本框架已经完成并在 AWS 平台的测试验证成功，从手工到自动化里面还有很多小坑，不一一赘述，后续团队会继续完善对其他平台的支撑，包括进一步优化，比如对于成本，在 AWS 上尽量采用竞价实例，更好的脚本执行结束通知机制，测试即服务包装成对外的 API 甚至 Web 交互界面，后续数据分析的自动化等等。