第 3 章技術需求

技術需求分析以商業分析階段期間所建立的商業需求文件開始著手進行。使用商業需求為基礎，執行以下步驟：

使用實例也是在設計階段中設計邏輯架構 的基礎。邏輯架構與系統需求一起形成稍後成為部署設計階段輸入資料的部署方案。

下圖顯示與商業分析、邏輯設計和部署設計階段相關的技術需求階段。

在商業分析中，對於技術需求分析而言，並不存在產生使用分析、使用實例與系統需求的神奇公式。技術需求分析需要瞭解商業領域、商業目標以及系統科技的構成。

使用分析

使用分析包含確認您設計的部署的各種使用者以及決定使用者的使用模式。您收集的資訊提供預期負載情況的概念並且稍後用於決定效能需求以及其他系統需求。使用分析資訊在分配使用實例的權重時也非常的有用，如使用實例中所述。

在使用分析期間您應該盡可能地約談使用者，研究使用模式現存的資料，也應該約談設計者和之前系統的管理員。下表列出執行使用分析時應該考慮到的主題。

表 3-1 使用分析主題
主題	描述
使用者的數量與類型	決定您的部署必須支援多少使用者，並在需要時分類使用者。例如：「企業到消費者」部署可能有大量的訪問者，不過只有少數的使用者會登記並從事商務交易。「企業到員工」部署通常必須要能容納每一個員工，不過有些可能需要從公司網路外部存取。在「企業到員工」部署中，負責人可能需要得到一般員工不能存取的特定區域授權。
作用中和非作用中的使用者	確認使用模式以及作用中和非作用中使用者的比例。作用中的使用者指的是登入系統並且與系統元件互動的使用者。非作用中的使用者則可能是未登入系統的使用者或者是登入系統沒有與系統元件互動的使用者。
管理使用者	確認能進入部署系統監控、更新以及支援部署的使用者。決定任何可能會影響到系統需求的特定管理使用模式。例如：來自防火牆外部的部署管理。
使用模式	確認不同類型的使用者如何存取系統並提供目標給預期的使用。例如：使用錯誤時是否有尖峰時段？正常上班時間為何？使用者是否分散全球？使用者連線的預期持續期間為何？
使用者成長	確定使用者基礎規模是否固定或者部署是否預期使用者數量的成長。如果預期使用者基礎將會成長，試著針對此一成長做出合理的規劃。
使用者交易	確認必須支援的使用者交易類型。這些使用者交易可以轉化成使用實例。例如：使用者會執行什麼工作？使用者何時登入，他們會維持登入狀態嗎？或者他們只是執行一些工作後就登出？使用者之間是否需要一般的行事曆、網路會議及網際網路網頁的部署等值得注意的協作？
使用者研究及統計資料	利用既有的使用者研究及其他來源來決定使用者的行為模式。通常企業或工業組織擁有使用者的研究資料，從這裡您可以取得關於使用者的有用資訊。現存應用的登入檔案可能包含可用於評估系統的有用統計資料。

使用實例

使用實例以您設計的部署塑造出典型的使用者互動，從一般使用者的角度描繪出作業的完整流程。圍繞完整使用實例的優先設計確保持續集中焦點在預期功能的傳送上。

每個使用實例可包括關於使用者行為模式的數量估計，稍後您可以用來決定效能、可用性和其他服務品質的系統需求。使用實例也是設計邏輯架構的起始點，如第 4 章，「設計邏輯架構」中所述。

您經常指定相對的權重給使用實例，權重最高的使用實例代表最常見的使用者工作。使用實例的權重可幫助決定系統需求。

系統需求

系統需求敘述部署系統必須提供符合商業需求的服務品質，透過商業分析達成。您通常連同商業需求使用使用分析和使用實例以獲得系統需求。

表 3-2 系統品質影響部署設計
系統品質	描述
可用性	對於一般使用者取得系統資源和服務的頻繁度測量，通常表現在系統的正常執行時間。
潛在容量	系統處理不尋常尖峰負載使用而無須額外資源的能力。
效能	回應時間以及與使用者負載狀況有關的潛在因素評量。
延展性	日後增加容量 (以及使用者) 到部署的系統上的能力。延展性通常包含增加資源到系統中，但不需要變更部署架構。
安全性	說明系統和其使用者健全性的因素複雜組合。安全性包括認證和授權使用者以及資訊的安全傳輸。
可服務性	部署系統可管理的舒適度，包括監控系統、修復產生的問題以及升級硬體和軟體元件的工作。

影響部署設計的系統品質互相之間息息相關。系統品質的需求可能會影響其他系統品質的需求和設計。例如，高階的安全性可能會影響效能，接著就影響可用性。增加額外的伺服器來應付可用性問題可能會影響維護成本 (可服務性)。

瞭解系統品質如何產生關聯以及必須建立的交易，是設計能夠成功滿足商業需求和商業限制的系統最大的關鍵。

