上个月陪雨花台区做零售SaaS的老周改配置，改到凌晨两点。
他当时拍桌子骂娘，说早知道不省那点事搞什么手工配服务器了。
那天机房空调坏了。
机柜里的热风裹着灰尘吹在脸上，他攥着的笔记本屏幕上，是第17次报错的Nginx配置。
那些被你忽略的手工运维代价
他们刚起步的时候总共10个人，三台ECS，上线那天运维小哥手动敲命令，配安全组，装Docker，调内核参数，半小时就搞定了，当时所有人都觉得效率高得离谱。
没人去记当时改了啥。
等业务扩到30台服务器的时候，新招的运维小哥不知道之前改了sysctl的net.core.somaxconn参数，直接按默认配置上新节点，结果大促前压测，新节点直接触发半连接队列溢出，连续挂了三次。
那次故障排查花了整整6个小时，最后还是翻旧的运维笔记才找到问题根源。
说实话，这种事在南京的中小IT公司里太常见了。
大家总觉得资源少的时候，手动配就是快，没必要搞什么复杂的流程。可你算过隐形成本吗？每一次手动登服务器改配置，都是一次没有记录的变更。人走了，配置就丢了。新的人上来，不知道之前动过啥，出了问题只能瞎猜。
我第一次接触Terraform的时候，光记HCL的变量类型就记了三天，当时还骂过这玩意为啥不能直接用Shell写。后来用久了才发现，之前写Shell脚本改配置，改完就忘，根本没有版本记录，出了问题连是谁改的都找不到。
别把IaC当成运维的专属工具
老周一开始接触基础设施即代码的时候，直接把所有Terraform文件都扔给运维团队管。开发要加个对象存储桶，要申请个新的负载均衡，都得给运维提需求，走排期。
有时候排期排到一周后，开发都忘了之前要啥了。
后来我们帮他们梳理了下，把每个业务线的基础设施代码拆成独立的模块，权限放开给对应的开发团队。开发要调整资源，直接在自己的模块里提PR，代码合并之后自动触发流水线创建资源，运维只需要做代码评审，把控安全规则就行。
基础设施即代码的核心从来不是写一堆复杂的YAML或者HCL代码，而是把所有基础设施的变更流程，变成和应用代码一样可审计、可回溯、可自动执行的流程。
很多人对这个东西有误解，觉得是运维要搞的新花样，和开发没关系。其实真不是。当你把基础设施的变更纳入代码评审流程之后，谁改了啥，为啥改，改了之后影响啥，都能在Git的提交记录里找到，再也不会出现“我就改了一个小参数怎么就挂了”的扯皮事。
落地的时候别上来就全量替换
我见过太多团队，一听到要搞IaC，上来就喊着要三个月把所有存量资源全部纳管，结果搞了半个月就卡壳了。
去年帮江北的一家做工业互联网的公司做落地，他们技术总监一开始拍胸脯说要三个月搞定所有存量物理机和云资源的纳管。结果第一个月就卡住了——有几台跑了五年的物理机，上面的配置根本没人能说清是怎么来的，当年负责运维的小哥都离职三年了。
后来我们改了策略，不搞全量替换那套。先从新上线的资源开始，所有新申请的服务器、数据库、安全组，必须走Terraform代码创建，不允许手动在云控制台点鼠标配置。存量的资源慢慢补，先把变更流程卡死，只要是涉及生产环境的基础设施修改，必须提交代码，禁止直接登服务器改配置。
真的，别信那些吹IaC能解决所有运维问题的鬼话。
我见过太多团队，写了一堆Terraform代码，但是没有代码评审，没有流水线校验，提交的代码直接能在生产环境执行。结果一次错误的安全组配置，直接把整个数据库暴露在公网上，被拖走了三百万条用户数据。那时候你就算把所有代码都存在Git里，也救不回丢出去的数据。
前几天碰到老周，他说现在他们团队上线新的业务线，从申请服务器到配好负载均衡，只需要十分钟。再也不用熬夜蹲机房，对着热得发烫的机柜改配置了。
其实哪有什么银弹啊。
不过是把之前靠人记、靠人传、靠运气兜底的那些破事，都变成白纸黑字的代码而已。