企業網D1Net 1月2日訊
變更管理是一條復雜的道路,路途中到處坑坑洼洼。學習一些方法和指南有助于幫助您更好地管理數據中心。
雖然系統或網絡管理的工作往往就是要維持現狀,但是變革管理也是你的工作。為了保證有效地交付服務和資源,必須在老系統過渡到新系統時,應盡可能地保持數據中心正常運行。
變革管理(也稱為配置管理)并不總是安全的或容易的。換句話說,在IT方面,如果我們只是一味地追求安全,那么我們現在可能仍然運行著Windows NT 4 SP 6a。新系統和新技術似乎總是更快、更有活力。曾有一些系統在建成后的第二年,為了安裝更好的系統而被拆除。從財政角度,我對這其中可能產生的浪費驚駭不已,而在技術層面,部署新事物讓我著實高興。
多年以來,我學會了一些變革管理的方法想與大家分享。一些來自于直接的經驗,另外一些來自于他人的知道,而更多的來自于在現實中對朋友或同事公司的糟糕環境的觀察。
我所提到的變更管理,是指技術安裝、升級、修復及遷移(比如從物理服務器遷移到虛擬機)。請注意,在信息技術基礎設施庫(ITIL)中有正規的變更管理過程的相關內容,也有如Evolven和McCabe CM等專門的軟件包來幫助完成變更管理。而這里則將帶來一些得到成功實踐的非官方技巧。
冗余永遠不嫌少
大多數的IT專業人員并不需要熱衷于增加冗余(各種的挑戰在于說服財務部門),但是任何一個關鍵任務都需要有雙備份系統。這點適用于服務器、網絡硬件,甚至是存儲。如果您想正常運行您的業務,請確保有雙備份的系統。如果你沒有雙備份系統,那么你得知道,當主系統不可用時如何能拼湊出替換系統。例如,幾年前我設立了一個Windows文件服務器用來在SAN共享數據。我們沒有正式集群或網絡負載均衡解決方案方面的預算,因此我開發了一個備份服務器故障轉移計劃:
1、我分析并測試了在備份服務器上安裝服務器SAN卷的方法。
2、我每天晚上從主服務器注冊表中導出文件共享配置,并保存在C盤中:以此驅動備份服務器。
3、我每5分鐘記錄一次主服務器的域名服務器。
4、我在備份服務器注冊表禁用嚴格的名字登陸檢查,因此客戶可以通過任何我希望的DNS名與其連接(默認Windows服務器操作系統可以防止這一點)。
5、我記錄了整個故障轉移過程。
這意味著通過相關DNS記錄的更新,備份服務器可以很容易地“成為”主服務器,并且用戶可以很快地重新轉入(很多用戶甚至不會注意到這個中斷)。這包括驅動器映射和文件共享訪問。完備的記錄意味著我同事當中的任何一個都可以遵循以上的步驟。
對于冗余部件,應千方百計地使它們保持一致性——它們應該是相同的制造商/模型,運行相同的操作系統,有相同的驅動和熱補丁,以不同的交換機或PDU插入相同的端口等等。
還有一個關于冗余的關鍵提示…
冗余系統之間應分別進行變更
當應用變更時,冗余系統會為你提供巨大的杠桿作用,你可以讓冗余系統中的一半先停止工作來進行轉移或升級,然后再對另一半系統進行同樣的操作。然而,一定要在兩次變更之間留一段的間隔時間來確保第一次的系統變更是成功的。例如,當修補服務器時,一定要騰出幾天時間來發現和糾正問題,之后在對第二套系統進行修補,這段期間你將需要依靠功能仍然正常的系統。
使用集中解決方案來部署更新
對于質量變更管理,你應該始終選擇復雜度最低的方式,這意味著一個能安裝補丁、軟件、殺毒軟件更新和配置設定的集中內部系統。這將使得你能更好地追蹤系統,為變更做準備并報告結果。例如微軟的Windows服務器更新服務、微軟系統中心配置管理器、微軟群組策略(Active Directory的一部分)、賽門鐵克端點保護管理器和戴爾管理控制臺等,這些產品將給你一個參考,并確保你的客戶端和服務器不會只是沒有選擇地從網上下載更新(或者更糟的是,更新失敗且沒有通知你)。
絕不要使用系統粉碎機
沒有什么比完全摧毀現有系統,以求讓一個新系統來代替它來得恐怖。無論是文件服務器、郵件服務器、存儲設備,還是別的東西,在遷移到新系統時,你都應該完整地保留舊系統,直到更新全部完成。直到舊系統過時了,你才可以使其退役。
例如,如果要使Windows 2008文件服務器更新到Windows 2012系統,需要將所有數據(與權限)從舊系統拷貝到新系統,并安排用戶來測試訪問。在更新系統的時候,我發現了新服務器網絡驅動程序的一些問題,這迫使我將用戶遷移回舊系統。我并不介意這一步,我為還可以使用舊系統而感到慶幸。
采用多點輸入的方式來設計變更計劃
跟冗余越多越好一樣,變更計劃的步驟也要越多越好,就像一個好的聚會,參與者越多,效果才越好。
盡可能多得的利用其他的輸入信息來識別一切隱藏的陷阱。你的初步計劃盡可能的周密,這樣不需要其他步驟為你填補空白。比如,你在思科交換機上升級固件,然后就可以直接重新啟動嗎?你如何能確保升級成功了呢?好吧,你可以發送信息,如果收到回復的話就斷定升級完成,但是我認為那只是表面。你應該登錄、檢查錯誤日志,并測試所有功能。登錄后,確保它沒有因內存泄漏而鎖定。多次對其進行重新啟動。從另一個子網絡連接它。也許除了這些檢查之外,還有人會建議測試一些運行在與交換機相連的服務器上的核心應用程序。所有的這些都是你應該一步步檢查的,最理想的是你在測試系統上提出這個清單,盡管測試環境中的結果在實際生產中并不能保證總是一致的。
不要以為你會做的事就一定會成功,一定必須親自注冊并嘗試過。我見過很多的問題,以管理員權限可以執行很好的功能,但普通用戶權限卻不能按期工作,至少需要調整之后才行。
最后一點:在不同的系統上多次執行你的檢查列表會是冗長無味的,然后你可能會忍不住跳過某些步驟或者偷工減料,你會想:“對呀,已經檢查過兩次了為什么還要如此的繁瑣呢?”墨菲定律告訴我們,要抵制這樣的邪念。
多重驗收
如果能從別人那得到應該在完善什么的反饋那就再好不過了。聰明的公司懂得分散風險:制定計劃應獲得員工或其他相應當事人的批準。這也許包括你的老板、相關部門主任,或者是客戶基礎副總裁。審批過程應確保所有人都知道和同意,并支持擬議的變更。讓我們面對現實:如果我知道我將負責一個失敗了將影響企業盈虧的計劃,我會努力確保過程是合理的。
這樣的安全措施不僅可以在出現差錯時保護你,而且將讓人們了解該事故,并能幫助團隊共同努力來找到解決方案。
制定撤銷計劃
每一個變更都應該有相應的撤銷方案。如果失敗了,你打算怎樣把事物歸回原位?你會在虛擬環境中使用快照?你會重新導入重要的注冊表,或是應用備份組策略使Windows服務器配置回歸到之前的狀態?你需要制定這個計劃,并使其盡可能的明了細致。一次失敗的變更或升級可能會大大地損傷你的創造力,在緊張時刻,查找可行的選擇會是你想做的最后一件事。撤銷方案很可能是一個你不曾用到的保險單,但能為我們帶來平和的心態。
如果你確實需要撤銷變更,確保你盡可能多地記筆記、截圖或保留其他的證據,以便下一次你可以找出錯誤并進行糾正。擺脫不愉快的開端的秘訣便是“第二次嘗試并希望它成功”。
仔細選擇你的變更計劃
毫無疑問,數據中心的大多數變更都應該在下班后或非關鍵時期。如果你的備用服務器在周一上午10點罷工的話,即使是升級冗余系統也可能會構成風險。無論如何,要仔細地計劃你的時間表。
你可以在周日晚上11點執行數據庫轉換。但如果某些原因造成延遲,而且7個小時過后當用戶到達辦公室時,轉換仍在進行,那該怎么辦呢?
也許選擇在周五下午5點會是一個更好的主意。呃,好吧,只是要注意你不要沉醉于家庭生活,直到周一早上上班,才想起來檢查升級結果。
也許你有備用站點可以用于災難恢復(DR),并且你已經讓它成為主站點來測試故障轉移功能。在你計劃反轉的12小時前,不要急于升級原來的主站點系統。
正如我上面所說的,你的計劃應該是使用、支持和管理這些系統的利益相關者和團體的產物。
使用審計和個人賬戶
如果可能的話,在您的環境中總是使用審計賬戶(即使你不得不在變更項目期間暫時的打開,之后為了保護資源又將其關閉)。這將有助于追蹤系統命令及產生的效果。
類似的,如果你可以避免的話,不要使用如“管理員”這類的共享或通用賬戶。這些命令應該與個人賬戶相連(最好是只用來執行這類工作的特定賬戶,盡可能使用有限制的帳戶)。在動態目錄環境中,這并不是那么容易,許多時候都需要使用“管理員”帳戶。無論如何,要盡可能地遵循這一原則。
這令人聯想起 “如果屋里有東西壞了,你只有一個孩子,你當然知道是誰干的!”然而,這不是指責,而是記錄發生了什么,由哪個賬戶產生的。如果需要撤銷變更或是確認問題所在,你將需要這些信息。
在監控系統中安排停機時間
假設您設立了一個健全的監控環境來檢查關鍵系統的健康和正常運行時間,并在出現任何問題時通知你。當你打算使這些系統脫機來進行變革管理時,你應該在你的監控系統中事先安排合理的停機時間,因此它才會保持沉默。采取這一步是挺痛苦的,尤其是對于多重系統來說,但是忽視重要警示的做法實在是太危險了,以至于必須先不去追蹤它。
因為當你處于升級中時,你無法確切地知道發生了什么,除了手頭的緊迫任務,你可能會發現自己被環境愚弄了。例如,你收到一個告知你思科郵件網關反應遲鈍的信息,你可能會想:“是的,我知道它反應遲鈍,因為我在升級它!”如果你之后發現該信息是由其他工作良好的郵件網關產生的,而它停機了三十分鐘,該怎么辦呢?
總結
IT人員常常承受著大量(外部或內部)的壓力,完成一個任務之后又急著開始下一個任務,這樣他們才可以繼續體現對組織的價值。然而,這種壓力與IT本身的概念正相反:以最少的停機時間和中斷來運行設備。
許多優秀的數據中心變更管理技術可以歸結為常識、保守和謹慎行事。希望這些方法將有助于你的環境變革變得可預測和可控制,從而你可以接受一切可能性而無所畏懼。
(作者Scott Matteson是一位高級系統管理員,同時也為中小企業提供咨詢服務)