服務設計之容量管理

1、容量管理容量管理貫穿于服務生命周期的始終。容量管理的關鍵成功因素就是在服務設計階段已經考慮到它，因此，容量管理的內容包含在本書籍中。容量管理首先在服務戰(zhàn)略階段得到支持，在服務戰(zhàn)略階段，決策和業(yè)務要求與客戶結果的分析影響著業(yè)務活動模型（PBA的開發(fā)、服務的水平（LOS）和服務水平包（SLPs）。這提供了需要調整容量以滿足需求的預測性的指標。意圖、目的與目標“容量管理的目的就是保證在IT的所有領域有成本合理的IT容量，并且及時地滿足現在及將來的業(yè)務需求?！比萘抗芾淼囊鈭D就是對所有的容量及服務和資源相關的性能問題進行關注和管理。容量管理的目標是：生成和維護一個合適的和最新的容量計劃，反映當前和將來的

2、業(yè)務需要在業(yè)務和IT的其他領域提供容量和性能相關問題的建議和指導通過管理服務和資源的容量及性能，保證服務性能滿足或超過所有既定的性能指標為性能和容量相關的故障及問題的診斷和解決提供幫助評估容量計劃的所有變更所帶來的影響，評估所有服務和資源的性能和容量保證提高服務性能的主動措施在成本合理的情況下得到實施范圍容量管理應該關注所有的IT性能和容量問題。技術管理職能如網絡支持、服務器支持、運營管理等實施大部分的日常管理任務，可以為容量管理提供性能信息。容量管理應該包含包括硬件和軟件在內的所有技術領域，適合于所有的技術組件和環(huán)境。容量管理也要考慮空間規(guī)劃、環(huán)境系統容量和人力資源的某些方面。但是只有人力資

3、源的缺失能導致SLA或OLA目標的違背、端到端性能的延遲、滿足將來任務和計劃的無能（例如，因為操作人員的缺失以致不能裝載磁帶，從而導致夜間數據備份不能及時完成）。通常情況下，容量管理是一種線性管理責任，雖然服務臺員工使用同樣的容量管理技術。人力資源安排、員工水平、技能水平、能力水平都應該被包含在容量管理的范圍中。容量管理的驅動力應該是組織的業(yè)務要求和規(guī)劃能夠提供與SLAs（OLA一致的服務水平所需要的資源。容量管理需要了解整體的IT和業(yè)務環(huán)境，包括：通過業(yè)務活動模型（PBA來了解當前的業(yè)務運營和要求通過服務組合來了解將來的業(yè)務規(guī)劃和要求通過SLAs和標準運營流程來了解服務目標和當前的IT服務運

4、營狀況IT技術、容量、性能的所有方面，包括基礎設施、數據、環(huán)境、應用程序等了解所有這些可以使容量管理能夠保證服務的當前和將來的容量和性能的所有方面可以成本合理有效地提供。容量管理也需要了解新服務傳遞的可能。需要了解新技術，如果合適的話，應客戶的要求改革和傳遞這些服務。容量管理需要重新確認技術變更的比率可能增加并且新技術可以被安全使用以保證IT服務在改變業(yè)務期望時仍然讓用戶滿意。需要在服務戰(zhàn)略和服務組合間建立一種直接的聯系以保證在將來的服務規(guī)劃中把新興的技術考慮進來。容量管理應該包括：通過性能、效用、IT服務的生產能力、基礎設施、環(huán)境、數據、應用程序組件、正常產出、服務報告、組件容量和性能等監(jiān)控

5、業(yè)務活動模型和服務水平計劃進行調優(yōu)以便現有的IT資源達到最有效的使用了解用戶對IT資源所達成的當前和將來的需求和將來的生產預期可能與財務管理一起影響需求管理生成一個容量計劃可以使服務提供商提供符合SLAs所規(guī)定質量的服務并且能夠有足夠的時間安排來滿足將來服務組合和SLRs所規(guī)定的服務水平為服務或組件相關的任何故障和問題的確認和解決提供輔助作用在成本合理和滿足業(yè)務需求的情況下對服務或組件的性能進行主動性地改進管理巨大的分布式IT基礎設施的容量是一件復雜的和高要求的任務，尤其是IT容量和財務投資一直增加的情況下。所以對增長進行規(guī)劃顯得更有意義。因為在分布式環(huán)境下單一組件的更新成本通常情況下會少于在

6、集成式主機環(huán)境下的組件更新成本，所以經常有許多的組件需要更新。當需要購買很多組件時，單個組件的成本由于規(guī)模效應而減少。容量管理可以用于服務組合和采購過程以保證在與供應商談判中達成最好的交易。容量管理提供單個組件當前的和計劃的資源效用的必要信息可以是組織有把握地做出決定：哪個組件需要更新（如：更大內存、更快的存儲設備、更快的處理器、更多的帶寬）什么時候進行更新-理想狀態(tài)下不能過早，否則導致超出容量的過多支出；也不能太晚，否則導致不能有效利用新技術、瓶頸、不連續(xù)性能、最終地，客戶不滿意和失去生意機會更新的成本是多少-在預算的生命周期中把容量管理的預期因素和計劃因素考慮進來以保證計劃性投資。如果沒有

7、容量管理的信息輸入，許多其他管理過程的效率會大大降低。例如：變更管理在可用性的容量方面能夠評估任何變更的效果嗎實施新服務時，服務級別管理能保證新服務的SLRs達到了嗎現存服務的SLAs將不會受到影響問題管理能夠診斷由低劣性能所導致的故障的潛在原因嗎IT服務持續(xù)性管理能夠準確確定關鍵業(yè)務流程的容量需求嗎容量管理是一個前瞻性的過程，當進行實施時，可以在業(yè)務事件和影響發(fā)生前預測到它們。好的容量管理保證服務和組件的設計與性能不會出現驚險的情況。在組織中，容量管理和服務戰(zhàn)略與規(guī)劃流程有密切的雙向的聯系?；痉矫嫔?，組織的長期戰(zhàn)略包含在業(yè)務規(guī)劃的更新中。服務戰(zhàn)略反映業(yè)務規(guī)劃，業(yè)務規(guī)劃來自于組織對外部因素如

