云蔓延不可避免；但复杂性不必如此

不到十年前，大多数团队在单个云账户中运行开发、预生产和生产环境。如今，这似乎难以想象。

现在，您至少从10个AWS账户开始云之旅。每个环境一个：一个用于网络，一个用于日志记录，一个用于安全，一个用于……您明白的。如果您有多个业务单元或产品？将所有内容至少乘以三。

当我们启动ControlMonkey时，我当然构建了基础设施（infra）。一周后，我们的一位开发人员问道：“为什么我们已经有了这么多云账户？”他是在开玩笑，某种程度上。

这是因为账户数量并不是真正的问题；问题是云领导者如何管理它们。

问题不在于多账户——而在于多一切

挑战不仅仅是规模——而是波动性：工程师变更角色、需求变化、新工具引入而缺乏文档等等。不久之后，您就会拥有无人完全理解的脆弱系统。当出现问题时，您的团队会花费数小时扮演侦探角色，而不是交付成果。风险不仅仅是技术性的；它们是组织性、操作性和财务性的。

一旦您跨数十个云账户操作，以下事项几乎立即变得困难：

• 可见性：您需要在标签、仪表板和日志之间跳转，才能找到什么在何处运行。
• 安全性和合规性：每个账户都成为另一个攻击面、另一个审计跟踪和另一个待办事项。
• 知识保留：设置那个“遗留”账户的工程师已经离开——上下文也随之消失。
• 工程负担：手动工单、控制台点击操作、漂移调查。每个人都在救火。

这不仅仅是关于云。还包括SaaS工具、可观察性平台、CI/CD系统和版本控制。现在，您正在管理数十个影响基础设施覆盖范围的系统。

所有这些的未来是清晰的：将会有更多的账户、基础设施和需求，随着团队成员离开，机构知识将比今天更少，而交付期望不会放缓。

如果您的运营模式无法跟上，所有这些复杂性就是混乱的配方。

每个人都知道答案：基础设施即代码

首先，说实话——仅仅拥有Terraform或OpenTofu并不意味着您在大规模、一致或安全地使用它。基础设施即代码（IaC）覆盖本身并不是万能药。

我建议问自己（就像我问自己一样）：

• 所有基础设施变更是否都通过代码进行？
• 有人可以通过手动变更绕过流水线吗？
• 您是否不断分诊警报并回滚事物？

根据我的经验，大多数云团队不需要被说服IaC是答案。真正的问题是执行和规模。除非您能保证每个变更都通过代码进行，否则您就是在盲目飞行，并为此付出累积的工单、负担和风险。

系好安全带……并开得更快

我是这样想的（用另一个交通比喻）。

今天的云团队在浓雾中以100英里/小时的速度行驶。我们正在加速交付、更快发布、部署AI工作负载并全球扩展。但没有可见性和控制，您就是在不系安全带的情况下超速行驶。

一个有弹性的（即系安全带的）多账户策略始于三件事：

• 全面可见性：您无法管理看不到的东西。每个账户、每个资源、每个流水线——在一个地方可见。仪表板，而不是侦探工作。
• 全面自动化：基础设施应该只有一种交付方式：通过代码。没有手动快捷方式，没有一次性流水线；只有一条通往生产的设计路径。
• 全面弹性：所有配置都得到备份，每个变更在生产之前都经过验证和政策对齐。这就是让您的团队晚上能睡觉、白天能建设的原因。

如果您没有这些东西？您会在各处感受到：安全问题、合规审计、人员流失和无尽的负担。与此同时，业务的其余部分不会等待。AI、产品速度、全球扩展——这些不会在您弄清楚如何重新获得控制时暂停。

那么，该怎么办？

从哪里开始：10分钟内的5个问题

• 按环境划分，您的真实IaC覆盖范围是多少？
• 您能检测到是否有人绕过您的Terraform或OpenTofu流水线吗？
• 您的团队在基础设施拉取请求（PR）来回和手动审查上损失了多少时间？
• 您是否在未来12-24个月内管理更多基础设施？
• 您能否无需手动挖掘就证明您的生产基础设施现在合规？

如果其中任何一个让您停顿，它可能已经在让您付出代价。

无论您是构建自己的框架还是采用平台，都由您决定。如果它是基于OpenTofu或Terraform的多云，重要的是您停止接受云蔓延为不可避免，并开始管理所有这些账户。

全面可见性。全面自动化。全面弹性。这就是您保持控制的方式，无论您走得多快。