\n\n本文探讨了多云环境下的资源管理挑战，指出即便顶尖团队也常因缺乏统一视图而处于“盲飞”状态。作者强调应将资源盘点视为基础架构，利用自动化工具构建实时可见性。
译自：The one Slack message that proved our elite engineering team was flying blind
作者：Joe Karlsson
有人在 Slack 上发了一个看似简单的问题：我们在两个云环境中实际运行的到底是什么？
不是我们的基础设施即代码（IaC）文档怎么说，也不是账单报告显示了什么。而是此时此刻，跨越每个账户、每个供应商、两个组织，实际运行的是什么。
我们在讨论串里花了一个小时，动用了三个不同的团队，中间至少出现了一句“我觉得那个试点项目里有一些 Azure 的东西，让我找找了解情况的人”，最后才得到了一个接近答案的回复。最终的回答不是“这是清单”，而是：“这是我们非常有把握的部分，还有一些缺口需要调查。”
“我们是一个由严肃工程师组成的组织，对基础设施态度严谨。然而，我们却不存在一张完整的技术栈图谱。”
我们是一个由严肃工程师组成的组织，对基础设施态度严谨。然而，我们却不存在一张完整的技术栈图谱。这并非因为缺乏人才，而是因为缺乏必要性。直到那条 Slack 消息出现，一切都改变了。
没人计划过这一切
在过去几年的会议演讲中，我多次听到“多云策略”这个词。这种描述通常涉及对工作负载放置、避免供应商锁定以及跨区域和供应商的高可用拓扑的深思熟虑的架构选择。
根据 Flexera 2024年云状态报告，89% 的企业正在跨多个公有云运行工作负载，高于前一年的 87%。这个数字经常在供应商的演示文稿中被引用，作为多云被广泛采用的证据。但它没有捕捉到的是，大多数组织是如何走到这一步的。
通常发生的是“积累”：
- 你的核心产品运行在 AWS 上，因为那是你开始时的选择，或者是做出选择的人当时在那里工作，或者是因为那是 2014 年，其他替代方案还不成熟。
- 你集成的某个 SaaS 供应商 运行在 GCP 上，而他们的某个功能需要 GCP 原生服务，所以你也在那里建立了一个项目。
- 有人为了处理 API 网关的边缘情况构建了 Cloudflare Worker，因为延迟更低，且这很重要。
- 你合并的公司使用 Azure 作为其身份层和一些遗留数据流水线，而本季度没有人去迁移这些东西。
随着时间的推移，在足够多的团队中累加足够多的此类决策，你就会发现自己在四个供应商上运行基础设施。没有任何策略会议制定了这一计划，也没有任何架构评审批准了它。每个单独的决策在当时的环境下都是合理的；但合在一起，它们创造了一个跨越供应商且没有统一视图的云足迹。
大多数跨供应商的 IaC 平台（包括 env0）为你提供了一个管理 AWS、GCP 和 Azure 部署的统一场所，并对通过流水线的内容实施一致的策略。这确实很有用，但它只涵盖了通过流水线的资源。
任何早于流水线存在的、通过收购进入的、或者在流水线之外配置的内容：依然是盲点。env0 与 CloudQuery 的合并专门为了缩小这一差距，但即便如此，问题也必须被清晰地命名。
可靠的 IaC 管理能让你洞察流水线中发生了什么。它无法告诉你流水线之外存在什么。
我放弃了那个电子表格
云控制台是按供应商和按账户划分的。为了获得完整的画面，按照老方法，你需要打开 AWS 控制台，逐个账户、逐个区域地查看。然后切换到 GCP，在一个完全不同的界面和心理模型中重新开始。
接着，Azure 也有自己的导航惯例。它们之间互不通信。没有一个适用于所有供应商的“显示所有内容”按钮。
然后是标签（Tagging）问题。在我们的案例中，两个组织正在合并，每个组织都有不同的标签惯例、不同程度的强制执行力度、对于哪些标签是必填项的不同看法，以及值应该是什么样子。
CloudQuery 这边的一些资源使用了单一所有者格式。env0 这边的一些资源使用了另一种格式。有些资源早于任何标签政策。有些是由不遵循任何标准的自动化程序配置的。
要针对完整的合并足迹运行像“谁拥有这个资源？”这样的查询，首先需要就“所有者”到底意味着什么达成一致，然后交叉引用多个系统，以确定给定资源使用了哪种惯例。
我曾尝试制作一个电子表格。我花了大半天时间，从控制台和成本报告中提取数据，并询问团队负责人，等我完成第一个供应商的部分时，我对所写内容的准确性已经信心不足，于是决定不再继续另外两个。
成本报告告诉你你在为什么付钱，而不是在运行什么。它们是计费条目，不是资源清单。询问团队负责人得到的是团队经常思考的内容列表，这与存在的所有内容并不等同。
如果重新开始，有一件事我会做得不同：在合并完成前商定一个统一的标签模式，哪怕是最小化的（所有者、环境、成本中心），并从第一天起就强制执行。你无法追溯性地将两个组织的资源标签整理到一致。但你可以防止未来两年出现无法回答“谁拥有这个？”的情况。
给出答案的查询
CloudQuery 将你来自 AWS、GCP、Azure、Kubernetes、Cloudflare 和 数十个其他供应商 的真实云状态拉取到你可以直接查询的 SQL 表中。每个供应商同步到自己的表中（aws_ec2_instances、gcp_compute_instances、azure_compute_virtual_machines），因此跨供应商的计数看起来像这样：
SELECT 'aws' AS provider, 'ec2_instance' AS resource_type, COUNT(*) AS count
FROM aws_ec2_instances
UNION ALL
SELECT 'gcp', 'compute_instance', COUNT(*) FROM gcp_compute_instances
UNION ALL
SELECT 'azure', 'virtual_machine', COUNT(*) FROM azure_compute_virtual_machines
ORDER BY count DESC;
你可以为你关心的每种资源类型扩展这个查询。预构建的多云清单报告 会自动处理完整的聚合，这正是我们实际使用的。但即使是手动编写，从“我们没有画面”到“这是按供应商分类的明细”，也只是一个上午的事情，而不是长达一周的审计。我可以按标签过滤，连接成本数据，并交叉引用 IaC 声明的内容与实际存在的内容。
那个需要三个 Slack 讨论串的问题，变成了一个只需要三分钟就能解决的问题。
仍有不足之处
一旦清单统一了，下一个问题很快就出现了：我仍然必须知道要寻找什么。
在两个供应商的规模下，你可以编写查询。你构建一个小型的定期检查库（未加标签的资源、不应公开访问的东西、本应退役的计算资源）并按计划运行。这很有效。
合并后我们处理的足迹不只是两个供应商。它是两个供应商乘以两个组织，有两种不同的命名惯例、两种不同的政策制度，以及一长串双方近期都没有查看过的资源。要通过手动编写查询来覆盖所有内容，需要预先知道每一类可能出错的事情。而你不可能预先知道。
当我们一夜之间从一个云足迹变成两个时，我意识到我们需要系统主动浮现值得查看的内容，而不仅仅是回应我们想到的问题。清单保持更新。异常情况会自动推送到你面前。你不再需要费神去问。
多云不是我们做出的决定。它是我们所处的一种状态，是由多年来每一个单独合理的选择积累而成的。我所见过的处理得好的团队，并不是那些拥有最刻意云架构的团队。而是那些将清单和可见性视为基础基础设施的团队，他们在合并之前、事故之前、审计强制要求之前，就构建了统一的画面。
“我所见过的处理得好的团队，并不是那些拥有最刻意云架构的团队。而是那些将清单和可见性视为基础基础设施的团队。”
如果让我重新开始，那是第一件我会落实的事情。不是因为它解决了多云的复杂性（它并不能），而是因为你无法管理你看不见的东西。
先构建清单。安全审计、成本分摊、事件响应、合规准备：所有这些都假设你知道运行的是什么。清单是基础，而且它是唯一一件无法通过追溯变得更容易构建的事情。如果你想在自己的基础设施上运行这个，CloudQuery 快速入门指南 涵盖了设置过程。多云流程与单一供应商相同，只是配置了更多的源插件。全 工智能