8、競爭性的市場環(huán)境、經濟前景、法律法規(guī)和內部的人力、供應能力等容量的理解。通常會開發(fā)一個短期的戰(zhàn)術計劃或業(yè)務變更來實現短期或中期的必要的變更從而可以進行全局的業(yè)務規(guī)劃和服務戰(zhàn)略。容量管理也需要了解短期、中期和長期的業(yè)務規(guī)劃以便提供最新的理念、趨勢及硬件軟件供應商所開發(fā)技術的信息。組織業(yè)務規(guī)劃驅動特殊的IT服務戰(zhàn)略，容量管理需要熟悉服務戰(zhàn)略的內容，并為服務戰(zhàn)略輸入重大的和不斷的信息。合適的時間合適的容量，這是很關鍵的。服務戰(zhàn)略可以為容量管理在識別新技術、硬件、軟件的獲得和實施的時間方面提供幫助。業(yè)務價值容量管理負責保證IT資源按計劃的方式來提供連續(xù)的服務水平，其能夠與當前和將來的業(yè)務需求相符合，這

9、些需求在SLAs和OLAs中被一致同意和文檔化了。容量管理結合業(yè)務規(guī)劃，提供了容量規(guī)劃來指導支撐業(yè)務規(guī)劃所需的的IT資源和資金以及支出費用的成本調整。策略、原則與基本概念容量管理保證IT服務和系統的容量和性能以最節(jié)約成本和時間的方式符合業(yè)務的既定需求。容量管理本質上是一種平衡：成本和所需資源的平衡：保證依據業(yè)務需要所購買的容量是成本合理的，并對這些資源進行最有效的使用。供求平衡：保證IT處理能力的有用性供應與當前和將來的業(yè)務需求相符合。為一種特定的資源管理或改變需求也是必要的。容量管理過程和規(guī)劃必須融合于服務生命周期的所有階段，從服務戰(zhàn)略、服務設計、服務轉換、服務運營到服務改進。從戰(zhàn)略的角度來

10、看，服務組合包含所有的IT資源和功能。服務導向架構的出現、虛擬化、IT服務條款(provision)中的價值網絡使用在容量管理中都是關鍵的因素。在初始的設計階段就應該把恰當的容量和性能帶到服務和組件中來。這樣不僅可以保證新的或變更的服務的性能符合期望的目標，還可以保證所有現存的服務能夠繼續(xù)符合它們的所有目標。這是穩(wěn)定服務條款的根本。整體的容量管理過程以持續(xù)地成本合理地方式使IT資源和能力符合不斷變更的業(yè)務需求。這就需要對當前的資源進行調優(yōu)和優(yōu)化并對將來的資源規(guī)劃進行有效的估計，如圖例所示。容量管理是一種極其技術、負責、高要求的過程，為了達成必要的結果，它需要三個3個支撐的小過程。容量管理的關鍵

11、活動之一就是生成一個規(guī)劃，把資源利用和服務性能的當前水平進行文檔化，并在慎重考慮服務戰(zhàn)略和規(guī)劃后，預測將來能夠支撐業(yè)務活動的IT服務所需要的資源需求。這個計劃應該清楚地顯示任何所做出的假定。它還要包含任何量化的資源、成本、收益、影響等方面的建議。需要在預定的時間段內生成和維護容量規(guī)劃。它本質上是一個投資規(guī)劃，所以需要每年公布一次，并且與業(yè)務或預算生命周期一致，還要在將來預算的協商前完成。在服務規(guī)劃中，考慮到變化的情況，每季度更新一次規(guī)劃是必需的，可以增加預測的準確度，還可以提出或提煉出一些建議。這需要額外的活動，但是如果它被定期地更新，容量規(guī)劃會變得更加準確并能反映變化的業(yè)務需求。容量規(guī)劃的內

12、容參見附錄J。業(yè)務容量管理業(yè)務容量管理把業(yè)務需求和規(guī)劃轉變?yōu)閷Ψ蘸虸T基礎設施的需求，保證IT服務將來的業(yè)務需求得到及時地量化、設計、規(guī)劃和實施。這可以通過對各種服務所使用的當前資源利用情況的現存數據來預報、建模或者預測將來的需求來完成。這些將來的需求來自于服務戰(zhàn)略和服務組合，如新流程和服務需求、變更、改進和現存服務的增長。服務容量管理服務容量管理關注于端到端性能、現實狀況的IT服務使用和工作負載的容量的管理、控制和預測。它可以保證服務目標中符合SLAs和SLRs的所有服務的性能得到監(jiān)控和測量，并可以記錄、分析和報告所收集的數據。如有必要，可以實行主動的措施來保證所有服務的性能符合既定的業(yè)務

13、目標。這通常是由具有使用端到端服務傳遞技術的所有領域的知識的員工來執(zhí)行的，還經常需要向組件容量管理的專家尋求建議。如果可能，應該把自動化的閾值控制技術應用于運營服務，來保證服務目標被違背或威脅時能夠及時地得到識別，并使減少或避免潛在影響的成本合理的措施得到實現。組件容量管理組件容量管理關注于對單個IT技術組件的性能、使用和容量進行管理、控制和預測。這保證擁有限定的資源的IT基礎設施內的所有組件得到監(jiān)控和測量，并可以記錄、分析和報告所收集的數據。同樣地，如果可能，可以使用自動化的閾值控制技術應用于所有組件，來保證組件使用或性能的服務目標被違背或威脅時能夠及時地得到識別，并使減少或避免潛在影響的成

14、本合理的措施得到實現。這三個子管理過程有許多相似的活動，但是每一個有其不同的關注點。業(yè)務容量管理關注于當前和將來的業(yè)務需求，服務容量管理關注于支撐業(yè)務的現存服務的傳遞，而組件容量管理關注于支持IT條款的IT基礎措施。每個子管理過程在容量管理中所扮演的角色如圖例所示。容量管理所使用的工具應該符合組織管理架構并且與IT系統和自動化處理的其他管理工具進行集成。服務運營中的監(jiān)控和控制活動將會為容量管理的支持和分析工具提供良好的基礎?；顒印⒎椒ㄅc技術容量管理的一些活動是被動的，還有一些是主動的，這些主動的活動包括：在性能問題發(fā)生前采取必要的措施解決它生成當前組件使用情況的趨勢分析，估計將來的需求，為計劃