下節更進一步觀察影響部署設計的系統品質，提供公式化系統需求時的因素指導。也有關於服務層級需求的章節，其為一組特別用來建立服務層級需求的系統需求。

可用性

可用性是指定部署系統正常執行時間 的一種方式。通常被測量為使用者存取系統的時間的百分比。系統無法存取的時間 (當機時間 ) 可能歸咎於硬體、軟體、網路錯誤或者任何其他造成系統當機的因素 (例如斷電)。大部分的狀況下，服務 (維護和升級) 的排程時間不考慮當機時間。

通常您會用可以達成的「九」的數量來評量可用性。例如，99% 的可用性為兩個「九」。指定額外的「九」會明顯地影響可用性的部署設計。下表顯示增加可用性額外的「九」到系統的結果，系統為一整年 24x7 小時執行，合計為 8,760 小時。

表 3-3 系統執行一整年 (8,760 小時) 的當機時間
九	可用百分比	當機時間
二	99%	88 小時
三	99.9%	9 小時
四	99.99%	45 分鐘
五	99.999%	5 分鐘

容錯系統

四或五個「九」的可用性需求通常需要容錯系統。容錯系統必須能夠在硬體或軟體錯誤期間繼續服務。通常，容錯是透過硬體 (例如 CPU、記憶體和網路裝置) 和軟體兩者的冗餘提供關鍵服務。

錯誤單點 是一個沒有透過冗餘元件備份的硬體或軟體元件。此元件的錯誤會導致系統服務的損失。在設計容錯系統時，您必須確認潛在錯誤單點並且進行排除。

容錯系統的實施和維護可能很昂貴。確定您瞭解用於可用性的商業需求特性，並考慮符合這些需求的可用性解決方案的策略和成本。

Sun Cluster 3.1 4/04

Sun Cluster 3.1 4/04 軟體為需要高可用性、容錯系統的部署提供了一個高可用性的解決方案。Sun Cluster 3.1 4/04 結合伺服器、儲存裝置和其他網路資源來提供故障轉移過程，完成快速並且只對系統的使用者造成極小的服務中斷。

服務的優先可用性

從使用者觀點來看，比起整體系統的可用性，可用性更常應用在部署系統提供的每個服務上。例如，如果即時訊息服務變成無法使用，對其他服務的可用性影響通常很小或根本沒有影響。然而，在其他許多服務所依賴的服務可用性之上 (例如 Directory Server) 則對系統有較大的影響。

根據優先性的順序組合列出可用性需求會很有幫助。下表排出服務的不同類型的可用性順序。

表 3-4 服務的優先可用性
優先性	服務類型	描述
1	策略	作業所需的服務。例如，許多服務依賴 Directory Server。
2	關鍵任務	尖峰負載時必須能用的服務。例如，對應用程式的資料庫服務定義為關鍵任務。
3	必須可用	必須能用的服務，但是在降低效能時可以利用。例如，Messaging Server 可用性在某些商業環境中可能不是關鍵。
4	可以延遲	在給定期間內可以使用的服務。例如，Instant Messaging 可用性在某些商業環境中可能不是必要。
5	選擇性	可以無限延遲的服務。

如需關於實施可用性需求的各種設計策略資訊，請參閱調整可用性大小。

潛在容量

潛在容量是部署處理不尋常尖峰負載使用而無須額外資源的能力。一般而言，您不會直接圍繞著潛在容量來指定系統需求，但是這項系統品質是決定可用性、效能和延展性需求的因素。

效能

決定效能需求是轉換效能上的商業需求預期為系統需求的過程。商業需求通常以指定回應時間的非技術名詞表示效能。例如，以 Web 架構存取的商業需求可能強調以下：

以商業需求開始，檢查所有使用實例來決定如何在系統層級表達此需求。考慮使用者負載條件，如同使用分析期間的決定。表示在特定負載條件下的回應時間 或是回應時間加上處理能力 方面每個使用實例的效能需求。您可能也指定允許的錯誤數量。

效能需求與可用性需求 (故障轉移如何影響效能) 以及潛在容量 (處理不尋常尖峰負載的容量有多少) 息息相關。

延展性

延展性描述日後增加容量以及使用者到系統上的能力。延展性通常需要額外的資源，但是不應該需要變更部署架構的設計，或是因為需要加入額外資源的時間而損失服務。

如同可用性，延展性更多應用在系統提供的個別服務上而不是整個系統。然而，在其他許多服務所依賴的服務之上 (例如 Directory Server)，延展性可能會有全系統的影響。

您不需要以系統需求來指定延展性需求，除非部署的計畫性成長清楚地說明在商業需求中。在部署設計階段期間，部署架構應該考慮調整系統比例，即使您未指定延展性需求。

