服務品質需求

服務品質需求 (QoS ) 是一些技術規格，它們指定系統功能品質，像是效能、可用性、延展性及服務性。QoS 需求以業務需求中指定的業務需要為導向。例如，如果這些服務必須 24 小時全天候提供，可用性需求就必須解決這項業務需求。

下表列出通常會形成 QoS 需求基礎的系統品質。

表 3–2 系統品質影響 QoS 需求

系統品質	說明
效能	衡量相對於使用者負載條件的回應時間和處理能力。
可用性	一種衡量一般使用者可存取系統資源與服務頻率的指標，常以系統的正常執行時間表示。
延展性	隨時間推移在已部署系統中新增容量及使用者的能力。延展性通常牽涉在系統中新增資源，但不應要求對部署架構做出變更。
安全性	描述系統及其使用者的完整性之複雜因子組合。安全性包括使用者的認證和授權、資料安全性以及部署系統的安全存取。
潛在容量	系統在不新增資源的情況下處理少見的尖峰負載的能力。潛在容量是可用性、效能和延展性品質中的一個因素。
服務性	對已部署系統進行維護的易行度，維護包括系統監視、修復發生的問題及升級硬體與軟體元件等作業。

系統品質彼此息息相關。對某個系統品質的需求可能會影響對其他系統品質的需求與設計。例如，較高層級的安全性可能會影響效能，而效能又會影響可用性。增加額外伺服器來解決可用性問題卻可能影響到服務性 (維護成本)。

瞭解系統品質如何產生關聯以及其利弊，是設計能夠成功滿足業務需求和業務限制的系統最大的關鍵。

以下各節更進一步描述影響部署設計的系統品質，提供公式化 QoS 需求時需考慮因素的指導。關於服務層級需求的章節，其中亦包含形成服務層級合約的基礎。

效能

業務需求通常以指定回應時間的非技術名詞表示效能。例如，以架構存取的業務需求可能強調以下：

使用者在登入時可預期合理的回應時間，通常不會大於四秒。

以業務需求開始，檢查所有使用實例來判定如何在系統層級表達此需求。在某些情況下，您可能想要包含在使用分析期間所判定的使用者負載條件。以特定負載條件下的回應時間或是回應時間加上處理能力來表示每個使用實例的效能需求。您還可以指定可容許的錯誤數量。

這是兩個如何指定用於效能的系統需求範例。

• 當日網頁重新整理的回應不得大於四秒，每隔 15 分鐘進行取樣一次，每百萬次交易要少於 3.4 個錯誤。

• 在定義的尖峰期間內，系統必須每秒允許 25 個安全登入，且任何使用者的回應時間不得大於 12 秒，每百萬次交易要少於 3.4 個錯誤。

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

可用性

可用性是指定部署系統正常執行時間的一種方式，且通常以系統可供使用者存取時間的百分比為測量基準。系統無法存取的時間 (當機時間) 可能歸咎於硬體、軟體、網路錯誤或者任何其他造成系統當機的因素 (例如斷電)。規劃的服務當機時間 (維護和升級) 不列入當機時間計算。以正常執行時間的比率計算系統可用性的基本方程式為：

可用性 = 正常執行時間/(正常執行時間 + 當機時間) * 100%

通常以可達成的「九」的數量來衡量可用性。例如，99% 的可用性為兩個「九」。指定額外的「九」會明顯地影響部署設計。下表量化了為某個系統增加額外的可用性「九」後的非排程當機時間，該系統全年 24x7 方式執行 (合計 8,760 小時)。

表 3–3 系統執行一整年 (8,760 小時) 的未排程當機時間

「九」的數量	可用百分比	未排程的當機時間
2	99%	88 小時
3	99.9%	9 小時
4	99.99%	45 分鐘
5	99.999%	5 分鐘

容錯系統

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

錯誤單點是一個硬體或軟體元件，為重要路徑的一部分，但沒有透過備援元件備份。此元件的錯誤會導致系統服務的損失。在設計容錯系統時，您必須確認並排除潛在的錯誤單點。

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

排定服務可用性優先順序

從使用者觀點來看，比起整體系統的可用性，可用性更常應用在個別的服務上。例如，無法使用即時訊息傳送服務，通常不會對其他服務的可用性造成太大的影響。不過，如果無法使用許多其他服務所依賴的服務 (像是 Directory Server)，對系統的影響就會大得多。較高的可用性規格應該清楚地參照到需要較高可用性的特定使用實例和使用分析。

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

表 3–4 依優先性排列的服務可用性

優先性	服務類型	說明
1	關鍵任務	必須隨時能用的服務。例如，應用程式的資料庫服務 (如 LDAP 目錄)。
2	必須可用	必須能用的服務，但是在降低效能時可以利用。例如，訊息傳送可用性在某些業務環境中可能不是關鍵的。
3	可以延遲	在給定期間內可以使用的服務。例如，行事曆服務可用性在某些業務環境中可能不是必要的。
4	選擇性	可以無限延遲的服務。例如，在某些環境中，即時訊息傳送服務可能被視為有用但不是必要的服務。