15、的更新和增強使用趨勢分析和閾值控制技術建模和趨勢分析IT服務中的潛在變化，識別IT基礎設施和應用中的服務和組件需要作出的改動，從而保證適當的資源處于可用狀態(tài)。在違背As和服務目標或性能問題出現之前，保證所有的變更被預算、計劃和實施在成本合理的情況下主動尋找改進服務性能的機會調優(yōu)和優(yōu)化服務和組件的性能被動的活動包括：監(jiān)控、測量、報告、回顧服務和組件的當前性能響應所有容量相關的閾值事件并采取正確的行動對特殊的性能問題做出反應和協助。服務臺可能把低劣性能故障歸結于技術原因，這就需要使用容量管理技術來解決它們。關鍵信息：容量管理的主動活動越成功，需要的被動活動越少。業(yè)務容量管理業(yè)務容量管理的主要目標是

16、保證IT服務的將來業(yè)務需求（客戶結果）能夠被考慮和理解，同時保證在合理的時間跨度內支撐新服務或變更的服務的充足IT容量被規(guī)劃和實施。圖例顯示了業(yè)務活動模型是如何影響業(yè)務容量管理的和服務是如何使用的。容量管理必須隨容量需求的改變而改變。新服務或者變更的服務被要求來支撐變更的業(yè)務?，F存的服務需要修改以提供額外的功能。陳舊的服務被淘汰，從而釋放出一些空閑容量。結果是使?jié)M足客戶SLRs和SLAs的能力也會受到影響。容量管理的責任就是預測變更所需要的容量和管理需求。新需求可能從許多不同的來源（sources）和由于許多不同的原因引起容量管理的注意，但是供應需求的最主要的來源應該來自需求管理的業(yè)務活動模型

17、和為服務組合所生成的服務級別包。例如升級以便利用新技術的建議，或解決性能問題的一個調優(yōu)活動的實施。圖例顯示了需求管理的循環(huán)過程。在所有的戰(zhàn)略、規(guī)劃和設計活動中盡可能早的把容量管理包含進來，例如：協助和支持服務戰(zhàn)略的開發(fā)參與IT戰(zhàn)略和政策的回顧與改進參與技術架構的回顧與改進關鍵信息：容量管理應該優(yōu)先被客戶接納，而不是最后的選擇。如果在這些過程中容量管理能早些參與進來，IT容量的規(guī)劃和設計就會與業(yè)務需求緊密地結合，并能保證完成和維護服務目標。協助同意服務級別要求容量管理應該協助服務級別管理（SLM依據服務/系統響應時間、期望生產能力、使用模式和用戶數量來理解客戶容量和性能的需求。容量管理應該提供一

18、定情境下的可能解決方案以便在談判過程中有所幫助。例如，如果用戶數量少于2000,則可以保證響應時間低于2秒；如果多于2000用戶的連接數，則應啟用額外的網絡帶寬來保證所要求的響應時間。或者保證降低響應時間是可以被接受的。建模、趨勢分析或者應用定型技術經常被用于此來保證預測能夠準確地反映現實狀況。設計、獲得或修改服務配置容量管理應該參與到新服務或變更服務的設計中來，并且為硬件和軟件的采購提供建議，這種情況下，性能和（或）容量是重要的因素。在一些例子中容量管理其作為變更咨詢委員會的一員是通過變更管理來達到新需求的實施的。為了平衡成本與能力，容量管理獲得可供選擇的解決方案的成本并建議最合適的成本合理

19、的建議。核實服務等級協議（SLA）服務等級協議應該包括期待服務能力和性能要求的詳細情況。容量管理建議服務級別管理（SLM監(jiān)控可達成的目標和服務設計基于其上。容量管理應該充滿信心，即服務設計符合SLRs,并且可以提供通過建模、趨勢分析和定型技術獲得未來增長的能力。支持服務等級協議談判使用預測技術的結果可以驗證服務性能。這可能需要服務等級管理給予這些結果重新談判服務級別協議。容量管理通過建議潛在的解決方案和相關的成本信息為SLM提供支持，重新談判則顯得是必要的。一旦要求可以達到，服務級別管理的職責就是同意服務級別并簽署服務級別協議。控制和實施所有對服務和資源的容量的變更必須遵循所有的IT流程，如變

20、更、發(fā)布、配置和項目管理流程以保證對所有變更的控制和協調是適當的，以及保證任何新的或改變的組件在他們的生命周期中被記錄和跟蹤。服務容量管理服務容量管理的主要目標是識別和理解IT服務、資源的使用、工作模式、高峰與低谷，并保證服務達到SLA目標，例如保證IT服務表現得如所期望的那樣。服務容量管理主要關注于管理包含在既定SLAs或SLRs中的目標所決定的服務性能。服務容量管理保證服務符合既定的服務目標?？梢詫Ρ槐O(jiān)控的服務所提供的數據進行趨勢分析，從而在趨勢中建立正常的服務等級。通過對這些等級進行定期監(jiān)控和對比，可以定義、識別和報告異常情況。這樣，容量管理可以顯示任何服務的服務級別管理的違背或喪失。存

21、在這樣的情況，即涉及容量管理的故障和問題來自于其他流程，或者識別到某項服務可能不能符合SLA目標。在某些情況中，潛在失敗的原因并不能由組件容量管理決定。例如，分析失敗的原因，可能會發(fā)現是因為容量不夠或者沒有單個組件是超額利用的。然而，即使程序的設計或編碼是效率低的，仍需要管理服務性能，也需要管理單個硬件或軟件資源。服務容量管理應該監(jiān)控服務負載和事務處理情況來保證它們仍處于既定的限制和閾值下。成功的服務容量管理的關鍵是預測問題，如果可能，可以通過監(jiān)控性能上的變更和監(jiān)控變更所帶來的影響。這樣，其實它是另一個子流程，是主動的、預測性的，甚至是優(yōu)先的，而不是被動的流程。然而，它需要對特殊的性能問題做出

