先承认吧，我们都被“自动化一切”洗脑了
2019年我在上一家公司主导了一次“DevOps转型”，当时老板从AWS re:Invent回来，拍板要上K8s，要全链路自动化。我们组三个运维一个后端，吭哧吭哧把Jenkins流水线拆了重建，上了GitLab CI，搞了ArgoCD，写了上百个自动化脚本。结果呢？三个月后，线上一个配置变更直接引发雪崩——因为我们的自动化发布流程自动把老配置备份给删了，回滚的时候才发现历史版本全没了。那晚我蹲在机房里手动改配置，看着旁边屏幕滚动着“自动化成功”的绿色日志，心里就一个念头：这玩意儿是来帮我的还是来要我命的？
我后来的教训是：自动化从来不是银弹，它甚至是一种负债。你每写一个自动化脚本，就增加了一个需要被维护、被监控、被理解的活物。尤其是那些“临时用一下”的脚本，最后都变成了没人敢碰的定时炸弹。真正的DevOps工程师不是看你写了多少自动化，而是看你能在哪些环节主动踩刹车——比如保留人工审批的关键变更、故意不写某个环境的自动部署、甚至用最原始的手工文档来防止信息熵增。
平台工程？不过是给自动化穿上新马甲的皇帝新衣
这两年“平台工程”概念火得不行，好像不提它就没法混DevOps圈子。我看过太多团队，花半年搭了个内部开发者平台，封装了一堆自服务能力，结果开发者根本不用——因为平台文档写了80页，还不如直接提个工单让运维手动建环境来得快。这问题的根源不是平台不好，而是我们太沉迷于“抽象一切”的工程快感，忘了开发者真正要的是最短路径解决问题。
我见过一个反例：某支付公司把发布平台做得极其完善，每个服务都有标准化的CI/CD模板，参数全部可配置，环境一键申请。听起来很完美对吧？但每次业务方要上线新服务时，他们光是用这个平台配置权限、网络策略、资源配额就得花两天——因为平台把每个细节都参数化了，你得填一堆你以为懂但其实没人懂的字段。最后业务方宁可绕过平台，让运维直接在集群里yaml手工敲。这不是自动化，这是自动化带来的摩擦。真正的平台应该是薄薄的一层，只暴露最少必要抽象，剩下的事让团队自己用原生工具解决。我那句话怎么说来着：如果你需要写一份50页的文档来解释你的自动化平台，那它就不是平台，是另一个需要运维的怪物。
我眼里的DevOps工程师：不是自动化狂魔，而是效率止损师
很多入行新人问我怎么学DevOps，我第一句话永远是：去学怎么手工执行一套流程，把它跑通了，再想自动化。因为如果你不理解每一步的因果和失败模式，你写出来的自动化只是把人的错误变成了机器的错误，而且放大得更快。
比如我最近帮一个客户排查CI卡顿问题，他们用了特别高级的BuildKit缓存策略，但每次构建还是慢。我花了一下午把他们的流水线日志翻出来，发现有个步骤在拉取私有依赖时每次都重新认证，缓存形同虚设。就是因为当初设计流水线的人太信任缓存插件，没想过认证信息过期这个“低端”问题。这种问题你翻遍所有最佳实践文档都找不到——只能靠对底层机制和人的行为模式的真实体感去发现。
所以我现在对DevOps工程师的定义是：能精准判断在哪些环节投入自动化收益最大、在哪些环节引入自动化反而让系统更脆弱的止损师。你会写代码不稀奇，你会设计自愈系统不稀奇，你能在凌晨三点被叫起来时，十分钟内从备份里找回被“自动化”删掉的配置，那才叫本事。
别再三天两头换工具了，先把“不自动化”清单列出来
我见过太多团队，今年从Jenkins迁到GitHub Actions，明年又换到Tekton，每次迁移都耗费大量人力，问他们为什么换，答案基本是“工具链更现代”或“别人都在用”。但工具只是表面，你的交付流水线到底卡在哪？是你的依赖下载太慢？还是测试环境不稳定？还是团队之间协作的地域时差？如果你连这些根因都没摸清楚，换什么工具都是在同一条烂路上开更好的车。
这里我给出一个实操建议：在你写任何自动化脚本之前，先花两周时间人工执行你日常最痛的那个流程——比如从代码提交到生产部署。记录每一步耗时、出错概率、依赖的外部因素。然后找到一个最痛的步骤，只自动化这一步，并且故意保留其他步骤手动。比如你发现配置审核最耗时，那你写个脚本自动生成配置变更报告，但仍然保留人工点“批准”的动作。别小看这个动作，它让你在自动化过程中保留了人对关键变更的知情和判断，很多大型事故就是因为这个“确认”按钮被自动化跳过才酿成的。
另外，我建议每个DevOps团队都维护一份“不自动化清单”——明确写出哪些操作永远不做成自动化。比如：数据库结构变更的首次执行、权限提升操作、故障回滚中的特殊修复。这些操作要么风险极高、要么上下文极强，自动化的收益远小于意外代价。我敢打赌，你能从这份清单里得到的对团队的保护，比你从任何自动化工具库里得到的都要多。
最后说句掏心窝的：这个行业永远在发明新词，从持续交付到DevOps到平台工程到GitOps，但核心从来没变过——让软件交付更快、更稳、更可预测。别被概念带着走，多问问自己：我现在做的这件事，是减少了不确定性，还是增加了新的不确定性？如果是后者，哪怕它是“最佳实践”，也请你停下来。就像我那位老前辈说的：“自动化是仆，不是主。你什么时候把仆人当成了主人，家里迟早出事。”