上周跟前同事撸串，他刚从连续一周的大促救火里缓过来，眼下的青黑快垂到下巴。
起因说出来都好笑。大促前三天，运维小哥为了扛流量，临时手动扩容了四台应用服务器，顺带给数据库开了个临时的公网访问端口，方便外面的数据分析团队拉数据。大促结束忙到脚不沾地，谁也没想起把这个端口关了。
结果大促后第二天凌晨，漏洞扫描系统弹了高危告警——那个端口被境外的扫描器盯上，差点拖库。整个运维组从床上爬起来，折腾到凌晨四点才把所有风险点清完。
换作以前，大家可能只会骂一句“这小哥怎么这么粗心”。但那天我们聊到最后都觉得，这种事根本不是靠个人细心就能完全避免的。人在忙到脑子发懵的时候，漏记个步骤太正常了。
别把写配置代码当成最终目标
很多人刚接触基础设施即代码的时候，很容易走偏。
觉得只要把之前手动敲的命令，换成terraform或者ansible的配置文件，就算大功告成。
真不是。
我之前见过一个二十多人的技术团队，把所有生产环境的配置都堆在一个2000多行的main.tf文件里，没有拆分，没有注释，谁也不敢随便动。上个月有个新入职的运维同学，为了加一个新的CDN域名，直接复制粘贴了一段老的配置块，不小心把原来数据库的安全组规则给覆盖了。
等业务侧反馈页面打不开的时候，已经停服了四十分钟。
你看，哪怕你全用代码写了配置，要是写得跟一团乱麻一样，跟手动操作的风险其实没差多少。
基础设施即代码的核心从来不是“把配置写成代码”，而是让所有的资源变更都可追溯、可审计、可复现。你不用靠谁的脑子记着“上次改了哪个安全组”，翻一下git提交记录，谁改的、改了什么、为什么改，全在上面。
别上来就追求跟大厂一样的多层module拆分。小团队有小团队的玩法，只要代码是分模块存的，每次变更都有记录，就已经跑赢了90%还在手动点控制台的团队。
生产环境的操作从来没有小事
之前跟一个做金融科技的团队聊天，他们刚上基础设施即代码的时候，踩过一个特别蠢的坑。
整个团队的代码仓库没有权限控制，所有人都能直接把代码推到main分支，跑apply的时候连plan环节都直接跳过。有个刚实习的同学，照着网上的教程改配置，把生产环境的核心计算实例从高规格的c7实例，换成了便宜的t3突发实例。
代码推上去跑通的那一刻，整个核心交易链路的性能直接掉了60%。下午的用户投诉把工单系统都刷爆了。
说真的，这种坑真的没必要踩。
你根本不需要搭一套复杂到需要专门运维来维护的流水线，只要守住三个最基础的规则就行：
第一，所有涉及生产配置的代码修改，必须走PR流程，哪怕是团队负责人自己改，也要找另一个人过一遍plan的输出，确认没有误操作再合入。
第二，生产环境的apply操作，必须两个人交叉确认，谁也没有单独修改生产资源的权限。
第三，terraform的状态文件必须存在远端的加密对象存储里，别存在自己的本地电脑上。我见过有个哥们电脑硬盘坏了，本地存的状态文件全没了，花了整整一周才把现有线上资源和代码配置对上，那段时间他连企业微信都不敢开。谁要是不信可以去搜搜，多少人因为丢了state文件哭天抢地的。
别为了工具把自己绑死
很多人聊起基础设施即代码，总觉得要把所有的线上资源，从云服务器到负载均衡，从存储桶到监控告警，全部用代码管起来，才算“落地完成”。
说实话，真的没必要。
我之前见过一个团队，为了把所有的监控告警阈值都写进代码，每次业务侧要调整个告警灵敏度，都要走一遍提PR、审PR、跑流水线、apply的全流程。本来在监控平台上点三下鼠标两分钟就能搞定的事，硬生生走了两天流程。
最后业务侧怨声载道，运维也觉得委屈。
工具本来就是为人服务的。
你完全可以挑那种变更频率低、影响范围大的核心资源先做代码化——比如数据库、核心应用集群、安全组规则这些，真要是手动操作错了要出大事的部分。至于那种一年改不了两次的非核心配置，你直接在控制台手动改，反而效率更高。
别硬套别人的最佳实践。适合自己团队节奏的，才是真的好。
上周跟之前撸串的那个前同事聊天，说他们团队现在已经把核心的生产资源都用代码管起来了。
上次大促扩容，运维只需要改一下代码里的实例数量，跑个plan确认没问题，apply下去几分钟就扩完了。大促结束再把参数改回去，连那个临时开的数据库端口，都写在配置里，扩容的时候自动开，缩容的时候自动关。
这次大促，整个运维组准点下班。
没人半夜被电话叫起来补配置。