22、被動地反應，這種情況已經存在多次了。對正在使用的每個服務的性能要求的知識和理解、對應用服務變更的效果的評估、所采取的措施，這些來保證達到所需服務性能的要求。組件容量管理組件容量管理的主要目標是識別和理解性能、容量及支撐IT服務的技術的單個組件的使用，包括基礎架構、環(huán)境、數據和應用程序。這可以保證當前硬件和軟件資源得到最佳使用從而達到和維持既定的服務等級。IT基礎架構下的所有的硬件組件和許多的軟件組件都有限定的容量，達到或超過這一容量，可能引發(fā)性能問題。組件容量管理關注于處理器、內存、磁盤、網絡帶寬、網絡連接等組件。所以需要持續(xù)不斷地收集資源利用的信息。需要在單個硬件和軟件的組件上安裝監(jiān)控器，然

23、后對其進行配置以便收集必要的數據，這些數據需要在一段時間內進行累積和存儲。這項活動通常在服務運營部分通過監(jiān)控和控制得到實施。對組件容量管理進行實時反饋應該應用于這一子流程中。同服務容量管理一樣，成功的組件容量管理的關鍵也是預測問題，如果可能，也需要以主動的和預測性的方式進行。然而，組件容量管理需要對特定的問題做出被動地響應，如容量不夠或者組件的無效率使用所引起的問題。這種情況也是存在的。來自于對正在運行的服務的資源使用的知識和理解，對服務使用的變更效果的估計，對硬件和軟件更新的預算和規(guī)劃?？晒┻x擇的是，對現存資源與服務進行平衡可以達到當前資源的最有效率的利用。容量管理的支撐活動本部分所描述的活

24、動對支持容量管理的子流程是必要的，這些活動可以以被動的或主動的甚至優(yōu)先的方式進行。各子流程間最大的不同是被監(jiān)控和收集的數據及對數據分析的視角。例如在基礎架構中單個組件的利用水平，如處理器、磁盤和網絡連接，是與組件容量管理相關的，事務處理產出比率和響應時間是和服務容量管理相關的。對于業(yè)務容量管理，對在線服務來說，事務處理產出比率需要轉化為業(yè)務量，例如，以銷售發(fā)票或訂單的形式。容量管理最大的挑戰(zhàn)是理解業(yè)務需求和業(yè)務負載之間的聯系，并能轉換為對服務和資源的負載和利用的影響和效果，所以可以在每一層級上設置合適的閾值。調諧（tuning）和優(yōu)化活動應該重復地進行一系列的活動并形成一個自然的循環(huán)，如圖例所

25、示。這些活動提供了基本的歷史性的信息和觸發(fā)因素，對容量管理的所有其他活動和流程是必要的。應該建立對所有組件和每個服務的監(jiān)控。如果可能，這些數據應該使用專家系統來對比利用水平和閾值。分析的結果應該以報告的形式表現出來，并包含合適的建議。一些控制機制的表現形式應該對這些建議做出響應。如平衡服務、平衡負載、變更并發(fā)數量、增加或刪除資源。在這些活動中所累積的所有信息應該存儲在容量管理信息系統（CMIS）中，這樣，當循環(huán)再次開始時，監(jiān)控發(fā)生的任何變更以保證他們能夠產生有益的效果并為將來的行動收集更多的數據。利用監(jiān)控方式應該對特定的操作系統、硬件配置、應用程序等實行不同的監(jiān)控方式。重要的是監(jiān)控能夠收集容量

26、管理所需求的對于某一組件或服務的所有信息。典型的監(jiān)控數據包括：處理器利用情況內存利用情況事務處理類型所占用的CPU百分比輸入輸出比率（物理的和緩沖區(qū)的）和設備利用情況隊列長度磁盤利用情況事務處理比率響應時間批處理時長數據庫使用情況索引使用情況命中率并發(fā)用戶數網絡流量比率在考慮所要包括的數據的時候，還要把監(jiān)控容量（如吞吐量）收集的數據和監(jiān)控性能（如響應時間）收集的數據區(qū)分開來。服務容量管理和組件容量管理都需要這兩種類型的數據。監(jiān)控和收集的數據需要結合在服務中需要的所有組件，從而監(jiān)控端到端的用戶體驗。需要在整體的資源利用水平上收集數據，還要收集每個服務在每個組件上的負載的詳細情況。這需要貫穿于整個

27、技術、主機或服務器、網絡、本地服務器和客戶端（或工作站）之中來進行。監(jiān)控活動的一部分就是監(jiān)控正常操作水平的閾值、基準或配置。如果超出了指標，應該進行報警和發(fā)布異常報告。這些閾值和基準應該由當前記錄數據的分析結果所決定，并可以在組件和服務水平上進行設置。所有的閾值設置都應低于組件或服務超常利用的水平或者低于SLAs中的目標。這樣，在將要達到或達到閾值時，仍然有機會在違背SLA或資源被過度利用之前采取正確的行動，只是存在一段性能不佳的時期。這些事件、閾值、報警的監(jiān)控和管理在服務運營書籍中有詳細的討論。通常得到業(yè)務容量管理所需要的關于當前業(yè)務量的數據是很難的。這些數據可能派生于對服務容量管理和組件容

28、量管理可用的數據。響應時間監(jiān)控許多SLAs把測量用戶響應時間作為眾多目標之一，但是，同樣地，許多組織在支持這一要求是存在很大的困難。IT和網絡服務的的響應時間可以由以下方式監(jiān)控和測量：在客戶端和服務器應用軟件中注入特殊代碼：這種方式可以提供完全的端到端響應時間或者提供中間時間點來分解整體的響應時間到其組成部件上。通過這些工具所得到的數據可以提供實際的響應時間，如同某一個服務的使用者所感覺的一樣。在終端模擬軟件中使用“機器人腳本系統”：這些系統由帶有終端模擬軟件的客戶端系統（如瀏覽器或者遠程登陸系統）和特殊的腳本軟件組成，可以生成和測量事務處理和響應情況。這些系統通常提供的是樣本的端到端服務響應

