我一开始压根没想过要“救赎”啥的，就是想把手头这摊破事儿捋顺了。这事儿得从我前年换工作说起。
那时候我还在一家小厂做运维，天天累得跟狗一样，关键是公司技术栈老得掉渣，干啥都是修修补补，一点成就感都没有。我心里憋着一股劲，总觉得我还能干点别的，就是没找到那个门路。天天刷招聘网站，看那些高大上的需求，心里干着急。
入了行，才发现坑在哪儿
后来我咬咬牙，报了个线上培训班，学了点现在所谓的“DevOps”皮毛。学完就投简历，运气进了一家号称在搞“数字化转型”的公司。刚进去那会儿，我觉得自己像是得了宝，终于能施展拳脚了。
刚开始我是负责一个内部工具链的搭建。我兴冲冲地拉起 Jenkins，想着自动化部署那套流程跑起来。结果？上线第一天就懵了。老版本的代码部署脚本还在用几十年前的 Shell 写的，各种路径硬编码，参数写死在文件里。我尝试用 Ansible 去统一管理这些配置，结果配置中心那边的人死活不同意，说他们那套流程跑了这么多年了，动一下怕出乱子。
我费了九牛二虎之力，天天找那帮老员工磨嘴皮子。我跟他们解释新流程的好处，他们就回一句：“我们以前都是这么干的，没出问题。” 整个过程就是我一个人在前面跑，后面的人拽着裤腿往后拉。
我当时就感觉不对劲了，这哪是转型？这简直是旧瓶装新酒，而且酒还不是新的。我每天的工作重心都从“实现自动化”变成了“说服别人接受自动化”。
第一次“救赎”尝试的失败
为了证明我的新工具链靠谱，我决定找个没人管的边缘业务下手。我挑了一个快被淘汰的内部系统，偷偷摸摸地把它的 CI/CD 流程用我新搭的平台跑通了。我花了整整一个月时间，把所有环境配置、测试脚本全自动化了，部署时间从原来的半小时硬生生压缩到了五分钟。
我满心欢喜地找老板邀功，以为能换个部门，或者至少让大家重视一下。结果老板看了一眼报告，点了点头，然后说：“不错，你先把那个老旧系统的部署文档更新一下，记得要详细点，免得以后别人接手的时候看不懂。” 完了，就没了。我的自动化成果，变成了“让别人能看懂老流程的文档”。
那一阵子我特别丧，感觉自己所有的努力都白费了，公司根本没有想改变的意思，大家图的就是个安稳，谁愿意折腾？我开始怀疑自己是不是真不适合搞这些前沿的东西，是不是该老老实实找个安稳的工作混日子算了。
抓住了真正能“救赎”的机会
转折点发生在我被派去支援另一个项目组的时候。那个组的项目是给外部客户用的，代码质量奇差，BUG 满天飞，客户天天催着要修复，搞得团队压力山大。我这个“运维背景”的人被塞进去救火。
我进去后没急着修 BUG，先花了两周时间通读了他们的代码结构和发布流程。发现他们的问题不在于代码本身有多复杂，而是测试覆盖率几乎为零，每次发布都像开盲盒。
这回我学乖了，不搞大的，我只盯着“发布这个环节”。我没有和任何人争论用什么技术，而是直接拿出那套老旧系统的部署脚本，用我熟悉的工具链，把他们最频繁出问题的那个模块，从头到尾用自动化跑了一遍。
- 我拆分了发布流程，把数据库迁移和应用重启拆成了独立的步骤。
- 我强制要求所有配置必须走参数文件，不接受任何现场修改。
- 我甚至自己写了个简单的界面，让测试人员点一下按钮就能触发回滚操作。
关键是，这回我没去争取“创新”，我直接“解决问题”。客户那边看到发布速度快了，而且出了问题能快速退回去，他们满意了。团队里的人也看到了实实在在的好处，抱怨声慢慢少了。
这算是我第一次真正体会到“救赎”是什么感觉——不是搞得多高大上，而是把眼前最痛的点给解决掉，让大家的生活能过下去。这回成功后，我才慢慢被允许把这套流程推广到其他模块。虽然过程还是很慢，但至少方向对了。我明白，真正的改变，是从解决最迫切的痛苦开始的，而不是空喊口号。
