[轉]SLA

服務水平管理概述（SLA）

關鍵詞： SLA

 

服務水平管理概述

網絡公司一直以來都通過構建堅實的網絡基礎設施及主動處理每個業務問題來滿足不斷擴展的網絡要求。當業務異常中斷時，公司將構建新流程、管理功能或基礎設施來防止此類故障再次發生。然而，由於快速變更及日益增長的可用性要求，我們現在需要改進模式來預先防止意外故障並快速修復網絡。許多服務供應商和企業一直都試圖更好地定義服務水平以便實現商業目標。

關鍵成功因素

SLA的關鍵成功因素用來定義支持成功構建可獲得的服務水平及維護SLA的主要要素。要成爲合格的關鍵成功因素，流程或流程步驟必須可以改進SLA質量並從整體上提高網絡的可用性。關鍵成功因素還應具備可測量性，以便使企業能夠判斷：與定義的程序相比，它所取得的成功程度。

性能指標

性能指標提供了公司測量關鍵成功因素的機制。您通常需要每月審查一次，以確保服務水平定義或SLA運行良好。網絡運行小組及必要的工具組可實施以下測量標準。

注意：對於沒有SLA的公司，我們建議您同時實施服務水平定義、服務水平審覈及測量標準。

性能指標包括：

• 記錄的服務水平定義或SLA，包括可用性、性能、主動業務應答時間、排障目標及問題升級等。
• 月度網絡服務水平審覈會議，審覈對服務水平的執行情況並實施改進。
• 性能指標測量標準，包括可用性、性能、按優先級劃分的業務應答時間、按優先級劃分的排障時間以及其他可測量的SLA參數。

服務水平管理流程

面向服務水平管理的高級別流程主要包括兩組：

1.定義網絡服務水平

2.創建並維護SLA

實施服務水平管理

實施服務水平管理包括十六步，分爲以下兩個主要範疇：

• 定義網絡服務水平—步驟1-6
• 創建並維護SLA —步驟7-16

定義網絡服務水平

網絡管理人員需要定義支持、管理並測量網絡的主要規則。服務水平爲所有網絡人員提供目標並可用作整體業務質量的測量標準。您也可將服務水平定義用作網絡資源預算工具以及投資於更高服務質量的證據。它們還提供評估供應商及運營商的表現的方法。

如果沒有服務水平定義和測量，公司不可能制定明確的目標。服務是否滿意由用戶決定，在應用、服務器/客戶機運行或網絡支持方面並無明顯差距。由於企業對最終結果沒有把握，因此很難作預算。最終，網絡公司在提高網絡及支持模式方面都趨向於選擇被動應答，而非主動預防的方式。

我們建議採取以下步驟來構建並支持服務水平模式：

• 分析技術目標及限制因素。
• 確定可用性預算。
• 創建詳細記錄關鍵應用網絡特徵的應用資料庫。
• 定義可用性、性能衡量標準及通用術語。
• 創建服務水平定義，包括可用性、性能、業務應答時間、排障平均時、故障檢測、升級門限及上報途徑。
• 收集測量標準並監控服務水平定義。

第1步：分析技術目標及限制因素

開始分析技術目標和限制因素的最佳方式是集體討論或研究技術目標與要求。因爲這些人都有特定的業務目標，所以有時這有助於要求其他IT技術人員參與討論。技術目標包括可用性級別、吞吐量、抖動、延遲、應答時間、可用性要求、新特性的推出、新應用的推出、安全性、可管理性及成本等。隨後，公司應研究限制因素，以便使用可用資源實現這些目標。您可爲每個目標創建帶有對限制因素解釋的工作表。最初看似大多數目標都無法實現。隨後劃分目標的優先級或降低對仍可滿足商業要求的目標的期望值。

例如，您制定的可用性級別可能是99.999%，或每年5分鐘的故障停機時間。實現這一目標存在大量限制因素，如硬件的單點故障、遠程位置中的故障硬件的平均修復時間(MTTR)、運營商可靠性、預先故障檢測、高變更率及當前網絡容量限制等。因此，您需要將這個目標調節到更加易於實現的級別。下個章節中介紹的可用性模式可幫您制定現實的目標。

您可能也考慮在限制因素相對較少的網絡領域提供可用性。當網絡公司公佈業務的可用性標準時，公司中的各業務部門可能發現無法接受這個級別的可用性。這自然而然引發對SLA的討論，或爲可滿足商業要求的模式進行投資/做預算。

確定所有限制因素或風險的工作包括要實現技術目標。根據實現理想目標的最大風險或影響方面劃分限制因素的優先級。這可幫助公司確定網絡改進計劃的優先順序，並確定解決限制因素的難易程度。限制因素分三類：

• 網絡技術、故障恢復能力和配置
• 生命週期方案，包括：規劃、設計、實施和運行
• 當前的話務負載或應用行爲

網絡技術、故障恢復能力及配置限制因素是指與當前技術、硬件、鏈路、設計或配置相關的任何限制因素或風險。技術限制因素指技術本身造成的任何限制。例如，當前沒有一種技術允許冗餘網絡環境中實現少於1秒的聚合時間，而這恰恰是維持整個網絡上的話音連接的關鍵。另一個例子是數據通過地面鏈路時的原始速度，大約是100英里/毫秒。

網絡硬件故障恢復能力風險調查應集中在硬件拓撲、分級體系、模塊化、冗餘、MTBF及定義的路徑這幾方面。網絡鏈路限制因素應強調企業網絡鏈路及運行商連接。鏈路限制因素可能包括鏈路冗餘和多樣性、媒介限制、佈線基礎設施、本地環路連接性以及長距離連接性。設計限制因素與網絡的物理或邏輯設計相關，包括從爲設備可用空間到路由協議實施的可擴展性等各個方面。您應在配置、可用性、可擴展性、性能及容量方面考慮所有協議和媒介設計。動態主機配置協議（DHCP）、域名系統（DNS）、防火牆、協議轉換及網絡地址轉換等網絡業務限制因素也應列入考慮之列。

生命週期方案定義用於實現解決方案的統一部署、檢測和修復故障、防止容量或性能問題以及配置一致性和模塊化的網絡流程和管理。您需要認真考慮這個領域，因爲專業技術和流程通常是導致不可用性的最大影響因素。網絡生命週期指規劃、設計、實施和運行週期。在每個階段中，您都必須瞭解性能管理、配置管理、故障管理及安全性等網絡管理功能。思科NSA高可用性服務部（HAS）提供網絡生命週期評估服務，確定與網絡生命週期方案相關的當前網絡可用性限制因素。

當前的話務量或應用限制因素只是指當前話務和應用的影響。

不幸的是，許多應用都帶有大量需要慎重管理的限制因素。當前應用的抖動、延遲、吞吐量及帶寬要求通常帶有許多限制因素。編寫應用的方式也可能產生一些限制因素。彙編應用資料庫可幫您更好地瞭解這些問題；下文將介紹這一特性。研究當前的可用性、話務、容量及性能還可幫助網絡管理人員瞭解當前的服務水平目標及風險。這一工作常通過名爲網絡基準制定的流程來完成，該流程可幫您定義規定時段內（通常是一個月）的平均網絡性能、可用性或容量。這些信息通常用於容量規劃和趨勢分析，但也可用來了解服務水平問題。

下面的工作表使用了上述目標/限制因素方法來實現防止安全性***或拒絕服務***（DoS）的目標。您也可使用該工作表來決定可最大限度地減少安全性***的業務範圍。

風險或限制因素	限制因素類型	潛在影響
可用的DoS檢測工具無法檢測出全部DoS***類型。	技術/故障恢復能力	高
不具備對告警做出相應所需的人員和流程。	生命週期方案	高
當前網絡接入策略未加執行。	生命週期方案	一般
如果利用帶寬擁塞來發動***，則當前的低帶寬互聯網連接成爲限制因素。	網絡容量	一般
幫助防止***的當前安全性配置不完善。	技術/故障恢復能力	一般

第2步：確定可用性預算

可用性預算是期望在定義的兩點間出現的、理論上的網絡可用性。準確的理論信息可在多個方面發揮作用：

• 公司可將其視爲內部可用性目標，並且能夠立刻定義偏離並進行補救。
• 網絡規劃人員可使用這些信息來確定系統的可用性，以確保設計滿足商業要求。

造成不可用性或故障停機的因素包括軟硬件故障、電源和環境問題、鏈路或運營商故障、網絡設計、人爲錯誤或缺乏流程等。在評估網絡的整體可用性預算時，您必須嚴格評估上述的所有參數。

如果公司目前正在測量可用性，則可能不需要可用性預算。用可用性測量標準作爲基準來評估服務水平定義使用的當前服務水平。然而，您可將二者進行對比，以便了解潛在的理論可用性與實際測量結� ?淶牟罹唷�

