配置漂移指南以及如何防止它

配置漂移是所有 IAAC 開發人員關注的重要問題。 這篇文章將了解配置漂移管理、它的重要性、原因和潛在的解決方案。

什麼是配置漂移？

應用程序所有者必須隨著時間的推移改變他們的應用程序和底層基礎設施，以不斷增強客戶體驗。 這些客戶可能在公司內部或外部。

這些更新和更改會導致應用程序和基礎架構的配置發生更改。 這些修改可能是有益的，也可能會降低系統的硬化狀態。 配置漂移就是這個術語。

配置漂移的工作原理

配置漂移的可能性隨著軟件生產和交付系統的複雜性而增加。 代碼通常從開發人員的工作站轉移到共享開發環境、測試和 QA 環境，最終轉移到登台和生產環境。

潛在影響隨著沿管道發生漂移的距離而增加。 即使是安裝在開發人員筆記本電腦上的軟件包版本與安裝在測試服務器上的版本之間的微小差異也會延遲問題調試。 通常，只有分期和生產預計是彼此的副本。 壓力很大，因為許多企業每天都會多次部署新代碼。

配置漂移的常見原因

缺乏溝通

有時上游團隊無法與下游合作夥伴就他們所做的更改進行溝通，從而導致整個下游系統崩潰。

修補程序

修補程序是對代碼所做的更改，以解決不能等到應用程序的下一次計劃更新的關鍵問題。 有時，致力於解決問題的工程師未能對管道中的其他環境進行更改或記錄相同的修復，從而導致漂移。 通常，重新引入原始問題將解決這種漂移。

關鍵軟件包更新

關鍵包更新有點類似於修補程序。 兩者都以快速的速度執行。 主要區別在於應用關鍵包更新是為了避免將來發生事件。 因此，此類更新可能會以與修補程序相同的方式導致漂移。

缺乏自動化

自動化不會完全消除配置漂移的可能性。 它只會減少它的機會。

便利變化

有時，開發人員所做的更改是暫時的。 例如，如果開發人員在測試服務器上安裝了一個新包來測試某些功能並且忘記將其恢復到其原始狀態，就會發生漂移。

為什麼配置管理很重要？

配置漂移如此具有破壞性的原因之一是，如果沒有人一直在尋找它，漂移可能不會被發現，因為它會逐漸破壞您的基礎設施的基礎，就像牆後房子裡的小洩漏一樣。

當發現配置漂移時，找到導致這一切發生的配置漂移的根本原因需要時間，這是緊急情況下的寶貴資源。

在軟件開發中，漂移是發布週期緩慢的重要原因。 它可能會導致不必要的工作並妨礙開發人員的工作效率。

降低成本

  當您擁有 IT 基礎架構的詳細圖像時，您可以通過識別重複或過度配置來降低所需的總量。

更高的生產力

  具有穩定且知名配置的集群可以實現批量管理和基礎設施建設。 此外，通過限制唯一（或雪花）服務器減少了手動管理單個設置的要求。

更快的調試

一致的配置允許調試團隊排除配置錯誤。 團隊可以專注於其他潛在原因，更快地解決故障單，因為他們不必尋找服務器、服務器集群或環境之間的配置差異。

由於配置偏差導致的問題

安全問題

不安全的配置是安全漏洞最常見的原因之一。 即使您從受保護的配置開始，配置漂移也可能使其他攻擊和網絡破壞更有可能發生。

停機時間

  配置錯誤可能導致嚴重的停機時間，使攻擊者能夠使用 DoS 漏洞或危及關鍵服務器。 不過，這還不是全部。 假設您修改了網絡設備的配置，從而影響了性能。 你總是可以回到你的“黃金配置”，對吧？ 如果該配置有缺陷，恢復服務將需要更長的時間。

不合規

  嚴格的安全控制對於遵守 ISO 27001、PCI-DSS 和 HIPAA 等法規是必要的。 如果不停止配置漂移，可能會導致您破壞合規性。

性能下降

當配置處於預期狀態時，配置通常處於最佳狀態。 臨時修改會通過導致瓶頸和衝突來阻礙網絡優化嘗試。

浪費時間

對您不太了解或與網絡文檔不匹配的網絡進行故障排除可能需要很長時間。 這意味著配置偏差可能會導致 IT 故障排除問題，如果網絡處於預期狀態，這些問題可能不存在或更容易解決，此外還會導致用戶停機。

監控配置漂移時要注意的常見錯誤

在一個完美的世界中，開發人員（Dev/QA/Staging/Prod）的所有環境服務器都將具有相同的配置。 不幸的是，這不是事物在“真實”世界中的運作方式。 在商業環境中，當向軟件引入新功能時，應用程序所有者經常修改基礎架構。

監控配置漂移對於確保軟件環境盡可能同質至關重要。 配置管理可減少開支、提高生產力和調試時間，並增強用戶體驗。

