1、 服務水平管理和服務水平協議（SLA）本文描述面向高可用性網絡的服務水平管理和服務水平協議（SLA）。它包括服務水平管理的成功因素以及幫您評估成功與否的性能指標。本文以一個國際性的網絡詳細描述遵從高可用性業務工作組確定的最佳方案指導原則的SLA。 服務水平管理概述網絡公司一直以來都通過構建堅實的網絡基礎設施及主動處理每個業務問題來滿足不斷擴展的網絡要求。當業務異常中斷時，公司將構建新流程、管理功能或基礎設施來防止此類故障再次發生。然而，由于快速變更及日益增長的可用性要求，我們現在需要改進模式來預先防止意外故障并快速修復網絡。許多服務供應商和企業一直都試圖更好地定義服務水平以

2、便實現商業目標。關鍵成功因素SLA的關鍵成功因素用來定義支持成功構建可獲得的服務水平及維護SLA的主要要素。要成為合格的關鍵成功因素，流程或流程步驟必須可以改進SLA質量并從整體上提高網絡的可用性。關鍵成功因素還應具備可測量性，以便使企業能夠判斷：與定義的程序相比，它所取得的成功程度。性能指標性能指標提供了公司測量關鍵成功因素的機制。您通常需要每月審查一次，以確保服務水平定義或SLA運行良好。網絡運行小組及必要的工具組可實施以下測量標準。注意：對于沒有SLA的公司，我們建議您同時實施服務水平定義、服務水平審核及測量標準。性能指標包括：· 記錄的服務水平定義或SLA，包括可用性、性能、

3、主動業務應答時間、排障目標及問題升級等。· 月度網絡服務水平審核會議，審核對服務水平的執行情況并實施改進。· 性能指標測量標準，包括可用性、性能、按優先級劃分的業務應答時間、按優先級劃分的排障時間以及其他可測量的SLA參數。服務水平管理流程面向服務水平管理的高級別流程主要包括兩組：1.定義網絡服務水平 2.創建并維護SLA實施服務水平管理實施服務水平管理包括十六步，分為以下兩個主要范疇：· 定義網絡服務水平步驟1-6· 創建并維護SLA 步驟7-16定義網絡服務水平網絡管理人員需要定義支持、管理并測量網絡的主要規則。服務水平為所有網絡人員提供目

4、標并可用作整體業務質量的測量標準。您也可將服務水平定義用作網絡資源預算工具以及投資于更高服務質量的證據。它們還提供評估供應商及運營商的表現的方法。如果沒有服務水平定義和測量，公司不可能制定明確的目標。服務是否滿意由用戶決定，在應用、服務器/客戶機運行或網絡支持方面并無明顯差距。由于企業對最終結果沒有把握，因此很難作預算。最終，網絡公司在提高網絡及支持模式方面都趨向于選擇被動應答，而非主動預防的方式。我們建議采取以下步驟來構建并支持服務水平模式：· 分析技術目標及限制因素。· 確定可用性預算。· 創建詳細記錄關鍵應用網絡特征的應用資料庫。· 定義可用性、性

5、能衡量標準及通用術語。· 創建服務水平定義，包括可用性、性能、業務應答時間、排障平均時、故障檢測、升級門限及上報途徑。· 收集測量標準并監控服務水平定義。第1步：分析技術目標及限制因素開始分析技術目標和限制因素的最佳方式是集體討論或研究技術目標與要求。因為這些人都有特定的業務目標，所以有時這有助于要求其他IT技術人員參與討論。技術目標包括可用性級別、吞吐量、抖動、延遲、應答時間、可用性要求、新特性的推出、新應用的推出、安全性、可管理性及成本等。隨后，公司應研究限制因素，以便使用可用資源實現這些目標。您可為每個目標創建帶有對限制因素解釋的工作表。最初看似大多數目標都無法實現。

6、隨后劃分目標的優先級或降低對仍可滿足商業要求的目標的期望值。例如，您制定的可用性級別可能是99.999%，或每年5分鐘的故障停機時間。實現這一目標存在大量限制因素，如硬件的單點故障、遠程位置中的故障硬件的平均修復時間(MTTR)、運營商可靠性、預先故障檢測、高變更率及當前網絡容量限制等。因此，您需要將這個目標調節到更加易于實現的級別。下個章節中介紹的可用性模式可幫您制定現實的目標。您可能也考慮在限制因素相對較少的網絡領域提供可用性。當網絡公司公布業務的可用性標準時，公司中的各業務部門可能發現無法接受這個級別的可用性。這自然而然引發對SLA的討論，或為可滿足商業要求的模式進行投資/做預算。確定所

7、有限制因素或風險的工作包括要實現技術目標。根據實現理想目標的最大風險或影響方面劃分限制因素的優先級。這可幫助公司確定網絡改進計劃的優先順序，并確定解決限制因素的難易程度。限制因素分三類：· 網絡技術、故障恢復能力和配置· 生命周期方案，包括：規劃、設計、實施和運行· 當前的話務負載或應用行為網絡技術、故障恢復能力及配置限制因素是指與當前技術、硬件、鏈路、設計或配置相關的任何限制因素或風險。技術限制因素指技術本身造成的任何限制。例如，當前沒有一種技術允許冗余網絡環境中實現少于1秒的聚合時間，而這恰恰是維持整個網絡上的話音連接的關鍵。另一個例子是數據通過地面鏈路時的原

