上周帮前司的老伙计排障，凌晨两点的微信弹出来，我以为是要喊我撸串，结果是他们刚上的生产环境又崩了。
原因说出来都好笑。大促前要扩数据库的白名单，运维小哥手动在控制台点了半天，光顾着给支付环境加IP，忘了同步到订单系统的安全组。流量一进来直接把数据库连接打满，整个下单链路卡了四十多分钟，算下来赔了小六十万。
手动点控制台的账迟早要还
做运维的谁没经历过这种事？
三个运维轮值，每个人的操作习惯不一样，有人改完配置随手记在自己的笔记里，有人改完连个备注都不留。攒到最后，安全组里两百多条规则，没人敢删——你永远不知道哪条规则是哪个半年没维护的项目在用，删错了就是线上事故。
之前见过个更离谱的团队，为了对齐配置，专门拉了个Excel表，每次改完控制台手动填进去。结果有次两个运维同时改了同一个安全组，Excel表的版本对不上，最后为了找出哪条规则是对的，翻了三个小时的操作日志。
说穿了，手动操作的问题从来不是“人会出错”。是没有记录，没有追溯，出了问题连谁改的、改了什么都查不到，只能挨个排查。
基础设施即代码本质上就是解决这个事——把你平时点鼠标的所有操作，用代码写下来，存在Git仓库里。谁改了什么，什么时候改的，改完之后会不会影响其他资源，全有记录。出了问题想回滚，直接提交个历史版本就行，不用对着控制台一条条找差异。
很多人刚接触这个的时候，总觉得这是个高大上的架构改造。真不是。你哪怕就把安全组的规则写成YAML文件存在Git里，每次改完走个简单的审核流程，都比手动点控制台靠谱十倍。
那些被吹上天的最佳实践坑死过人
别信网上那些教程吹的“一套代码管所有环境”的鬼话。
听着特别美好对吧？测试、预发、生产全用同一套模板，配置统一，不用维护多套代码。实际落地的时候呢？
测试环境经常要临时开端口测接口，要改内存参数压测，要是全走代码提交、走流水线审批，光流程就能把开发逼疯。上次见个团队，测试环境改个虚拟机的内存配置，要提MR，找两个开发审，找运维审，等流程走完，开发都下班了，第二天来还得重新改。
还有个常见的坑，就是把基础设施代码和应用代码塞同一个仓库。听着是方便，不用跨仓库找配置，结果每次改个应用的版本号，都要触发基础设施的流水线，平白无故多跑一堆没用的任务。更糟的是，经常因为依赖版本冲突，把整个流水线搞挂，改个应用代码都要等半天才能部署。
我之前还见过个团队，为了追“最佳实践”，上来就用最复杂的工具链，Terraform配Argo CD，还要搞什么策略即代码，所有配置都要走OPA审核。三个人的小团队，光搭这套流程就花了两周，结果实际用的时候，每天要花一个小时处理流水线的报错，真正用来写业务的时间都没多少。
说白了，工具是为人服务的，不是反过来让人给工具当保姆。
小团队落地别搞太复杂
真的，别上来就追求大而全。
先从最容易出问题的部分开始搞就行。比如安全组规则、数据库白名单、负载均衡的转发策略，这些东西手动改最容易出事故，先把这部分用代码管起来，比你搞一堆花里胡哨的东西有用得多。
也别一上来就动生产环境。先把测试环境的配置全迁到代码里，跑通整个流程，知道出问题了怎么回滚，怎么排查，再慢慢往预发、生产迁。上次有个小伙子，刚学了两周Terraform，上来就把生产环境的VPC配置全写了，提交的时候把路由表的规则写错了，直接把整个公司的官网搞挂了两个小时。
还有，别搞那些反人类的命名规则。什么项目名加环境加业务线加负责人，变量名长的能绕屏幕三圈。能短则短，能看懂就行，毕竟以后维护代码的是你的同事，不是来参加命名大赛的评委。
对了，代码评审真的不能省。哪怕是两个人的小团队，改个基础设施配置，至少拉个同事看一眼。别自己改完直接点合并上线，你永远不知道自己是不是漏了个逗号，写错了个IP段。
其实到最后你会发现，基础设施即代码从来不是什么必须完成的KPI，也不是什么要对外吹的技术亮点。它就是个帮你少加几次凌晨的班，少背几次手动操作的锅的工具而已。
别被厂商的营销忽悠了，非要买几十万的平台才能搞。用个开源的Terraform，配个简单的GitLab CI，两三个人的小团队一两天就能跑起来。关键是解决你自己的实际问题，不是为了写代码而写代码。