29、時間，不過對于提供代表性的響應時間仍然是有用的，特別是對多階段的事務處理或復雜的交互來說。這些只是提供了樣本的響應時間，不是實際的響應時間，不像某一服務的使用者所感覺的那樣。使用分布式的代理監(jiān)控軟件：通過帶有監(jiān)控軟件的分布式代理系統監(jiān)控網絡的不同節(jié)點（如網絡上的不同國家）可以得到關于服務響應時間的有用信息。這些系統可以用來生成訪問某一網站的來自不同地域的匯報并提供周期性的測量數據，如同某一網站的國際用戶所感覺的那樣。然而，再次強調一下，收到的數據只能作為響應時間的指標，不能作為實際的用戶響應時間。使用特殊的被動的監(jiān)控系統：跟蹤客戶端系統的有代表性的樣本數。這種方法依賴于特殊網絡監(jiān)控系統的連接工

30、具，通常作為“嗅探器”插入到網絡上的合適節(jié)點。這些工具就能夠監(jiān)控、記錄和測定網絡中通過某個特殊節(jié)點的所有流量了。一旦記錄下來，就可以分析這些流量數據從而得到關于服務響應時間的詳細信息。再次強調，這只能用于估計實際的用戶響應時間，雖然這些信息通常非常接近現實世界中的狀況，但是這依靠于在IT基礎架構中的監(jiān)控的位置。在一些情況下，需要使用一系列系統的組合。響應時間的監(jiān)控是一項復雜的流程，即使它是一項運行于私有網絡的內部的服務。如果是外部的網絡服務，這一流程會因為不同組織和技術的卷入而變得更加復雜。虛構：擁有一個主要網站的私營公司使用外部供應商實現的網絡監(jiān)控服務可以提供網站可用性和相應能力的自動報警。

31、監(jiān)測點自身的可用性和速度低于被監(jiān)控網絡的可用性和速度，這樣，監(jiān)控服務所得到的是監(jiān)控服務自身的可用性和相應能力的數據，而不是被監(jiān)控網站的數據。提示：當需要實施外部監(jiān)控服務時，需要保證監(jiān)控服務的水平和性能承諾超出被監(jiān)控服務的水平和承諾。分析需要對監(jiān)控所收集到的數據進行分析以便從正常的利用水平和服務水平中識別趨勢，或者建立基準。通過定期監(jiān)控和對比基準，可以定義單個組件或服務的閾值利用的異常條件，可以報告在SLA考核中的違背或有驚無險的情況并做出相應的行動。同時，這些數據也可用來預測將來的資源使用情況，或者監(jiān)控實際的業(yè)務增長是否與預測的增長相抵。對數據的分析可以識別問題，例如：基礎架構中的瓶頸或熱點在

32、有可用資源的情況下負載分發(fā)的不恰當不恰當的數據庫索引應用程序設計中的無效性工作負載或事務處理比率出乎預料地增加調度或內存使用的效率低每個組件和服務的使用需要在短期、中期、長期中得到考慮，并記錄下最小、最大和平均的使用情況。經常地，短期指的是24小時，中期指的是1-4周，長期指的是1年。隨著時間的過去，各個IT服務所使用資源的趨勢就會變得明顯起來。通過記錄使用情況中的任何導致高峰或低谷的因素，這可以提高信息的有效性-例如，業(yè)務流程或員工的變更應該和正常的使用情況存在差異。理解這些時期的使用情況是很重要的，這樣把在任何服務使用中的變更與單個組件的利用水平上的預測的變更聯系起來。識別某個特別IT服務

33、所依靠的特殊的硬件或軟件組件的能力通過一個準確的、最新的、綜合的容量管理系統（CMS得到了極大地提高?？紤]某個特殊的資源使用情況的時候，了解這個資源利用的總水平和使用該資源的單個服務的利用情況是很重要的。例子：如果在峰值時間一個使用率為75%勺處理器由服務A和服務B所使用，了解這75%是如何被每個服務所使用的是重要的。假定系統使用了處理器的5%剩下的70%可能被這兩個服務平分了。如果服務A或B中的一個變更估計需要雙倍的處理器資源，處理器將會出現超載的情況。然而，如果服務A使用處理器的60%服務B使用10%這種情況下服務A需要雙倍處理器資源的時候，處理器將會超載；而服務B需要雙倍處理器資源的時候

34、則不會。調諧（tuning）對監(jiān)控數據的分析可以識別配置的領域從而進行調整以便更好地使用服務、系統和組件資源或者提高某個特殊服務的性能。輔助的調諧技術包括：均衡負載和流量：事務處理通過某個特定的網關到達主機或服務器，依靠于事務處理的發(fā)起位置，均衡發(fā)起位置到網關的比率可以提供更好的調諧收益。均衡磁盤流量：高效地和戰(zhàn)略地在磁盤上存儲數據，例如，通過多種方式剝離數據能夠減少數據沖突?？山邮艿逆i定戰(zhàn)略的定義，可以說明什么時候進行鎖定是必要的和恰當的鎖定水平，如數據庫、頁、文件、記錄和行-延遲鎖定直到更新能夠產生收益以致變得必要的時候。內存的有效使用-可能包括依據具體的情況使用更多或更少的內存在實施來自

35、調諧技術所提出的任何建議之前，考慮測試這些建議的有效性是恰當的。例如：“能夠使用需求管理來規(guī)避實行任何調諧的必要嗎”或者“能夠對提議的變更在實施之前進行建模以展示它的效果嗎”實施實施活動的目標是把由監(jiān)控、分析、調諧活動所確定的任何變更引進實際的運營服務。這些變更的實施需要通過嚴格的正式的變更管理流程來進行。系統調諧變更的影響對于使用服務的客戶有重大的意義。與這種類型的變更相關的影響和風險可能要比其他類型的變更更大。重要的是，采取更進一步的監(jiān)控以便評估變更的影響。必要時需要采取進一步的變更或者調整一些初始的變更。利用新技術這設計到了解新技術和科技，以及它們是如何被使用來支持業(yè)務和促進改善的。引進