可用性指產品或業務在需要時投入運行的可能性。參見以下定義：

a.可用性

¨1- (總的連接中斷時間) / (總服務連接時間)

¨1- [總和(業務中斷期間受影響的連接數量 X 業務中斷時間)] / (運行的連接數量X 運行時間)

b.不可用性

1-由以下因素造成的可用性或總的連接中斷時間：軟硬件故障、電源和環境問題、鏈路和運營商故障、網絡設計、用戶錯誤及流程故障等。

c.硬件可用性

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

冗餘的典型LAN環境中，適當的可用性是 99.99%，平均修復時間是4-小時。

d.軟件可用性

下一個需要研究的領域是軟件故障。出於測量的目的，思科將軟件故障定義爲由軟件錯誤引發的設備冷啓動。思科已經開發出許多流程來幫助瞭解軟件的可用性；然而，更新的版本尚需一段時間進行測量，並且我們認爲它的可用性不及一般的部署軟件。IOS 11.2版(18)等一般部署軟件經測量，證明具備99.9999%的可用性。這個數字是基於修復時間爲六分鐘（路由器重新裝載的時間）的思科路由器的實際冷啓動次數來計算的。採用不同版本的公司，可用性將隨着複雜性的增加、互操作性的增強以及排障時間的縮短略有降低。採用最新軟件版本的公司，不可用性將有所提高。不可用性的分配也相當廣泛，這意味着客戶將感覺到很高的不可用性或接近一般部署版本的可用性。

e.環境和電源的可用性

您還必須考慮環境和電源的可用性問題。環境問題與將設備保持在特定的運行溫度範圍內的冷卻系統的故障相關。當溫度大大超過技術指標時，許多思科設備只是停止運轉，而不會損害所有硬件。出於可用性預算的目的，您必須將電源考慮在內，因爲它是造成本領域中不可用性的主要原因。

雖然電源故障是造成網絡不可用性的重要原因，但對它的討論還是受到限制，這是因爲無法進行準確的、理論上的電源分析。企業必須基於所在地區的經驗、電源備份功能以及實施的流程，對其設備的電源可用性的大約測量結果進行評估，以確保爲所有設備提供具備一致質量的電源。

基於保守的估計，我們可以認爲配備了備用發電機、不間斷供電電源 (UPS)系統並採用合格電源實施流程的企業，可實現高達六個九（99.9999%）的可用性，而未配備這些系統的企業，其可用性僅爲 99.99%，或者說每年有36分鐘的故障停機時間。當然，您可根據公司的觀察或實際數據來調整這些數值，使其更真實地反映企業的具體情況。

f.鏈路或運營商故障

鏈路和運營商故障是影響WAN環境中的可用性的主要因素。切記：WAN環境只是同企業網絡遭遇同樣可用性問題的其他網絡，包括：軟硬件故障、用戶錯誤及電源故障等。

許多運營商網絡都已經開始對系統進行可用性預算，但獲得這些信息並不容易。切記，運營商的可用性保證級別很少基於或根本不基於實際可用性預算。這些保證級別有時只是用來提高運營商知名度的營銷和銷售方法。在某些情況下，這些網絡還公佈看似相互突出的可用性統計數據。切記，這些統計數據可能只適用於完全冗餘的核心網絡，而不作爲導致不可用性的因素（不可用性由本地環路接入引起），本地環路接入纔是WAN網絡中不可用性的主要因素。

對WAN環境進行可用性評估應基於實際的運營商信息以及WAN連接的冗餘級別。如果公司擁有多個大樓入口設施， 冗餘本地環路供應商、同步光網絡 (SONET)本地接入、以及分佈在多個地區的冗餘長途運營商，則WAN的可用性將得到明顯增強。

電話業務是WAN環境中、非冗餘網絡連接相當準確的可用性預算。使用類似於本文所描述的可用性預算方法進行測量，電話業務的端到端連接的可用性預算大約爲99.94%。這種方法業已成功應用於數據環境中，結果基本相同，目前正被用作服務供應商有線網絡中分組有線規程的預算。如果將該數值用於完全冗餘的系統，則我們可以假定，WAN可用性會接近99.9999%。當然，由於成本及可用性問題，目前很少有哪家公司部署了分佈在多個地區且完全冗餘的WAN系統，所以應使用適當的判斷方法測定這種功能。

LAN環境中不太可能發生鏈路故障，然而，規劃人員可能希望假定連接器斷開或鬆動會引發短時間的故障停機。對LAN網絡而言，保守的可用性估計約爲99.9999%，或大約30秒故障停機/年。

g.網絡設計

網絡設計是影響可用性的另一個主要因素。不可擴展的設計、設計錯誤及網絡聚合時間都會對可用性產生負面影響。

注意：出於本文的目的，我們將在下面的篇幅中描述不可擴展的設計或設計錯誤。

網絡設計被限定在可測量的數值上（基於網絡中導致話務重新路由的軟硬件故障）。這些數值通常被稱作“系統故障切換時間”，並且是系統中自治癒協議功能的影響因素。

使用與系統計算相同的方法便可計算可用性。然而，它只有在網絡故障切換時間滿足網絡應用要求時纔有效。如果故障切換時間可以接受，則不把它計算在內。如果故障切換時間不能接受，則計算時必須將其考慮在內，例如：估計或實際的故障切換時間爲30秒的環境中下的IP 話音(VoIP)。在這個例子中，用戶只是掛斷電話，並有可能重新撥叫。用戶肯定會將這30秒看作是非可用時段，但在可用性預算時卻未加考慮。

根據系統故障切換時間來計算不可用性時要着眼於理論的軟硬件可用性以及冗餘路徑，因爲故障切換將出現在這個領域。您必須瞭解可能發生故障並導致冗餘路徑中出現故障切換的設備數量，這些設備的MTBF以及故障切換時間。一個簡單的例子就是，冗餘的相同設備中，每臺設備的MTBF爲35433小時，故障切換時間爲30秒。用35，433除以8766（年平均小時數，包括閏年），我們可以看出該設備每四年出現一次故障。如果使用30秒作爲故障切換時間，我們便可以假設：由於故障切換，每臺設備每年平均停機7.5秒。由於用戶可能會跨兩條路徑，因此需要將此結果乘以2，即：每年15秒。當以秒/每年進行計算時，這個簡單系統中由於故障切換引起的可用性的計算結果爲99.99999785%。由於可能出現故障切換的網絡中的冗餘設備數量，在其他環境中，這個數字可能還要略高些。

h.用戶錯誤和流程

用戶錯誤和流程可用性問題是造成企業和運營商網絡中不可用性的主要原因。約80%的不可用性問題是由於無法檢測錯誤、變化故障及性能問題造成的。

公司在制定可用性預算時，不願意接受用戶錯誤和流程引發的不可用性是其他所有理論上的不可用性的四倍這一實施，然而，各種證據一致表明，這種情況存在於許多環境中。下面我們將詳細闡述不可用性的這個方面。

由於您無法從理論上計算由用戶錯誤和流程引發的不可用性數量，我們建議您在制定企業力求完美的可用性預算時不將其考慮在內。但企業必須瞭解其流程和專業技術水平中現在所面臨的可用性風險。透徹地瞭解了這些風險及抑制因素之後，網絡規劃人員便有可能將這些問題引發的一定數量的不可用性考慮在內。Cisco NSA HAS項目深入研究了這些問題，並可幫助企業瞭解由於流程、用戶錯誤或專業技術問題引發的不可用性。

i.制定最終的可用性預算

您可將以前定義的所有領域的可用性相乘來決定整個可用性預算。這種方法通常適用於任意兩點間的連接相類似的同機種環境，如：分級體系模塊化LAN環境或分級體系標準WAN環境等。

這下面的例子中，爲分級體系模塊化LAN環境確定了可用性預算。該環境爲所有網絡組件都配備了備用發電機和UPS系統，並對電源進行適當的管理。企業未使用VoIP，也不希望將軟件故障切換時間考慮在內。估算結果如下：

• 兩個端點間的硬件路徑可用性= 99.99%
• 使用GD軟件可靠性作爲基準的軟件可用性= 99.9999%
• 帶有備用系統的環境和電源可用性= 99.999%
• 考慮LAN 環境中的鏈路故障的可用性= 99.9999%
• 未將系統故障切換時間計算在內的可用性= 100%
• 認爲不存在用戶錯誤和流程缺陷的可用性= 100%

企業希望達到的最終可用性預算是：0.9999 X 0.999999 X0.999999 X 0.999999 = 0.999896，或99.9896%的可用性。如果我們將用戶或流程錯誤引發的潛在不可用性考慮在內，並假設其引發的不可用性是技術因素引發的可用性的四倍，則最終可用性預算是99.95%。

