一、需求分析階段

客戶需求

在需求分析階段，需要挖掘出客戶真正在乎的需求，最好對需求進行分優先級，不能眉毛胡子一把抓。而且需求并不是一成不變，項目過程中增減需求是平常的事，但由此造成的影響要評估并更新文檔。有時項目組需要和客戶協商撤銷或者推后某些需求。可能的原因有：造成整個方案成本大幅上升；與其它關鍵需求沖突；可能造成項目延遲等等。

環境的限制

這點尤其重要，卻常常容易被忽略。在分析階段盡可能挖掘限制條件，會避免后面階段很多的問題。比如客戶已經在使用NFS，并且現有維護人員有能力維護該系統。你在推薦SAN的時候就要考慮帶來的影響；若客戶與某大供應商有協議，你是否可以考慮其它廠商？若客戶有較嚴格的安全性策略，設計共享時要考慮哪些部分是不可以共享的，是否需要虛擬層的防火墻等等。

假設的條件

有時在項目執行中會因為某些需要客戶或第三方完成的事情不具備，而造成項目延遲。這就需要在合同中就對這些假設特別說明/，以避免后面的責任不清。比如假設客戶網絡環境是可以支持你的設計的，可實施時才發現上行網絡的防火墻的帶寬或端口限制會大大影響你的方案的性能。
比如假設你需要使用客戶已有的數據庫，卻發現版本和你的方案不兼容。

二、設計階段

概念設計

根據需求分析階段的信息，應該盡快出一個概念設計的草圖來描述以下信息。系統大概分幾個運行環境，是否需要單獨的開發和測試環境；
多個數據中心之間的聯系，是ACTIVE-ACTIVE還是ACTIVE-PASSIVE；數據是否在數據中心之間同步；虛擬和物理網絡如何共享等等。

邏輯設計

以概念設計為綱，邏輯設計描述了更多系統各部分的聯系。HBA和光纖交換機，存儲設備是如何聯系的；集群是如何設計的；主要的管理軟件等等

物理設計

依據邏輯設計，物理設計具體到使用什么設備和型號，與上行物理網絡的聯系，服務器在機柜位置的分配等等。

可能的影響和風險。

某一個設計決定可能會影響到其它設計決定，也有可能帶來一些風險。需要評估風險并提出規避風險的方案。

最佳實踐(Best Practice)

盲目照搬所謂的最佳實踐，可能并不適合你的環境。需要知道最佳實踐背后的原因和使用的環境。

重點是不僅知道做什么，還要知道為什么這么做。為了避免人們對所謂最佳實踐的誤解，VMware

已經將其更改為設計指導

模塊和整體

虛擬化方案大概有存儲、網絡、主機及集群、虛擬機和管理系統幾個模塊，按模塊設計有助于系統的深入設計一個主題。不過一定要注意模塊間的關聯。比如你虛擬機的內存由2G改稱4G，那么集群設計中的內存就要重新考慮，同時影響到了Swap空間增長，存儲也要考慮。

在設計階段需要完成的文檔有以下：

架構設計

整個系統的概述和各個組成部分的描述。

安裝手冊

具體的安裝步驟。當然不是說要細到怎么安裝vCenter，標準安裝可參照已有官方文檔。關鍵是要突出設計中針對用戶環境定制的部分。比如你網卡負載均衡采用Load based teaming；集群的Admission control policy在只有20%空余資源時生效等等

衡量一個好的安裝手冊很簡單，如果有經驗的系統管理員按照安裝手冊部署的系統，沒有和架構設計有大的偏差，應該算是可以的。

實施計劃

在真實環境中項目經理負責和架構師一起制定適當的計劃。干什么，什么時候完成，誰負責等等。

有經驗的架構師可以分析各項任務的倚賴性，做好統籌分派。

測試計劃

很重要的一步，怎么才證明你的系統符合用戶要求？怎么才讓客戶簽字？成功執行測試計劃尤其重要。

運行計劃

架構師要有全局觀，某些設計決定對運維環境，人員能力以及成本都有影響。比如，vCenter Linked clone會讓維護人員用一個管理界面管理兩個vCenter；
盡可能利用腳本或者現有軟件自動的功能減少重復性的人工和不必要的人為失誤；考慮激活EVC，
避免以后新添服務器需要重啟集群中的服務器。

本文小結：

成功的系統是怎么煉成的？

充分了解真正客戶需求，并采取合適的技術方案滿足需求，是關鍵的第一步。溝通協商能力和技術能力一樣，二者不可或缺。
也要注意靈活性，有創意的解決問題。不能因為所謂技術上的完美，犧牲其它客戶很在意的方面，比如成本、項目進程、人員等等。有時適當的中庸之道不失為一個可行的方案。