36、新的技術來提高對組織所依賴的IT服務的支持是恰當的。這些信息可以通過學習專業(yè)文獻（雜志或出版的文章）或者參加以下的活動收集到：硬件和軟件供應商的宣傳研討會潛在的硬件和軟件的供應商的用戶組會議為涉及容量管理的其他IT專業(yè)人員召開的用戶組會議這些活動都是提供潛在的技術、科技、硬件和軟件相關信息的來源，實施它們可以實現業(yè)務收益。在所有情況下，容量管理都應該確認新技術的引進和使用是成本合理的并能為業(yè)務帶來真實的收益。并不只是新技術本身是重要的，容量管理通過使用網格計算、虛擬化和按需計算等技術，應該保持在新技術使用過程中獲得的優(yōu)勢。彈性設計在IT基礎架構或它的任何子集中容量管理協助彈性設計的確認與改進，

37、在任何成本合理的情況下。結合可用性管理，容量管理應該使用組彳失敗影響分析（CFIA,在可用性管理中有所描述）來確認當前配置是如何地受到影響以致單個組件的失敗或超載并提出任何成本合理的解決方案的建議。容量管理應該有能力確認關于某個失敗的可用性資源的影響，和使用剩余資源運行最重要的服務的潛力。所以，備用容量可以作為在失敗情況下的彈性準備或故障恢復。在服務或系統設計的時候總是應該考慮IT基礎架構中彈性設計的需求。然而，對許多服務來說，服務的彈性設計只是在實際運用使用之后才被考慮到。在服務設計中結合彈性設計比在服務運營后添加彈性設計更有效果和效率。閾值管理與控制監(jiān)控活動所使用的單個服務和組件的技術限制

38、和約束可以用來設置閾值，從而作為引發(fā)報警和發(fā)布異常報告的指標。然而，設置閾值的時候必須經過練習，因為許多閾值依靠于運行在某個特別組件上的運作情況。服務和組件閾值的管理和控制是有效傳遞服務以滿足既定服務水平的基礎。它保證所有服務和組件的閾值在恰當的水平上得到維護、連續(xù)地自動地得到監(jiān)控和出現異常的時候發(fā)出報警和警告。無論何時，當超過或者威脅到監(jiān)控的閾值的時候，能夠發(fā)出報警和生成警告和異常報告。應該對這種情況進行完全地分析并在合適的時候采取拯救的行動從而保證這種情況不再發(fā)生。使用相同的數據項可以確認什么時候違背了或可能違背SLAs或什么時候組件性能降級了或可能降級。通過設置高于或低于實際目標的的閾值

39、，可以采取及時的行動和避免違背SLAs的目標。閾值監(jiān)控不應該只是對超出閾值進行報警，還應該監(jiān)控變更的比率和預測達到閾值的時間。例如，磁盤空間監(jiān)控需要監(jiān)控增長的的比率并以當前比率的增長速度在接下來的N天內占滿磁盤的情況發(fā)出報警。假設一塊1G磁盤已經使用了90%增長速度是100KB/天，則需要1000天會占滿磁盤空間。如果增長速度是10MB仄，10天時間就會占滿磁盤空間。這些事件和報警的監(jiān)控和管理在服務運營書籍中有詳細的介紹?？赡艽嬖谝恍﹫龊希枰獌?yōu)化基礎架構的組件和資源來維護和提高性能和吞吐量。這通常是由負載管理完成的，它是一個一般的術語，覆蓋如下的行動：重新調度某個特殊的服務或負載以便在一天的

40、不同時間或者一周的某天運行從一個位置或配置項目的設置轉移服務或負載到另一個-通常是為了平衡利用或流量虛擬化技術：設置和使用虛擬化技術和系統來允許圍繞基礎架構的流程移動以動態(tài)的形式發(fā)揮更好的性能/彈性通過需求管理技術，結合財務管理，限制或轉移對組件或資源的需求（見章節(jié)）對某一負載何時運行及在基礎架構中每一負載使用多少資源的良好理解才能使有效地管理負載成為可能。盡心的負載監(jiān)控和分析，與綜合的容量管理信息系統一起，被不斷進行地運維基礎所需要。需求管理需求管理的主要目標是影響用戶和客戶對IT服務的需求和管理對IT資源的影響。需求管理可以作為短期需求來執(zhí)行，因為沒有足夠的容量來支持不斷進行的工作，或者,

41、作為IT管理的一項經過考慮的政策，來限制長期所需要的容量。短期需求管理發(fā)生在IT基礎架構中某一項關鍵資源發(fā)生局部失敗的時候。例如，多處理器的服務器中一個處理器發(fā)生故障，從而不可能運行全方位的服務。不過，仍然可以運行全方位服務的一個有限子集。容量管理需要知道每一服務的業(yè)務優(yōu)先級，了解每一服務的資源需求（在這個例子中，運行某一服務的處理器的數量），這樣才能夠確認在有限的處理器可用情況下可以運行哪個服務。長期需求管理發(fā)生在難以花費巨大的成本進行升級的時候。例如，許多處理器僅僅在每天的幾個小時被嚴重利用，典型的是上午10點到12點和下午2點到4點。在這些期間內，服務器超載的時間僅僅一到兩個小時。對于晚

42、6點到第二天早8點，處理器的負載是很低的并且組件的利用率也是很低的。調整升級的成本僅僅是為24小時中的幾個小時提供附加的容量，這可能么或者影響需求或伸展貫穿一天24小時的資源要求，這樣可以延遲或避免昂貴的升級的需要，這可能么需求管理需要了解哪個服務正在使用資源以及當他們必須運行的時候在何種水平上進行調度。這樣可以對此服務是否可能影響到資源的使用做出決策，如果可以的話，做出恰當的選擇。對正在運行的服務的影響可能來自：物理約束：例如，在某些特定的時間從可用的服務中停止某些服務或者限制能夠使用某個特殊服務的用戶數量-例如，限制并發(fā)用戶數量；對特殊的資源或組件實行約束-例如，限制連接網絡路由器或交換機