對這個例子的分析使我們瞭解到，LAN可用性在99.95%與99.989%之間。現在，這些數值能夠用作網絡公司的服務水平目標。可以測量系統中的可用性並確定上述六個領域分別引發的不可用性百分率來計算其他數值。這使公司能夠對供應商、運營商、流程和人員進行適當評估。這些數值也可用來設置業務期望值。如果您對99.95%與99.989%之間的可用性不滿意，可投資更多資源來獲得理想的可用性級別。

網絡管理人員瞭解每個特定可用性級別的故障停機時間將大有幫助。計算任何可用性級別的年故障停機時間（分鐘）的公式如下：

故障停機（分鐘）/年= 525600 —（可用性級別 X 5256）

如果可用性級別是99.95%，則結果是525600。(99.95 X 5256)，或者相當於222.8分鐘的故障停機。對於上述可用性定義，這等於網絡中所有業務連接的平均故障停機時間。

第3步：創建應用資料庫

應� 米柿峽飪砂鎦??綣?玖私獠⒍ㄒ迕扛鮎τ玫耐?綬?袼?揭?蟆Ｕ庥兄?諶繁Ｍ?繮С置扛鮎τ靡?蠹罷?逋?繅滴瘛５庇τ沒蚍?衿髯櫓賦鐾?鞝嬖諼侍饈保?τ米柿峽飠箍捎米魍?綬?裰С值氖槊婊?肌Ｗ詈螅?τ米柿峽飪山?閱薌翱捎眯緣扔τ靡?笥胝媸檔耐?繅滴衲勘昊虻鼻跋拗埔蛩亟?卸員齲?吹鶻諭?繅滴衲勘輳?蠱漵肷桃狄?蟊３忠恢隆Ｕ獠喚齠苑?袼?焦芾硨苤匾???葉哉?鐾?縞杓埔蠶嗟敝匾?�

每次向網絡中添加新應用時都應創建應用資料庫。您還可能需要在IT應用部門、服務器管理部門以及組網部門間達成協議，以便爲現有及全新業務創建應用資料庫，完成用於商業應用及系統應用的應用資料庫。商業應用可能包括電子郵件、文件傳輸、Web瀏覽、醫療圖象處理或製造等。系統應用可能包括軟件分發、用戶鑑權、網絡備份及網絡管理等。

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

• 應用名稱
• 應用類型
• 新應用
• 業務重要性
• 可用性要求
• 使用的協議和端口
• 估計的用戶帶寬 (kbps)
• 用戶數量和位置
• 文件傳輸要求（包括時間、量及端點）
• 網絡故障停機影響
• 延遲、抖動及可用性要求

應用資料庫的目標是瞭解應用的商業要求、業務關鍵性以及帶寬、延遲及抖動等網絡要求。此外，網絡公司還應瞭解網絡故障停機的影響。在某些情況下，您可能需要重啓應用或服務器，這將大幅度延長總的應用故障停機時間 。完成應用資料庫後，您可將所有網絡功能進行對比，並幫助調節網絡服務水平，使其與商業和應用要求相一致。

第4步：定義可用性及性能標準

可用性及性能標準爲企業制定業務期望值。可根據不同網絡區域或特定應用進行定義這些標準。還可以確定往返延遲、抖動、最大吞吐量、帶寬承諾及總體可擴展性等方面的性能。此外，爲了制定業務期望值，企業還應謹慎定義每個業務標準，以便使致力於網絡工作的用戶及IT工作組能夠全面瞭解業務標準以及他們與應用或服務器管理要求的關係。用戶及IT工作組還應瞭解如何測量業務標準。

以前服務水平定義步驟的結果可以幫助制定標準。這時，網絡公司應明確瞭解當前網絡所面臨的風險和限制因素及應用行爲，並進行理論上的可用性分析或制定可用性基準。

1. 定義業務標準適用的地理區域或應用領域，可能包括園區LAN、本國WAN、外聯網及合作伙伴連接等。在某些情況下，企業在相同區域內的服務水平目標可能有所不同。這對企業或服務器供應商來說並不罕見。這時，它們通常基於各自的業務要求制定不同的服務水平標準。這些在同一地理區域或服務區域中的標準有金牌、銀牌和銅牌之分。
2. 定義業務標準參數。可用性及往返延遲是最常見的網絡業務標準。根據需要，還可以包括最大吞吐量、最低帶寬承諾、抖動、接受的錯誤率以及可擴展性功能。當審覈用於測量方法的業務參數時要特別謹慎。無論參數是否包括在SLA中，公司都應考慮出現問題或業務不一致性時，如何測量並證明業務參數的可行性。

完成對業務領域和業務參數的定義後，您可使用以前步驟獲得的信息來構建業務標準圖。企業還需要定義可能使用戶和IT工作組產生混淆的區域。例如，往返ping的最長應答時間與在遠程位置單擊回車鍵啓動特定應用的

最長應答時間有很大區別。下表列出了美國採用的性能目標：

網絡區域	可用性目標	管理方法	平均網絡應答時間目標	可接受的最常應答時間	應答時間管理方法
LAN	99.99%	受影響的用戶時間	5毫秒內	10 毫秒	往返ping應答
WAN	99.9%	受影響的用戶時間	100毫秒內(往返ping)	150 毫秒	往返ping應答
關鍵WAN及外聯網	99.95%	受影響的用戶時間	100毫秒內(往返ping)	150 毫秒	往返ping應答

第5步：定義網絡業務

這是實現基本的服務水平管理的最後一步；它定義您實施用於實現服務水平目標的被動/主動流程和管理功能。最終文件通常被稱作“運行支持計劃”。大多數應用支持計劃只包括被動支持要求。在高可用性環境中，公司必須考慮採用主動的管理流程，以便在網絡故障發生前對其進行隔離並加以處理解決。總的來說，最終文件應：

• 描述用於實現服務水平目標的被動和主動流程
• 介紹業務流程的管理方式
• 介紹測量業務目標和業務流程的方式

本部分將描述許多服務供應商和企業均需考慮的主動和被動業務定義的實例。構建服務水平定義的目標是創建滿足可用性及性能目標的業務。爲了實現上述目標，公司必須構建業務，並謹記當前的技術限制因素、可用性預算及應用資料庫。特別是，公司應定義並構建始終能夠在可用性模式規定的時間內快速確定並排除故障的業務。公司還必須定義可快速識別並解決潛在業務問題的業務，如果忽略這些問題，將對可用性及性能產生負面影響。

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

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

被動服務水平定義

以下的服務水平領域通常使用幫助臺數據庫統計數據進行測量並定期審計。下表顯示企業故障嚴重程度的實例。請注意：此表不包括處理新業務請求的方式，這項工作可通過SLA或其他應用資料庫編制及性能假設分析來完成。如果通過相同的支持流程進行處理，新業務請求可以數據嚴重級別5。

嚴重級別1	嚴重級別2	嚴重級別3	嚴重級別4
嚴重的業務影響 LAN用戶或服務器部分停機 嚴重的WAN站點故障停機	網絡功能的丟失或降級對業務造成嚴重影響，可能需要運行應變措施 園區LAN故障停機； 5-99名用戶受到影響 國內WAN站點故障停機 國際WAN站點故障停機 嚴重影響性能	某些特定的網絡功能丟失或降級，如：冗餘丟失等 園區LAN性能受到影響 LAN冗餘丟失	對企業無業務影響的功能查詢或故障

完成問題嚴重性級別定義之後，定義或研究創建業務應答定義的支持流程。總的來說，業務應答定義要求採用分級支持結構，以及幫助臺軟件支� 窒低忱蠢?黴收掀備?儻侍狻Ｍ?被褂ξ?扛鮎畔燃豆收系撓Υ鶚奔浜徒餼鍪奔洹?從畔燃痘?值暮艚惺?懇約壩Υ鸞餼鮒柿恐貧ú飭勘曜肌６ㄒ逯С至鞽炭砂鎦?ㄒ騫?灸誆棵扛鮒С旨侗鸕哪勘曇捌淙撾裼朐鶉巍Ｕ庥兄?詮?玖私庥糜諉扛鮒С旨侗鸕淖試匆?蠹白ㄒ導際跛?健Ｏ滷砭倮?得髁朔旨噸С紙峁辜捌湮侍飩餼鮒傅莢?頡�

支持級別	職責	目標
第1級支持	專職幫助臺支持 接聽支持電話、發放故障票、15分鐘內解決問題、記錄故障票並上報到第2級支持	解決40%的入局呼叫
第2級支持	隊列監控、網絡管理、工作站管理 爲確定的軟件故障發放故障票 實施 接聽第1級、供應商的電話，並上報到第3級支持 對呼叫負責，直到排障爲止	在第2級解決所有呼叫
第3級支持	必須立刻爲第2級提供優先級爲1的全部故障所需的支持 同意在SLA解決期限內幫助解決所有第2級未排除的故障	不直接對故障負責

