如果你要一個數據中心遷移或整合項目，就要做一些非常具體的準備工作，才能確保這個項目取得成功。如果你正從一家供應商換成一家新的供應商，就不要急著開展這個項目，等到滿足了規劃方面的某些標準再開展也不遲。

從這類遷移項目汲取的經驗有重大意義，這有幾個原因，包括IT部門內外客戶的滿意度、成本以及為集成商贏得業務的普遍成功。

就其性質而言，這類項目往往給人的壓力特別大，因而團隊建設和幽默感成為了重要的工具。讓項目三方的技術團隊及早參與這個過程，將便于轉移知識、加強團隊合作。

與客戶和第三方分包商積極溝通，并得到他們的大力支持，這至關重要;與第三方企業的上上下下積極溝通事關這種項目的成功。這種項目同樣面臨人員配備、管理、溝通、談判和架構等方面的挑戰。行動要靈活，思維要有創造性，還要準備打破既定的方法，那樣才能竭力推進架構方面的工作。

第一道障礙將是確保現現有和新的供應商、客戶及與項目有利害關系的其他任何人都參與進來，并且就承包出去的工作達成一致意見。不管協議多么不重要，任何協議都必須列入文檔，因為幾個月后大家會漸漸淡忘。

合同內容通常很繁瑣，要花很大的精力來擬訂草案。如果你有一個團隊坐等合同擬訂草案、通過審批，預計項目會出現超出預算的情況。這方面要把握的一個準則是，要是沒有訂好適當的協議，項目就不要開始，因為這會消耗項目資金、導致預算出現問題。

一旦擬訂好了協議，經驗表明：雖然我們會發現平日的技術人員非常樂于合作，但是第三方供應商的管理人員可能會抵抗，如果他們失去業務更是如此。由此帶來的結果將是，由于需要上報無關緊要的事情、轉型期間的活動以及競爭優先事項，項目時間表會被往后推遲。

一家供應商習慣采用的流程可能要加以改動;這在一些情況下可能需要修訂合同。遷移過程可能由項目團隊來推動，這是個錯誤。就因為你有一支精干的技術團隊，能夠在周末把數百臺服務器遷移過去，并不意味著客戶或公司就有能力來測試、核實和接收環境出現的那么多變化。

想確保項目成功，還需要額外的項目管理費用，以及面面俱到的溝通策略和創造性思維。你必須預料到僅僅安排與客戶及供應商、架構和技術中小企業開會就面臨困難，因為彼此的優先事項可能并不總是一致。

我發現，當遷移項目不是各團隊的優先事項時，三方之間缺乏力度或不連貫的項目管理會導致進一步延遲。要牢記一點：如果三方的目標不一致，那么一些簡單的任務也需要上報，比如轉移許可證，或者建立從新供應商環境到原供應商環境的網絡連接。

通常情況下，供應商不會允許任何第三方的人員進入其場地，如果這家供應商在共享基礎設施上托管多個客戶更是如此。這就意味著，你將無法直接訪問管理工具，也無法直接訪問收集數據的服務器，這影響了敲定解決方案的進度。

要是無法訪問數據中心和管理工具，你就只好賴供應商的人員來做一些工作;這將導致工作從一家內部或新的供應商移交到原供應商。轉移資源意味著范圍出現變化，可能會推遲項目進度。

出于安全方面的顧慮，供應商阻止你進入其數據中心;同樣的原因可能也會阻止你運行數據收集和遷移工具。由自動發現改為手動發現會導致項目推遲幾個月，而且事實的確如此。這是由于客戶覺得現有供應商擁有的數據常常不完整。此外，環境通常比客戶所了解的來得復雜。連鎖反應是：

•非功能性需求可能需要加以改動;

•由于提供了新數據，架構方面的決定可能需要重新考慮;

•由于現在可以使用新數據，技術設計可能需要加以修改;

•由于環境的復雜性，測試階段可能需要比原先預期更多的資源。

在供應商的確允許訪問自動化工具的少數情況下，現有供應商的管理人員可能想要審查提供給第三方的任何客戶數據。這個過程可能涉及沒有落入到新供應商的人員手里的一部分數據。提供的通常是不充足的、過時的數據，不過并非總是這種情況。

最后，新供應商應該準備好只接收所請求的數據;因而，請求在想要多詳細的數據方面必須非常具體。

不要簡單地請求利用率方面的數據;還要請求處理器線程和利用率、內存和調整內存、網絡輸入/輸出、磁盤輸入/輸出、磁盤空間使用情況等方面的數據。另外，由于數據收集可能需要重新考慮，進行評估所需要的任何工具都應該在數據收集工作完成后一段時間內保持仍然可用，最好是直到技術設計通過驗收。

原文鏈接： http://www.zdnet.com/blog/btl/datacenter-and-workload-migrations-lessons-from-the-trenches/79942?tag=content;search-results-river

轉載鏈接：http://server.51cto.com/sCollege-343332.htm