服務器遷移安全講解

　　用戶要面臨的挑戰是即要完成服務器遷移又不會損失解決方案A所需的功能和資源或者引發過多的宕機從而招致用戶對IT部門的投訴。
　　因此當你小心謹慎的實施遷移的過程又不願遭受損失整個系統的風險，那麼你該如何應對這種兩難的狀況呢？你又該如何滿足用戶對零宕機的苛刻要求呢？以下是幫助你規避這些風險的五個提示。
　　提示一：了解系統之間的從屬性
　　雖然IT員工可能不願意承認這一點，但某些員工可能確實不完全了解一項解決方案在既定的遷移戰略中是如何工作的。以Exchange Server為例。更改為Exchange Server可以用幾種方式完成，從單個用戶遷移簡單的電子郵箱轉移的操作到從整個服務器轉移到新的域這種第三方解決方案（如果必要的話）都涵蓋在內。
　 　面臨的挑戰是這種遷移會對諸如Good Technologies服務，黑莓企業級服務器，Lync和移動技術套裝向Exchange（Outlook WebAccess/App,OutlookAnywhere和ActiveSync）本地遷移的系統產生影響。與在電子郵箱服務器遷移過程中將這些生態 系統解決方案考慮在內的方法不同，你可以非常快速的導出所有的移動用戶。但是無法全面了解所有的外圍系統，而你的目標遷移系統可能會依賴這些外圍系統或者 相互依賴，從而讓你陷入真實遷移的夢魇。
　　提示二：知道什麼是必須要進行遷移的
　　一套解決方案是 由涉及一個或者多個服務器或者硬件資源的一個或者多個組件所組成的。在遷移過程中正確的步驟能確保你首先了解解決方案的工作原理和遷移部分在開始實際遷移 前會占到所遷移系統中的比例。傳真服務器就是這種解決方案類型的最好示例，因為要保證操作正確許多企業都需要物理傳真卡。如果你沒有確保傳真卡與你試圖遷 移的新硬件/虛擬化平台相兼容的話，那麼再好的遷移計劃也會大打折扣。
　　提示三：了解什麼應該被遷移
　　一旦你計算出必須從目前平台遷移出去的組件，你應該全面分析你可能需要遷移或者不需要遷移的組件。總會有一些系統組件是沒必要遷移到新平台上，但是為了將宕機的可能性和復雜性降到最低可能又有必要遷移過去。
　　舉例來說，Windows系統狀態信息可能需要適合的工具從一個硬件平台遷移到另一個硬件平台。如果這種信息可以被遷移過去，那麼新服務器配置的復雜性就能被大大降低，至少從Windows系統和軟件的角度來說是這樣的。
　　提示四：設定期望值並堅持目標
　 　用戶都希望實現無宕機的遷移。但是不幸的事實是這種零宕機的夢想在真實的遷移世界中通常是不可能的。即使在實施物理遷移時沒有出現可見的宕機（比如在 Exchange或者Notes中遷移電子郵箱），你仍然需要給你的員工一些喘息的空間來應對意料之外的突發狀況。遷移系統狀態信息和二進位，認真規劃和 在遷移之前提前做好每一件事情能讓宕機的可能性降到最低。不過消除所有主要硬件遷移過程當中的宕機只是種期許，可能很難實現。