8、始速度，大約是100英里/毫秒。網絡硬件故障恢復能力風險調查應集中在硬件拓撲、分級體系、模塊化、冗余、MTBF及定義的路徑這幾方面。網絡鏈路限制因素應強調企業網絡鏈路及運行商連接。鏈路限制因素可能包括鏈路冗余和多樣性、媒介限制、布線基礎設施、本地環路連接性以及長距離連接性。設計限制因素與網絡的物理或邏輯設計相關，包括從為設備可用空間到路由協議實施的可擴展性等各個方面。您應在配置、可用性、可擴展性、性能及容量方面考慮所有協議和媒介設計。動態主機配置協議（DHCP）、域名系統（DNS）、防火墻、協議轉換及網絡地址轉換等網絡業務限制因素也應列入考慮之列。生命周期方案定義用于實現解決方案的統一部署、檢

9、測和修復故障、防止容量或性能問題以及配置一致性和模塊化的網絡流程和管理。您需要認真考慮這個領域，因為專業技術和流程通常是導致不可用性的最大影響因素。網絡生命周期指規劃、設計、實施和運行周期。在每個階段中，您都必須了解性能管理、配置管理、故障管理及安全性等網絡管理功能。思科NSA高可用性服務部（HAS）提供網絡生命周期評估服務，確定與網絡生命周期方案相關的當前網絡可用性限制因素。當前的話務量或應用限制因素只是指當前話務和應用的影響。不幸的是，許多應用都帶有大量需要慎重管理的限制因素。當前應用的抖動、延遲、吞吐量及帶寬要求通常帶有許多限制因素。編寫應用的方式也可能產生一些限制因素。匯編應用資料庫可

10、幫您更好地了解這些問題；下文將介紹這一特性。研究當前的可用性、話務、容量及性能還可幫助網絡管理人員了解當前的服務水平目標及風險。這一工作常通過名為網絡基準制定的流程來完成，該流程可幫您定義規定時段內（通常是一個月）的平均網絡性能、可用性或容量。這些信息通常用于容量規劃和趨勢分析，但也可用來了解服務水平問題。下面的工作表使用了上述目標/限制因素方法來實現防止安全性攻擊或拒絕服務攻擊（DoS）的目標。您也可使用該工作表來決定可最大限度地減少安全性攻擊的業務范圍。風險或限制因素限制因素類型潛在影響可用的DoS檢測工具無法檢測出全部DoS攻擊類型。技術/故障恢復能力高不具備對告警做出相應所需的人員和流

11、程。生命周期方案高當前網絡接入策略未加執行。生命周期方案一般如果利用帶寬擁塞來發動攻擊，則當前的低帶寬互聯網連接成為限制因素。網絡容量一般幫助防止攻擊的當前安全性配置不完善。技術/故障恢復能力一般第2步：確定可用性預算可用性預算是期望在定義的兩點間出現的、理論上的網絡可用性。準確的理論信息可在多個方面發揮作用：· 公司可將其視為內部可用性目標，并且能夠立刻定義偏離并進行補救。· 網絡規劃人員可使用這些信息來確定系統的可用性，以確保設計滿足商業要求。造成不可用性或故障停機的因素包括軟硬件故障、電源和環境問題、鏈路或運營商故障、網絡設計、人為錯誤或缺乏流程等。在評估網絡的整體可

12、用性預算時，您必須嚴格評估上述的所有參數。如果公司目前正在測量可用性，則可能不需要可用性預算。用可用性測量標準作為基準來評估服務水平定義使用的當前服務水平。然而，您可將二者進行對比，以便了解潛在的理論可用性與實際測量結果間的差距。可用性指產品或業務在需要時投入運行的可能性。參見以下定義：a.可用性¨1- (總的連接中斷時間) / (總服務連接時間)¨1- 總和(業務中斷期間受影響的連接數量 X 業務中斷時間) / (運行的連接數量X 運行時間)b.不可用性1-由以下因素造成的可用性或總的連接中斷時間：軟硬件故障、電源和環境問題、鏈路和運營商故障、網絡設計、用戶錯誤及流程故障

13、等。c.硬件可用性首先需要研究的領域是潛在硬件故障及其對不可用性的影響。要確定這方面的影響，公司應了解所有網絡組件的MTBF以及MTTR，以確定兩點間的路徑中所有設備的潛在硬件問題。如果網絡采用模塊化和分級體系結構，則幾乎任意兩點間的硬件可用性都是相同的。MTBF信息可用于所有思科組件，并且可根據請求、向本地客戶經理提供。Cisco NSA HAS項目還使用一種工具來幫助確定硬件可用性及網絡路徑，即使在系統中存在模塊冗余、機底冗余及路徑冗余時也可以使用這種工具。硬件可靠性的一個主要因素是MTTR。公司應評估它們修復故障硬件的速度。如果公司未制定備用方案，只依賴于標準Cisco SMARTnet

14、? 協議，則潛在的評估硬件更換時間為24小時。在帶有核心冗余但不帶有接入。冗余的典型LAN環境中，適當的可用性是 99.99%，平均修復時間是4-小時。d.軟件可用性下一個需要研究的領域是軟件故障。出于測量的目的，思科將軟件故障定義為由軟件錯誤引發的設備冷啟動。思科已經開發出許多流程來幫助了解軟件的可用性；然而，更新的版本尚需一段時間進行測量，并且我們認為它的可用性不及一般的部署軟件。IOS 11.2版(18)等一般部署軟件經測量，證明具備99.9999%的可用性。這個數字是基于修復時間為六分鐘（路由器重新裝載的時間）的思科路由器的實際冷啟動次數來計算的。采用不同版本的公司，可用性將隨著復雜性

