env zero和CloudQuery合并，旨在弥合云运营中的“运营差距”。面对AI时代加速的基础设施变化，新平台将提供统一治理与持续可见性，实现基础设施的自动化，解决手动管理难题。
译自：The operational gap is real, and it's getting wider
作者：Yevgeny Pats
为什么env zero和CloudQuery的合并不仅仅是一个产品故事；它是云运营市场一直缺失的论点。
当我创立CloudQuery时，问题似乎很简单。云基础设施数据是任何现代企业中最有价值、却最被忽视的资产之一。问一个平台团队他们在周二部署了什么，他们真的说不上来——并非因为他们疏忽，而是因为他们使用的工具并非旨在回答这个问题。
因此，我们构建了一个规范化的数据层：可SQL查询、多云、可扩展。财富100强银行的企业和快速发展的金融科技公司开始使用它，最终得以全面了解其环境中，跨账户、提供商和工具运行的一切。
当时我并未完全意识到云资产可见性本身会如此迅速地达到极限。知道资源存在并不意味着它受到治理。知道某些东西配置错误并不意味着你可以安全地修复它，或者有权采取行动的人会在问题出现之前发现它。在你能可观测到的和你实际能控制的之间存在一个差距。在大多数组织中，这个差距是通过人们编写粘合脚本和依赖组织记忆来非正式管理的。
这就是我所说的“运营差距”。这也是CloudQuery和env zero合并的核心原因。
平台工程一直存在分裂问题
该领域长期以来一直被Day 1和Day 2关注点所划分。Day 1是调配：通过审批工作流，安全地搭建基础设施，并设置正确的策略。Day 2是之后的一切：保持环境合规、发现偏差、管理成本，以及了解实际运行与预期之间的差异。这两个领域历来存在于独立的工具中，由重叠但不同的团队维护，之间没有共享的数据模型连接。
“运营差距一如既往，但它正在以一种让非正式管理变得不可持续的方式加剧。”
它们之间的差距以前并非为零，但尚可管理。团队编写集成。他们构建仪表板。他们进行周度审查。粘合代码尚能支撑，主要是因为变化速度足够慢，人类可以参与其中。
现在情况已非如此。由大语言模型驱动的软件开发加速改变了局面。以前需要数天才能调配的基础设施现在只需数分钟。中大型企业云环境中变化量的速度已经超越了任何手动审查过程。运营差距一如既往，但它正在以一种让非正式管理变得不可持续的方式加剧。
env zero的优势与不足
合并之前，env zero在交付时治理基础设施方面是一流的。策略执行、审批工作流、审计追踪和偏差检测——Pismo等客户将基础设施交付时间从两个月缩短到两天。Western Union在200多个应用程序中，将时间从数周缩短到数小时。核心治理模型非常稳固。
瓶颈在于后续发生的情况。发现一个未受治理的资源，和对其拥有权限是两码事。如果没有强制编码的机制，以及无法超越偏差来评估风险的能力，那么发现的资源依然只是被发现。平台工程师可以看到问题。但他们没有强制修复的工具。
CloudQuery的立场则相反。我们非常擅长发现云资产中存在的内容——规范化、可查询，并在基础设施、安全和成本数据之间进行上下文关联。我们所缺乏的是一个受治理的补救路径。在SQL查询中识别配置错误很有用。但让这一发现流入审批工作流，并带有完整的审计追踪和受控的补救过程，则是一种完全不同的能力。
组合平台旨在闭合这个循环。env zero治理部署的内容。CloudQuery提供对实际存在内容以及其与声明意图比较情况的持续可见性。当它们出现分歧时，该平台拥有采取行动的上下文，而不仅仅是告警。
为什么现在是治理的正确选择
我曾看到平台团队长期以来在治理工具方面投资不足，原因总是相同的：当治理发挥作用时，没有人会注意到。未导致事故的错误配置是不可见的。未出现的审计发现是不可见的。因为策略在部署时发现并阻止了成本超支，这笔超支也是不可见的。其价值几乎完全体现在未发生的事情上。
当AI生成的基础设施大规模出现时，情况就会改变。变化量变得过高，非正式控制无法应对。随着依赖关系加剧，单个错误配置的爆炸半径会变大。随着云基础设施变得对运营越来越关键，监管机构和客户的审计要求也变得越来越严格。届时，治理不再是组织可以通过流程和部落知识来管理的事情，它必须成为基础设施本身——编码化、持续化和自动化。
“届时，治理不再是组织可以通过流程和部落知识来管理的事情，它必须成为基础设施本身。”
那些弄清楚这一点的平台团队共享一个可识别的模式。他们不再将治理视为清单或一道门，而是将其视为一个在其他一切之下持续运行的层。开发者不会将其视为摩擦。审计师会看到一份完整、明确的记录。平台团队一次定义的标准会得到一致的应用，无论团队是部署到一个环境还是一百个环境。
这就是我们正在构建的云治理版本。
这对现有客户意味着什么
env zero和CloudQuery的客户都可以期待他们现有产品继续运行。我们经过深思熟虑，决定不立即将两个平台合并为一个并称之为集成。新的组合产品将拥有自己的身份和路线图，并将根据合并后的愿景来构建，而不是从现有代码库中拼凑而成。
目标客户是云优先企业中的平台团队，他们在生产环境中运行，而基础设施变化的速度和数量已经真正超越了手动治理的能力。如果这描述了你的情况——如果你有大量基础设施不在你的IaC中，如果偏差可追溯性是一个持续存在的问题，如果你的合规态势仍然依赖于某人运行脚本并记住提交工单——那么这就是我们正在为之构建的。
运营差距并非始于AI，但AI使其成为组织不能再推迟解决的问题。答案并非是再向技术栈中添加另一个单点解决方案。它是一个将完整的基础设施生命周期视为一个单一受治理系统的平台，拥有完整的记录，无需任何人手动维护。这就是我们正在构建的。我们尚处于早期阶段，我们认为我们指明了正确的问题。
