解決漂移檢測和漂移原因分析的問題

任何今天從事 DevOps 工作的人都可能同意，將資源編碼化可以更容易地觀察、管理和自動化。然而，大多數工程師也會承認，這種轉變帶來了一系列新的挑戰。

或許 IaC 運營中最大的挑戰是漂移 – 一種情況，其中運行時環境偏離其 IaC 定義的狀態，造成一個可能對長期影響嚴重的潛在問題。這些差異削弱了雲環境的一致性，導致基礎設施可靠性和可維護性可能出現問題，甚至還有重大的安全性和合規風險。

為了減少這些風險，負責管理這些環境的人將漂移歸類為基礎設施運營團隊的高優先級任務（以及主要的時間浪費）。

這推動了對漂移檢測工具的日益普及，這些工具可以標記所需配置與基礎設施實際狀態之間的差異。儘管對於檢測漂移很有效，但這些解決方案僅限於發出警報並突顯代碼差異，而沒有提供對根本原因的更深入洞察。

為何漂移檢測存在不足

目前的漂移檢測狀態源於漂移發生在已建立的 CI/CD 管道 之外，通常追溯到手動調整、API 觸發的更新或緊急修復。因此，這些變更通常不會在 IaC 層留下審計痕跡，造成了一個盲點，限制了工具僅能標記代碼不一致之處。這使得平台工程團隊不得不推測漂移的來源以及如何最好地解決這個問題。

這種不清晰使得解決漂移成為一項風險任務。畢竟，自動恢復變更而不理解其目的——一種常見的默認方法——可能會打開潘多拉的盒子，並引發一連串問題。

其中一個風險是，這可能會撤銷合法的調整或優化，潛在地重新引入已經解決的問題或擾亂一個有價值的第三方工具的運作。

例如，為了處理突發的生產問題而在通常的 IaC 流程之外應用的手動修復。在恢復這類變更之前，對其進行編碼以保留其意圖和影響至關重要，否則就有可能開出比病症更糟的治療方案。

檢測與上下文的結合

看到組織面對這些困境，激發了「漂移原因」的概念。這個概念利用人工智能輔助邏輯來篩選大量事件日誌，並為每次漂移提供額外的背景，追溯變更的來源——揭示的不僅是「什麼」，還有「誰」、「何時」和「為什麼」。

這種批量處理非統一日誌並收集漂移相關數據的能力，顛覆了對帳過程。為了說明這一點，讓我回到我之前提到的場景，描繪一下從檢測解決方案收到漂移警報的情況——這次帶有額外的背景信息。

現在，借助漂移原因提供的信息，你不僅可以察覺到漂移，還可以深入了解該變更是約翰在凌晨2點進行的，恰好是在應用處理流量高峰的時候。

如果沒有這些信息，你可能會認為這次漂移是有問題的，並回退變更，這可能會干擾關鍵操作並導致後續故障。

然而，借助額外的背景信息，你可以將線索串聯起來，聯繫約翰，確認該修復解決了一個緊急問題，並決定不應盲目進行對帳。此外，利用這些背景信息，你還可以開始提前思考，對配置進行調整，以增加可擴展性並防止問題再次發生。

這當然是一個簡單的例子，但我希望它能很好地展示擁有額外根本原因背景的好處——這是一個在漂移檢測中長期缺失的元素，儘管在其他除錯和故障排除領域是標準做法。當然，目標是幫助團隊了解不僅是什麼改變了，而是為什麼會改變，從而使他們能夠自信地採取最佳行動方案。

 

超越基礎設施即代碼管理

但對於漂移的額外背景雖然重要，但僅僅是更大拼圖中的一部分。管理大型雲端艦隊與編碼資源引入的不僅僅是漂移挑戰，尤其是在大規模情況下。當前一代的基礎設施即代碼管理工具在資源管理方面是有效的，但對於企業級環境中更高可見性和控制的需求正在引入新的要求並推動其不可避免的演變。

我看到這一演變走向的一個方向是雲資產管理（CAM），它跟踪和管理雲環境中的所有資源——無論是通過基礎設施即代碼、API還是手動操作提供——提供資產的統一視圖，幫助組織了解配置、依賴關係和風險，這些對於合規性、成本優化和運營效率都是至關重要的。

雖然基礎設施即代碼（IaC）管理專注於操作層面，但雲資產管理則強調對雲姿態的可見性和理解。作為額外的可觀測層，它彌合了編碼工作流程和臨時變更之間的差距，提供基礎設施的全面視圖。

1+1將等於三

IaC管理與雲資產管理的結合使團隊能夠以清晰和控制的方式管理複雜性。隨著年底的臨近，這是「預測季節」——這是我的預測。過去十年中，我主要致力於建立和完善其中一個較為流行的（如果我可以這麼說）IaC管理平台，我將此視為我們行業的自然進步：將IaC管理、自動化和治理與對非編碼資產的增強可見性相結合。

我相信，這種協同作用將形成更好的雲治理框架的基礎——一個更精確、適應性更強且未來可持續的框架。現在，幾乎可以說IaC是雲基礎設施管理的基石。然而，我們也必須承認，並非所有資產都會被編碼。在這種情況下，端到端的基礎設施管理解決方案不能僅限於IaC層。

那麼，下一個邊界就是幫助團隊擴大對非編碼資產的可見性，確保隨著基礎設施的演變，它能夠持續無縫運行——每次調整偏差及其後續的變化。