15、的增加、互操作性的增強以及排障時間的縮短略有降低。采用最新軟件版本的公司，不可用性將有所提高。不可用性的分配也相當廣泛，這意味著客戶將感覺到很高的不可用性或接近一般部署版本的可用性。e.環境和電源的可用性您還必須考慮環境和電源的可用性問題。環境問題與將設備保持在特定的運行溫度范圍內的冷卻系統的故障相關。當溫度大大超過技術指標時，許多思科設備只是停止運轉，而不會損害所有硬件。出于可用性預算的目的，您必須將電源考慮在內，因為它是造成本領域中不可用性的主要原因。雖然電源故障是造成網絡不可用性的重要原因，但對它的討論還是受到限制，這是因為無法進行準確的、理論上的電源分析。企業必須基于所在地區的經驗、電

16、源備份功能以及實施的流程，對其設備的電源可用性的大約測量結果進行評估，以確保為所有設備提供具備一致質量的電源?；诒Ｊ氐墓烙嫞覀兛梢哉J為配備了備用發電機、不間斷供電電源 (UPS)系統并采用合格電源實施流程的企業，可實現高達六個九（99.9999%）的可用性，而未配備這些系統的企業，其可用性僅為 99.99%，或者說每年有36分鐘的故障停機時間。當然，您可根據公司的觀察或實際數據來調整這些數值，使其更真實地反映企業的具體情況。f.鏈路或運營商故障鏈路和運營商故障是影響WAN環境中的可用性的主要因素。切記：WAN環境只是同企業網絡遭遇同樣可用性問題的其他網絡，包括：軟硬件故障、用戶錯誤及電源故

17、障等。許多運營商網絡都已經開始對系統進行可用性預算，但獲得這些信息并不容易。切記，運營商的可用性保證級別很少基于或根本不基于實際可用性預算。這些保證級別有時只是用來提高運營商知名度的營銷和銷售方法。在某些情況下，這些網絡還公布看似相互突出的可用性統計數據。切記，這些統計數據可能只適用于完全冗余的核心網絡，而不作為導致不可用性的因素（不可用性由本地環路接入引起），本地環路接入才是WAN網絡中不可用性的主要因素。對WAN環境進行可用性評估應基于實際的運營商信息以及WAN連接的冗余級別。如果公司擁有多個大樓入口設施， 冗余本地環路供應商、同步光網絡 (SONET)本地接入、以及分布在多個地區的冗余長

18、途運營商，則WAN的可用性將得到明顯增強。電話業務是WAN環境中、非冗余網絡連接相當準確的可用性預算。使用類似于本文所描述的可用性預算方法進行測量，電話業務的端到端連接的可用性預算大約為99.94%。這種方法業已成功應用于數據環境中，結果基本相同，目前正被用作服務供應商有線網絡中分組有線規程的預算。如果將該數值用于完全冗余的系統，則我們可以假定，WAN可用性會接近99.9999%。當然，由于成本及可用性問題，目前很少有哪家公司部署了分布在多個地區且完全冗余的WAN系統，所以應使用適當的判斷方法測定這種功能。LAN環境中不太可能發生鏈路故障，然而，規劃人員可能希望假定連接器斷開或松動會引發短時間

19、的故障停機。對LAN網絡而言，保守的可用性估計約為99.9999%，或大約30秒故障停機/年。g.網絡設計網絡設計是影響可用性的另一個主要因素。不可擴展的設計、設計錯誤及網絡聚合時間都會對可用性產生負面影響。注意：出于本文的目的，我們將在下面的篇幅中描述不可擴展的設計或設計錯誤。網絡設計被限定在可測量的數值上（基于網絡中導致話務重新路由的軟硬件故障）。這些數值通常被稱作“系統故障切換時間”，并且是系統中自治愈協議功能的影響因素。使用與系統計算相同的方法便可計算可用性。然而，它只有在網絡故障切換時間滿足網絡應用要求時才有效。如果故障切換時間可以接受，則不把它計算在內。如果故障切換時間不能接受，則

20、計算時必須將其考慮在內，例如：估計或實際的故障切換時間為30秒的環境中下的IP 話音(VoIP)。在這個例子中，用戶只是掛斷電話，并有可能重新撥叫。用戶肯定會將這30秒看作是非可用時段，但在可用性預算時卻未加考慮。根據系統故障切換時間來計算不可用性時要著眼于理論的軟硬件可用性以及冗余路徑，因為故障切換將出現在這個領域。您必須了解可能發生故障并導致冗余路徑中出現故障切換的設備數量，這些設備的MTBF以及故障切換時間。一個簡單的例子就是，冗余的相同設備中，每臺設備的MTBF為35433小時，故障切換時間為30秒。用35，433除以8766（年平均小時數，包括閏年），我們可以看出該設備每四年出現一次

21、故障。如果使用30秒作為故障切換時間，我們便可以假設：由于故障切換，每臺設備每年平均停機7.5秒。由于用戶可能會跨兩條路徑，因此需要將此結果乘以2，即：每年15秒。當以秒/每年進行計算時，這個簡單系統中由于故障切換引起的可用性的計算結果為99.99999785%。由于可能出現故障切換的網絡中的冗余設備數量，在其他環境中，這個數字可能還要略高些。h.用戶錯誤和流程用戶錯誤和流程可用性問題是造成企業和運營商網絡中不可用性的主要原因。約80%的不可用性問題是由于無法檢測錯誤、變化故障及性能問題造成的。公司在制定可用性預算時，不愿意接受用戶錯誤和流程引發的不可用性是其他所有理論上的不可用性的四倍這一實

