事无定势，因时制宜。
运维工作这几年，见过有devops对terraform嗤之以鼻的，也见过对其奉为圭臬的。
诚然脱离场景讨论一个IaC工具本身是没有意义的。这就如同了每个人自顾自的描述自己的感受，旁人是无法感同身受的。
但最近看到一个reddit上clickops vs IaC的讨论，我还是想浅谈下我现在对terraform是否对运维有用的看法。
最初接触terrform是19年一个aws的项目，第一次发现云上的基础设施资源可以像代码声明一样去管理，确实很方便。像打开了新世界的大门。
虽然那会主要还是开发，但后边一路基础设施也都习惯了用terraform管理，直到如今做运维了，逐渐一年年也接触过了多个诸如aliyun，gcp，azure云的IaC.
先不论terraform的种种在我看来便利的方向，我想先从我接触到运维抱怨的问题开始。
点几下的事
clickops其实依旧还是很多运维主流，这个无关国内国外。
云平台界面上点点就搞定的事，你和我说用terraform代码自动化？
就算我愿意学terraform，多花点时间搞了各种自动化，多花的effort有人在乎么，又有多少能复用的场景？
也别和我说这能提效，省下的时间你确定是我的么，何必呢，对吧！
云支持差
你也别说我没试过IaC, 某些后起的云的接口你别提怎么设计的了，感觉自己都没想明白，terraform的provider写的明白么？
刚开始还兴高采烈的资源IaC呢，结果provider一升级，就这个问题那个问题的，也不知道他们terraform用户多不多，反正经常给debug，工单倒没少提。。。
还有好多资源不支持IaC, 你说说这半吊子的IaC， 还得弄写runbook专门记录哪些是手动操作的，哪些能自动化，哈哈，别忘了过段时间他们自家的provider改的可能也不一样了，对应的terraform文档还没变呢。
有的云好歹不支持的允许你用自家rest api provider去灵活管理，就是留了空间给你IaC, 某些云有么，有功夫搞这个么，哈哈！
资源庞杂
咱也好好弄过，一个terrform pipeline也管过几千的资源， 也不少了。
也让开发团队用moudle往里维护资源，结果资源越来越多了，pipeline越来越慢了，团队他只管申请啊，回收是完全不和你提啊。
不管吧，这一团粥了，管吧，你说咋整，分拆下terrform state？指标他不治本啊。你说terraform他方便了开发还是方便运维了，也没少多少事啊，你是不知道维护module那些麻烦啊，遇上provide的bug那也是一堆资源问题啊。
团队没人用
还有最尴尬的就是这了，我用terraform热火朝天，团队里没人用啊。
也试过推广，可是其他人要么clickops，要么感觉还不如自己的脚本方便，何必在学一门terraform。
这也不是最难受的，要是资源不是我自己单独管理的，指不定隔几天就给你来下state drift，别人又clickops了你的IaC资源，难不难受？可又能怪谁呢！
AI时代了
况且现在AI时代了，生成点terraform代码还不是手拿把掐，但是AI也能直接调用各方的cli工具和rest api啊。
你试试那感觉，不是瞬间完成，clickops都免了。
什么，你担心它乱来，那让他写点工具不好么，我靠AI写的脚本自动化它不香么？
至于你说的平台上复用性，规模化，统一整合上，等需要了再说，还指不定呢，是吧！
题外话：别说AI，现在输入法都不可信了，不信你试试输入拼音feng ruo gui gao 奉若圭皋，皋对么（实际是 nie：臬），也暴露笔者拼音水平了！
看到这，不知道你有没有过类似的经历，其实结论大家都知道。
问题本身不在于terraform本身，在于你是否有使用terraform运维的条件，以及持续治理的决心。
最后如果你还能快乐的用terrform，祝贺你有这份的幸运。
如有疑问，请文末留言交流或邮件：newbvirgil@gmail.com本文链接 : https://newbmiao.github.io/2026/11/14/does-terraform-matter-to-devops.html