下一步是確定業務應答及排障業務定義。它爲如何快速排障（包括硬件更換在內）制定了目標。爲這個領域制定目標是非常重要的，因爲業務應答及恢復時間直會接影響網絡的可用性。問題解決時間也要與可用性預算保持一致。如果在制定可用性預算時未將大量高嚴重級別的故障考慮在內，則公司隨後將需開展大量工作來了解此類故障的根源及可能的彌補方法。詳見下表：

問題嚴重級別	幫助臺應答	第2級應答	現場第2級	硬件更換	解決問題
1	立刻上報到第2級，網絡運行部經理	5分鐘	2小時	2小時	4小時
2	立刻上報到第2級，網絡運行部經理	5分鐘	4小時	4小時	8小時
3	15分鐘	2小時	12小時	24小時	36小時
4	15 分鐘	4小時	3 天	3天	6天

除業務應答及業務排障外，還需制定上報規定。上報表有助於確保將可用資源集中用於解決嚴重影響業務的問題。總的來說，如果分析員集中精力解決問題時，他們很少重視利用其他資源來解決問題。定義何時需要其他資源有助於促進管理層對問題的認識，並有助於促成未來的主動測量或預防性測量。詳見下表：

過去的時間	嚴重級別1	嚴重級別2	嚴重級別3	嚴重級別4
5分鐘	網絡運行部經理、第3級支持、聯網部主管
1小時	及時通知網絡運行部經理、第3級支持、聯網部主管	及時通知網絡運行部經理、第3級支持、聯網部主管
2 小時	上報副總裁、及時通知主任及網絡運行部經理
4 小時	向副總裁、主管、運行部經理、第3級支持提交根源分析，向CEO通知未排除的故障	上報副總裁，及時通知主管及網絡運行部經理
24 小時			網絡運行部經 理
5 天				網絡運行部經理

迄今爲止，服務水平定義始終集中在運行支持部門如何在問題發生後對其採取被動措施上。運行部門多年前便制定出了包括上述相似內容的運行支持計劃。然而，該方案中忽略了部門如何識別問題以及他們將識別哪些故障等內容 。比較成熟的網絡公司試圖制定預先確定的網絡問題百分率目標來解決這個問題，而不是通過用戶故障報告或投訴來被動地確定故障。

下表列出了公司對主動支持功能和被動支持功能的整體測量目標。

網絡領域	主動故障識別率	被動故障識別率
LAN	80 %	20 %
WAN	80 %	20 %

這爲確定更多的主動支持定義開了一個好頭，因爲它測量起來很簡單、也很容易，尤其在主動檢測工具可自動生成故障票。 這還有助於將網絡管理工具/信息集中用於主動排障，而不是在故障發生後被動地查找根源。然而，這種方法的主要問題在於它無法定義主動支持要求。這通常會造成主動支持管理功能間的差距並導致更大的可用性風險。

主動服務水平定義

更全面的制定服務水平定義方法包括，更詳細地解釋如何7 x 24全天候地監控網絡，以及運行部門如何7 x 24全天候對已定義的網絡管理站（NMS）門限做出響應。鑑於管理信息站（MIB）數量的不確定性以及提供MIB的網絡管理信息數量與網絡的運行情況相關，因此這看上去是一項無法完成的任務。同時，完成這項任務需大量資源且代價非常高昂。不幸的是，這些缺點大大妨礙了我們對主動業務定義的實施，而這種實施從本質上來說非常簡單輕鬆，且只適用於可用性或性能風險極大的網絡。如果公 司隨後看到了基本主動業務定義的價值，那麼只要採用分階段實施的方法，就可以逐漸添加更多變量，但不會對業務產生重大影響。

所有運行支持方案中均應包括第一個領域的主動業務定義。該業務定義只是簡單闡述運行部門如何識別不同網絡區域中的網絡或鏈路故障並對此做出響應。沒有這個定義（或管理支持），公司可能遇到支持不穩定、無法達到用戶期望等問題，最終會降低網絡可用性。

下表顯示了公司如何針對鏈路/設備故障制定服務定義。該實例中的企業在每天的不同時段及網絡區域方面有着不同的通知和響應要求。

網絡設備或鏈路故障	檢測方法	5 x 8 通知	7 x 24 通知	5 x 8 排障	7 x 24 排障
核心LAN	SNMP設備和鏈路輪詢陷阱	NOC創建故障票、向負責LAN的人員發出尋呼	自動向負責LAN的人員發出尋呼、 LAN負責人員爲核心LAN隊列創建故障票	NOC在15分鐘內派出LAN分析員、根據業務應答定義解決問題	立刻研究並排除優先級1和2的故障、優先級3和4的故障排隊等候次日上午排除
國內 WAN	SNMP設備和鏈路輪詢陷阱	NOC創建故障票、向負責WAN的人員發出尋呼	自動向負責WAN的人員發出尋呼、 WAN負責人員爲核心WAN隊列創建故障票	NOC在15分鐘內派出WAN分析員、根據業務應答定義排障	立刻研究並排除優先級1和2的故障、優先級3和4的故障排隊等候次日上午排除
外聯網	SNMP設備和鏈路輪詢陷阱	NOC創建故障票、向負責合作伙伴的人員發出尋呼	自動向負責合作伙伴的人員發出尋呼，合作伙伴負責人員爲合作伙伴隊列創建故障票	NOC在15分鐘內派出合作伙伴分析員、根據業務應答定義排障	立刻研究並排除優先級1和2的故障、優先級3和4的故障排隊等候次日上午排除

其餘的主動服務水平定義可分成兩類：網絡錯誤和容量/性能問題。只有少數網絡公司擁有這兩個領域的服務水平定義。因此，這些問題常被忽視或無法得到統一處理。這對某些網絡環境的影響可能不大，但高可用性環境一般都需要一致的主動業務管理。

網絡公司希望實現主動業務定義的原因很多，主要是他們尚未基於可用性風險、可用性規劃及應用問題對主動業務定義進行要求分析，致使主動業務定義的要求及優勢不明確，這主要是因爲需要更多的資源。

第二個原因是要平衡能夠利用現有及新定義的資源來實施的主動管理數量。但生成這些告警就可能對可用性或性能產生嚴重影響。您還必須考慮事件關聯管理或流程，以確保不就同樣的問題生成多個主動故障票。最後一個原因在於：創建一組全新的主動告警經常會生成以前未檢測出的初始信息流。運行部門必須爲解決這些最初問題以及增加短期資源做好準備，以便解決這些以前未檢測出的問題。

第一類主動服務水平定義是網絡錯誤。網絡錯誤還可細分爲系統錯誤（包括軟硬件錯誤）、協議錯誤、媒介控制錯誤、準確性錯誤及環境警告。制定服務水平定義首先要要大體瞭解如何檢測出此類問題、由誰負責解決問題以及故障的影響。必要時在服務水平定義中添加特定的信息或問題。您可能還需要在以下領域開展更多工作以確保成功定義：

• 第1、2和3級支持的責任
• 利用運行部門能夠有效開展的主動工作量來平衡網絡管理信息的優先級
• 按要求進行培訓以便確保支持人員可以有效地處理定義的告警
• 確定事件關聯方法以確保不爲同樣的問題生成多個故障票
• 記錄特定信息或告警，以幫助識別屬於第1級支持級別的事件

下表是用於網絡錯誤的服務水平實例，幫助您明確瞭解誰負責發送主動網絡故障告警、如何確定故障以及故障影響。根據上文所述，公司尚需開展更多工作以確保成功。

故障類型	檢測方法	門限	採取的行動
軟件故障（軟件造成的故障停機）	每天都使用系統日誌查看程序審覈系統日誌信息 由第2級支持完成	發生任何優先級0、 1和2的故障 發生100多起優先級3（或更高）的故障	審查問題、創建故障票並在新問題出現或問題需要特別注意時派出人員解決
硬件故障（硬件造成的故障停機）	每天都使用系統日誌查看程序審覈系統日誌信息 由第2級支持完成	任何第0、 1和2優先級別的故障的發生 發生100多起優先級3（或更高）的故障	審覈問題、創建故障票並在新問題出現或問題需要特別注意時派遣人員解決
協議錯誤(只適用於IP路由協議)	使用系統日誌查看程序每日審覈系統日誌信息 由第2級支持完成	發生任何優先級0、 1和2的故障 發生100多起第3優先級（或更高）故障	審覈問題、創建故障票並在新問題出現或問題需要特別注意時派出人員解決
媒介控制故障 (只限於FDDI、POS及快速以太網)	使用系統日誌查看程序每日審覈系統日誌信息 由第2級支持完成	任何第0、 1和2優先級別的故障的發生 發生100多起優先級3（或更高）的故障	審覈問題、創建故障票並在新問題出現或問題需要特別注意時派出人員解決
環境信息（電源和溫度）	使用系統日誌查看程序每日審覈系統日誌信息 由第2級支持完成	任何信息	對新問題創建故障票並派遣相關人員解決問題
準確度錯誤（鏈路輸入錯誤）	每五分鐘進行一次SNMP輪詢 NOC受理的門限事件	輸入或輸出錯誤 任何鏈路上、每5分鐘出現一次錯誤	對新問題創建故障票並派出第2級支持人員解決問題