22、施，然而，各種證據一致表明，這種情況存在于許多環境中。下面我們將詳細闡述不可用性的這個方面。由于您無法從理論上計算由用戶錯誤和流程引發的不可用性數量，我們建議您在制定企業力求完美的可用性預算時不將其考慮在內。但企業必須了解其流程和專業技術水平中現在所面臨的可用性風險。透徹地了解了這些風險及抑制因素之后，網絡規劃人員便有可能將這些問題引發的一定數量的不可用性考慮在內。Cisco NSA HAS項目深入研究了這些問題，并可幫助企業了解由于流程、用戶錯誤或專業技術問題引發的不可用性。i.制定最終的可用性預算您可將以前定義的所有領域的可用性相乘來決定整個可用性預算。這種方法通常適用于任意兩點間的連接相

23、類似的同機種環境，如：分級體系模塊化LAN環境或分級體系標準WAN環境等。這下面的例子中，為分級體系模塊化LAN環境確定了可用性預算。該環境為所有網絡組件都配備了備用發電機和UPS系統，并對電源進行適當的管理。企業未使用VoIP，也不希望將軟件故障切換時間考慮在內。估算結果如下：· 兩個端點間的硬件路徑可用性= 99.99%· 使用GD軟件可靠性作為基準的軟件可用性= 99.9999%· 帶有備用系統的環境和電源可用性= 99.999%· 考慮LAN 環境中的鏈路故障的可用性= 99.9999%· 未將系統故障切換時間計算在內的可用性= 100

24、%· 認為不存在用戶錯誤和流程缺陷的可用性= 100%企業希望達到的最終可用性預算是：0.9999 X 0.999999 X0.999999 X 0.999999 = 0.999896，或99.9896%的可用性。如果我們將用戶或流程錯誤引發的潛在不可用性考慮在內，并假設其引發的不可用性是技術因素引發的可用性的四倍，則最終可用性預算是99.95%。對這個例子的分析使我們了解到，LAN可用性在99.95%與99.989%之間?，F在，這些數值能夠用作網絡公司的服務水平目標?？梢詼y量系統中的可用性并確定上述六個領域分別引發的不可用性百分率來計算其他數值。這使公司能夠對供應商、運營商、流程和

25、人員進行適當評估。這些數值也可用來設置業務期望值。如果您對99.95%與99.989%之間的可用性不滿意，可投資更多資源來獲得理想的可用性級別。網絡管理人員了解每個特定可用性級別的故障停機時間將大有幫助。計算任何可用性級別的年故障停機時間（分鐘）的公式如下：故障停機（分鐘）/年= 525600 （可用性級別 X 5256）如果可用性級別是99.95%，則結果是525600。(99.95 X 5256)，或者相當于222.8分鐘的故障停機。對于上述可用性定義，這等于網絡中所有業務連接的平均故障停機時間。第3步：創建應用資料庫應用資料庫可幫助網絡公司了解并定義每個應用的網絡服務水平要求。這有助于確

26、保網絡支持每個應用要求及整體網絡業務。當應用或服務器組指出網絡存在問題時，應用資料庫還可用作網絡服務支持的書面基準。最后，應用資料庫可將性能及可用性等應用要求與真實的網絡業務目標或當前限制因素進行對比，來調節網絡業務目標，使其與商業要求保持一致。這不僅對服務水平管理很重要，而且對整個網絡設計也相當重要。每次向網絡中添加新應用時都應創建應用資料庫。您還可能需要在IT應用部門、服務器管理部門以及組網部門間達成協議，以便為現有及全新業務創建應用資料庫，完成用于商業應用及系統應用的應用資料庫。商業應用可能包括電子郵件、文件傳輸、Web瀏覽、醫療圖象處理或制造等。系統應用可能包括軟件分發、用戶鑒權、網絡

27、備份及網絡管理等。網絡分析員及應用或服務器支持應用小組應負責創建應用資料庫。新應用可能要求使用協議分析程序以及具備延遲模擬功能的WAN模擬程序來適當地劃分應用要求的特征。這有助于確定必要帶寬、應用可用性的最大延遲及抖動要求。只要您具備所需服務器，便可在實驗室環境中開展這項工作。在VoIP等其他情況下，包括抖動、延遲及帶寬在內的網絡要求會很好地公布，且無需再進行實驗室測試。應用資料庫應包括以下項目：· 應用名稱· 應用類型· 新應用· 業務重要性· 可用性要求· 使用的協議和端口· 估計的用戶帶寬 (kbps)· 用

28、戶數量和位置· 文件傳輸要求（包括時間、量及端點）· 網絡故障停機影響· 延遲、抖動及可用性要求應用資料庫的目標是了解應用的商業要求、業務關鍵性以及帶寬、延遲及抖動等網絡要求。此外，網絡公司還應了解網絡故障停機的影響。在某些情況下，您可能需要重啟應用或服務器，這將大幅度延長總的應用故障停機時間 。完成應用資料庫后，您可將所有網絡功能進行對比，并幫助調節網絡服務水平，使其與商業和應用要求相一致。第4步：定義可用性及性能標準可用性及性能標準為企業制定業務期望值?？筛鶕煌W絡區域或特定應用進行定義這些標準。還可以確定往返延遲、抖動、最大吞吐量、帶寬承諾及總體可擴展性等

29、方面的性能。此外，為了制定業務期望值，企業還應謹慎定義每個業務標準，以便使致力于網絡工作的用戶及IT工作組能夠全面了解業務標準以及他們與應用或服務器管理要求的關系。用戶及IT工作組還應了解如何測量業務標準。以前服務水平定義步驟的結果可以幫助制定標準。這時，網絡公司應明確了解當前網絡所面臨的風險和限制因素及應用行為，并進行理論上的可用性分析或制定可用性基準。· 定義業務標準適用的地理區域或應用領域，可能包括園區LAN、本國WAN、外聯網及合作伙伴連接等。在某些情況下，企業在相同區域內的服務水平目標可能有所不同。這對企業或服務器供應商來說并不罕見。這時，它們通常基于各自的業務要求制定不同

