上周帮杭州做跨境电商的老周擦了次屁股。
大促前一周，运维手动配了三台订单服务的ECS，复制旧脚本的时候漏了一行安全组规则，直接把内网的订单接口暴露在公网。等发现的时候，爬虫已经把近十万条用户的收货地址、手机号爬走了。
真的亏到肉疼。
老周拍着桌子骂，说早知道当初听人劝搞什么自动化运维，也不至于栽在这种低级错误上。我问他，你之前不是说要搞基础设施即代码吗？他挠头，嗨，那玩意儿不是大厂玩的吗？我们就十几个人，用得上？
别把shell脚本当成基础设施即代码
说实话，很多人对基础设施即代码的误解，从一开始就偏了。
老周他们之前也写过一堆批量配环境的shell脚本，存在共享文档里，谁都能改，改完也没记录，上次开错安全组就是这么来的。他以为这就是IaC，其实根本不是。
真正的IaC核心逻辑很简单——所有用来描述、配置基础设施的内容，都以代码形式存在，纳入严格的版本控制，每次变更都可追溯、可复现、可回滚。
你写的shell脚本如果存在没有提交记录的共享文件夹里，改了之后没人知道是谁改的、改了啥、之前的版本是什么，那本质上还是手动运维的变种，只是把敲命令的过程批量执行了而已。
不过话说回来，也没人说IaC就得用多么高大上的工具。你哪怕把配置文件存在Git仓库里，每次改都留提交记录，都比扔在共享文档里强一百倍。
小团队不用一上来就堆全套工具链
我见过太多小团队，一上来就照着大厂的技术栈抄：Terraform+Ansible+Pulumi+GitLab CI+监控告警全套，光搭工具链就花了两周，最后运维嫌麻烦，还是手动配服务器。
真的，别被那些大厂的技术分享忽悠瘸了。小团队搞IaC的核心目标只有一个：把最容易出人命的手动操作给替代了。
你不用一开始就搞什么多环境编排、跨云资源调度，先从最痛的点切入就行。比如老周他们最容易出问题的就是云服务器创建、安全组配置、数据库白名单这三块，那就先把这三块的配置用Terraform写下来，存在Git的私有仓库里，改的时候提个PR，过审了再用terraform apply跑一遍，就这么简单。
不用搞什么自动触发流水线，也不用搞什么资源成本核算，先把“手动敲命令配服务器”这个最容易出错的环节干掉，就算赢了第一步。
有个做创业公司的朋友跟我说，他们之前手动配测试环境，每次新同事入职都要花半天时间装环境、配权限，后来把测试环境的配置全写进IaC，一键就能拉一套一模一样的，省下来的时间够多写两个核心功能了。
别忽略了代码评审的那点作用
很多人搞了IaC之后，以为万事大吉了，代码写完直接push到生产分支，直接跑，结果还是出问题。
老周他们之前就是这样，运维改完Terraform文件，直接合到main分支，自动同步到生产环境，上次就是改配置的时候顺手把数据库的公网访问权限写成了0.0.0.0/0，差点又被爬一次。
其实IaC最容易被忽略的buff，就是代码评审。给基础设施变更加一道人工评审，比你事后花几万块做应急响应划算多了。
不用搞什么复杂的评审流程，就定个死规则：只要是涉及生产环境的配置变更，必须找另一个技术人员过一眼，哪怕花五分钟。
看看有没有安全组开太大、资源配额写错、把测试环境的配置混到生产里的低级错误。就这一条规则，老周他们上个月没出过一次基础设施类的事故。
我之前还见过有团队，把IaC的评审规则写到了CI流水线里：只要PR里出现了0.0.0.0/0的安全组配置，直接打回，必须加备注说明原因才能过。
说白了，基础设施即代码从来不是什么高大上的技术概念。
它只是把运维人员脑子里的经验、容易忘的配置、容易出错的手动操作，变成了所有人都能看到、能追溯、能复用的代码而已。
你不用追求一开始就写得多么完美，哪怕一开始的配置文件丑得要死，能少出一次线上事故，就值回票价了，对吧？