跑在Git提交记录里的基础设施即代码

去年6月在杭州出差，凌晨三点被朋友的电话直接炸醒。他是一个垂直电商团队的运维负责人，当天为了618大促的流量峰值，团队两个人熬到两点，手动在阿里云控制台开了12台应用服务器，配安全组的时候漏了两台的内网端口放行。

订单服务打过去全超时。

真的疼。本来算好的扩容成本白扔了不说，平台按峰值缺口扣了他们团队几万块的流量损失，本来大促的奖金直接扣没了一半。

手动点控制台的账，迟早要还

我陪他坐在酒店走廊的台阶上复盘的时候，他翻出来三年来的事故记录，近六成的线上故障，都和手动配置的偏差有关。有次测试环境的Redis密码被复制到生产，差一点被爬虫扫走存了半个月的用户行为数据；有次扩容的时候把磁盘挂载点配错，日志写满系统盘导致服务直接宕机；还有次调整负载均衡规则的时候，把内部管理后台的入口直接暴露到公网，被扫描器扫到之后差点出安全事故。

这些事说出来都不是什么技术难题，全是靠人肉记忆、靠表格记录、靠截图留证攒出来的隐患。你今天记得安全组要放3306端口，明天可能漏了开监控的上报端口，后天新来的同事按照文档操作，少勾了一个”强制HTTPS”的选项，前面所有的积累全打折扣。

别把它当成运维一个人的事

很多团队第一次接触基础设施即代码的时候，第一反应是”这是运维的活，让他们写脚本去就行”。

大错特错。

我见过太多团队踩过这个坑：运维同学花了两周时间写了全套的Terraform脚本，把生产环境的所有资源全迁到代码里，然后把这些代码存在自己的本地文件夹里，连Git仓库都没提交。后来这个同学离职，新来的运维看着满屏幕的.tfstate文件根本不敢动，上次要给新上线的营销活动加个临时的弹性伸缩组，折腾了三天都没敢碰原有的配置逻辑，怕改崩了影响全量业务。

基础设施即代码的核心从来不是写几段可执行的脚本，是把所有环境变更的决策权交还给整个协作团队。每一次服务器的扩容、安全组的调整、存储卷的挂载，都要像业务代码一样走PR评审、走测试环境验证、走版本回溯。哪个团队成员提了变更需求，为什么要改，改了之后影响哪些业务，全在代码提交记录里写得明明白白，再也不用翻三个群的聊天记录找半年前谁改了哪条规则。

不过话说回来，也真不能怪开发同学抵触。之前谁没被运维临时喊过去，手动改过一次生产环境的配置，改完还要拍个截图留证，跟做贼似的。现在把这些规则都搬到代码仓库里，谁提的变更，谁评审的，什么时候上线的，全有记录，出了问题直接回滚到上一个版本就行，比之前靠人肉记的状态靠谱一百倍。

落地的时候别上来就追求完美

我见过太多团队一上来就喊着要”全量基础设施即代码改造”，买了几十万的商业平台，招了三个专门的工程师负责治理，结果折腾了三个月，一半的资源迁了代码化的管理，一半的还留在控制台手动点，两边的配置对不上，反而出了更多的配置漂移问题。

真没必要。

你先从变更最频繁、最容易出错的资源下手就行。比如弹性伸缩组的配置、安全组的规则、负载均衡的转发策略，这些东西你每个月都要改好几次，每次手动点都可能错，先把这部分用代码管起来。剩下的那些跑了三五年、半年都不动一次的老服务器，完全可以等下次有业务变更的时候再慢慢迁，不用急着一口气吃成胖子。

当然，它也不是什么银弹。如果你团队连基本的代码评审流程都没跑顺，提交了PR都没人看，那就算把基础设施全写成代码，最后也只会变成另一个谁都不敢碰的黑盒。

上次和那个杭州的朋友再见面，是三个月后，他们团队现在所有的变更都走Git提交，上次大促补扩容20台服务器，从提PR到全部机器配置完成上线，一共花了17分钟，没有一个人碰过控制台的配置界面。

他说现在终于不用在大促的时候定凌晨三点的闹钟了。