30、的服務水平標準。這些在同一地理區域或服務區域中的標準有金牌、銀牌和銅牌之分。· 定義業務標準參數?？捎眯约巴笛舆t是最常見的網絡業務標準。根據需要，還可以包括最大吞吐量、最低帶寬承諾、抖動、接受的錯誤率以及可擴展性功能。當審核用于測量方法的業務參數時要特別謹慎。無論參數是否包括在SLA中，公司都應考慮出現問題或業務不一致性時，如何測量并證明業務參數的可行性。完成對業務領域和業務參數的定義后，您可使用以前步驟獲得的信息來構建業務標準圖。企業還需要定義可能使用戶和IT工作組產生混淆的區域。例如，往返ping的最長應答時間與在遠程位置單擊回車鍵啟動特定應用的最長應答時間有很大區別。下表列出

31、了美國采用的性能目標：網絡區域可用性目標管理方法平均網絡應答時間目標可接受的最常應答時間應答時間管理方法LAN99.99%受影響的用戶時間5毫秒內10 毫秒往返ping應答WAN99.9%受影響的用戶時間100毫秒內(往返ping)150 毫秒往返ping應答關鍵WAN及外聯網99.95%受影響的用戶時間100毫秒內(往返ping)150 毫秒往返ping應答第5步：定義網絡業務這是實現基本的服務水平管理的最后一步；它定義您實施用于實現服務水平目標的被動/主動流程和管理功能。最終文件通常被稱作“運行支持計劃”。大多數應用支持計劃只包括被動支持要求。在高可用性環境中，公司必須考慮采用主動的管理流

32、程，以便在網絡故障發生前對其進行隔離并加以處理解決?？偟膩碚f，最終文件應：· 描述用于實現服務水平目標的被動和主動流程· 介紹業務流程的管理方式· 介紹測量業務目標和業務流程的方式本部分將描述許多服務供應商和企業均需考慮的主動和被動業務定義的實例。構建服務水平定義的目標是創建滿足可用性及性能目標的業務。為了實現上述目標，公司必須構建業務，并謹記當前的技術限制因素、可用性預算及應用資料庫。特別是，公司應定義并構建始終能夠在可用性模式規定的時間內快速確定并排除故障的業務。公司還必須定義可快速識別并解決潛在業務問題的業務，如果忽略這些問題，將對可用性及性能產生負面影響。

33、實現理想的服務水平非一朝一夕之事。專業水準低、當前流程限制或人員不合格等缺點將妨礙公司實現理想的標準或目標，即使在完成對以前業務步驟的分析后也是如此。沒有一種方法可將所需服務水平與理想目標準確匹配。為了適應現實情況，公司應測量業務標準及用于支持業務標準的業務參數。如果沒有達到業務目標，公司應利用業務測量標準來幫助了解問題。在許多情況下，可適當增加預算以改進支持業務，并使這些改進功能成為實現理想業務目標的必要條件。企業可能會逐步進行多次調節（包括業務目標或業務定義），以使網絡業務與商業要求保持一致。例如，當目標遠遠高于99.9%可用性時，企業可能只實現了99%的可用性。在服務及支持測量標準方面，

34、企業代表發現硬件替換約需要24小時，遠遠高出最初的估計的4小時。此外，企業還發現主動管理功能受到忽視且故障的冗余網絡設計沒有及時修復。企業發現的問題還有缺乏實施改進的員工等。因此，考慮降低當前服務目標后，企業便投資購買實現理想服務水平所需的其他資源。業務定義應同時包括主動和被動支持定義。被動定義規定企業如何解決根據用戶投訴或網絡管理功能中確定已經發生的問題。主動定義描述企業如何確定并解決潛在的網絡問題，包括修復故障的“備用”網絡組件、錯誤檢測、容量門限問題及升級問題等。以下提供主動與被動服務水平定義實例。被動服務水平定義以下的服務水平領域通常使用幫助臺數據庫統計數據進行測量并定期審計。下表顯示

35、企業故障嚴重程度的實例。請注意：此表不包括處理新業務請求的方式，這項工作可通過SLA或其他應用資料庫編制及性能假設分析來完成。如果通過相同的支持流程進行處理，新業務請求可以數據嚴重級別5。嚴重級別1嚴重級別2嚴重級別3嚴重級別4嚴重的業務影響LAN用戶或服務器部分停機嚴重的WAN站點故障停機網絡功能的丟失或降級對業務造成嚴重影響，可能需要運行應變措施園區LAN故障停機； 5-99名用戶受到影響國內WAN站點故障停機國際WAN站點故障停機嚴重影響性能某些特定的網絡功能丟失或降級，如：冗余丟失等園區LAN性能受到影響 LAN冗余丟失對企業無業務影響的功能查詢或故障完成問題嚴重性級別定義之后，定義或

36、研究創建業務應答定義的支持流程?？偟膩碚f，業務應答定義要求采用分級支持結構，以及幫助臺軟件支持系統來利用故障票跟蹤問題。同時還應為每個優先級故障的應答時間和解決時間、按優先級劃分的呼叫數量以及應答解決質量制定測量標準。定義支持流程可幫助定義公司內部每個支持級別的目標及其任務與責任。這有助于公司了解用于每個支持級別的資源要求及專業技術水平。下表舉例說明了分級支持結構及其問題解決指導原則。支持級別職責目標第1級支持專職幫助臺支持接聽支持電話、發放故障票、15分鐘內解決問題、記錄故障票并上報到第2級支持解決40%的入局呼叫第2級支持隊列監控、網絡管理、工作站管理為確定的軟件故障發放故障票實施接聽第1

