获课：shanxueit.com/12450/

运维脚本跑不过三台机器：我是怎么用Go破局的

做了几年运维，我手里积累了一大堆脚本。Shell写的、Python写的，五花八门。它们在我的"个人工作环境"里跑得飞起，各种依赖装得整整齐齐，环境变量配得妥妥帖帖。但只要把脚本扔到另一台机器上，几乎必然出问题——Python版本不对、某个库没装、系统命令路径不一样、环境变量没配……每一次"就过去跑一下"都变成了一场环境灾难。

直到我开始用Go重写这些运维工具，这个困扰我很久的问题才算真正解决。这不是某个新技术带来的兴奋，而是一种实在的解放感——编译完扔过去就能用，这种感觉让我重新思考了运维工具开发这件事。

脚本语言的便利，也是它的枷锁

先说清楚，我不是在否定脚本语言。Python和Shell写运维任务的开发效率确实高，几句话就能搞定文件处理、文本解析、API调用。这种"随手就能写"的便利性让我在过去几年积累了大量的运维脚本，它们是帮我解决过一个又一个具体问题的功臣。

但问题出在"分发"这个环节。脚本语言的本质是"源代码+解释器+依赖库"的组合。你在A机器上能跑，是因为那台机器上刚好有所有运行时条件。换成B机器，条件不一定成立。Python脚本可能依赖十几个第三方库，用pip freeze导出依赖列表看起来简单，但在离线环境里装过的人都知道那有多痛苦。Shell脚本更依赖系统命令的兼容性——同样的逻辑，在CentOS上能跑，到了Ubuntu上命令参数可能就不一样了。

我印象最深的一次是在一个客户的内网环境部署一套日志采集脚本。开发的时候在本地CentOS上用Python3.8开发完，结果客户的机器是旧版的CentOS，自带的Python还是2.7，而且内网不能联网装新版本。我只能把脚本用Python2的语法重写一遍，改了一堆不兼容的地方，折腾了大半天。类似的"环境不匹配"导致的返工，在这几年里至少经历了十几次。每一次都在重复同样的痛苦：我的脚本本身没问题，有问题的是它跑不起来的环境。

Go的跨界属性：运维世界的"通用语言"

接触Go之后，我最大的感受是：它好像天然就是为运维工具分发设计的。编译成静态二进制文件之后，没有任何运行时依赖，拷到目标机器上直接执行。不需要目标机器上有Go环境、不需要装任何库、不用管操作系统版本差异——只要CPU架构和操作系统匹配就行。

第一次体会到这种"拷过去就能用"的爽感，是在做一个跨平台的文件同步工具时。我开发用的Mac，目标机器是Linux amd64服务器。在Mac上执行一条交叉编译命令：GOOS=linux GOARCH=amd64 go build，拿到一个二进制文件，scp传到服务器上，直接运行。全程不到一分钟，没有任何依赖安装的步骤。这在之前用Python的时候，光是装依赖就得折腾好一阵。

更让我觉得踏实的是，Go程序对系统环境非常"脱敏"。不需要特定的Python版本、不需要设置PYTHONPATH、不依赖系统里装了哪些命令。唯一需要关心的是目标机器的操作系统内核版本是否满足要求。这种"几乎不挑环境"的特性，让我在交付运维工具时，再也没有"这个机器能不能跑"的担忧。打包即交付，交付即运行，这六个字说起来简单，但对运维来说意味着巨大的确定性。

并发任务不再束手束脚

运维脚本的另一个痛点就是并发能力。Shell脚本做并发基本靠后台进程和wait命令，但很难精细控制并发数。Python的多线程受GIL的限制，多进程又太重，做几百个节点的批量操作时总在并发控制和资源消耗之间纠结。

Go的goroutine处理这个问题显得特别自然。几行代码就能起成百上千个轻量级协程去同时处理不同的目标机器，配合channel做结果收集和限流控制，代码结构清晰，资源开销还小。我用Go重写了一个之前用Python写的批量命令执行工具，同样执行300台机器的命令，Go版本完成的时间比Python版本快了将近四倍，而且内存占用还更低。

这种性能上的提升在运维场景里感受特别明显。批量操作是运维的日常工作，以前跑一个批处理脚本要等很久，中间还不能中断，人就得干等着。现在同样的任务跑得快了，而且资源占用少了，可以和其他任务并行执行。运维效率的提升，很多时候不是靠优化单条命令的执行速度，而是靠把并发能力提上去，把等待时间降下来。 Go在这方面的优势是实打实的。

运维开发的经验沉淀变得更容易

用Go重构运维工具的另一个意外收获，是"代码的长期价值"变高了。

以前用Shell和Python写脚本，习惯是"够用就行"。因为写的时候就预期这东西可能用几次就扔了，或者环境变了就废了，所以不会花太多心思在代码结构和可维护性上。结果就是，很多脚本过几个月再拿出来看，自己都看不懂了，更别说修改。

Go相对严格的代码结构和类型系统，逼着我写出更规范、更有组织的代码。一个运维工具从"随手写的脚本"变成了"经过设计的程序"。哪怕几个月后再拿出来看，清晰的包结构、明确的类型定义、规范的错误处理，让理解和修改的成本都大大降低。

更重要的是，因为Go程序的跨平台特性，一个工具写出来可以持续在不同的项目里使用，不会因为环境变化而报废。这种"一次编写、长期复用"的属性，让我愿意花更多时间去打磨代码质量，因为我知道这份投入是有长期回报的。沉淀下来的不再是碎片的脚本片段，而是可积累、可演进的技术资产。

运维开发的范式转移

从脚本到Go程序，表面上是换了一种编程语言，本质上是运维开发的一次范式转移。以前的方式更像是"写一次性作业单"，每个任务单独写个脚本，跑完就扔。现在的方式更像是"构建持续可用的工具集"，每一个程序都是精心打磨过的、可以在不同环境中反复使用的、可以持续迭代改进的正式作品。

这种转变让我对运维开发这件事有了新的认知：运维工具不是一次性消耗品，它应该是可以被持续投资的技术资产。而选择Go作为实现语言，就是给这些资产赋予了"跨环境生存的能力"和"长期演进的空间"。

如果你也还在为脚本在不同机器上跑不起来而加班，试着用Go重写一个你最常用的运维工具，感受一下那种"编译完拷过去就能跑"的踏实感。这道坎迈过去了，你的运维工具箱才算真正准备好了。