決定延展性需求不是一項精密科學。評估系統的成長包含設計、評估和可能無法滿足的假設。這裡有建立延展性系統的三個關鍵。

表 3-5 延展性考慮
主題	描述
使用分析	透過研究現有資料，瞭解目前 (或是計畫) 使用者基礎的使用模式。缺少目前的資料時，分析工業資料或市場估計。
合理的最大規模設計	為已知和可能的需要設計朝向最大需求規模的目標。通常，根據現有使用者負載和未來負載的合理預期，這會是一個 24 個月的評估。估計的時期絕大部分依賴設計的可信度。
設定適當的里程碑	遞增式實施部署設計來符合短期需求，並使用緩衝以允許預期外的成長。設定增加系統資源的里程碑。例如：資金取得例如季度或年度硬體前置時間例如，一到六週緩衝 (10% 到 100%，根據成長預期)
吸收新興技術	瞭解新興技術，例如較快的 CPU 和 Web 伺服器，以及會如何影響基礎架構的效能。

安全需求

安全性是影響系統和使用者健全性的系統品質，包括使用者交易和相關資料的健全性。如同其他系統需求，商業需求、使用分析和使用實例驅動安全需求的分析。

認證、授權和識別管理，連同屬於健全安全性實施的企業範圍策略，提供交易安全的信心並且儲存在網站上的資料不會被危及。

認證

認證是使用者如何向系統確認自己，同時系統向使用者確認自己的方式。認證是系統健全的關鍵部分，保護系統免於未認證的存取。

您應該瞭解使用者需求來選擇屬於部署的最佳認證方案。例如，「企業到客戶」部署可能允許使用者使用使用者名稱/密碼組合來註冊。這些使用者依賴可靠的認證機構發出的伺服器憑證，例如 VeriSign，驗證銷售系統經由安全傳輸。

「企業到員工」部署反而可能從現有的使用者基礎提供給員工。若來自公司防火牆內部，則允許存取到已知的安全位置。若來自公司防火牆外部，存取安全位置是經由執行認證的代理伺服器，並重新導入公司防火牆內部。

授權

授權是給認證使用者的特定權限識別。例如，具有管理員授權的使用者有部署系統的部份存取權，一般使用者則無法存取。

授權在部署實施單次登入 (SSO) 時也扮演重要的角色。部署認證的使用者具有多重服務的存取權，而不需要重複登入。

識別管理


注意	影響架構 (例如防火牆軟體和網路設計) 健全的安全需求通常不會在系統需求分析期間考慮。反之，這些安全性問題在部署設計期間開始作用。

部署系統必須有一套方法新增、修改或刪除存取系統服務的使用者。根據您的需要，識別管理可以透過授權的管理員完成，或是藉由授權管理介面的工具讓使用者自己達成。中型或大型企業的部署應該考慮授權管理設計。授權管理可增加顧客的滿意度並減少系統管理的成本。

可服務性需求

可服務性是部署系統可管理的舒適度，包括監控系統、修復產生的問題以及升級硬體和軟體元件的工作。

表 3-6 可服務性需求的主題
主題	描述
當機時間規劃	確認需要特定服務無法使用或是部分無法使用的維護工作。在其他需要中斷對使用者的服務時，有些維護和升級可以不間斷地進行。如果有可能，請將維護活動時需要當機時間的使用者納入排程，讓使用者規劃當機時間。
使用模式	確認部署的使用模式來決定維護機會時的視窗。例如，在尖峰使用通常為一般企業時間的系統上，機會的視窗出現在晚上或週末。對於地理分散的系統來說，確認這些時間會更具挑戰性。
可用性	可服務性經常是您可用性設計的反映。維護和升級的最小化當機時間策略以您的可用性策略為中心。需要高度可用性的系統具有較小的維護、升級和修復的視窗。處理可用性需求的策略影響您處理維護和升級的方式。例如，在地理上分散的系統，服務在維護期間可以依靠傳送工作量到遠端伺服器的能力。同時，需要高度可用性的系統可能需要更多成熟的解決方案，使用少量人力介入的系統就可以自動重新啟動。
診斷與監控	透過定期執行診斷和監控工具來確認問題區域，您可以改善系統的穩定性。這樣可以在發生前避免問題，根據可用性策略幫助平衡工作量並為維護和當機時間改善規劃。

服務層級需求

服務層級需求 是一組系統需求，指定在必須提供的客戶支援下的條件。服務層級需求是服務層級協定的基礎，通常在專案核准時簽訂。

如同系統需求，服務層級需求來自商業需求，並代表一種關於部署必須達到的整體系統品質的客戶擔保。因為服務層級協定是您和客戶之間的約束，服務層級需求的規格不能模稜兩可。服務層級需求精確定義何種狀況下測試需求，以及明確地說明何種組成不滿足需求。

上一頁目錄下一頁
Sun Java Enterprise System 部署規劃白皮書