37、級、供應商的電話，并上報到第3級支持對呼叫負責，直到排障為止在第2級解決所有呼叫第3級支持必須立刻為第2級提供優先級為1的全部故障所需的支持同意在SLA解決期限內幫助解決所有第2級未排除的故障不直接對故障負責下一步是確定業務應答及排障業務定義。它為如何快速排障（包括硬件更換在內）制定了目標。為這個領域制定目標是非常重要的，因為業務應答及恢復時間直會接影響網絡的可用性。問題解決時間也要與可用性預算保持一致。如果在制定可用性預算時未將大量高嚴重級別的故障考慮在內，則公司隨后將需開展大量工作來了解此類故障的根源及可能的彌補方法。詳見下表：問題嚴重級別幫助臺應答第2級應答現場第2級硬件更換解決問題1立

38、刻上報到第2級，網絡運行部經理5分鐘2小時2小時4小時2立刻上報到第2級，網絡運行部經理5分鐘4小時4小時8小時315分鐘2小時12小時24小時36小時415 分鐘4小時3 天3天6天除業務應答及業務排障外，還需制定上報規定。上報表有助于確保將可用資源集中用于解決嚴重影響業務的問題。總的來說，如果分析員集中精力解決問題時，他們很少重視利用其他資源來解決問題。定義何時需要其他資源有助于促進管理層對問題的認識，并有助于促成未來的主動測量或預防性測量。詳見下表：過去的時間嚴重級別1嚴重級別2嚴重級別3嚴重級別45分鐘網絡運行部經理、第3級支持、聯網部主管1小時及時通知網絡運行部經理、第3級支持、聯網

39、部主管及時通知網絡運行部經理、第3級支持、聯網部主管2 小時上報副總裁、及時通知主任及網絡運行部經理4 小時向副總裁、主管、運行部經理、第3級支持提交根源分析，向CEO通知未排除的故障上報副總裁，及時通知主管及網絡運行部經理24 小時  網絡運行部經 理5 天網絡運行部經理迄今為止，服務水平定義始終集中在運行支持部門如何在問題發生后對其采取被動措施上。運行部門多年前便制定出了包括上述相似內容的運行支持計劃。然而，該方案中忽略了部門如何識別問題以及他們將識別哪些故障等內容 。比較成熟的網絡公司試圖制定預先確定的網絡問題百分率目標來解決這個問題，而不是通過用戶故障報告或投訴來被

40、動地確定故障。下表列出了公司對主動支持功能和被動支持功能的整體測量目標。網絡領域主動故障識別率被動故障識別率LAN80 %20 %WAN80 %20 %這為確定更多的主動支持定義開了一個好頭，因為它測量起來很簡單、也很容易，尤其在主動檢測工具可自動生成故障票。 這還有助于將網絡管理工具/信息集中用于主動排障，而不是在故障發生后被動地查找根源。然而，這種方法的主要問題在于它無法定義主動支持要求。這通常會造成主動支持管理功能間的差距并導致更大的可用性風險。主動服務水平定義更全面的制定服務水平定義方法包括，更詳細地解釋如何7 x 24全天候地監控網絡，以及運行部門如何7 x 24全天候對已定義的網絡

41、管理站（NMS）門限做出響應。鑒于管理信息站（MIB）數量的不確定性以及提供MIB的網絡管理信息數量與網絡的運行情況相關，因此這看上去是一項無法完成的任務。同時，完成這項任務需大量資源且代價非常高昂。不幸的是，這些缺點大大妨礙了我們對主動業務定義的實施，而這種實施從本質上來說非常簡單輕松，且只適用于可用性或性能風險極大的網絡。如果公司隨后看到了基本主動業務定義的價值，那么只要采用分階段實施的方法，就可以逐漸添加更多變量，但不會對業務產生重大影響。所有運行支持方案中均應包括第一個領域的主動業務定義。該業務定義只是簡單闡述運行部門如何識別不同網絡區域中的網絡或鏈路故障并對此做出響應。沒有這個定義（

42、或管理支持），公司可能遇到支持不穩定、無法達到用戶期望等問題，最終會降低網絡可用性。下表顯示了公司如何針對鏈路/設備故障制定服務定義。該實例中的企業在每天的不同時段及網絡區域方面有著不同的通知和響應要求。網絡設備或鏈路故障檢測方法5 x 8  通知7 x 24  通知5 x 8  排障7 x 24  排障核心LANSNMP設備和鏈路輪詢陷阱NOC創建故障票、向負責LAN的人員發出尋呼自動向負責LAN的人員發出尋呼、 LAN負責人員為核心LAN隊列創建故障票NOC在15分鐘內派出LAN分析員、根據業務應答定義解決問題

43、立刻研究并排除優先級1和2的故障、優先級3和4的故障排隊等候次日上午排除國內WANSNMP設備和鏈路輪詢陷阱NOC創建故障票、向負責WAN的人員發出尋呼自動向負責WAN的人員發出尋呼、 WAN負責人員為核心WAN隊列創建故障票NOC在15分鐘內派出WAN分析員、根據業務應答定義排障立刻研究并排除優先級1和2的故障、優先級3和4的故障排隊等候次日上午排除外聯網SNMP設備和鏈路輪詢陷阱NOC創建故障票、向負責合作伙伴的人員發出尋呼自動向負責合作伙伴的人員發出尋呼，合作伙伴負責人員為合作伙伴隊列創建故障票NOC在15分鐘內派出合作伙伴分析員、根據業務應答定義排障立刻研究并排除優先級1和2的故障、優

