我对 Linux 以及像 sed、awk、python 这类脚本语言非常精通，几乎到了炉火纯青的地步。这项技能成为了我的一个独特标签，一个让我区别于其他普通程序员的骄傲。所以每次写脚本时，我都不由自主地挺直腰板，仿佛在雕琢一件精美的艺术品。
比如，看到别人一遍遍翻文档手动安装 elasticsearch，我就浑身难受，于是写了下面这个脚本来加速整个过程：
mkdir /data
useradd es -d /data/es
chown -R es:es /data
cat > /etc/security/limits.conf <<EOF
* soft nofile 65536
* hard nofile 65536
* soft nproc 65536
* hard nproc 65536
es soft memlock unlimited
es hard memlock unlimited
EOF
cat > /etc/sysctl.conf <<EOF
vm.swappiness = 0
vm.max_map_count = 262144
EOF
sysctl -p
chown -R es:es /opt/elasticsearch
这种脚本能让我快速抓住软件安装的核心要点，省去阅读冗长文档的时间。类似的事情我一直在做，久而久之，反倒显得自己好像很清闲。
这几天，我发现同事小王一直在捣鼓一个 Excel 文件。这是一堆从其他平台迁移过来的、杂乱无章的数据，大概有三四十兆。不知为何，数据清洗的活儿就落到了他头上。
文件不小，公司的电脑配置却一般。小王每次打开文件，风扇就呼呼作响。他只能一次次使用 Ctrl+F 查找异常数据，再手动复制到另一个文件里。工期紧、数据多，昨晚他一直加班到十一点多。
总监为此还专门表扬了他。
我坐在小王旁边，实在看不下去了。长期养成的习惯让我对低效操作忍无可忍，就像一只常年奔跑的兔子无法忍受蜗牛的爬行速度。
只扫了一眼需求，我就断定这个需要三天的任务，用脚本两小时就能搞定。倒不是我多乐于助人，只是我太享受写这种脚本，以及它带来的那种效率上的巨大反差所带来的快感。
一小时后，我把调试好的 python 脚本交给小王。在 shell 里一运行，正确的文件立刻就生成了。那种感觉，爽！
小王自然对我佩服得五体投地，逢人便吹嘘 xjjdog 多么厉害。
没想到，这事不知道怎么传到了总监耳朵里。我被叫进了他宽敞的办公室。看着他阴沉的脸，我知道不妙，却不明就里。我刚入职不久，应该没触犯什么禁忌，心中满是疑惑。
“听说你帮小王解决了个问题？” 总监开口了， “以后少写这样的东西。”
“为什么？” 我几乎不敢相信自己的耳朵， “脚本能显著提升工作效率啊。”
“就知道你会这么问。” 总监严肃的表情缓和了一些，给我讲了一个关于一位架构师的故事。
小宋曾是公司的架构师。很多“三脚猫”架构师不写代码，所以能写代码的小宋显得尤为珍贵。他的绝活就是写脚本，就像我现在干的一样。
脚本能提升效率，这是我多年坚信不疑的。但“效率”这个词本身，往往难以衡量和量化。即便你把工期从三天压缩到两小时，也未必能证明你的效率高，因为这可能只是众多琐事中的一件，省下的时间也许被用来“摸鱼”了。这种提升，有时反而会打乱正常的研发节奏，甚至“扼杀”了一些想通过加班表现的同学的机会。所以，“提升效率”这种有实际价值的行为，有时反而难登大雅之堂，最终可能只沦为一句口号。
小宋的脚本第一次大显身手是在一次线上事故中。当时，程序有个BUG导致数据库和缓存部分数据不一致。由于缓存分布在二十多台机器上，无法简单粗暴地清空所有缓存。
业务经理很着急，讨论后决定开发一个定时任务，扫描所有缓存和数据库记录进行修正。数据量庞大，程序还需验证，预计修复至少需要两天。
小宋却说，不用那么麻烦。他只需要问题发生期间的所有业务日志。
接下来的三个小时，小宋从日志中过滤出了问题期间所有被更新过的key。稍加思考，他就写了个脚本，精准地删除了这批有问题的缓存，完美解决了故障。
这件事之后，小宋就经常被请去写脚本处理各种疑难杂症。他乐此不疲，来者不拒。
一切似乎都在向好的方向发展，直到一次线上故障的发生。
公司的几百台机器都托管在 AWS 的 EC2 服务上。使用 EC2 提供的 API 可以做很多事，但原生命令实在太难记。于是，小宋对其进行了封装。
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html
用这个脚本，可以批量管理部分或全部机器（比如添加安全组、调整权限等），无需登录繁琐的管理后台。每次看到黑色屏幕上流淌的字符，小宋都觉得，这就是效率的魅力。
脚本太好用了，于是逐渐流传开来。一位运维拿到了脚本，鬼使神差地想在生产环境“验证”一下。
他向所有机器发送了关机指令。
公司瞬间炸开了锅，扯皮推诿在所难免。但最终的矛头，指向了小宋。
脚本是他写的，而他首先是一名架构师。架构师可以不出活、不写代码，但必须有强烈的风险意识。
“但这些命令不是我提供的啊，是 AWS 平台自带的，我只是封装了一下。测试这些危险命令，和用不用我的脚本没有直接关系！” 小宋争辩道。
但命令确实是通过他的脚本发出去的，也的确造成了严重后果。背后那些复杂的责任链条，没人愿意深究。那些曾经享受小宋脚本便利的同事，此刻也选择了沉默。因为“责任”和“效率”一样，很多时候都是模糊地带，没有明确标准。
这类事情，小宋也经历过不少。比如提供了 redis 管理脚本，就有人非要运行 FLUSHALL；封装了 docker 命令，就有人喜欢调用 docker system prune -a 来清理。根本防不胜防。
他认为，这是使用者水平的问题，而非脚本的过错。与总监大吵几架后，小宋一气之下，愤然离职。
他删掉了公司所有人的联系方式，彻底消失了。
“所以，我是为你好，才这么要求你。相比可能引发的风险，那点效率提升，真的微不足道。” 讲到这里，总监意味深长地看着我。 “我这是在及时制止你，免得你步小宋的后尘。”
我点点头，道理我懂。以前有家公司，觉得 Linux 学习成本高、命令危险，宁愿花钱买授权、忍受各种不便，也要选择 Windows 做服务器。把“风险”二字挂在嘴边，逻辑是相通的。
突然间，我感觉自己多年的信仰要崩塌了。花了那么大力气把命令行学精，最后却被告知“学无所用”，真是莫大的悲哀。
“总监，不好了！” 就在我想说点什么的时候，一个小伙子闯了进来， “线上有人用 ansible 练手，把根目录权限全改成 000 了！”
我脑子里立刻浮现出那个命令，看来这次锅得 Linus Torvalds 背了。
chmod -R 000 /
没想到总监却笑了。 “你刚来，不了解情况。这个月都发生好几回了。是时候换成更安全可靠的 Windows 了，我认识采购的人。”
我微笑着点头，不置可否，但“虚心”受教。
我灰溜溜地回到工位，长叹一声。看来，公司找不到 Linus Torvalds 问责，但可以找到我。毕竟，ansible 这个自动化运维工具，是我前几天刚推荐给大家的。
今天就把辞呈交了吧。作为技术人员，我们总是在追求极致的效率与优雅，但在某些环境下，这种追求本身可能就是最大的“风险”。
那么，如果你是一名架构师，在离开时，又会选择留下怎样的脚本呢？这背后的思考，或许比脚本本身更有价值。技术道路上的点滴心得与踩坑经历，也欢迎来 云栈社区 与更多同行交流分享。
发表于 20 小时前
|
查看: 2|
回复: 0
