那条证明我们精英工程团队在“盲飞”的Slack消息

译自：The one Slack message that proved our elite engineering team was flying blind[1]

作者：Joe Karlsson

一切始于Slack上一个看似简单的问题：我们到底在两个云环境里运行着什么？

注意，这里问的不是基础设施即代码（IaC）文档里写了什么，也不是账单报告上显示了什么。而是此时此刻，横跨每个账户、每个供应商、两个组织的真实运行状态。

为了回答这个问题，我们在讨论串里花了一个小时，惊动了三个不同的团队，中间还夹杂着“我觉得那个试点项目里有些Azure的东西，我去找找看谁了解情况”这样的对话。最终得到的回复，并非一份确切的清单，而是一句：“这是我们比较有把握的部分，但还有些缺口需要调查。”

“我们是一个由严肃工程师组成的组织，对基础设施态度严谨。然而，我们却不存在一张完整的技术栈图谱。”

这听起来有些讽刺：一个由严肃工程师组成的组织，对基础设施管理向来严谨，却拿不出一张完整的技术栈图谱。问题并非出在人才上，而是必要性——直到那条Slack消息出现，才把问题摆在了所有人面前。

没人计划过这一切

过去几年，在各种技术会议上，“多云策略”这个词被反复提及。演讲者描绘的，往往是经过深思熟虑的架构选择：精心规划工作负载部署、规避供应商锁定、设计跨区域和供应商的高可用拓扑。

Flexera 2024年云状态报告[2]显示，89%的企业正在多个公有云上运行工作负载，高于前一年的87%。这个数字常被供应商引用，作为多云广泛采纳的证据。但它没有揭示的是，大多数组织是如何走到这一步的。

现实情况，更多是“积累”的结果：

• 核心产品跑在AWS上，可能是因为创业之初就选了它，或者当时做决定的人熟悉AWS，又或者因为在2014年，其他选项还不够成熟。

• 集成的某个SaaS供应商[3]运行在GCP上，其某个功能必须依赖GCP原生服务，于是你不得不在那边也开个项目。

• 为了处理API网关的某个边缘情况，有人构建了Cloudflare Worker，因为延迟更低，而这恰恰是关键。

• 被合并的公司使用Azure作为其身份层和一些遗留数据流水线，而本季度没人有精力去迁移它们。

随着时间的推移，当足够多的团队做出足够多类似的“合理”决策后，你就会发现自己已经在四个云供应商上运行着基础设施。没有任何一场策略会议规划过这一切，也没有任何一次架构评审批准过这个局面。每一个单独的决策在当时都合情合理；但组合在一起，它们就创造了一个跨越多个供应商、却缺乏统一视图的云足迹。

大多数跨供应商的IaC平台（包括env0[4]）确实提供了一个统一管理AWS、GCP和Azure部署的地方，并对流水线内容实施一致的策略。这很有用，但它只覆盖了“通过流水线”的资源。

任何早于流水线存在的、通过收购带来的、或者在流水线之外配置的资源：依然是盲点。env0与CloudQuery的合并[5]正是为了缩小这一差距，但前提是，你必须先清晰地定义出问题所在。

可靠的IaC管理能让你洞察流水线内发生的事。但它无法告诉你，流水线之外还存在着什么。

我放弃了那个电子表格

云控制台是按供应商和账户划分的。想用老办法获得全貌？你得先打开AWS控制台，逐个账户、逐个区域地查看。然后切换到GCP[6]，在一个界面逻辑和心智模型都完全不同的地方重新开始。

接着，Azure又有自己的一套导航习惯。它们彼此不通气。没有一个通用的“显示所有内容”按钮。

接下来是标签（Tagging）问题。以我们为例，两个正在合并的组织，各有各的标签惯例：不同的强制力度、对哪些标签必填的不同看法、以及标签值应该是什么样子的不同标准。

CloudQuery这边的资源使用一种所有者格式。env0那边的资源使用另一种。有些资源早于任何标签政策。有些则是由不遵循任何标准的自动化程序配置的。

想要针对合并后的完整足迹运行诸如“谁拥有这个资源？”的查询，你首先得就“所有者”到底指什么达成一致，然后还得交叉引用多个系统，才能确定某个资源到底遵循了哪套惯例。

我曾尝试制作一个电子表格。花了半天时间，从控制台和成本报告里扒数据，向团队负责人询问。等到完成第一个供应商的部分时，我对所填内容的准确性已经信心不足，于是决定放弃另外两个。