服務損失

可用性設計會考慮可用性降低或元件遺失時可能發生的情況。同時也會考慮相關的使用者是否必須重新開始階段作業，以及一個區域的錯誤對系統其他區域所造成的影響程度。需求應該要考慮這些方案，並指定部署如何對這這些解決方案做出回應。

延展性

延展性是增加容量到您系統的能力，如此系統才能支援來自現有使用者或增加的使用者基礎的額外負載。延展性通常需要額外的資源，但是不應該需要變更部署架構的設計，或是因為需要加入額外資源的時間而損失服務。

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

不需要以 QoS 需求來指定延展性需求，除非業務需求中清楚地說明了部署的預期成長。在解決方案生命週期的部署設計階段期間，部署架構應該有增加調整系統規模的容錯比率，即使您未指定延展性的 QoS 需求。

估計成長

評估系統的成長以判定延展性需求包含預測、評估和可能無法滿足的假設。可延展系統之開發需求的三個關鍵，如下所示。

• 高效能設計策略。在指定效能需求期間，請納入潛在容量以處理日後可能增加的負載。同時，在預算限制內將可用性最大化。這項策略可讓您吸收成長並提高調整系統規模的排程基準點。

• 增量部署。增量部署可協助排程資源的增加。指定調整系統的清楚基準點。基準點通常是會與特定日期相互協調以評估延展性的負載型需求。

• 大規模效能監視。監視效能可協助判定何時需要為系統增加資源。監視效能需求可為負責維護及升級的作業人員和管理員提供指導。

下表列出在判定延展性需求時要考慮的因素。

表 3–5 延展性因素

主題	說明
分析使用模式	透過研究現有資料，瞭解目前或是預期使用者基礎的使用模式。缺少目前的資料時，分析工業資料或市場估計。
合理的最大規模設計	為已知和可能的需要設計朝向最大需求規模的目標。  這常是基於對現有使用者負載和合理預期的未來負載的 24 個月估計。估計的時期絕大部分依賴設計的可信度。
設定適當的基準點	遞增式實作部署設計來符合短期需求，並使用緩衝以允許預期外的成長。設定增加系統資源的基準點。  例如：  取得資金 (例如季度或年度) 購買硬體和軟體的前置時間 (例如一到六個星期) 緩衝 (10% 到 100%，根據成長預期)
吸收新興技術	瞭解新興技術，例如較快的處理器和伺服器，以及這項技術會如何影響基礎架構的效能。

安全需求

安全性是一個複雜的主題，與部署系統的所有層級相關。開發安全性需求會以識別安全性威脅和開發對抗策略為中心。此安全性分析包括下列步驟：

1. 識別重要資產

2. 識別那些資產的威脅

3. 識別會造成這些威脅的漏洞，這些威脅會對組織形成風險。

4. 開發可減輕組織風險的安全性規劃

安全性需求的分析應該要包含組織內各種利益關係人，包括經理、業務分析師和資訊技術專業人員。通常，組織會指定安全性架構師領導安全性措施的設計和實作。

下列章節描述安全性規劃所涵蓋的區域。

安全性規劃的元素

系統的安全性規劃是部署設計的一部份，是成功實作不可或缺的要素。規劃安全性時，請考慮下列項目：

• 實體安全性。實體安全性是指對路由器、伺服器、伺服器機房、資料中心和基礎架構其他部份的實體存取。如果未經授權的人可以進入伺服器機房和拔除路由器，則其他的安全性措施就會遭到危害。

• 網路安全性。網路安全性是指透過防火牆、安全存取區域、存取控制清單和連接埠存取來存取網路。為求網路安全性，需要開發針對未經授權存取、篡改和拒絕服務 (DoS) 攻擊的策略。

• 應用程式和應用程式資料安全性。應用程式和應用程式資料安全性涵蓋透過認證及授權程序與策略對使用者帳戶、公司資料和企業應用程式的存取。此區域包括定義下列策略：

  • 密碼策略

  • 存取權限，例如相對於管理員存取的使用者委託管理

  • 帳戶關閉

  • 存取控制

  • 加密策略，包含資料的安全傳輸以及使用認證簽定資料

• 個人安全性措施。整體組織的安全性策略定義作業環境以及所有使用者都須遵守的措施，以確定其他安全性措施將如同所設計般運作。通常，您會開發關於安全性指南或手冊，並為使用者提供安全性措施的訓練。為了取得有效的整體安全性策略，良好的安全性措施必須成為組織文化的一部份。

潛在容量

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

可服務性需求

可服務性是維護已部署系統的輕易程度，包括監視系統、修復產生的問題、從系統新增和移除使用者以及升級硬體和軟體元件的作業。

當規劃可服務性需求時，請考慮下表列出的主題。

表 3–6 可服務性需求的主題

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