為了盡可能成功地進行監控，組織必須避免錯誤，即使他們使用配置管理並監控其配置漂移。

常見的錯誤如下：

不維護 CMDB

使配置管理數據庫 (CMDB) 保持最新是配置管理的重要組成部分。 可以在一個地方檢查網絡硬件和軟件安裝的信息，由配置管理數據庫提供。 為每個資產或配置項收集數據，提供工作場所的可見性和透明度。

未能維護 CMDB 會使企業面臨無法完全理解一個項目的配置如何影響另一個項目的危險。 組織冒著破壞其基礎設施和安全性的風險，卻不了解後果。

CMDB 可能難以管理，尤其是隨著資產數量的增加，但有效的數據庫組織和管理對於成功跟踪配置漂移和理解基礎設施至關重要。

沒有如何監控配置漂移的計劃

組織經常擁有需要監視的龐大、複雜的基礎設施。 確定最需要監控的組件至關重要。 否則，配置管理可能很快變得難以管理和混亂。

組織必須指定哪些資產對於公司監控和特定業務部門至關重要。 將關注最關鍵的系統，這些系統將因單位和行業而異。

不自動監控

組織可以通過多種方式監控配置漂移。 然而，有些方法比其他方法更精細和更成功。

手動監控配置漂移既昂貴又耗時。 手動監控也暴露了人為錯誤的可能性。 除非您的公司的基礎架構佔用空間非常小，否則這不是監控配置漂移的最佳技術。

自動監控是將配置保持在所需狀態的最發達和最有效的方法。 專用配置監控系統可以立即檢測漂移並經常提供解決方案，包括快速校正。 這保證了業務的基礎設施在可行的情況下盡快恢復到所需的狀態，並且影響最小。

如何監控配置漂移：

一旦您意識到配置漂移可能造成的損害，為什麼檢測配置漂移應該成為頭等大事就變得顯而易見了。 了解要保留的內容以及為什麼將其呈現為造成漂移的更改是該過程的第一步。

知道你在找什麼

您可以通過識別對整個組織至關重要的組件以及對每個業務部門至關重要的組件來對您的組織進行分類。

這因單位而異，並且可能在高度監管的行業中很廣泛，或者僅專注於較窄的系統關鍵文件/應用程序。 系統的重要性將決定監控系統的頻率和嚴重性。

設置基線

由於各種設置，生產環境和測試階段之間總會存在差異。 通過定義每個步驟應該是什麼以及允許的偏差類型來創建檢查漂移的基線。

與用戶驗收測試設置或零漂移製造階段相比，早期測試階段可能更適合更高的漂移容限。

監控您的系統

所需的監控級別將根據組織的成熟度、其當前系統、工具、需要檢查的配置總數以及所需的審查級別而有所不同。 根據要求和合規性，組織內每個單位的監控可能會有所不同。

如何防止配置漂移

在定義了配置基線和允許的差距之後，監控必須確保基礎設施保持在適當的配置中。 如果沒有監控策略，構建配置計劃和文檔會浪費時間。

可以採用各種方法來監控配置漂移，許多企業將根據其成熟度和合規性要求組合方法和工具。

持續手動監控

可以手動查看單個機器配置並將其與已知配置文件進行比較。 由於人為因素，這個過程仍然容易出錯並且在員工工時方面成本高昂。 我應該隻小規模地用於一些特定的服務器集群或具有適度基礎設施足蹟的公司。

審計

作為配置審計的一部分，一個團隊手動檢查服務器配置，並將它們與指定的模型進行比較。 這些審計可能很昂貴，因為它們需要專業知識來確定應該如何構建系統，然後對任何未記錄的機會進行徹底調查，以決定是否應該保留它。

審核小組還對將在下次審核期間應用的配置文件進行必要的調整。 出於時間和成本方面的考慮，通常會為高價值或合規性高的集群保留審計，並定期執行，通常一年多次。

審計確實可以保證按照預定的時間表進行一致且可重複的服務器配置。

但是，在下一次審核之前，設置會越來越多地漂移並保持不變。

實時自動監控

自動實時監控是將配置保持在所需狀態的最複雜的方法。 為此，必須創建服務器或服務器組，並說明應如何使用專用服務器設置工具對其進行配置。

這些程序將使用輕量級代理來監視該組中的服務器配置並將其與其定義進行比較。

這個自動化過程會立即對漂移發出警告，並且通常會提供多種選擇來糾正服務器漂移。

最後的話：

計算機或設備之間不一致的配置項 (CI) 是配置漂移的根本原因。 配置漂移在數據中心環境中很自然地發生，當軟件和硬件修改是在沒有徹底記錄或跟踪的情況下動態完成時。

許多高可用性和災難恢復系統故障都歸因於配置漂移。 管理員應仔細記錄硬件設備的網絡地址，以及安裝在設備上的軟件版本和已進行的升級，以盡量減少配置漂移。