“版本管理？啊，我总是直接用最新版本——能出什么问题呢？”
正是这种心态，让一些工程师在凌晨三点被电话吵醒。也是为什么第二天早晨的 Daily Stand-up 上，大家都低头盯着自己的鞋尖看。
在本系列《Terraform @ Scale》的最后一篇中，让我们简单聊聊这个话题——免得同样的事情也发生在您身上。
"去他的可见性 - 只要能跑就行！"
这正是大多数 Platform-Engineering 团队自取灭亡的态度。就像在陌生的厨房里蒙着眼睛做饭：一开始也许还能凑合，但一旦烧焦，那就真的完蛋了。
而最糟糕的莫过于当系统崩溃时，看着团队成员一脸茫然的样子。
在前两部分中，我们主要讨论了依赖关系带来的痛苦。今天我们来看看，当孩子已经掉进井里时，我们还有哪些办法能把它完好无损地救上来。
在上一篇文章中，我们已经考察了嵌套模块的隐藏复杂性以及由此引发的 Ripple-Effect，并且越来越清楚地认识到，这些情况在运维和生命周期管理中可能带来的不良后果。此类问题的入口会在初学者错误操作时被大开 - 尤其是将多个甚至所有 Terraform 模块塞进一个共享的 Git 仓库这一错误。同样地，如果具备一定的经验和良好的规划，这类问题则可以从一开始就被最大限度地减轻。
在本部分中，我们将看看在实践中如何处理这些依赖关系，而不会让痛点完全占据主导。
当一次简单的模块更新让 47 个团队陷入停滞...
星期一上午 10:30。一家大型托管云服务提供商的 Platform-Engineering 团队刚刚将用于 VM 实例的基础模块从 v1.3.2 更新到 v1.4.0，看似“无害”。变更是什么？一个新的、但强制性的 Freeform-Tag，用于资源的成本中心归属。
而没人注意到的一点是：那位曾经强烈坚持所有 Terraform 模块必须存放在一个单一 Git 仓库中的 Senior Engineer。他当时的理由是：“版本管理就是过度的 Micromanagement。这样放在一起更整洁，也更省事。”
同一天，下午 15:00：来自不同客户的 47 个团队陆续反馈，他们的 CI/CD-Pipelines 失败了。原因是什么？他们的 Root-Module 引用了提供商更新后的模块，但没有人在自己的 Root-Modulen 中实现新的参数。提供商的合规性检查机制正在运行，并且因为缺少必填的 Tags 而拒绝了 Terraform-Runs。本来计划中的改进，最终演变为一次组织范围内的停摆，并对托管客户产生了巨大的外部影响。
欢迎来到 Terraform @ Scale 模块依赖的世界。
在上一篇文章 5a 中，我们看到大规模的 Terraform Rollouts 很快会触碰到 API 限制，例如当 DR 测试需要并行创建上百个资源时，429 错误会像雪崩一样触发大量 Retries。本篇续篇正是从这里切入，展示如何通过 Oracle Cloud Infrastructure 的 API Gateway 以及 Amazon API Gateway 来有意识地管理这些限制，实现干净的可观测性，并通过「Policy as Code」将其落实到稳定的运营实践中。