43、的物理設備數量。財務約束：如果為IT服務所做的變更是恰當的，對資源需求少的時候可以降低每天的某些期間運行服務的比率。這就是所謂的代價。建模和趨勢分析容量管理的首要目標是在給定的容量和工作種類下預測IT服務的行為。建?；顒涌梢詰糜谌萘抗芾淼娜魏巫恿鞒虂懋a生有益的效果。建模的不同類型從基于經驗和當前資源利用信息的估計延伸到前期研究、原型和全規(guī)模的基準。前一種類型對于日常的小決定是便宜的和合理的，后幾種類型在實施一項大的工程或服務時是昂貴的，但是卻是可取的。通過各種類型的建模，可以獲得類似水平的精確度，但是所有這些都依靠于建模人員所使用的信息和建構技巧?；鶞式５牡谝浑A段是建立一個準確反映正在達成

44、的性能的基準模型。基準模型建立后，預測模型也就完成了，例如，詢問一些“如果怎么樣，會發(fā)生什么”之類的問題來顯示失敗、計劃變更對硬件和（或）負載容量（或種類）的影響。如果基礎模型是精確的，潛在失敗和變更的結果的精確性也是可以信賴的。有效的容量管理和建模技術能夠回答“如果怎么樣，會發(fā)生什么”之類的問題。如果服務A的吞吐量加倍，會發(fā)生什么如果服務B從當前服務器移到另一臺新服務器，會發(fā)生什么對這兩種服務的響應時間會帶來什么樣的影響趨勢分析依靠容量管理收集的資源利用和服務性能的信息可以完成趨勢分析?？梢栽陔娮颖砀窈蛨D形化的趨勢和預測工具中進行分析，用來顯示先前一段時間中某項特殊資源的利用情況及將來它會出

45、現怎樣的變更。典型地，趨勢分析僅僅對未來資源利用信息進行估計。趨勢分析在估計精確的響應時間方面是效果不佳的，這種情況下可以使用分析模型或者模擬模型。趨勢分析在少數變量之間存在線性聯系時是最有效的，但是如果變量很多或者變量之間不是線性聯系時就不太有效了。分析模型分析模型是使用數學技術如多層次網絡排隊理論的計算機系統行為的代表。典型地，使用個人計算機上的軟件包，通過規(guī)范需要建模的配置組件和結構以及多種多樣的負載或應用程序對組件（如處理器、內存、磁盤等）的利用情況可以建立分析模型。運行模型時，在計算機系統中可以使用排隊理論來計算響應時間。如果此模型預測的響應時間足夠接近與真實環(huán)境下記錄的響應時間，那

46、么這個模型就可以被認為是計算機系統的精確代表。分析模型的技術比模擬模型需要更少的時間和付出，通常得出的也是不夠精確的結果。同樣的，應該保持模型是最新的。然而，利用情況的誤差在5現內、在線應用程序響應時間的誤差在15-20%以內，這樣的結果通常是令人滿意的。模擬模型模擬涉及的是離散事件的模型，如在給定的硬件配置下事務處理的到達比率。模擬模型在新應用的定型或者現存應用變更的效果的預測方面是非常精確的，卻是非常耗時的所以成本巨大。模擬事務處理到達比率的時候，需要一定數量的員工以隨機到達的比率從準備好的腳本中鍵入一系列的指令或者使用軟件輸入同樣的腳本指令。每種途徑都需要時間和付出進行準備和運行。然而，

47、這對于擁有大量服務和系統的組織是成本合理的，因為昂貴成本和與之相連的性能承擔著巨大的價值。應用定型應用定型具有有限的生命跨度。它開始于一項新服務的設計階段或者需要對現存服務做出重大變更的時候，終止于實際運營環(huán)境接受此應用的時候。定型活動應該包含應用相關的技術的所有方面，而不僅僅是應用本身。即應該包含基礎架構、環(huán)境、和數據，還經常使用建模和趨勢分析技術。應用定型的主要目標是估計資源需求以支持對現存服務提議的變更或一項新服務的實施，從而保證滿足服務等級的要求。為了達到這一目標，應用定型必須作為服務生命周期的一部分。在最初的需求和設計期間，所需求的服務等級必須在SLR中得到規(guī)定。這能夠使服務設計和開

48、發(fā)使用相關的技術和產品完成設計以符合服務要求的等級。如果服務設計在服務生命周期的開始階段（而不是其后的階段）考慮到所要求的服務等級，達到此等級會更加的容易和低廉。應用定型中其他考慮是彈性設計方面，這對于新服務的設計可能是必須的。容量管理能夠為可用性管理在資源需求方面提供建議和指導以提供性能和彈性設計所要求的等級。應用定型應該和設計、開發(fā)一樣是精確的?？梢栽趹枚ㄐ椭惺褂媚Ｐ?。不應該孤立地考慮計劃的應用開發(fā)的SLR其他服務分享可能會分享應用所利用的資源，必須辨識和管理對現存SLA目標的潛在威脅。向外部供應商購買軟件包的時候，了解支持服務的資源需求是重要的。通常很難從供應商那得到信息，并且它是變化

49、的，依賴于吞吐量的變化。因此，確認產品的相似客戶和從那些客戶中了解資源的利用情況是有益的。在購買之前進行檢查、評估和試驗是中肯的。關鍵信息：質量必須是內在的。在實施之后也可以提高服務質量的某些方面（例如，增加額外的硬件以提高性能）。其他方面，特別是應用軟件的可靠性和可維護性方面，依賴于內在的質量，因為實際上，在后期階段嘗試添加額外的東西就是重新設計和開發(fā)，正常情況下會比原始開發(fā)花費更高的成本。即使在上面所舉的硬件例子中，在服務實施之后增加額外的容量（而不是作為原始項目的一部分）可能會花費得更多。觸發(fā)、輸入輸由與接口許多情況會觸發(fā)容量管理活動。包括：違背服務、容量或性能事件和報警，包括閾值事件異

50、常報告當前容量和性能的周期性的修訂和預測、報告和計劃的回顧新的或變更的服務需要額外的容量周期性的趨勢分析和建模業(yè)務和IT規(guī)劃（和戰(zhàn)略）的回顧和修訂設計和戰(zhàn)略的回顧和修訂SLA、OLA合同或其他協議的回顧和修訂有許多容量管理相關信息的來源，部分如下所述。輸入業(yè)務信息：來自于組織的業(yè)務戰(zhàn)略、計劃和財務規(guī)劃及關于當前和將來需求的信息。服務和IT信息：來自于服務戰(zhàn)略、IT戰(zhàn)略、規(guī)劃和當前預算，覆蓋技術和技術規(guī)劃的所有領域，包括基礎架構、環(huán)境、數據和應用程序及它們與業(yè)務戰(zhàn)略和規(guī)劃相關聯的方式。組件性能和容量信息：來自于制造商和供應商的關于現存技術和新技術的信息。服務性能問題：來自于故障管理和問題管理中性

