自动化脚本的一些思考：一个成都程序员的上岸心路
作者：一个正在准备考公、每天和Shell/Python死磕的成都打工人
写于2024年5月的一个加班夜，窗外是熟悉的玉林西路小酒馆灯光
去年十月的一个周五晚上，我瘫在工位上，盯着屏幕上第17次失败的自动化部署日志，差点把键盘砸了。
那天本来计划七点下班——毕竟老婆说好了一起去吃巷子口那家开了二十年的蹄花汤。结果呢？运维同事临时请假，测试环境崩了，老板在群里@我说：“小李，你不是会写脚本嘛？能不能搞个自动化的方案，以后别老手动跑部署了？”
我苦笑。会写脚本？是啊，我确实会。但“能用”和“可靠”之间，隔着一条岷江。
那天晚上十点半，我才拖着疲惫的身体走出公司大楼。成都的秋夜微凉，地铁末班车快停了。我一边等滴滴，一边刷朋友圈——看到前同事晒出他跳槽后22k的offer，而我月薪还是15k，房租3500，娃的奶粉钱每月1800。那一刻，我真的焦虑到想哭。
我不是技术不行，我只是困在一个低工资、高重复劳动的死循环里。
从“能跑就行”到“不敢上线”
刚入行那会儿，我也以为写自动化脚本就是“把命令堆一起，跑通就行”。比如下面这种经典操作：
#!/bin/bash
git pull origin main
npm install
npm run build
scp -r dist/ user@server:/var/www/html
看起来没问题对吧？直到某天，git pull 因为冲突卡住，脚本挂了；或者 npm install 网络超时，build目录没生成，结果把空文件夹传上生产服务器……客户投诉电话直接打到老板手机上。
那次事故后，我被叫去开了三次复盘会。HR还委婉地问：“小李，你是不是最近状态不太好？要不要调休几天？”
其实我状态挺好的，就是技术债堆得太高了。自动化不是“省事”，而是“把风险提前暴露出来”。 这句话，是我用两次线上事故换来的教训。
后来我开始认真研究“健壮”的自动化脚本。加日志、加异常处理、加回滚机制。比如现在我的部署脚本会这样写：
def deploy():
try:
backup_current_version()
git_pull_with_retry(max_retries=3)
run_tests() # 关键！先跑单元测试
build_artifact()
sync_to_server()
health_check() # 验证服务是否真的起来了
except Exception as e:
rollback()
alert_on_slack(f"部署失败: {str(e)}")
raise
看似多写了几十行代码，但换来的是半夜不用被电话叫醒。
面试题里的“陷阱”：你以为的自动化，可能只是玩具
今年春招，我偷偷投了几家大厂（别告诉老婆，她说我现在应该全力备考公务员）。有一轮技术面，面试官问我：
“你平时怎么保证自动化脚本的可靠性？”
我自信满满地讲了日志、重试、回滚那一套。结果他微微一笑，问：
“如果脚本本身有逻辑错误，比如把‘删除旧文件’写成了‘删除所有文件’，你怎么防？”
我愣住了。这不就是传说中的 rm -rf / 事故* 吗？
后来我查资料才知道，真正成熟的自动化体系，脚本本身也要被测试、被版本控制、被权限隔离。比如用 Docker 容器跑脚本，限制文件系统访问范围；或者用 Terraform 这种声明式工具，而不是直接执行命令。
这件事让我意识到：很多程序员（包括曾经的我）把自动化当成“提效工具”，但高手把它当成“安全系统”。
区块链？别笑，它真和脚本有关！
说到这儿，你可能会问：文章标题不是要提“区块链”吗？这玩意儿和自动化脚本有啥关系？
还真有。
上周我在图书馆刷题（对，我在备考行测，但技术不能丢），翻到一本《区块链原理与实践》。里面提到一个概念：智能合约（Smart Contract）本质上就是一段自动执行的代码。
比如以太坊上的合约，一旦部署，满足条件就自动转账、发币、更新状态——没人能干预，也不能反悔。
这不就是“终极自动化”吗？
虽然我现在的工作用不到区块链，但它的设计哲学给了我很大启发：自动化脚本的核心，不是“快”，而是“确定性”和“不可篡改性”。
所以现在我写脚本，会尽量做到：
- 输入明确（比如用配置文件，而不是硬编码）
- 输出可验证（比如生成校验和）
- 执行过程可追溯（完整日志+时间戳）
哪怕只是一个备份脚本，我也当成“微型智能合约”来对待。
考公路上的技术人：我们不是放弃，是选择
很多人不理解，为什么一个程序员要去考公务员？尤其在成都这种新一线，互联网岗位也不少。
但现实是：35岁危机不是段子，是悬在头顶的剑。
我和老婆算过一笔账：按现在15k的月薪，扣除五险一金、房贷、育儿支出，每月能存下的不到3k。而成都一套像样的学区房，首付至少60万。靠打工，一辈子都追不上房价。
更重要的是，我越来越觉得，技术不该只是谋生的工具，而应该是让人活得更从容的手段。
公务员考试很卷，但我发现，写脚本练就的“拆解问题 + 严谨执行”能力，在行测和申论里居然也用得上。比如资料分析题，我习惯用 Python 快速计算增长率；申论写对策，我会像写函数一样分步骤、列边界条件。
技术分享不是为了炫技，而是为了把复杂变简单，把混乱变有序——这不正是公共服务的本质吗？
给还在折腾脚本的你：几点真心话
如果你也在写自动化脚本，不管是为了工作、面试，还是单纯想偷懒，我想分享几点血泪经验：
别追求“全自动”，先做到“半自动+人工确认”
很多事故源于过度信任脚本。关键操作（比如删库、发版）加个read -p "确认执行？(y/n)"，能救你命。日志不是可选项，是救命稻草
我现在每个脚本开头都加：exec >> /var/log/my_script_$(date +%Y%m%d).log 2>&1。出问题时，这是唯一能还原现场的证据。用版本控制管理你的脚本
别再用U盘拷来拷去了！哪怕只有你一个人用，也请放到 Git 仓库。git blame比“谁动了我的脚本”高效一万倍。面试官爱问“如何测试脚本”
准备一个答案：比如用 Mock 数据、隔离环境、断言输出。这比背八股文更能体现工程素养。技术是手段，不是目的
写脚本是为了让自己有更多时间陪家人、学习、甚至备考。别本末倒置，变成“为了自动化而自动化”。
尾声：在成都的慢生活里，做自己的“自动化引擎”
写完这篇稿子，已经是凌晨一点。窗外玉林路的酒吧还没打烊，但我的闹钟定在了六点——早上要送娃上幼儿园，然后去图书馆刷题。
我知道，从程序员到公务员的路很难。但我更知道，无论身份怎么变，解决问题的能力不会贬值。
自动化脚本教会我的，从来不是几行代码，而是：把重复的事交给机器，把创造的事留给人。
或许未来的某一天，我不再写 Python，而是坐在窗口为市民办理业务。但当我面对一堆繁琐表格时，我依然会想：“这里能不能做个自动化流程？”
因为真正的自动化，不在服务器里，而在人的思维里。
后记：如果你也在成都，也在技术与体制之间徘徊，欢迎留言聊聊。也许我们能在IFS楼下的星巴克，一边喝38块的拿铁，一边讨论怎么用 Shell 脚本自动生成行测错题本（笑）。
共勉。
评论 0