另一類主動服務水平是性能及容量。真正的性能和容量管理包括例外情況管理、基準制定與趨勢分析以及假設分析。服務水平定義只定義需要調查或更新的性能及容量的例外門限以及平均門限。隨後，可以以某種方式將這些門限應用到三種性能和容量管理流程中。

容量及性能服務水平定義可細分成幾個類別：網絡鏈路、網絡設備、端到端性能及應用性能。制定這些領域的服務水平定義需要具備與設備容量、媒介容量、QoS特徵及應用要求的特定領域相關的淵博技術知識。出於這個原因，我們建議網絡設計師通過供應商輸入的信息制定與性能和容量相關的服務水平定義。

與網絡錯誤相似，爲容量和性能制定服務水平定義首先應大體瞭解如何檢測此類故障、由誰負責排障以及故障的影響。必要時向服務水平定義中添加特定的信息或問題。您可能還需要在以下領域開展更多工作以確保成功：

• 明確瞭解應用性能要求
• 基於業務要求及總成本，對公司重要的門限值進行深入的技術研究
• 預算週期以內和以外的升級要求
• 第1、2和3級支持的責任
• 利用運行部門能夠有效開展的主動工作量平衡的網絡管理信息的優先級及危急程度
• 按要求進行培訓以便確保支持人員瞭解信息或告警，並可有效地處理所定義的情況
• 確定事件關聯方法以確保不爲同樣的問題生成多個故障票
• 記錄特定信息或告警，以幫助識別屬於第1級支持的事件

下表是面向鏈路使用情況的服務水平定義實例，幫助您明確瞭解誰負責發送主動網絡故障告警、如何確定故障以及故障影響。公司仍需開展上面定義的更多工作以確保成功。

網絡領域/媒介	檢測方法	門限	採取的行動
園區LAN骨幹及分配鏈路	五分鐘進行一次SNMP輪詢 核心及分配鏈路上的RMON例外陷阱	每五分鐘的使用率爲50% 通過例外陷阱實現90%的使用率	向性能和容量電子郵件別名發送電子郵件通知< /p> 安排小組組解決問題或制定升級計劃
國內WAN鏈路	五分鐘進行一次SNMP輪詢	每五分鐘的使用率爲75%	向性能電子郵件別名發送電子郵件通知 安排工作組評估QoS要求或爲重複出現的故障制定升級計劃
外聯網WAN鏈路	五分鐘進行一次SNMP輪詢	每五分鐘的使用率爲65%	向性能和容量電子郵件別名發送電子郵件通知 安排工作組評估QoS要求或爲重複出現的故障制定升級計劃

下表給出了設備容量和性能門限的服務水平定義，以確保您創建對防止出現網絡故障或可用性問題有意義、很有用的門限。這是一個非常重要的領域，因爲未檢測出的設備控制板資源問題可對網絡造成嚴重影響。

設備	主要信息	檢測方法	門限	採取的行動
Cisco 7500	CPU、內存、顯卡	五分鐘進行一次SNMP輪詢 面向CPU的RMON通知	五分鐘內的CPU使用率門限是75%，達到99%時，利用RMON發出通知五分鐘內的內存使用率門限是50%、顯卡使用率門限是99%	向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃RMON CPU爲99%，發放故障票並向第2級支持人員發送尋呼
Cisco 2600	CPU、內存、	五分鐘進行一次SNMP輪詢	五分鐘內的CPU使用率門限是75%五分鐘內的內存使用率門限是50%	向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃
Catalyst?5000	背板使用情況、內存	五分鐘進行一次SNMP輪詢	背板使用率門限是50% 內存使用率門限是75%	向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃
LightStream?1010 ATM switch	CPU、內存	五分鐘進行一次SNMP輪詢	CPU使用率門限是65% 內存使用率門限是50%	向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃

下表給出了端到端性能和容量的服務水平定義。這些門限值一般基於應用要求，但也可用於指示某類網絡性能或容量問題。因爲測量網絡中任意兩點間的性能需要大量資源並會帶來大量的網絡開銷，所以大多數有性能服務水平的公司都只創建少數性能定義。這些端到端的性能問題也可能出現在鏈路或設備容量門限中。我們建議根據地理位置制定一般定義。必要時需添加一些關鍵站點及鏈路。

網絡領域/媒介	測量方法	門限	採取的行動
園區LAN	無 不會出現問題 很難測量整個LAN基礎設施	始終保證10-毫秒或更短的往返響應時間或	向性能和容量電子郵件別名工作組發送電子郵件通知以便解決問題或制定升級計劃
國內WAN鏈路	目前只使用互聯網監視器（IPM）和ICMP回聲完成從SF到NY以及從SF到芝加哥的測量	五分鐘內平均往返應答時間爲75-毫秒	向性能電子郵件別名工作組發送電子郵件通知，以便評估 QoS要求或爲重複出現的故障制定升級計劃
舊金山到東京	目前只使用互聯網監視器（IPM）和ICMP回聲完成從舊金山到布魯塞爾的測量	五分鐘內平均往返應答時間爲250-毫秒	向性能電子郵件別名工作組發送電子郵件通知，以便評估 QoS要求或爲重複出現的故障制定升級計劃
舊金山到布魯塞爾	目前只使用互聯網監視器（IPM）和ICMP回聲完成從舊金山到布魯塞爾的測量	五分鐘內平均往返應答時間爲175-毫秒	向性能電子郵件別名工作組發送電子郵件通知，以便評估 QoS要求或爲重複出現的故障制定升級計劃

服務水平定義的最後一個領域是應用性能。因爲服務器本身的性能和容量可能是應用性能的最大影響因素，所以應用性能的服務水平定義通常由應用或服務器管理部門制定。網絡公司可通過爲應用性能創建服務水平定義獲得巨大收益，因爲：

• 服務水平定義及測量有助於消除部門間的衝突。
• 如果已爲關鍵應用配置了QoS並將其他話務視爲可選，則每個應用的服務水平定義都非常重要。

如果您選擇創建並測量應用性能，最好不要測量服務器本身的性能。這將有助於將網絡故障與應用或服務器故障區分開來。使用運行在思科路由器上的探針或系統可用性代理軟件以及控制數據包類型及測量頻率的IPM控制。

下表給出了用於應用性能的簡單服務水平定義。

應用	測量方法	門限	採取的行動
企業資源規劃(ERP)應用 TCP 端口1529 布魯塞爾到SF	使用IPM測量端口1529往返性能來完成從布魯塞爾到舊金山的測量,布魯塞爾網關到SFO網關2	五分鐘內平均往返應答時間爲175-毫秒	向性能電子郵件別名工作組發送電子郵件通知，以便評估問題或爲重複出現的問題制定升級計劃
RP應用 TCP端口1529 東京到SF	使用IPM測量端口1529往返性能來完成從布魯塞爾到舊金山的測量布魯塞爾網關到SFO網關2	五分鐘內平均往返應答時間爲200-毫秒	向性能電子郵件別名工作組發送電子郵件通知，以便評估問題或爲重複出現的問題制定升級計劃
客戶支持應用 TCP端口1702 悉尼到SF	使用IPM測量端口1702往返性能來完成從悉尼到舊金山的測量悉尼網關到SFO網關1	五分鐘內平均往返應答時間爲250-毫秒	向性能電子郵件別名工作組發送電子郵件通知，以便評估問題或爲重複出現的問題制定升級計劃

第6步：收集測定標準和監控

服務水平定義本身並無多大價值，只有在企業收集測定標準和監控是否成功時才能體現出價值。在定義關鍵服務水平的過程中要定義其測定辦法和彙報方式。測定服務水平可確定企業是否在實現目標，還可以確定導致可用性和性能問題的根本原因。另外，在選擇服務水平定義的測定方法時，還要考慮到定義的目的。有關更多信息請參閱“制定和維護服務水平協議（SLA）”。

監控服務水平需要定期召開總結會議以對業務進行階段性的討論，通常每月召開一次這樣的會議。討論內容包括所有測定標準以及這些標準是否與目標一致。如果存在不一致，找出問題的根本原因，並進行改進。討論內容還應包括目前的計劃和具體案例的進展情況。

制定和維護服務水平協議