成本报告告诉你钱花在哪，而不是东西跑在哪。那是计费条目，不是资源清单。询问团队负责人得到的是他们经常关注的列表，这与实际存在的所有内容并不等同。

如果重来一次，有件事做法会不同：在合并完成前，哪怕是最小化的（所有者、环境、成本中心），也要商定一套统一的标签模式，并从第一天起就强制执行。你无法追溯性地将两个组织的资源标签整理一致，但你可以避免未来两年都回答不了“这归谁管？”的尴尬。

给出答案的查询

CloudQuery[7]将来自AWS、GCP、Azure、Kubernetes、Cloudflare等数十个供应商[8]的真实云状态，拉取到可以直接查询的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;

你可以为你关心的每种资源类型扩展这个查询。预构建的多云清单报告[9]会自动完成完整的聚合，这正是我们实际使用的。但即便是手动编写，从“没有画面”到“获得按供应商分类的明细”，也只是一个上午的工作，而非长达一周的审计。你可以按标签过滤，关联成本数据，并交叉核对IaC声明的内容与实际存在的内容。

那个需要三个Slack讨论串才能勉强回答的问题，变成了一个三分钟就能解决的查询。

仍有不足之处

一旦清单统一了，下一个问题立刻浮现：我仍然需要知道该寻找什么。

在一两个供应商的规模下，你可以编写查询。构建一个小型的定期检查库（比如未加标签的资源、不应公开访问的东西、本应退役的计算资源）并按计划运行。这很有效。

但合并后我们面对的足迹，不只是两个供应商。它是两个供应商乘以两个组织，伴随着两套不同的命名惯例、两套不同的政策制度，以及一长串双方近期都没仔细检查过的资源。试图通过手动编写查询来覆盖所有可能的问题，需要你预先知道每一类“可能出错的事情”。而这几乎是不可能的。

当我们一夜之间从一个云足迹变成两个时，我意识到，我们需要系统能主动浮现值得关注的内容，而不仅仅是被动回应我们想到的问题。让清单保持实时更新，让异常情况自动推送到面前。你不再需要费神去“问”，问题会自己“找上门”。

多云，往往不是我们主动做出的决定，而是我们所处的一种状态——由多年来每一个单独看来都合理的选择积累而成。那些处理得好的团队，通常并非拥有最刻意、最完美的云架构，而是那些将清单和可见性视为基础基础设施的团队。他们在合并之前、在事故之前、在审计强制要求之前，就已经构建了统一的画面。

“我所见过的处理得好的团队，并不是那些拥有最刻意云架构的团队。而是那些将清单和可见性视为基础基础设施的团队。”

如果从头再来，这是我会首先落实的事情。不是因为它能解决多云的所有复杂性（它不能），而是因为一个根本原则：你无法管理你看不见的东西。

先构建清单。安全审计、成本分摊、事件响应、合规准备——所有这些工作都基于一个前提：你知道正在运行的是什么。清单是这一切的基础，而且它是唯一一件无法通过事后追溯变得更容易构建的事情。如果你想在自己的基础设施上尝试，CloudQuery快速入门指南[10]涵盖了设置过程。多云流程与单一供应商类似，只是需要配置更多的源插件而已。

引用链接

[1]The one Slack message that proved our elite engineering team was flying blind:https://thenewstack.io/multi-cloud-blind-spots/
[2]Flexera 2024年云状态报告:https://www.flexera.com/blog/finops/cloud-computing-trends-flexera-2024-state-of-the-cloud-report/
[3]SaaS 供应商:https://thenewstack.io/how-to-assess-integration-security-risks-when-evaluating-saas-vendors/
[4]env0:https://www.env0.com/solutions/cloud-asset-management
[5]env0 与 CloudQuery 的合并:https://thenewstack.io/closing-cloud-operational-gap/
[6]GCP:https://thenewstack.io/googles-cloud-idp-could-replace-platform-engineering/
[7]CloudQuery:https://www.cloudquery.io/blog/complete-guide-building-multi-cloud-asset-inventory
[8]数十个其他供应商:https://www.cloudquery.io/hub/
[9]预构建的多云清单报告:https://www.cloudquery.io/hub/reports/multi-cloud-asset-inventory
[10]CloudQuery 快速入门指南:https://www.cloudquery.io/product/cloud-asset-inventory