管理員需要防止未經授權的變更對虛擬化環境帶來負面影響，及時找到rogue server并決定是否將其從現有環境中移除，避免其對當前環境造成破壞。
理想情況下，應用和服務器能夠一直不間斷正常運行，不會出現資源和沖突等問題，數據中心的所有一切保持著十分和諧的關系。不幸的是，我們并非生活在這樣的理想環境當中。雖然針對虛擬化環境編寫文檔和制定控制流程能夠起到幫助作用，但是盡了所有努力之后，我們依然可能遇到rogue server問題，并且這種問題會產生嚴重影響。而這種問題通常是管理員工作計劃過于緊張的結果。如果沒有事先制定清晰的變更流程，那么后期可能需要更多的人參與到其中才能夠完成原有目標。
盡管某些操作的最終目的是合理的，但是本質上其仍然屬于對系統進行未經授權的變更。僅僅一個未經授權的變更也許不足以摧毀整個虛擬化基礎架構，但是如果大量變更累加在一起，就有可能對系統造成嚴重破壞 。對于那些擁有關鍵系統控制權的管理員來說，得知變更是在超越其知識或者權限的情況下進行的是一件非常令人沮喪的事情，但是需要記住的是，這種變更從來都不是出于惡意的。作為虛擬化管理員，能夠暫時后退一步，不將個人感受帶到工作當中是非常重要的;也許聽起來有些像心靈雞湯，但是清醒的頭腦對于整個流程來說是至關重要的。
深入研究日志
如果想要修復未經授權變更所帶來的影響，那么第一步就是調查并且掌握究竟發生了些什么。問題的根源有可能是一些非常小的事情，比如添加或者調整資源;也有可能是非常大的事情，比如創建新的虛擬機或者徹底更改配置。研究日志的目標在于定位系統變更，之后找出變更的目標、時間以及涉及的人員。如果不進行恰當的調查，那么管理員肯定無法反向推理出整個變更過程。同時作為IT人員，你的首要任務之一就是保證系統正常運行，因此不管怎樣也不能拔掉電源插頭。
完全弄清楚究竟發生了哪些改變可能是一件非常困難的事情，但是計算機系統最擅長完成的任務之一就是記錄日志。有時候改變是顯而易見的，但是大多數情況下，管理員必須深入挖掘日志，來找出系統究竟發生了哪些改變以及是何時進行的。如果公司很好地遵守相關流程，不使用通用賬戶來登陸關鍵系統和基礎架構，那么管理員還能夠在日志當中找出是誰執行了這些變更。任何變更都會留下管理員能夠追蹤的痕跡。在審查日志的過程當中，需要特別注意變更發生的日期和時間，將其和當前查看的日志相互關聯，能夠提供很大幫助。
移除還是保留?
當管理員了解發生了哪些改變、何時發生以及變更執行人之后，就可以計劃一系列操作來修復這個問題。而在這一步，不同管理員可能使用不用的處理方式，因此情況可能會變得復雜。管理員可以選擇保留或是移除rogue server，但是無論哪種方案都有缺點。盡管看起來移除服務器非常容易，但是實際上并非如此。假設下面這種情況：你的一位上司告訴你移除服務器。你按照正常的操作流程進行驗證，之后移除了服務器。但是兩個星期之后，你接到電話說一些重要資料仍然保存在服務器上，而你的上司馬上就要使用這些東西。當然，現在所有東西都被刪除了，你和你的部門都將陷入困境當中。如果服務器創建時沒有遵循正常流程，那么管理員很有可能并不清楚這臺服務器的真正用途，因此在移除任何東西之前，都需要關閉服務器，之后將信息存儲到單獨的SATA磁盤當中。我建議管理員在最初收到命令和真正移除服務器之間等待幾個星期，只是以防萬一，將其作為一個簡單的保險策略。
移除一臺rogue server好像不是特別容易，但是將其保留下來需要面對更多的挑戰。即便服務器使用基礎模板進行創建，管理員也必須進行健康檢查。服務器是否已經配置了恰當的安全策略、備份以及監控?以及恰當的資源管理、命令規則和地址規劃?所有這些都需要一項一項進行驗證。當然，如果系統已經上線，那么管理員可能會遇到更多挑戰，但是這些步驟需要被盡快完成。其他關鍵組件還有申請/批準表格。對于rogue server來說，負責創建這臺服務器的管理員很有可能沒有完成這些文檔工作。為了解決這個問題，你需要讓管理員填寫恰當的批準/申請表，即便出現問題的服務器已經被移除了。如果出現和rogue server相關的安全問題或者事故，文檔能夠提供審計線索，未來可能會派上用場。事后完成文檔工作對于基礎架構濫用者來說也能夠起到警示作用，讓其認識到不能隨便繞過規定。畢竟，這些規則的存在是有原因的——能夠避免未來解決問題時遇到的種種麻煩。
京公網安備 11010502049343號