44、先級3和4的故障排隊等候次日上午排除其余的主動服務水平定義可分成兩類：網絡錯誤和容量/性能問題。只有少數網絡公司擁有這兩個領域的服務水平定義。因此，這些問題常被忽視或無法得到統一處理。這對某些網絡環境的影響可能不大，但高可用性環境一般都需要一致的主動業務管理。網絡公司希望實現主動業務定義的原因很多，主要是他們尚未基于可用性風險、可用性規劃及應用問題對主動業務定義進行要求分析，致使主動業務定義的要求及優勢不明確，這主要是因為需要更多的資源。第二個原因是要平衡能夠利用現有及新定義的資源來實施的主動管理數量。但生成這些告警就可能對可用性或性能產生嚴重影響。您還必須考慮事件關聯管理或流程，以確保不就同

45、樣的問題生成多個主動故障票。最后一個原因在于：創建一組全新的主動告警經常會生成以前未檢測出的初始信息流。運行部門必須為解決這些最初問題以及增加短期資源做好準備，以便解決這些以前未檢測出的問題。第一類主動服務水平定義是網絡錯誤。網絡錯誤還可細分為系統錯誤（包括軟硬件錯誤）、協議錯誤、媒介控制錯誤、準確性錯誤及環境警告。制定服務水平定義首先要要大體了解如何檢測出此類問題、由誰負責解決問題以及故障的影響。必要時在服務水平定義中添加特定的信息或問題。您可能還需要在以下領域開展更多工作以確保成功定義：· 第1、2和3級支持的責任· 利用運行部門能夠有效開展的主動工作量來平衡網絡管理信

46、息的優先級· 按要求進行培訓以便確保支持人員可以有效地處理定義的告警· 確定事件關聯方法以確保不為同樣的問題生成多個故障票· 記錄特定信息或告警，以幫助識別屬于第1級支持級別的事件下表是用于網絡錯誤的服務水平實例，幫助您明確了解誰負責發送主動網絡故障告警、如何確定故障以及故障影響。根據上文所述，公司尚需開展更多工作以確保成功。故障類型檢測方法門限采取的行動軟件故障（軟件造成的故障停機）每天都使用系統日志查看程序審核系統日志信息由第2級支持完成發生任何優先級0、 1和2的故障發生100多起優先級3（或更高）的故障審查問題、創建故障票并在新問題出現或問題需要特別注意時

47、派出人員解決硬件故障（硬件造成的故障停機）每天都使用系統日志查看程序審核系統日志信息由第2級支持完成任何第0、 1和2優先級別的故障的發生發生100多起優先級3（或更高）的故障審核問題、創建故障票并在新問題出現或問題需要特別注意時派遣人員解決協議錯誤(只適用于IP路由協議)使用系統日志查看程序每日審核系統日志信息由第2級支持完成發生任何優先級0、 1和2的故障發生100多起第3優先級（或更高）故障審核問題、創建故障票并在新問題出現或問題需要特別注意時派出人員解決媒介控制故障 (只限于FDDI、POS及快速以太網)使用系統日志查看程序每日審核系統日志信息由第2級支持完成任何第0、 1和2優先級別

48、的故障的發生發生100多起優先級3（或更高）的故障審核問題、創建故障票并在新問題出現或問題需要特別注意時派出人員解決環境信息（電源和溫度）使用系統日志查看程序每日審核系統日志信息由第2級支持完成任何信息對新問題創建故障票并派遣相關人員解決問題準確度錯誤（鏈路輸入錯誤）每五分鐘進行一次SNMP輪詢NOC受理的門限事件輸入或輸出錯誤任何鏈路上、每5分鐘出現一次錯誤對新問題創建故障票并派出第2級支持人員解決問題另一類主動服務水平是性能及容量。真正的性能和容量管理包括例外情況管理、基準制定與趨勢分析以及假設分析。服務水平定義只定義需要調查或更新的性能及容量的例外門限以及平均門限。隨后，可以以某種方式將

49、這些門限應用到三種性能和容量管理流程中。容量及性能服務水平定義可細分成幾個類別：網絡鏈路、網絡設備、端到端性能及應用性能。制定這些領域的服務水平定義需要具備與設備容量、媒介容量、QoS特征及應用要求的特定領域相關的淵博技術知識。出于這個原因，我們建議網絡設計師通過供應商輸入的信息制定與性能和容量相關的服務水平定義。與網絡錯誤相似，為容量和性能制定服務水平定義首先應大體了解如何檢測此類故障、由誰負責排障以及故障的影響。必要時向服務水平定義中添加特定的信息或問題。您可能還需要在以下領域開展更多工作以確保成功：· 明確了解應用性能要求· 基于業務要求及總成本，對公司重要的門限值進

50、行深入的技術研究· 預算周期以內和以外的升級要求· 第1、2和3級支持的責任· 利用運行部門能夠有效開展的主動工作量平衡的網絡管理信息的優先級及危急程度· 按要求進行培訓以便確保支持人員了解信息或告警，并可有效地處理所定義的情況· 確定事件關聯方法以確保不為同樣的問題生成多個故障票· 記錄特定信息或告警，以幫助識別屬于第1級支持的事件下表是面向鏈路使用情況的服務水平定義實例，幫助您明確了解誰負責發送主動網絡故障告警、如何確定故障以及故障影響。公司仍需開展上面定義的更多工作以確保成功。網絡領域/媒介檢測方法門限采取的行動園區LAN骨干及

