解决漂移检测和漂移原因分析的问题

今天，在DevOps领域工作的人很可能都同意，资源的编码化使得观察、管理和自动化变得更容易。然而，大多数工程师也会承认，这一转变带来了新的挑战。

也许，基础设施即代码（IaC）操作中最大的挑战就是漂移——一种运行时环境偏离其IaC定义状态的情况，这会导致一个潜在的问题，可能会带来严重的长期影响。这些差异破坏了云环境的一致性，可能导致基础设施的可靠性和可维护性问题，甚至可能带来重大的安全和合规风险。

为了尽量减少这些风险，负责管理这些环境的人员将漂移列为基础设施运营团队的高优先级任务（也是一个主要的时间消耗）。

这推动了漂移检测工具的日益采用，这些工具可以标记期望配置与基础设施实际状态之间的差异。虽然这些解决方案在检测漂移方面有效，但它们仅限于发出警报和突出代码差异，而未能提供有关根本原因的深入见解。

漂移检测的不足之处

漂移检测的现状源于漂移发生在既定的CI/CD流水线之外，通常追溯到手动调整、API触发的更新或紧急修复。因此，这些变化通常不会在基础设施即代码（IaC）层留下审计痕迹，从而形成一个盲点，限制了工具仅仅标记代码差异。这使得平台工程团队不得不推测漂移的来源以及如何最好地解决它。

这种缺乏清晰度使得解决漂移成为一项风险任务。毕竟，在不了解其目的的情况下自动撤销更改——这是一种常见的默认方法——可能会引发一系列问题。

一个风险是，这可能会撤销合法的调整或优化，可能重新引入已经解决的问题，或干扰有价值的第三方工具的操作。

例如，针对突发生产问题在通常的IaC流程之外应用的手动修复。在撤销此类更改之前，至关重要的是将其编码，以保留其意图和影响，或冒着开出可能比病症更糟的药方的风险。

检测与上下文相遇

看到组织在这些困境中挣扎，激发了“漂移原因”这一概念。该概念利用人工智能辅助逻辑，筛选大量事件日志，为每个漂移提供额外的背景信息，追溯变化的源头——揭示不仅是“什么”，还有“谁”，“何时”，以及“为什么”。

这种批量处理非统一日志并收集与漂移相关数据的能力，彻底改变了对账过程。为了说明这一点，我想带你回到我之前提到的场景，描绘一下从检测解决方案收到漂移警报的情景——这次带有额外的背景信息。

现在，借助漂移原因提供的信息，你不仅能够意识到漂移的存在，还能深入了解变更是由约翰在凌晨2点进行的，恰好是在应用程序处理流量激增的时候。

如果没有这些信息，你可能会认为漂移有问题，并撤销该变更，可能会干扰关键操作并导致下游故障。

然而，有了额外的背景信息，你能够连接各个点，联系约翰，确认该修复解决了一个紧迫的问题，并决定不应盲目对账。此外，利用这个背景信息，你还可以开始提前思考，进行配置调整，以增加可扩展性并防止问题的再次发生。

这只是一个简单的示例，但我希望它能很好地展示具有额外根本原因上下文的好处 — 尽管在漂移检测中一直缺乏这一要素，但在调试和故障排除的其他领域中却是标准的。当然，目标是帮助团队不仅了解发生了什么变化，还要了解为什么会发生变化，从而赋予他们以信心采取最佳行动。

 

超越基础架构即代码管理

然而，虽然获得有关漂移的额外上下文可能很重要，但这只是更大难题的一部分。使用编码资源管理大型云资源群带来的挑战不仅仅是漂移问题，尤其是在规模上。当前一代基础架构即代码管理工具能够有效地解决资源管理问题，但在企业规模环境中对更大的可见性和控制需求引入了新的要求，推动了它们不可避免的演进。

我看到这种演进的一个方向是云资产管理（CAM），它跟踪和管理云环境中的所有资源 — 无论是通过基础架构即代码、API还是手动操作进行配置 — 提供资产的统一视图，并帮助组织了解配置、依赖关系和风险，这些对合规性、成本优化和运营效率都是至关重要的。

虽然基础设施即代码（IaC）管理关注于操作方面，但云资产管理则强调对云态势的可见性和理解。作为额外的可观察性层，它弥补了编码工作流程与临时更改之间的鸿沟，提供了基础设施的全面视图。

1+1等于三

IaC管理与云资产管理（CAM）的结合使团队能够以清晰和可控的方式管理复杂性。随着年末的临近，进入了“预测季节”——这是我的预测。在过去十年中，我花了大部分时间构建和完善一个较为流行（如果我可以这么说） 的IaC管理平台，我认为这是我们行业的自然进展：将IaC管理、自动化和治理与对非编码资产的增强可见性结合起来。

我相信这种协同作用将为一种更好的云治理框架奠定基础——一种更精确、适应性强且具备未来保障的框架。现在，几乎可以肯定的是，IaC是云基础设施管理的基石。然而，我们也必须承认，并非所有资产都能被编码。在这种情况下，端到端的基础设施管理解决方案不能仅限于IaC层。

因此，下一个前沿是帮助团队扩大对非编码资产的可见性，确保随着基础设施的演变，它继续无缝运行——一次调和漂移及其后续发展。