基础设施即代码是给团队留的安全垫

上周帮杭州那个做家居电商的团队排障，大促倒计时72小时，值班的运维小哥熬了两个通宵，手动在云控制台点了14台弹性服务器，配完才发现其中4台的公网带宽选了1Mbps的最低档，离要求的100Mbps差了十万八千里。临时改配置吧，系统提示已经触发了单账号的带宽配额上限，要申请提额得走三个工作日的审批流程。那天晚上整个团队的人都在会议室里坐着，运营的小姑娘眼睛都红了，就怕攒了三个月的大促流量因为几台破服务器接不住。

别把写脚本等同于搞定了基础设施即代码

很多人对这件事的认知，还停留在“把运维手动点控制台的步骤，写成Terraform或者CloudFormation的脚本，扔到代码仓库里就算完事”。

真的不是。

我见过最离谱的一个团队，写了整整3000行的Terraform脚本，所有配置硬编码在一个文件里，谁都能直接改，改完直接apply到生产环境，连个提交记录都没有。上次出问题的时候，没人说清楚到底是谁把生产环境的数据库端口开放给了全网，翻了半天git log，发现是新来的实习生改的，他觉得端口限制太麻烦，干脆把规则改成了0.0.0.0/0，图自己测试方便。

说实话，这种操作比手动点控制台还危险。手动操作至少还有个操作日志，写在脚本里乱改，连个追责的依据都找不到。不过话说回来，谁刚开始接触的时候没踩过这个坑呢？

真正值钱的是把所有变更关进版本库

之前那个差点搞砸大促的电商团队，后来花了一周时间，把所有和大促扩容相关的配置全部拆成了独立的代码模块。弹性服务器的规格、带宽阈值、安全组的入站出站规则、CDN的回源地址，甚至连数据库连接池的大小参数，全部写进了对应的配置文件里。

现在他们改任何一条基础设施配置，都得先提PR。

脚本会自动跑校验：有没有把高危端口对外开放，有没有配置和环境不匹配的实例规格，有没有把临时测试的规则留在生产配置里。校验过了，再@对应的业务负责人评审，评审通过了才会自动同步到对应的云环境。

之前改个安全组规则，要在三个运维群里发三遍截图，等主管回复，没个半小时下不来。现在？从提交配置变更到同步完成，最快15分钟。最关键的是，每一次修改都有记录，谁改的、改了什么、为什么改，翻git log就能看到，再也不会出现出了问题所有人都懵的场景。

上次有个运维想临时给测试环境加个公网IP，脚本直接拦下来了——因为测试环境的公网IP必须经过安全团队的审批，不符合规则的配置，连提交都过不了。

别一上来就追求百分百覆盖

我知道很多人一接触这个概念，就想着要把所有的基础设施全部代码化，从网络拓扑到存储配置，从负载均衡到边缘节点，恨不得三个月之内就把所有手动操作全部干掉。

真的没必要。

大部分中小团队的技术栈没那么复杂，上来就搞全量覆盖，最后大概率是拆模块拆到吵架，写的脚本没人维护，最后又回到手动点控制台的老路。

疼过才知道什么是最该先做的。

先从你最容易出人为错误的地方开始就行。比如之前那个电商团队，最开始只把“大促临时扩容的弹性服务器配置”写成了代码，就这一个小模块，第一年大促就省了运维整整12个小时的手动操作时间，还没出过一次配置错误。跑顺了，再慢慢把安全组规则、数据库参数这些容易出问题的部分加进来。

我上次帮一个团队梳理的时候，发现他们的脚本里硬编码了三个不同环境的Access Key，当时后背都凉了。敏感信息绝对不能硬编码在代码里，哪怕你觉得仓库是私有的也不行。把密钥放到专门的管理工具里，代码里只留引用路径，这是底线。

很多人说基础设施即代码是给运维用的工具，其实根本不是。它是给整个团队留的安全垫——不用再怕谁手动点错了配置，不用再翻半天聊天记录找之前的操作步骤，不用再在出问题的时候互相甩锅。

就这么简单。