服務水平定義是理想的組成部分，因爲它有助於在整個企業範圍內建立一個統一的服務質量和提高可用性。下一步是作爲一項改進成果的服務水平協議，這是因爲通過這一步可以將企業目標和成本要求直接與業務質量相協調統一。然後，合理計劃的服務水平協議可以作爲一種模式來提高效率、質量，並通過保持清晰的業務網絡維護和故障排除過程來協調用戶與支持部門之間的關係。

服務水平協議具有以下幾方面的優點：

• � ?袼?叫?榻?⒘慫?揭滴裨鶉沃疲?簿褪撬擔?沒Ш陀τ貌棵哦醞?繅滴穸加性鶉巍Ｈ綣??講徊扇⌒卸?次?嚀逡滴窠?⒁桓齜?袼?叫?椋換蠆揮臚?綺棵啪鴕滴裼跋煳侍飩?薪渙鰨?敲矗??絞導噬隙運?⑸?奈侍舛加性鶉巍�

服務水平協議有助於確定標準工具和滿足業務要求所需的資源。不通過服務水平協議來確定工作人數和所使用的工具通常只能人爲地估計。在這種情況下，從事某一業務的工作人員可能過剩並導致過多支出；也可能不足而導致無法滿足企業目標的要求。調整服務水平協議有助於實現最優化的合理分配。

以文件形式存在的服務水平協議提供一個更簡單準確的方法來確定業務級別的期望值。

定義了業務級別之後，我們推薦採用以下步驟來編制服務水平協議：

7.滿足服務水平協議的必要條件。

8. 確定服務水平協議所涉及的有關各方。

9. 確定業務組分。

10. 瞭解用戶業務需求和目標。

11. 確定每個部門所需的服務水平協議。

12. 選擇服務水平協議的格式。

13. 成立服務水平協議工作組。

14. 召開工作組會議並草擬服務水平協議。

15. 商討服務水平協議。

16. 測定和監控服務水平協議是否符合要求。

第7步：滿足服務水平協議的必要條件

IT 服務水平協議編制領域的專業人士確定了服務水平協議成功的3個必要條件。遺憾的是，不能滿足這些客觀要求的企業在服務水平協議的進程中可能會遇到問題，這些企業還應考慮服務水平協議流程中的潛在問題。如果聯網部門可以定義滿足基本業務要求的業務級別，即使未執行服務水平協議，也不會帶來害處。

以下是服務水平協議流程的必要條件：

• 企業必須具有面向業務的文化。

企業必須將用戶需要放在首位，還要遵守優先權自上而下的業務承諾以完全瞭解用戶需要和想法。

進行用戶滿意度調查，並開展以用戶爲中心的業務計劃。

另外一個業務指標是企業將公司目標確定爲業務或用戶支持滿意度。這種情況是很普遍的，這是因爲，IT部門現在與整個企業的成功密切相關。

由於服務水平協議流程主要是基於用戶需要和企業需求來改進業務，所以服務文化就顯得格外重要。如果企業在過去未執行這一步驟，那麼在進行服務水平協議方面的工作時會有一定的難度。

• 所有 IT 活動必須以用戶和業務計劃爲中心。

公司的遠景規劃或工作說明必須與用戶和業務計劃相一致，然後爲包括服務水平協議在內的所有 IT 活動指引方向。經常出現的情況是，企業已部署好網絡來滿足特定要求，而聯網部門卻看不到目標或後續業務的需求。在這種情況下，已經爲網絡事先做好了預算，這種預算可能遠遠高於或遠遠低於當前的需要，從而導致最終的失敗。

在用戶和業務計劃與 IT 活動相一致的情況下，聯網部門可以更容易地與新業務應用的部署、新業務和其他業務需求保持一致。業務關係和實現公司目標的共同關注焦點都非常清楚，並且所有部門都團結協作。

• 您必須努力滿足服務水平協議流程和合同方面的要求。

首先必須要努力掌握服務水平協議流程以編制有效的協議。

其次，必須遵循合同的業務要求。不要奢望無需每個參與者的投入和承諾就能建立一個具有高效力的服務水平協議。這種承諾還必須來自管理部門和與服務水平協議流程有關的所有人員。

第8步：確定服務水平協議所涉及的有關各方

企業級網絡服務水平協議在很大程度上依賴於網絡單元、服務器管理單元、幫助臺支持、應用單元和用戶需求。通常情況下，服務水平協議流程涉及到每個領域的管理部門。在企業指定基本的被動支持服務水平協議時，此方案起到很好的作用。要求更高可用性的企業在 服務水平協議流程中可能需要技術支持以處理這方面的問題（如：可用性預算、性能限制、應用信息管理和主動管理能力）。對於主動管理服務水平協議方面的問題，我們建議成立一個由網絡設計師和應用設計師組成的技術小組。技術支持小組可以對網絡可用性和運行能力、實現具體目標所需要的資源進行非常準確的計算。服務供應商的服務水平協議通常不需要用戶的參與，這是因爲，編制服務水平協議的唯一目的是獲得超過其他服務供應商的競爭優勢。在某些情況下，上層管理以高可用性和高性能級別來編制這些服務水平協議以宣傳服務，併爲內部員工提供內部目標。其他供應商將注意力集中在改進可用性的技術方面上，他們通過編制內部測定和管理的高效業務級別定義來實現這一點。在其他情況下，這兩方面的努力會同時發生，但沒必要結合在一起，或爲了同一目標而進行。

服務水平協議中所涉及各方的選擇將基於服務水平協議的目標。可能的一些目標如下：

• 實現被動支持業務目標
• 通過定義主動的服務水平協議來獲得最高級別的可用性
• 宣傳或推銷一種服務產品

第9步：確定服務單元

主要業務和支持服務水平協議通常由許多部分組成，其中包括支持級別、測定辦法、服務水平協議調和的上報途徑和總體預算事宜。

用於高可用性環境的業務單元應包括主動業務定義和被動目標。

其他詳細內容包括以下方面：

• 現場支持正常工作時間和非工作時間的服務程序
• 優先權定義，包括問題類型、最遲處理問題的時間、解決問題的最長時間和上報程序。
• 按重要程度排列的所支持產品或業務
• 專業技術期望支持、性能級別期望值、狀態報告和故障解決方案的用戶責任
• 地理或業務單元支持級別問題和要求
• 故障管理方法和程序 (呼叫跟蹤系統)
• 幫助臺目標
• 網絡故障監測和業務響應
• 網絡可用性測定和報告
• 網絡容量、性能測定和報告
• 衝突解決程序
• 爲執行服務水平協議提供資金

網絡應用或服務的服務水平協議可根據用戶組要求和業務重要性而有其他要求。網絡部門必須仔細聽取這些業務要求並開發適合整體支持結構的專門解決方案。企業不應將主要業務只針對於某些個人或部門，這一點非常重要，因此對總體支持文化的適應也就很重要。在多數情況下，這些附加要求可以納入“解決方案”類中。這樣的例子包括基於業務需求的白金級、金級和銀級解決方案。有關具體業務需求，請參閱以下示例。

注意：爲了維護和改進統一的業務文化，支持結構、上報途徑、幫助臺程序、測定和優先權定義在很大程度上應是相同的。

• 寬帶要求和 burst（突發）能力
• 性能要求
• 服務質量 要求和定義
• 建立解決方案標準的可用性要求和冗餘度
• 監控和報告要求、方法和流程
• 爲應用和業務單元升級標準
• 爲滿足預算外要求融資或交叉付費辦法。

例如，您可以爲 WAN 站點連接創建解決方案類別。向站點提供具有雙路 T1 業務的白金級解決方案。由不同的運營商分別提供一條T1 線。站點應配置2個路由器以保證T1 或路由器發生故障時站點不會發生停機現象。金級業務有2個路由器，但是將使用備份“幀中繼”。該解決方案在停機時段內提供有限的寬帶。銀級解決方案只有一個路由器和一套載波業務。針對不同優先級別考慮這些解決方案以確定故障票。.如果停機要求優先級爲1 或 2的故障票，有些企業可能需要白金級或金級解決方案。用戶企業然後可以投資購買所要求的業務級別。下表說明了提供3種業務級別的企業，這些級別基於外聯網連接的業務需求。

解決方案	白金級	金級	銀級
設備	WAN連接冗餘路由器	核心站點備份冗餘路由器	無設備 冗餘
WAN	冗餘 T1連接，多載波	具有“幀中繼”備份的T1連接	無 WAN 冗餘
寬帶要求與突發 Burst	具有用於burst （突發）的負載共享冗餘 T1	非負載共享“幀中繼”（只用於關鍵業務應用）;“幀中繼” 64K（只用於CIR）	最多爲：T1
性能	一直爲100.ms往返響應時間或小於此值。	響應時間 100ms 或小於期望值的99.9%	響應時間100 ms 或少於期望值的 99%
可用性要求	99.99%	99.95%	99.9%
停機時幫助臺優先權	優先權 1：重要業務服務故障	優先權 2：會影響業務的服務故障	優先權 3： 業務連接故障

