|
| |
| Sun Java Enterprise System 2005Q1 部署規劃指南 | |
第 3 章
技術需求在解決方案生命週期的技術需求階段，您會執行使用分析、識別使用實例，以及決定提議部署解決方案的服務品質需求。
本章包含以下各節：
關於技術需求技術需求分析以解決方案生命週期的業務分析階段期間所建立的業務需求文件開始著手進行。使用業務分析為基礎，執行以下步驟：
服務品質需求來自使用分析和使用實例，請記住先前已確認業務需求和限制。
稍後，會在邏輯設計階段中將服務品質需求與邏輯架構搭配以形成部署方案。部署方案是解決方案生命週期之部署設計階段的主要輸入資料。
在業務分析中，對於技術需求分析而言，並沒有產生使用分析、使用實例與系統需求的簡單公式。技術需求分析需要瞭解業務領域、業務目標以及系統科技的構成。
使用分析使用分析包含確認您設計的解決方案的各種使用者以及決定使用者的使用模式。您所收集的資訊是估計系統負載情況的基礎。使用分析資訊在分配使用實例的權重時也非常的有用，如使用實例中所述。
在使用分析期間您應該盡可能地約談使用者，研究使用模式現存的資料，以及約談設計者和之前系統的管理員。下表列出執行使用分析時應該考慮到的因素。
使用實例使用實例以您設計的解決方案塑造出典型的使用者互動，從一般使用者的角度描繪出作業的完整流程。決定完整使用實例的設計優先順序可確保持續集中焦點在達成預期功能上。使用實例是邏輯設計的主要輸入資料。
指定相對的權重給使用實例，權重最高的使用實例代表最常見的使用者作業。使用實例的權重可讓您將設計的重點放在最常使用的系統服務上。
使用實例可描述為兩種層級。
服務品質需求服務品質需求 (QoS) 是技術規格，可指定系統功能品質，例如，效能、可用性、延展性及服務性。QoS 需求以業務需求中指定的業務需要為導向。例如，如果這些服務必須 24 小時全天候提供，可用性需求就必須解決這項業務需求。
下表列出通常會形成 QoS 需求基礎的系統品質。
系統品質彼此息息相關。對某個系統品質的需求可能會影響對其他系統品質的需求與設計。例如，較高層級的安全性可能會影響效能，而效能又會影響可用性。新增額外伺服器來解決可用性問題卻可能影響到服務性 (維護成本)。
瞭解系統品質如何產生關聯以及其利弊，是設計能夠成功滿足業務需求和業務限制的系統最大的關鍵。
下節更進一步描述影響部署設計的系統品質，提供公式化 QoS 需求時的因素指導。關於服務層級需求的章節，其中亦包含形成服務層級合約的基礎。
效能
業務需求通常以指定回應時間的非技術名詞表示效能。例如，以 Web 架構存取的業務需求可能強調以下：
以業務需求開始，檢查所有使用實例來決定如何在系統層級表達此需求。在某些情況下，您可能想要包含在使用分析期間所決定的使用者負載條件。以特定負載條件下的回應時間或是回應時間加上處理能力來表示每個使用實例的效能需求。您還可以指定可容許的錯誤數量。
這是兩個如何指定用於效能的系統需求範例：
效能需求與可用性需求 (故障轉移如何影響效能) 以及潛在容量 (處理不尋常尖峰負載的容量有多少) 息息相關。
可用性
可用性是指定部署系統正常執行時間的一種方式，且通常以系統可供使用者存取時間的百分比為測量基準。系統無法存取的時間 (當機時間) 可能歸咎於硬體、軟體、網路錯誤或者任何其他造成系統當機的因素 (例如斷電)。規劃的服務當機時間 (維護和升級) 不列入當機時間計算。以正常執行時間的比率計算系統可用性的基本方程式為：
可用性 = 正常執行時間 / (正常執行時間 + 當機時間) * 100%
通常您會用可以達成的「九」的數量來評量可用性。例如，99% 的可用性為兩個「九」。指定額外的「九」會明顯地影響部署設計。下表顯示增加可用性額外的「九」到系統的未排程當機時間，系統為一整年 24x7 小時執行，合計為 8760 小時。
表 3-3 系統執行一整年 (8760 小時) 的未排程當機時間
「九」的數量
可用百分比
未排程的當機時間
2
99%
88 小時
3
99.9%
9 小時
4
99.99%
45 分鐘
5
99.999%
5 分鐘
容錯系統
四或五個「九」的可用性需求通常需要容錯系統。容錯系統必須能夠在硬體或軟體錯誤期間繼續服務。通常，容錯是透過硬體 (例如 CPU、記憶體和網路裝置) 和軟體兩者的備援提供關鍵服務。
錯誤單點是一個硬體或軟體元件，為重要路徑的一部分，但沒有透過備援元件備份。此元件的錯誤會導致系統服務的損失。在設計容錯系統時，您必須確認並排除潛在的錯誤單點。
容錯系統的實作和維護可能很昂貴。確定您瞭解用於可用性的業務需求特性，並考慮符合這些需求的可用性解決方案的策略和成本。
排定服務可用性優先順序
從使用者觀點來看，比起整體系統的可用性，可用性更常應用在個別的服務上。例如，無法使用即時訊息傳送服務，通常不會對其他服務的可用性造成太大的影響。然而，如果是無法使用其他許多服務所依賴的服務 (例如 Directory Server)，對系統就會有較大的影響。較高的可用性規格應該清楚地參照到需要較高可用性的特定使用實例和使用分析。
根據優先性的順序組合列出可用性需求會很有幫助。下表排出服務的不同類型的可用性順序。
服務損失
可用性設計會考慮可用性降低或元件遺失時可能發生的情況。同時也會考慮相關的使用者是否必須重新開始階段作業，以及一個區域的錯誤對系統其他區域所造成的影響程度。QoS 需求應該要考慮這些方案，並指定部署如何對這這些解決方案做出回應。
延展性
延展性是增加容量到您系統的能力，如此系統才能支援來自現有使用者或增加的使用者基礎的額外負載。延展性通常需要額外的資源，但是不應該需要變更部署架構的設計，或是因為需要加入額外資源的時間而損失服務。
如同可用性，延展性更多應用在系統提供的個別服務上而不是整個系統。然而，在其他許多服務所依賴的服務之上 (例如 Directory Server)，延展性可能會影響整個系統。
您不需要以 QoS 需求來指定延展性需求，除非部署的計畫性成長清楚地說明在業務需求中。在解決方案生命週期的部署設計階段期間，部署架構應該有增加調整系統規模的容錯比率，即使您未指定延展性的 QoS 需求。
估計成長
評估系統的成長以決定延展性需求包含預測、評估和可能無法滿足的假設。可延展系統之開發需求的三個關鍵，如下所示。
下表列出在決定延展性需求時要考慮的因素。
安全需求
安全性是一個複雜的主題，與部署系統的所有層級相關。開發安全性需求會以識別安全性威脅和開發對抗策略為中心。此安全性分析包括下列步驟：
安全性需求的分析應該要包含組織內各種利益關係人，包括經理、業務分析師和資訊技術專業人員。通常，組織會指定安全性架構師領導安全性措施的設計和實作。
下列章節描述安全性規劃所涵蓋的區域。
安全性規劃的元素
系統的安全性規劃是部署設計的一部份，是成功實作不可或缺的要素。規劃安全性時，請考慮下列項目：
- 實體安全性。 實體安全性是對路由器、伺服器、伺服器機房、資料中心和基礎架構其他部分的實體存取。如果未經授權的人可以進入伺服器機房和拔除路由器，則其他的安全性措施就會遭到危害。
- 網路安全性。 網路安全性是透過防火牆、安全存取區域、存取控制清單和連接埠存取，存取您的網路。為求網路安全性，您開發未經授權存取、篡改和拒絕 (DoS) 服務攻擊的策略。
- 應用程式和應用程式資料安全性。 應用程式和應用程式資料安全性包含透過認證及授權程序和策略，對使用者帳戶、公司資料和企業應用程式的存取 此區域包括定義下列策略：
- 個人安全性措施。 整個組織的安全性策略定義作業環境以及所有使用者必須遵守的措施，藉以確定安全性措施將如同設計運作。通常，您會開發關於安全性指南或手冊，並為使用者提供安全性措施的訓練。為了取得有效的整體安全性策略，良好的安全性措施必須成為組織文化的一部份。
潛在容量
潛在容量是部署處理不尋常尖峰負載使用而無須額外資源的能力。一般而言，您不會直接根據潛在容量指定 QoS 需求，但是這項系統品質是決定可用性、效能和延展性需求的因素。
可服務性需求
可服務性是維護已部署系統的輕易程度，包括監視系統、修復產生的問題、從系統新增和移除使用者以及升級硬體和軟體元件的作業。
當規劃可服務性需求時，請考慮下表列出的主題。
服務層級需求服務層級合約 (SLA) 指定最低的效能需求以及依據達成那些需求造成的失敗指定必須提供的客戶支援的層級和範圍。服務層級需求是系統需求，會指定以 SLA 為基礎的情況。
如同 QoS 需求，服務層級需求來自業務需求，並代表關於部署系統必須達到的整體系統品質的擔保。因為服務層級合約被視為合約，所以服務層級需求的規格必須相當明確。服務層級需求精確定義何種狀況下測試需求，以及明確地說明何種組成不滿足需求。