我做过很多没用的轮子，但有一个例外。它一共 130 行，从写完到现在跑了两年多，我几乎每天都用。
它解决的是一个很蠢的问题
那阵子我负责的服务分布在四套环境，日志分散在若干台机器上。每次排查问题的流程是这样的：打开跳板机、想一下这个环境的机器地址是哪几台、逐台登录、切到日志目录、按日期找文件、用关键字过滤、再把结果拷回本地看。整套动作大概三到五分钟，一天要来回七八次。
更烦的不是时间，是它打断了我的思路。我脑子里正想着某个可能的原因，一开始敲那些机械命令，等结果出来，刚才那个念头已经跑了。
它的演化过程
第一版就是个别名，把最常用的那条命令固定下来，写死了一台机器。用了两天就不够，因为要查另一台。
第二版加了参数：第一个参数是环境名，第二个是关键字。脚本里维护一张环境到机器列表的映射，循环登录、并行执行、结果带上机器名前缀汇总输出。这一版就已经能省掉大半时间了，我写它花了不到一小时。
第三版是我最喜欢的改动：加了交互式模糊选择。因为环境名我总记不住到底叫预发还是灰度，每次要翻脚本看。加了模糊选择之后，敲两个字母，列表里挑一个回车，不用记了。这个改动技术含量为零，但体验提升最大。
第四版把配置从脚本里拆出来，放到用户目录下的一个配置文件里，这样脚本本身可以分享给同事，各自填自己的配置。后来组里五个人都在用，还有人给我提了功能：支持按追踪标识跨机器串起来输出，按时间戳排序。这个功能是同事贡献的，我到现在还挺得意——一个工具被别人主动改，说明它真的有用。
我算过一笔账
按每天八次、每次省三分钟算，一天二十四分钟。两年下来是一百多个小时。但我觉得这个算法有点自欺欺人，因为省下的时间并不会被我用来做更有价值的事，多半就是刷会儿手机。
真正的收益是另一个：因为查日志变便宜了，我查得更勤了。以前一个可疑但不确定的猜想，我会因为验证成本太高而放弃，先猜一个更省事的方向。现在敲三下就能验证，我愿意把五个猜想全部验一遍。排查问题的质量提高了，这是省时间之外的东西。
也有翻车的
我还写过一个「聪明」的工具，能自动分析日志、聚类相似错误、给出可能原因排序。写的时候很兴奋，用了两百多行，有配置有插件机制。结果三个月后再打开，我自己都想不起来那个插件接口是怎么设计的，改一个小逻辑要读半天代码。最后我把它删了。
这两个工具的差别，我后来想明白了：好用的那个，做的事情我自己心里完全清楚，工具只是替我敲键盘；翻车的那个，做的事情我自己都没想明白，指望工具帮我想。
我现在写小工具的三条自律
- 先手动做十次，确认流程稳定了再自动化。流程还在变的时候写工具，等于给移动靶画框。
- 不超过 200 行。超了就说明我在解决一个不该用脚本解决的问题。
- 失败时把原始命令打出来。这样工具坏了我也能立刻手动接管，不至于被自己的工具卡住。
最后这条是血泪教训——有次脚本因为一个环境变量没设静默失败，返回空结果，我对着空日志找了二十分钟的「不存在的问题」。