第10步：瞭解客戶業務需求和目標

此步驟給予服務水平協議編制人員很大的信任。通過了解各種業務組的需求，初期的服務水平協議文件更接近於業務需求和希望的結果。設法瞭解用戶業務停機帶來的損失，估計生產力、收入和用戶信譽方面的損失。請牢記，即使只是和幾個� 說牧?右部梢匝現氐賾跋斕絞杖搿Ｔ謖庵智榭魷攏?繁Ｓ沒Ю斫飪贍芊⑸?目捎眯院託閱芊矯嫺姆縵眨?傭?蠱笠蹈?玫乩斫饉?枰?囊滴竦燃丁Ｈ綣?鄙僬庖徊劍?嵊行磯嚶沒е皇且?蟀俜種?俚目捎眯浴�

服務水平協議編制人員還應瞭解業務目標和企業發展速度以便適應網絡升級、工作量和預算。瞭解將要使用的應用程序也很有幫助。企業最好是有每個應用程序的應用信息文件，如果沒有，考慮一下是否可以對應用程序進行技術評估以確定與網絡有關的問題。

第11步：確定每個部門所要求的服務水平協議

主要支持服務水平協議應包括重要業務單元和功能組的要求，如網絡運行、服務器運行和應用程序支持組。這些組應基於業務需求和它們在支持過程中所起的作用來給確定。考慮多方面要求還有助於建立一個公平的整體支持解決方案而不偏向或優先考慮特定部門的需求。這有助於支持部門爲各個組提供最佳的服務，這是一種支撐企業整體服務文化的方案。例如，用戶可能堅持他的應用在公司範圍內是最重要的，而實際上，該應用故障所帶來的停機損失在收入、生產力降低和用戶信譽方面大大小於其他部門的應用。

企業內不同的業務部門將有不同的要求。網絡服務水平協議的一個目標應是實現一種可適應不同業務級別的總體格式。這些要求通常是：可用性、服務質量、性能和平均修復時間。在網絡服務水平協議中，這些變量通過以下方法來進行處理：爲各業務應用分配不同優先級來調整服務質量，針對各種網絡問題的平均修復時間來定義幫助臺優先順序，開發有助於處理各種可用性和性能要求的解決方案標準。一個加工企業的簡單解決方案示例如下表所示（可在可用性、服務質量和性能方面添加信息）：

業務部門	應用	故障損失	停機時的故障優先權	服務器和網絡要求
加工	企業資源規劃	高	1	最高冗餘度
用戶支持	客戶服務	高	1	最高冗餘度
工程	文件服務器，專用集成電路設計	中	2	局域網核心構件冗餘度
銷售	文件服務器	中	2	局域網核心冗餘度

第12步：選擇服務水平協議的格式

服務水平協議的格式可根據部門或企業的要求不同而有所變化。下面是一個推薦的網絡服務水平協議示例的要點：

• 協議目的
  • 協議有關方
  • 協議目標
• 所提供的服務和所支持的產品
  • 幫助臺服務和呼叫跟蹤
  • 用於定義平均修復時間的基於業務影響的故障嚴重性定義
  • 用於定義服務質量的關鍵業務優先權
  • 根據可用性和性能要求定義的解決方案類別
  • 培訓要求
  • 容量規劃要求
  • 上報要求
  • 報告
  • 提供的網絡解決方案
  • 新解決方案要求
  • 不受支持的產品和應用情況
• 業務策略
  • 工作時間提供的支持
  • 非工作時間支持的定義
  • 假期業務內容
  • 聯繫電話號碼
  • 工作量預測
  • 投訴處理
  • 業務授權標準
  • 用戶和部門安全責任
• 故障管理程序
  • 呼叫開始 (用戶和自動呼叫)
  • 第一級響應和呼叫修復率
  • 呼叫跟蹤和歷史記錄
  • 呼入方責任
  • 故障診斷和呼叫關閉要求
  • 網絡管理故障監測和業務響應
  • 故障解決類別或定義
  • 遺留故障處理
  • 上報策略
  • 故障轉移責任
  • 嚴重故障和意外情況呼叫處理
• 服務質量目標
  • 質量定義
  • 測定定義
  • 質量目標
  • 根據故障優先權開始處理故障前的平均等待時間
  • 根據故障優先權來解決故障的平均時間
  • 根據故障優先權來更換硬件的平均時間
  • 網絡可用性和性能
  • 管理容量
  • 管理擴容
  • 質量報告
• 人員配備和預算.
  • 人員配備模式
  • 運營預算
• 協議維護
  • 一致性審閱時間表
  • 性能報告和審閱
  • 報告測定標準的調整
  • 定期服務水平協議更新
• 批准
• 附件與正表
  • 呼叫流程圖
  • 上報標準
  • 網絡解決方案標準
  • 報告示例

第13步：成立服務水平協議工作組

下一步是確定服務水平協議工作組的成員，其中包括小組領導。工作組可以包括用戶、業務單位或職能部門經理或各地區的代表。這些人員向各自的工作組彙報服務水平協議方面的問題。經理和關鍵服務水平協議單元的決策人應加入該組。參加人員可以包括管理和技術兩方面的人員，這些人有助於定義與服務水平協議相關的技術問題和作出 IT.級別的決策 (即，幫助臺部門經理、服務器運行部經理、應用部經理和網絡運營部經理)。

網絡服務水平協議工作組還應由應用推广部和業務部代表組成，以在網絡服務水平協議方面達成一致，此協議涉及多個應用和業務部門。工作組有權對網絡的重要業務進程、業務、可用性和單個業務的性能要求進行安排。這方面的信息將用於爲各種會影響業務的故障類型創建優先權，爲網上的重要業務分配優先級，並創建基於業務要求的將來標準聯網解決方案。

第14步：召開工作組會議和草擬服務水平協議

工作組應首先編制工作組章程。章程應規定服務水平協議的目標、計劃、和時間框架。接下來，工作組將編寫具體工作計劃，並確定計劃表和編寫及執行服務水平協議的時間表。該工作組還應編寫根據支持標準測定支持級別的報告程序。最後一步是編寫服務水平協議草案。

聯網服務水平協議工作組最初應每週召開一次見面會以編寫服務水平協議。編寫並批准服務水平協議後，工作組可以每月甚至每季度召開一次會議以對服務水平協議進行增補。

第15步：商討服務水平協議

編寫服務水平協議的最後一步是最後協商和簽訂。這一步包括如下內容：

• 審閱草案
• 商討內容
• 編輯和修訂文件
• 獲得最後批准

在最後版本送交管理部門審批之前，審閱草案、商討內容和修訂的工作可以重複進行多次。

.從網絡部經理的角度來看，商討可以測定的預期結果是相當重要的。

設法吸引其他相關部門的人員來支持性能和可用性協議。這還包括質量定義、測定方法定義和質量目標。請記住，增加業務相當於額外開支。確保用戶組瞭解增加級別的業務將收取費用，並由用戶自己確定這是否是關鍵業務需求。您可以很容易地執行服務水平協議諸多方面的成本分析（如：硬件更換時間）。

第16步：測定和監控服務水平協議是否符合要求

測定服務水平協議是否符合要求和報告結果是服務水平協議流程的重要方面，因爲這有助於確保長期的連續性和結果。我們通常建議，服務水平協議的任何主要組成部分都是可測定的，並在執行服務水平協議前確定正確的測定辦法。然後每月召開用戶和支持部門間的會議以審覈測定辦法、找出問題的根本原因，並提出解決方案以滿足或超過業務級別要求。這有助於改進服務水平協議流程，使它現代質量改進計劃相似。

對於企業內管理部門是如何評定服務水平協議及其整體業務級別管理，以下小節提供了更多的詳細信息。

業務級別管理性能指標

業務級別管理性能指標將業務級別作爲一種衡量成功的方法來提供監控它的機制。這使企業可以對業務問題作出快速反應，並對影響業務或業務環境中的停機損失問題有一個更清楚的理解。如果沒有測定業務級別定義，將對以前完成的工作產生消極的影響，這是因爲企業被迫處於被動局面。沒有人會說服務真好，相反，會有很多用戶說服務滿足不了要求。因此，業務級別管理性能指標是業務級別管理的主要條件，這是因爲它提供方法來充分了解現有服務級別，並根據當前問題進行調整。這是提供主動支持和改進質量的基礎。當企業對問題進行根本分析並改進質量時，這將是提高可用性、性能和所提供服務的質量的最佳途徑。例如，考慮以下實例。