51、分配鏈路五分鐘進行一次SNMP輪詢核心及分配鏈路上的RMON例外陷阱每五分鐘的使用率為50%通過例外陷阱實現90%的使用率向性能和容量電子郵件別名發送電子郵件通知安排小組組解決問題或制定升級計劃國內WAN鏈路五分鐘進行一次SNMP輪詢每五分鐘的使用率為75% 向性能電子郵件別名發送電子郵件通知安排工作組評估QoS要求或為重復出現的故障制定升級計劃外聯網WAN鏈路五分鐘進行一次SNMP輪詢每五分鐘的使用率為65%向性能和容量電子郵件別名發送電子郵件通知安排工作組評估QoS要求或為重復出現的故障制定升級計劃下表給出了設備容量和性能門限的服務水平定義，以確保您創建對防止出現網絡故障或可用性

52、問題有意義、很有用的門限。這是一個非常重要的領域，因為未檢測出的設備控制板資源問題可對網絡造成嚴重影響。設備主要信息檢測方法門限采取的行動Cisco 7500CPU、內存、顯卡五分鐘進行一次SNMP輪詢面向CPU的RMON通知五分鐘內的CPU使用率門限是75%，達到99%時，利用RMON發出通知五分鐘內的內存使用率門限是50%、顯卡使用率門限是99%向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃RMON CPU為99%，發放故障票并向第2級支持人員發送尋呼Cisco 2600CPU、內存、五分鐘進行一次SNMP輪詢五分鐘內的CPU使用率門限是75%五分鐘內的內存使用率

53、門限是50%向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃Catalyst?5000背板使用情況、內存五分鐘進行一次SNMP輪詢背板使用率門限是50%內存使用率門限是75%向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃LightStream?1010 ATMswitchCPU、內存五分鐘進行一次SNMP輪詢CPU使用率門限是65%內存使用率門限是50%向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃下表給出了端到端性能和容量的服務水平定義。這些門限值一般基于應用要求，但也可用于指示某類網絡性能或容量問題。因為測量網絡中

54、任意兩點間的性能需要大量資源并會帶來大量的網絡開銷，所以大多數有性能服務水平的公司都只創建少數性能定義。這些端到端的性能問題也可能出現在鏈路或設備容量門限中。我們建議根據地理位置制定一般定義。必要時需添加一些關鍵站點及鏈路。網絡領域/媒介測量方法門限采取的行動園區LAN無不會出現問題很難測量整個LAN基礎設施始終保證10-毫秒或更短的往返響應時間或向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃國內WAN鏈路目前只使用互聯網監視器（IPM）和ICMP回聲完成從SF到NY以及從SF到芝加哥的測量五分鐘內平均往返應答時間為75-毫秒向性能電子郵件別名工作組發送電子郵件通知，

55、以便評估 QoS要求或為重復出現的故障制定升級計劃舊金山到東京目前只使用互聯網監視器（IPM）和ICMP回聲完成從舊金山到布魯塞爾的測量五分鐘內平均往返應答時間為250-毫秒向性能電子郵件別名工作組發送電子郵件通知，以便評估 QoS要求或為重復出現的故障制定升級計劃舊金山到布魯塞爾目前只使用互聯網監視器（IPM）和ICMP回聲完成從舊金山到布魯塞爾的測量五分鐘內平均往返應答時間為175-毫秒向性能電子郵件別名工作組發送電子郵件通知，以便評估 QoS要求或為重復出現的故障制定升級計劃服務水平定義的最后一個領域是應用性能。因為服務器本身的性能和容量可能是應用性能的最大影響因素，所以應用性能的服務水

56、平定義通常由應用或服務器管理部門制定。網絡公司可通過為應用性能創建服務水平定義獲得巨大收益，因為：· 服務水平定義及測量有助于消除部門間的沖突。· 如果已為關鍵應用配置了QoS并將其他話務視為可選，則每個應用的服務水平定義都非常重要。如果您選擇創建并測量應用性能，最好不要測量服務器本身的性能。這將有助于將網絡故障與應用或服務器故障區分開來。使用運行在思科路由器上的探針或系統可用性代理軟件以及控制數據包類型及測量頻率的IPM控制。下表給出了用于應用性能的簡單服務水平定義。應用測量方法門限采取的行動企業資源規劃(ERP)應用TCP 端口1529布魯塞爾到SF使用IPM測量端口1

57、529往返性能來完成從布魯塞爾到舊金山的測量,布魯塞爾網關到SFO網關2五分鐘內平均往返應答時間為175-毫秒向性能電子郵件別名工作組發送電子郵件通知，以便評估問題或為重復出現的問題制定升級計劃RP應用TCP端口1529東京到SF使用IPM測量端口1529往返性能來完成從布魯塞爾到舊金山的測量布魯塞爾網關到SFO網關2五分鐘內平均往返應答時間為200-毫秒向性能電子郵件別名工作組發送電子郵件通知，以便評估問題或為重復出現的問題制定升級計劃客戶支持應用TCP端口1702悉尼到SF使用IPM測量端口1702往返性能來完成從悉尼到舊金山的測量悉尼網關到SFO網關1五分鐘內平均往返應答時間為250-毫

58、秒向性能電子郵件別名工作組發送電子郵件通知，以便評估問題或為重復出現的問題制定升級計劃第6步：收集測定標準和監控服務水平定義本身并無多大價值，只有在企業收集測定標準和監控是否成功時才能體現出價值。在定義關鍵服務水平的過程中要定義其測定辦法和匯報方式。測定服務水平可確定企業是否在實現目標，還可以確定導致可用性和性能問題的根本原因。另外，在選擇服務水平定義的測定方法時，還要考慮到定義的目的。有關更多信息請參閱“制定和維護服務水平協議（SLA）”。監控服務水平需要定期召開總結會議以對業務進行階段性的討論，通常每月召開一次這樣的會議。討論內容包括所有測定標準以及這些標準是否與目標一致。如果存在不一致，找出問題的根本原因，并