51、能不佳相關的故障和問題服務信息：來自于服務級別管理，關于服務組合、服務目錄、SLAs和SLRs規(guī)定的服務水平目標的服務細節(jié)信息，可能來自于SLAs的監(jiān)控、SLAs的服務回顧和違背的服務細節(jié)信息財務信息：來自于財務管理，服務規(guī)定的成本、資源、組件和升級的成本、結果的業(yè)務收益、財務規(guī)劃和預算、服務和組件失敗相關的成本。一些組件和組件升級的成本來自于采購商、供應商和制造商。變更信息：來自于變更管理，變更安排和評估所有變更對技術容量的影響的需要性能信息：來自于容量管理信息系統中所有現存服務和IT基礎架構組件的當前性能的信息。組件管理系統（CMS：包含業(yè)務、服務、支撐服務與技術之間聯系的信息。負載信息：

52、來自于IT運營團隊，所有需要運行的工作的調度、不同服務和信息之間關于依賴關系的信息、某項服務的內部依賴關系的信息輸由容量管理的輸出可以用于容量管理流程的其他部分、其他的流程和組織的其他部門。通常這些信息在共享的領域以電子報告（或展示）的形式或者在內部服務器上的文件被提供，來保證可以使用到最新的信息。提供的信息如下：容量管理信息系統（CMIS）:儲存容量管理中所有子流程所需要的信息。例如，作為組件容量管理和服務容量管理的一部分，監(jiān)控到的和收集的信息可以用于業(yè)務容量管理以決定需要什么樣的基礎架構組件或升級以及什么時候需要。容量規(guī)劃：被業(yè)務和IT管理的所有領域所使用。由IT服務提供商和組織的高級管理

53、層所使用來規(guī)劃IT基礎架構的容量。它還可以作為IT和業(yè)務其他領域的輸入。它包含了服務和組件的當前使用狀況的信息及所做的IT容量的發(fā)展以滿足現存服務和任何同意的新服務的需要的規(guī)劃。容量規(guī)劃可以作為制定政策的基礎。經常存在的情況是，建立了容量規(guī)劃但從來沒有參考過或使用過它。服務性能信息和報告：被許多其他流程所使用。例如容量管理協助服務等級管理對服務性能、新SLRs開發(fā)或現存SLAs變更進行報告和回顧。它還可以協助財務管理確定什么時候為IT基礎架構或者新組件的購買提供預算所需的資金。負載分析和報告：由IT運營使用，結合容量管理一起來評估和實施變更以調度或重新調度服務（或負載）的運行時間，保證對可用的

54、資源進行最有效果和有效率的使用。容量和性能報告：被容量管理、IT和業(yè)務的所有領域所使用來分析和解決服務和性能問題。預測報告：被所有的領域所使用來分析、預測特殊的業(yè)務和IT情境及潛在的解決方案。閾值、報警和事件。關鍵性能指標一些關鍵性能指標和度量標準可以用來判斷容量管理的效率和效果，包括：精確的業(yè)務預測：按時地對負載產出的預測對業(yè)務趨勢預測的百分比精度及時地把業(yè)務規(guī)劃結合到容量規(guī)劃中減少業(yè)務規(guī)劃和容量規(guī)劃之間的差異關于當前和將來技術的知識：監(jiān)控所有服務和組件的性能和吞吐量的增強的能力符合業(yè)務需求的新技術的及時調整和實施（時間、成本、功能）減少因為性能或支持所導致的違背SLAs的舊技術的使用。展示

55、成本效益的能力減少在最后時刻進行采購以應付緊急性能問題的情況減少IT方面的容量過剩精確預測計劃性的支出減少由缺乏IT容量導致的業(yè)務失敗相對減少容量規(guī)劃的成本規(guī)劃和實施恰當的容量以符合業(yè)務需求的能力：減少因為性能不佳導致的故障的數量減少因為容量不足導致的業(yè)務損失所有實施的新服務符合服務等級要求（SLRS）減少因為服務性能不佳或組件性能不佳導致的違背SLA的情況的數量信息管理容量管理信息系統的目的是提供相關的容量和性能信息以生成報告和支持容量管理流程。這些報告為許多的IT和服務管理流程提供了有價值的信息。這些報告包括：基于組件的報告應該有一個技術團隊對每個組件進行控制和管理。這些報告必須圖例化地說

56、明組件的性能表現和最大容量內正在使用的容量。基于服務的報告這些報告必須圖例化地說明服務及其構成組件在遵守整體的服務目標和約束的情況下的性能表現。它們也為服務級別管理報告和客戶服務報告提供基礎。異常報告這些報告顯示當某個特定組件或服務的容量和性能變得不可接受的時候需要管理人員和技術人員對容量數據進行分析。在容量管理信息系統中可以為組件、服務或測量方式設置閾值。例如，閾值可能是某個特定服務器的處理器使用百分比在連續(xù)的三個小時都超過70%，或登錄用戶的并發(fā)數量超過規(guī)定的限制。特別地，異常報告可以用于服務級別管理（SLM以決定是否已經違背了SLAs目標。故障和問題管理也可以使用異常報告來解決故障和問題。預測報告為保證IT服務提供者能夠繼續(xù)提供所要求的服務水平，容量管理必須預測未來的負載和增長。為了做到這些，必須預測未來的組件和服務的容量和性能。依靠所使用的技術和科技，可以有不同的方式來完成預測。新功能和服務的開發(fā)和實施所帶來的對負載的變更必須在由業(yè)務增長驅動的當前功能和服務的情況下得到考慮。容量預測的一個簡單的例子是業(yè)務驅動和組件利用之間的關聯，例如，處理器的利用以用戶數量為背景。這些相關的數據可以發(fā)現增加用戶數量對處理器利用的影響。如果未