某公司收到越來越多的投訴說網絡經常出現長時間的故障。通過測定可用性，該公司發現主要問題是一小部分 WAN 站點。更進一步的研究發現大部分問題出現在這以小部分WAN站點上。企業發現問題並解決了這個問題。企業然後確定可用性的業務等級目標，並與用戶組簽訂協議。後來的故障測定過程根據服務水平協議的不適應性而變得很快。人們因此認爲網絡部門是具有很強的專業作風和技術的隊伍，是企業的財產。該部門很自然地從被動變爲主動，並有助於公司� 岣呔?眯б妗Ｒ藕兜氖牽?裉斕拇蠖嗍???棵諾囊滴竇侗鴝ㄒ搴苡邢蓿?⑽扌閱苤副輟＝峁?牽??怯麼罅康氖奔漵美從Ω隊沒?端呋蜆收希??皇侵鞫?頁齦?駒?蠆⒖?⒙?鬩滴襉枰?耐?綬?瘛�

通過以下服務水平協議性能指標來確定業務級別管理進程的成功與否：

• 以文件形式存在的業務級別定義或服務水平協議，服務水平協議包括可用性、性能、被動業務響應時間、故障解決方案目標和問題上報程序。
• 性能指標測定標準，其中包括可用性、性能、各優先權的業務響應時間，各優先級的處理時間和其他可測定的服務水平協議參數
• 審閱業務級別執行情況和整改工作的每月網絡業務級別管理會議

以文件形式存在的服務水平協議或業務級別定義

第1個性能指標只是詳細說明服務水平協議或業務級別定義的文件。業務級別定義的首要目標應是可用性和性能，因爲這是主要的用戶需求。

第2個目標很重要，這是因爲它們有助於定義可用性或性能級別的實現途徑。例如：如果企業具有挑戰性的可用性和性能目標，則預防發生故障和在出現故障時快速處理將非常重要。

. 第2個目標有助於定義實現期望可用性和性能級別所需的進程。

被動輔助目標包括：

• 各呼叫優先權的被動業務響應時間
• 故障解決目標或平均修復時間
• 問題上報流程

主動的輔助目標包括：

• 設備故障或鏈路故障監測
• 網絡故障監測
• 容量或性能問題監測

主要目標、性能和可用性的業務級別定義應包括：

目標

• 目標是如何測定的
• 測定可用性和性能的責任方
• 可用性和性能目標的責任方
• 不一致性進程

在可能的情況下，我們推薦，負責測定的人員和負責結果的人員應是不同的人員，以防止利益衝突。由於存在添加、移動和更改方面的錯誤，未監測到的故障或可用性測定問題，因此還要經常地調整可用性數值。業務級別定義還包括修改結果的程序以幫助提高準確性，並防止不正確的調整。有關測定可用性和性能的方法方面的信息，請參閱下一小節。

在確定 IT 範圍內的問題之後，企業要對這些問題或網絡進行響應，被動型輔助目標的業務級別定義對於企業在這方面的響應方式進行定義。其中，IT 範圍內的問題包括：

• 故障優先級定義
• 各故障優先級的業務響應時間
• 故障排除目標或平均修復時間
• 故障報告流程

通常情況下，這些目標定義指定時間內的故障負責人和在什麼情況下他們應停止手中的工作來完成指定的工作。與其他業務級別定義相似，業務級別文件也應詳細闡述目標的測定方法、測定負責方和不一致性處理流程。

主動式輔助目標的業務定義對企業提供主動支持的方式進行了定義，其中包括：網絡故障、鏈路故障和設備故障的識別，網絡故障情況和網絡容量門限。由於質量主動管理有助於排除故障和快速修復故障，因此需要確定宣傳主動管理的目標。通常情況下，通過確定建立和解決的主動式案例的目標數量來完成這一工作，其中，所解決的主動式案例是基於未通知用戶的情況。許多企業在幫助臺軟件中建立了標誌以據此來區別主動式案例和被動式案例。業務級別文件還應包括有關目標測定方式、測定責任方和不一致進程方面的信息。

性能指標測定標準

我們通常推薦，任何定義的業務級別目標應是可測定的，從而使企業可以測定業務級別，找出影響可用性和性能主要目標的根本原因，改進針對具體目標的工作方法。總之，測定目標只是一種工具，使網絡管理者可以管理業務等級的連續性，並根據業務要求改進工作質量。

遺憾的是，許多企業不收集可用性、性能和其他測定數據。企業將其歸因於沒有能力來提供準確性、成本、網絡費用和可用的資源。

這些因素可以影響測定業務的能力，但是企業應將注意力集中在整體目標上以管理並改進業務質量。許多企業可以建立低成本、低費用的測定標準，雖然這些標準不能提供絕對的準確性，但可以滿足主要目標的要求。

測定可用性和性能是業務級別測定標準經常忽略的一個環節。成功地使用這些測定標準地企業利用2種非常簡單的方法。一種是從網絡的核心位置向邊緣發送 Internet 控制信息協議主機連通性測試信息包（Internet Control Message Protocol (ICMP) ping packets）。通過這種方法還可以獲得一些性能數據。成功使用這種方法的企業還將類似設備組合爲“可用性”組。如局域網設備或本地域辦公設備。因爲企業對於不同的地理或重要業務地區企業通常有不同的業務級別目標，因此這方面就更加引人注目。這可以使測定標準部門通過可用性組來均分所有設備，從而達到合理的效果。

其他計算可用性的成功方法是使用故障票和稱爲“受影響用戶分鐘 (IUM)”的測定辦法。此方法對受到停機影響的用戶數量進行統計，並將該數值與停機時間相乘。用總時間佔該時間段的百分比形式來表示此數值時，這種方法很容易計算出可用性。無論這2種情況中的哪一種，這都有助於識別和測定故障的根本原因，以便使改進工作更有針對性。根本原因類別包括硬件問題、軟件問題、鏈路和載波問題、電源和環境問題、更改失敗和用戶錯誤。

可測定的被動支持目標包括：

• 各呼叫優先權的被動業務響應時間
• 故障排除目標或平均修復時間
• 故障排除目標，即MTTR
• 問題上報時間

通過從幫助臺數據庫生成報告來測定被動式支持目標，其中包括以下內容：

• 最初生成報告的時間(或輸入到數據庫的時間)
• 故障負責人收到呼叫的時間
• 故障上報的時間
• 故障處理完畢的時間

這些測定標準可能要求管理部門的干預以在數據庫中適當地輸入故障信息，並實時對故障信息進行更新。在某些情況下，企業可以爲網絡事件或電子郵件請求自動生成故障票。這有助於確定生成故障的準確開始時間。

通過這種測定標準生成的報告通過根據優先權、工作組和工作人員來對故障進行分類，以幫助確定潛在問題。

由於測定主動式支持進程要求監控主動式工作並對某些效率測定值進行計算，因此難度比較大。這方面的工作還做得很少。然而，很明顯，只有少部分人實際上向幫助臺報告網絡故障，並且很明顯需要時間來對故障進行解釋，或將問題歸結爲與網絡有關的問題。因爲冗餘設備或鏈路的故障對終端用戶的影響較小，所以不是所有的主動式案例都對可用性產生直接的影響。

企業因業務要求和潛在的可用性隱患而執行主動式業務級別定義或協議。然後根據主動式案例與被動式案例的數量或百分比進行測定，被動式案例是由用戶生成的。測定每個部分的主動式案例數量是一個很好的理念。這些類別將包括故障設備、故障鏈路、網絡錯誤和容量超限。還應通過可用性模式來進行某些工作以確定對可用性的影響，可用性是通過執行主動式業務定義來實現的。

業務級別管理審覈

業務級別管理是否成功的另一個測定方法是業務級別管理審閱。無論服務水平協議是否可用，都要執行這一步。通過測定負責人和提供定義的業務級別在每月一次的例會上對業務級別管理進行審閱。當涉及到服務水平協議時，用戶組也可以加入進來。會議的目的是審閱測定的業務級別定義的性能，並進行相應的整改。

每個會議應有一個確定的工作計劃，其中包括：

• 指定時間段內測定的業務級別的審閱
• 某一部分所確定的改進計劃的審閱
• 當前業務級別測定標準
• 需要根據當前的測定標準對改進方案進行討論

隨着時間的推移，企業還可以分析業務級別適應性趨勢以確定部門的效率。此進程不屬於質量範疇或質量改進程序。會議有助於針對具體問題，並根據根本原因來確定解決方案。

業務級別管理摘要

總之，業務級別管理逐漸使企業從被動支持模式變爲主動支持模式，在這種模式下，網絡可用性和業務級別由業務要求來確定，而不是由最近的一系列故障來確定。該進程有助於建立一個不斷提高業務級別的環境，並提高企業的競爭力。另外，業務級別管理還是主動網絡管理的最重要組成部分。因此，我們極力建議在任何網絡規劃和設計過程中都採用業務級別管理，並在最新定義的網絡結構中採用。這可以使企業在開始階段就能正確地執行解決方案，並使故障時間和重複工作量降到最低。