云服務器配置也能“漂移”？這個問題在IDC行業經常被提及，但很少站長會關注和重視這個問題。”配置漂移“(某些文件在部署到服務器之后發生了一些變化)是不允許出現的，因為這很可能會導致應用程序不穩定，是系統的一大致命隱患。以下內容介紹什么是配置漂移以及如何避免配置漂移。
云服務器配置“漂移”咨詢：http://www.bxgb88.com/dedicated/hkcloud.html
一、云服務器配置也能“漂移”？
以Linux操作系統為例，如果在變更規格后執行ifconfig命令發現云服務器原來是eth0、eth1的網卡設備沒有了，變成了eth2、eth3，說明云服務器變更規格后發生了網卡漂移。云服務器的配置漂移，主要原因是你改變了云服務器環境中的某一項配置，引起了超出預期的偏差或變化。尤其是隨著時間推移，開發和運維對發生的需求和問題多次作出響應后，云服務器的環境和系統逐漸偏離了既定策略或標準。例如，
1、在排查bug，或者處理線上問題時經常會出現這樣的場景： “我在測試環境做了一個修改，但忘記在生產服務器上同步這樣的改動”;
2、 “為滿足某臺云服務器實例中應用程序的需求，我改動了某個安全組規則，造成這個安全組內的其他云服務器出現問題”;
3、 “我之前設置了某些自動化任務，后來運行其他任務時，與之前的自動任務產生了沖突”。
事實上，超過 50%
不定期系統停機時間可歸因于配置問題。如果云服務器和應用部署不是采用相同的標準進行配置，則管理多個云服務器實例和應用可能很快變得非常復雜。即使對于最初被完全相同的配置的云服務器實例和應用副本，配置變化也可能隨時間的退役而產生偏差。配置漂移越大，就變得越難以調試問題，使得對系統的有效管理和維護更加困難。
二、如何避免配置漂移?
1.)基礎設施代碼化
基礎設施，即制作服務鏡像時的需要的 jdk
庫、環境變量配置、證書文件等。將其代碼化，保證了服務鏡像的一致性。為快速修復做好準備。對于經常偏移的特定資源(如安全組)，請考慮部署自動修正解決方案以防止系統停機事件。
2.)服務器不可變
鏡像制作完成并成功部署到環境后，不允許開發人員或系統管理員對服務器進行修改。在某些時候你需要對應用程序可以創建的可能配置選項范圍，應用一些安全驗證。
3.)定期重啟服務器
為避免因基礎架構漂移而遭受數據泄露，必須使用自動檢測和修復關鍵資源的漂移事件的解決方案。你不能讓關鍵數據暴露數小時、數天或更長時間。
這里我們針對的是測試環境。服務運行的時間越長，就越容易發生配置漂移，因為我們不能保證一定不會有人會去修改環境的配置數據。我們需要對服務器進行定期重啟，使用最開始的配置來重啟服務。能有效避免服務被更改配置的情況。不過這種做法目前沒見過，可能是大家對配置漂移都不太重視的原因，也有可能是我經驗不豐富見識少的緣故。
在測試環境重啟服務一般是升級和重新部署時才有的行為，如果一定要這樣做，又不影響到QA進行測試，實現起來應該是這樣子，先新增一臺初始配置的服務實例，然后下線舊的實例，當然這種情況需要考慮業務對機子存在粘性的情況，舊的實例下線可能會影響正在進行的業務。這就需要服務支持灰度升級，才能實現對
QA 無感知的效果。
當然也可以約定一個服務的卸載時間，比如運維的腳本在凌晨3點卸載所有服務，然后重新部署服務。這相當于運維-測試之間的一種約定，運維保證服務定時卸載，QA
已知這種行為并且在測試時需要注意。我們討論的避免配置漂移的方案主要的目的就是在配置漂移影響到生產環境前能夠盡可能地消除配置漂移的存在。
上一篇：
租用臺灣服務器如何計算流量和帶寬?
下一篇：
為什么你需要國外視頻服務器加速服務?
