服務級別管理：最佳實踐白皮書
目錄
簡介
本文檔介紹高可用性網路的服務級別管理和服務級別協定(SLA)。它包括服務級別管理的關鍵成功因素和幫助評估成功的績效指標。本文檔還提供了遵循高可用性服務團隊確定的最佳實踐指南的SLA的重要詳細資訊。
服務級別管理概述
過去，網路組織通過構建穩固的網路基礎設施並以積極行動處理個別服務問題來滿足不斷擴展的網路需求。發生中斷時，組織將構建新的流程、管理功能或基礎架構來防止特定中斷再次發生。但是，由於變更率較高且可用性要求不斷提高，我們現在需要一個改進的模型來主動預防計畫外停機並快速修復網路。許多服務提供商和企業組織已嘗試更好地定義實現業務目標所需的服務級別。
關鍵成功因素
SLA的關鍵成功因素用於定義成功構建可獲得的服務級別和維護SLA的關鍵要素。要證明是關鍵成功因素，流程或流程步驟必須提高SLA的品質，並普遍改善網路可用性。關鍵的成功因素還應可衡量，以便組織能夠確定相對於定義的程式其成功程度。
有關更多詳細資訊，請參閱實施服務級別管理。
績效指標
績效指標是組織用來衡量關鍵成功因素的機制。通常您每月會檢視這些資訊，以確保服務級別定義或SLA運行良好。網路操作組和必要的工具組可以執行以下度量。
注意：對於沒有SLA的組織，我們建議您除了執行度量之外，還要執行服務級別定義和服務級別審查。
績效指標包括：
-
記錄的服務級別定義或SLA，包括可用性、效能、被動服務響應時間、問題解決目標和問題升級。
-
每月召開網路服務級別審查會議，審查服務級別合規性和實施改進。
-
效能指標指標，包括可用性、效能、按優先順序劃分的服務響應時間、按優先順序劃分的解決時間以及其他可衡量的SLA引數。
有關詳細資訊，請參閱實施服務級別管理。
服務級別管理流程
服務級別管理的高級流程流包含兩個主要組：
按一下下圖中的對象以檢視該步驟的詳細資訊。
實施服務級別管理
實施服務級別管理包括十六個步驟，分為以下兩大類：
定義網路服務級別
網路管理員需要定義支援、管理和衡量網路的主要規則。服務級別為所有網路人員提供了目標，可用作總體服務品質的指標。您還可以將服務級別定義用作預算網路資源的工具，並用作需要為更高的QoS提供資金的證據。它們還提供了一種評估供應商和運營商績效的方法。
如果沒有服務級別定義和衡量標準，組織就沒有明確的目標。服務滿意度可能由使用者管理，而應用程式、伺服器/客戶端操作或網路支援之間幾乎沒有區別。由於組織的最終結果不清楚，預算可能更加困難，最後，網路組織在改進網路和支援模式時傾向於更加被動而非主動。
我們建議以下步驟來構建和支援服務級別模型：
第1步：分析技術目標和限制
分析技術目標和限制的最佳方式是進行頭腦風暴，或研究技術目標和要求。有時，邀請其他IT技術合作夥伴參與討論會有所幫助，因為這些人員具有與其服務相關的特定目標。技術目標包括可用性級別、吞吐量、抖動、延遲、響應時間、可擴充性要求、新功能引入、新應用程式引入、安全性、可管理性甚至成本。然後，本組織在現有資源範圍內應調查實現這些目標的制約因素。您可以為每個目標建立工作表，並列出約束條件說明。最初，似乎大多數目標都無法實現。然後，開始確定目標優先順序或降低仍能滿足業務需求的期望值。
例如，您的可用性級別可能為99.999%，即每年停機時間5分鐘。實現此目標存在許多限制，例如硬體出現單點故障、遠端位置出現故障的平均修復時間(MTTR)、運營商可靠性、主動故障檢測功能、高更改率和當前網路容量限制。因此，您可以將目標調整到更易於實現的水準。下一節中的可用性模型可以幫助您設定現實的目標。
您還可能考慮在限制較少的網路的某些區域提供更高的可用性。當網路組織發佈可用性服務標準時，組織內的業務組可能會發現該級別無法接受。因此，這是開始討論可滿足業務要求的SLA或融資/預算模式的自然點。
確定實現技術目標涉及的所有制約因素或風險。根據對預期目標的最大風險或影響排定約束的優先順序。這有助於組織確定網路改進計畫的優先順序，並確定解決約束的難易程度。約束有三種：
-
網路技術、恢復能力和配置
-
生命週期實踐，包括規劃、設計、實施和操作
-
當前流量負載或應用行為
網路技術、恢復能力和配置限制是與當前技術、硬體、鏈路、設計或配置關聯的任何限制或風險。技術限制涵蓋技術本身造成的任何限制。例如，當前的技術都不允許在冗餘網路環境中實現次秒的收斂時間，這對於在整個網路中保持語音連線至關重要。另一個例子是資料在陸地鏈路上傳輸的原始速度，大約是每毫秒100哩。
網路硬體恢復能力風險調查應側重於網路中定義的路徑上的硬體拓撲、層次、模組性、冗餘和MTBF。網路鏈路限制應側重於企業組織的網路鏈路和運營商連線。鏈路限制可能包括鏈路冗餘和多樣性、介質限制、佈線基礎架構、本地環路連線和長途連線。設計限制與網路的物理或邏輯設計相關，包括從裝置可用空間到路由協定實施的可擴充性等所有限制。所有協定和介質設計都應考慮配置、可用性、可擴充性、效能和容量。還應考慮網路服務限制，如動態主機配置協定(DHCP)、域名系統(DNS)、防火牆、協定轉換器和網路地址轉換程式。
生命週期實踐定義了網路的流程和管理，用於一致地部署解決方案、檢測和修復問題、防止容量或效能問題以及為一致性和模組化配置網路。您需要考慮這一方面，因為專業知識和流程通常是造成不可用的最大因素。網路生命週期是指規劃、設計、實施和操作的週期。在這些方面，您必須瞭解網路管理功能，如效能管理、配置管理、故障管理和安全性。思科NSA高可用性服務(HAS)服務可提供網路生命週期評估，顯示與網路生命週期實踐相關的當前網路可用性限制。
當前流量負載或應用限制僅指當前流量和應用的影響。
遺憾的是，許多應用程式存在一些需要仔細管理的嚴重限制。當前應用的抖動、延遲、吞吐量和頻寬要求通常有許多限制。編寫應用程式的方式也可能造成限制。應用程式分析可幫助您更好地瞭解這些問題；下一部分將介紹此功能。調查當前的可用性、流量、容量和整體效能，還有助於網路經理瞭解當前的服務級別期望值和風險。這通常通過稱為網路基線化的過程完成，該過程有助於定義網路效能、可用性或規定時間段（通常為約一個月）的容量平均值。此資訊通常用於容量規劃和趨勢分析，但也可用於瞭解服務級別問題。
以下工作表使用上述目標/約束方法作為防止安全攻擊或拒絕服務(DoS)攻擊的示例。您還可以使用此工作表來確定服務覆蓋範圍，從而最大限度地減少安全攻擊。
| 風險或約束 | 約束型別 | 潛在影響 |
|---|---|---|
| 可用的DoS檢測工具無法檢測所有型別的DoS攻擊。 | 技術/恢復能力 | 高 |
| 沒有應對警報所需的人員和流程。 | 生命週期實踐 | 高 |
| 當前網路訪問策略未到位。 | 生命週期實踐 | 中 |
| 如果將頻寬擁塞用於攻擊，則當前的低頻寬Internet連線可能是一個因素。 | 網路容量 | 中 |
| 目前用於幫助防止攻擊的安全配置可能並不全面。 | 技術/恢復能力 | 中 |
第2步：確定可用性預算
可用性預算是網路在兩個定義的點之間的預期理論可用性。準確的理論資訊在以下幾個方面很有用：
-
組織可以將此作為內部可用性的目標，偏差可以快速定義和補救。
-
網路規劃人員可以使用該資訊來確定系統的可用性，以確保設計符合業務要求。
導致不可用或停機時間的因素包括硬體故障、軟體故障、電源和環境問題、鏈路或運營商故障、網路設計、人為錯誤或缺少流程。在評估網路的整體可用性預算時，應仔細評估其中每個引數。
如果組織當前度量可用性，則可能不需要可用性預算。將可用性測量用作基線，以估計用於服務級別定義的當前服務級別。但是，您可能希望將這兩個值進行比較，以便瞭解潛在的理論可用性和實際的測量結果。
可用性是指產品或服務在需要時運行的概率。請參閱以下定義：
-
可用性
-
1 — （總連線中斷時間）/（總服務中連線時間）
-
1 - [Sigma（中斷影響的num連線iX中斷持續時間i）] /（服務中的num連線數X操作時間）
-
-
不可用性
1 — 可用性或由於以下原因導致的總中斷連線時間（硬體故障、軟體故障、環境和電源問題、鏈路或運營商故障、網路設計或使用者錯誤和進程故障）
-
硬體可用性
首先要調查的方面是潛在的硬體故障及其對不可用性的影響。要確定這一點，組織需要瞭解所有網路元件的MTBF，以及兩點之間路徑中所有裝置的硬體問題的MTTR。如果網路是模組化和分層的，幾乎任何兩點之間的硬體可用性都相同。所有思科元件的MTBF資訊均可獲得，也可向本地客戶經理索取。Cisco NSA HAS程式還使用工具來幫助確定網路路徑上的硬體可用性，即使系統中存在模組冗餘、機箱冗餘和路徑冗餘也是如此。影響硬體可靠性的一個主要因素是MTTR。組織應評估修復損壞硬體的速度。如果組織沒有備用計畫並依賴標準的Cisco SMARTnet™協定，則潛在的平均更換時間約為24小時。在具有核心冗餘和無訪問冗餘的典型LAN環境中，4小時MTTR的可用性大致為99.99%。
-
軟體可用性
下一個調查領域是軟體故障。出於測量目的，思科將軟體故障定義為因軟體錯誤導致裝置冷啟動。思科在瞭解軟體可用性方面取得了重大進展；但是，較新的版本需要時間才能衡量，且被認為比常規部署軟體可用性更低。一般部署軟體(如IOS版本11.2(18))的可用性已超過99.999%。這是根據思科路由器上實際冷啟動時間計算的，使用六分鐘作為修復時間（路由器重新載入的時間）。 由於增加了複雜性、互操作性和故障排除時間，擁有各種版本的組織預計可用性會略低。具有最新軟體版本的組織預計具有更高的不可用性。不可用性的分佈範圍也相當廣泛，這意味著客戶可能遇到嚴重不可用性，或者在接近常規部署版本的情形下出現可用性。
-
環境和電源可用性
您還必須考慮可用性中的環境和電源問題。環境問題涉及將裝置保持在特定工作溫度所需的冷卻系統故障。許多思科裝置在嚴重不符合規格時就會關閉，而不會有損壞所有硬體的風險。出於可用性預算的目的，將使用電源，因為這是導致此領域不可用的主要原因。
雖然斷電是確定網路可用性的一個重要方面，但由於理論上的斷電分析無法準確完成，因此這種討論有限。組織必須評估的是基於其地理區域的經驗、電源備份功能和實施的過程來大致衡量其裝置的供電可用性，以確保為所有裝置提供一致的優質電源。
對於保守的評估，我們可以說，具有備用發電機、不間斷電源(UPS)系統和優質電源實施過程的組織可用性可能為6.9秒(99.9999%)，而不具備這些系統的組織可用性可能為99.99%（即每年停機大約36分鐘）。當然，您可以根據組織的感知或實際資料，將這些值調整為更實際的值。
-
鏈路或載波故障
鏈路和運營商故障是影響WAN環境中可用性的主要因素。請記住，WAN環境只不過是其他網路，其可用性問題與組織的網路相同，包括硬體故障、軟體故障、使用者錯誤和電源故障。
許多運營商網路已經在其系統上執行了可用性預算，但獲取此資訊可能很困難。請記住，運營商還經常有可用性保證級別，這些級別很少或沒有實際可用性預算的基礎。這些保證級別有時只是行銷和銷售方法，用於宣傳運營商。在某些情況下，這些網路還會發佈看起來非常好的可用性統計資訊。請記住，這些統計資訊可能僅適用於完全冗餘的核心網路，而不考慮由於本地環路接入導致的非可用性，而本地環路接入是導致WAN網路中不可用的主要因素。
應基於實際運營商資訊和WAN連線的冗餘級別來確定WAN環境的可用性。如果組織擁有多個建築物入口設施、冗餘本地環路提供商、同步光纖網路(SONET)本地接入和具有地理多樣性的冗餘長途運營商，則廣域網可用性將顯著提高。
對於廣域網環境中的非冗餘網路連線，電話服務是一個相當準確的可用性預算。使用類似於本節所述的可用性預算方法，電話的端到端連線具有大約99.94%的可用性預算。此方法已成功用於只有輕微變化的資料環境，目前被用作服務提供商有線網路資料包電纜規範的目標。如果將此值應用到完全冗餘的系統，我們可以假設WAN的可用性將接近99.9999-percent。當然，由於成本和可用性方面的原因，很少有組織擁有完全冗餘、地理上分散的WAN系統，因此請正確判斷此功能。
LAN環境中的鏈路故障可能性較低。但是，規劃人員可能需要假設因聯結器損壞或鬆動導致的少量停機。對於LAN網路，保守估計大約是99.9999%的可用性，即每年大約30秒。
-
網路設計
網路設計是另一個影響可用性的主要因素。不可擴展的設計、設計錯誤和網路融合時間都會對可用性產生負面影響。
注意：對於本文檔而言，以下部分包括不可擴展的設計或設計錯誤。
然後根據網路中導致流量重新路由的軟體和硬體故障將網路設計限製為可測量的值。此值通常稱為「系統切換時間」，是系統內自癒協定功能的一個因素。
僅使用與系統計算相同的方法計算可用性。但是，除非網路切換時間符合網路應用要求，否則此命令無效。如果切換時間可以接受，請將其從計算中刪除。如果轉換時間不可接受，則必須將其新增到計算中。例如，IP語音(VoIP)環境內的估計或實際切換時間為30秒。在此示例中，使用者只需掛斷電話並可能重試。使用者一定會將此時間視為不可用期，但可用性預算中未對此進行估計。
通過檢視冗餘路徑上的軟體和硬體可用性理論值，計算由於系統切換時間導致的不可用性，因為切換將發生在此區域。您必須知道在冗餘路徑中可能發生故障並導致切換的裝置數量、這些裝置的MTBF和切換時間。一個簡單的例子是兩個冗餘相同的裝置每台MTBF為35,433小時，切換時間為30秒。將35,433除以8766（年平均工作時數包括閏年），我們看到該裝置每四年就會故障一次。如果使用30秒作為切換時間，則我們可以假設每台裝置每年平均會因切換而經歷7.5秒的不可用時間。由於使用者可能正在遍歷任一條路徑，因此結果會成倍增加至每年15秒。如果用每年幾秒鐘計算此值，則在此簡單系統中，由於切換而導致的可用性數量可計算為99.99999785-percent可用性。由於網路中可能存在切換的冗餘裝置的數量，因此在其他環境中，這種情況可能會更高。
-
使用者錯誤和流程
使用者錯誤和進程可用性問題是造成企業和運營商網路中不可用的主要原因。大約80%的不可用性是由諸如檢測不到錯誤、更改故障和效能問題之類的問題造成的。
組織肯定不希望將所有其他理論上不可用的次數四倍於用來確定可用性預算，但不斷有證據表明，在許多環境中都是這種情況。下一節將更全面地介紹不可用的這一方面。
因為理論上由於使用者錯誤和流程造成的不可用數量是無法計算的，我們建議您將此項從可用性預算中去掉，並讓機構為做到完美而努力。一個警告是，組織需要瞭解其自己的流程和專業技能水準中當前的可用性風險。一旦您更好地瞭解這些風險和抑制因素後，網路規劃人員可能希望考慮由於這些問題導致的一些不可用數量。思科NSA HAS計畫會調查這些問題，並幫助組織瞭解由於流程、使用者錯誤或專業知識問題而可能出現的不可用情況。
-
確定最終可用性預算
您可以通過乘以每個先前定義的區域的可用性來確定整體可用性預算。這通常適用於任意兩點之間連線類似的同構環境，例如分層模組化LAN環境或分層標準WAN環境。
在本示例中，可用性預算針對分層模組化LAN環境執行。該環境對所有網路元件使用備用發電機和UPS系統並正確管理電源。組織不使用VoIP，也不希望將軟體切換時間考慮在內。估計如下：
-
兩個端點之間的硬體路徑可用性= 99.99%的可用性
-
軟體可用性使用GD軟體可靠性作為參考= 99.9999%的可用性
-
備份系統的環境和電源可用性= 99.999%的可用性
-
LAN環境中的鏈路故障= 99.9999%的可用性
-
未考慮系統切換時間= 100%的可用性
-
假定使用者錯誤和流程可用性完美無缺= 100%的可用性
各組織應努力爭取的最終可用性預算等於0.9999 X 0.999999 X 0.999999 X 0.999999 = 0.999896，或99.9896%的可用性。如果考慮使用者或流程錯誤造成的潛在不可用性，並假設由於技術因素造成的不可用性是4倍，則可用預算可以為99.95%。
此示例分析指出LAN可用性平均會下降99.95%到99.989%。現在，這些數字可用作網路組織的服務級別目標。通過測量系統中的可用性並確定由於以上六個方面的原因導致的非可用性百分比可以增加價值。這使組織能夠正確評估供應商、運營商、流程和員工。該數字還可用於設定企業內的預期。如果數字不可接受，則預算額外資源以獲得所需水準。
對於網路管理員來說，瞭解任何特定可用性級別的停機時間可能非常有用。無論可用性級別如何，一年的停機時間（以分鐘為單位）為：
一年內停機時間= 525600 — （可用性級別X 5256）
如果使用99.95%的可用性級別，這相當於停機525600 -(99.95 X 5256)或262.8分鐘。對於上述可用性定義，這等於網路中所有服務連線的平均停機時間。
-
步驟3:建立應用程式配置檔案
應用配置檔案可幫助網路組織瞭解和定義單個應用的網路服務級別要求。這有助於確保網路支援各個應用需求和整個網路服務。當應用程式或伺服器組指向網路時，應用程式配置檔案還可以作為網路服務支援的書面基準。最後，應用配置檔案通過將應用需求（例如效能和可用性）與現實的網路服務目標或當前限制進行比較，幫助將網路服務目標與應用或業務需求保持一致。這不僅對服務級別管理非常重要，而且對整個自上而下的網路設計也很重要。
每次將新應用程式引入網路時，都要建立應用程式配置檔案。您可能需要在IT應用程式組、伺服器管理組和網路之間簽訂協定，以幫助強製為新的和現有的服務建立應用程式配置檔案。完成業務應用程式和系統應用程式的應用程式配置檔案。業務應用程式可能包括電子郵件、檔案傳輸、Web瀏覽、醫療成像或製造。系統應用可能包括軟體分發、使用者身份驗證、網路備份和網路管理。
網路分析人員和應用程式或伺服器支援應用程式應建立應用程式配置檔案。新應用程式可能需要使用協定分析器和帶有延遲模擬的WAN模擬器來正確描述應用程式要求。這有助於確定必要的頻寬、應用程式可用性的最大延遲以及抖動要求。只要您擁有所需的伺服器，就可以在實驗室環境中完成此操作。在其他情況下（如VoIP），包括抖動、延遲和頻寬在內的網路要求會得到很好的公佈，不需要實驗室測試。應用配置檔案應包含以下項：
-
應用程式名稱
-
應用型別
-
新應用程式？
-
業務重要性
-
可用性要求
-
使用的協定和埠
-
估計使用者頻寬(kbps)
-
使用者數量和位置
-
檔案傳輸要求（包括時間、容量和端點）
-
網路中斷影響
-
延遲、抖動和可用性要求
應用配置檔案的目標是瞭解應用的業務要求、業務關鍵性和網路要求，例如頻寬、延遲和抖動。此外，網路組織應瞭解網路中斷的影響。在某些情況下，您需要重新啟動應用程式或伺服器，這會大大增加應用程式的總體停機時間。完成應用配置檔案後，您可以比較整體網路功能，並幫助使網路服務級別與業務和應用需求保持一致。
第4步：定義可用性和效能標準
可用性和效能標準設定了組織的服務期望值。這些可以針對網路的不同區域或特定應用來定義。效能還可以根據往返延遲、抖動、最大吞吐量、頻寬承諾和整體可擴充性來定義。除設定服務期望值外，組織還應注意定義各項服務標準，以便通過網路合作的使用者和IT團隊充分瞭解服務標準及其與應用程式或伺服器管理要求之間的關係。使用者和IT團隊還應瞭解如何衡量服務標準。
先前服務級別定義步驟的結果將有助於建立標準。此時，網路組織應明確瞭解網路中的當前風險和限制，理解應用程式行為，以及理論上的可用性分析或可用性基線。
-
定義將應用服務標準的地理或應用領域。
這可能包括園區LAN、國內WAN、外聯網或合作夥伴連線等領域。在某些情況下，組織在一個領域可能有不同的服務級別目標。對於企業或服務提供商組織來說，這種情況並不少見。在這些情況下，根據個別服務要求制定不同的服務級別標準並非不常見。這些標準可歸入一個地理或服務區域內的金、銀、銅服務標準。
-
定義服務標準引數。
可用性和往返延遲是最常見的網路服務標準。根據需要還可以包括最大吞吐量、最小頻寬承諾、抖動、可接受的錯誤率和可擴充性功能。檢視測量方法的服務引數時要小心。無論引數是否移至SLA，組織都應考慮在發生問題或服務分歧時如何衡量或論證服務引數。
定義服務區域和服務引數後，使用前面步驟的資訊構建服務標準矩陣。組織還需要定義可能會使使用者和IT團隊感到困惑的領域。例如，往返執行ping的最大響應時間與按特定應用程式遠端位置的Enter鍵的最大響應時間將非常不同。下表顯示了美國國內的績效目標。
| 網路區域 | 可用性目標 | 測量方法 | 平均網路響應時間目標 | 接受的最大響應時間 | 響應時間測量方法 |
|---|---|---|---|---|---|
| LAN | 99.99% | 受影響的使用者分鐘數 | 5毫秒以下 | 10毫秒 | 往返ping響應 |
| WAN | 99.99% | 受影響的使用者分鐘數 | 100 ms以下（來回ping） | 150毫秒 | 往返ping響應 |
| 關鍵WAN和外聯網 | 99.99% | 受影響的使用者分鐘數 | 100 ms以下（來回ping） | 150毫秒 | 往返ping響應 |
第5步：定義網路服務
這是基本服務級別管理的最後一步；它定義了為實現服務級別目標而實施的被動和主動式流程及網路管理功能。最終文檔通常稱為運營支援計畫。大多數應用支援計畫僅包括被動支援要求。在高可用性環境中，組織還必須考慮主動管理流程，這些流程將用於隔離和解決網路問題，然後啟動使用者服務呼叫。總的來說，最後檔案應：
-
描述用於實現服務級別目標的被動和主動過程
-
如何管理服務流程
-
如何衡量服務目標和服務流程。
本節包含反應服務定義和主動服務定義的示例，可供許多服務提供商和企業組織考慮。構建服務級別定義的目標是建立滿足可用性和效能目標的服務。為此，組織必須在建立服務時考慮到當前的技術限制、可用性預算和應用程式配置檔案。具體來說，組織應定義和構建一項服務，在可用性模型分配的時間內，一致而快速地識別並解決問題。組織還必須定義一項服務，該服務可以快速識別和解決潛在的服務問題，如果忽略這些服務問題，將會影響可用性和效能。
您不可能在一夜之間達到所需的服務級別。專業知識不足、當前流程限制或人員配備不足等缺點可能會阻礙組織實現期望的標準或目標，即使在先前的服務分析步驟之後也是如此。沒有精確的方法將所需的服務級別與預期的目標精確匹配。為此，組織應衡量服務標準，並衡量用於支援服務標準的服務引數。當組織未達到服務目標時，它應尋求服務指標來幫助瞭解問題。在許多情況下，增加預算是為了改善支助服務，並為實現預期服務目標進行必要的改進。隨著時間的推移，組織可能會對服務目標或服務定義做出一些調整，以使網路服務和業務需求保持一致。
例如，當目標為99.9%的可用性要高得多時，組織可能會達到99%的可用性。在檢視服務和支援指標時，組織的代表發現硬體更換大約需要24小時，這比最初的估計長得多，因為組織的預算只有4小時。此外，該組織發現，主動管理功能被忽略，冗餘網路裝置停止運行，並未修復。他們還發現，他們沒有人員來進行改進。因此，在考慮降低當前服務目標後，組織將預算用於實現所需服務級別所需的額外資源。
服務定義應包括被動支援定義和主動支援定義。反應性定義定義定義在問題從使用者投訴或網路管理功能中確定後，組織將如何做出反應。主動預防性定義描述組織如何識別和解決潛在網路問題，包括修復損壞的「備用」網路元件、錯誤檢測以及容量閾值和升級。以下部分提供了被動和主動服務級別定義的示例。
被動服務級別定義
通常使用服務檯資料庫統計資料和定期稽核來衡量以下服務級別區域。此表顯示組織的問題嚴重性示例。請注意，此圖表不包括如何處理新服務請求，這些請求可能由SLA或其他應用程式分析以及效能假設分析來處理。通常情況下，如果通過相同的支援流程處理，嚴重級別為5可能是請求新服務。
| 嚴重級別1 | 嚴重級別2 | 嚴重級別3 | 嚴重級別4 |
|---|---|---|---|
| 嚴重業務影響LAN使用者或伺服器段中斷嚴重WAN站點故障 | 通過丟失或降級產生高業務影響，校園區域網中斷時可能採取的因應措施；5-99個使用者影響國內WAN站點故障國際WAN站點故障關鍵效能影響 | 某些特定網路功能丟失或降級，例如冗餘丟失園區LAN性能受影響LAN冗餘丟失 | 對組織沒有業務影響的功能查詢或故障 |
定義問題嚴重性後，定義或調查支援流程以建立服務響應定義。通常，服務響應定義需要一種分層支援結構，該結構需與幫助台軟體支援系統配合使用，以便通過故障單跟蹤問題。此外，還應在每個優先順序的響應時間和解決時間、按優先順序的呼叫數以及響應/解決品質方面提供指標。為定義支援流程，它有助於定義組織中每個支援層的目標及其角色和職責。這有助於組織瞭解每個支援級別的資源需求和專業知識水準。下表提供了一個具有問題解決指導准則的分層支援組織的示例。
| 支援層 | 責任 | 目標 |
|---|---|---|
| 第1層支援 | 全職幫助台支援應答支援呼叫、發出故障單、在15分鐘內解決問題、記錄故障單並上報到適當的第2層支援 | 解決40%的來電 |
| 第2層支援 | 隊列監控、網路管理、站點監控為軟體發現的問題提供故障單實施接聽來自第1層、供應商和第3層上報的呼叫在問題解決前取得呼叫所有權 | 第2層呼叫的100%得到解決 |
| 第3層支援 | 必須針對所有優先順序為1的問題向第2層提供即時支援同意在SLA解決期內幫助解決第2層未解決的所有問題 | 沒有直接的問題所有權 |
下一步是為服務響應和服務解析服務定義建立矩陣。這將設定解決問題的速度（包括硬體更換）目標。在此領域設定目標很重要，因為服務響應時間和恢復時間直接影響網路可用性。問題解決時間也應與可用性預算保持一致。如果可用性預算中沒有考慮大量嚴重性級別較高的問題，組織隨後可以努力瞭解這些問題的根源和可能的補救方法。請參閱下表：
| 問題嚴重性 | 幫助台響應 | 第2層響應 | Onsite第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天 |
除了服務響應和服務解決之外，還要構建一個上報矩陣。Escalation matrix有助於確保可用資源集中用於嚴重影響服務的問題。一般而言，當分析師關注於解決問題時，他們很少關注於為問題帶來額外資源。確定何時應通知附加資源有助於提高管理中的問題意識，通常有助於制定未來的主動預防措施或預防措施。請參閱下表：
| 運行時間 | 嚴重級別1 | 嚴重級別2 | 嚴重級別3 | 嚴重級別4 |
|---|---|---|---|---|
| 5分鐘 | 網路運營經理，第3層支援，網路總監 | |||
| 1小時 | 網路運營經理更新，第3層支援，網路主管 | 網路運營經理更新，第3層支援，網路主管 | ||
| 2小時 | 升級至VP，更新至主管、運營經理 | |||
| 4小時 | 對副總裁、總監、運營經理、第3層支援進行根本原因分析，未解決問題需要CEO通知 | 升級至VP，更新至主管、運營經理 | ||
| 24小時 | 網路營運管理員 | |||
| 5天 | 網路營運管理員 |
到目前為止，服務級別定義的重點是操作支援組織在發現問題後如何作出反應。運營組織多年來一直使用與上述類似的資訊制定運營支援計畫。然而，在這些情況下，缺失的是組織如何確定問題以及他們將確定哪些問題。更為先進的網路組織試圖解決此問題，只需為主動確定的問題百分比建立目標，而不是使用者問題報告或投訴主動確定的問題。
下表顯示了組織可能希望如何衡量主動支援功能和主動支援總體。
| 網路區域 | 主動問題識別率 | 反應問題識別率 |
|---|---|---|
| LAN | 80 % | 20 % |
| WAN | 80 % | 20 % |
這是定義更主動支援定義的良好開端，因為它簡單且易於測量，尤其是當主動工具自動生成故障單時。這也有助於將網路管理工具/資訊集中到主動解決問題上，而不是幫助解決根本原因上。但是，此方法的主要問題是它沒有定義主動支援要求。這通常會導致主動支援管理功能出現缺口，從而導致額外的可用性風險。
主動服務等級定義
用於建立服務級別定義的更全面的方法包括網路如何監控以及運營組織如何對定義的網路管理站(NMS)閾值進行7 x 24響應的更多詳細資訊。考慮到大量的管理資訊庫(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層支援級別確定事件
下表顯示了網路錯誤的服務級別定義示例，通過該示例可以清楚地瞭解誰負責主動網路錯誤警報、如何識別問題以及發生問題時會發生什麼。本組織可能仍需要上文界定的其他努力來確保成功
s.
| 錯誤類別 | 檢測方法 | 閾值 | 已採取的行動 |
|---|---|---|---|
| 軟體錯誤（軟體強制崩潰） | 使用syslog viewer每天檢視系統日誌消息第2層支援完成 | 優先順序0、1和2的任何發生次數級別3或以上的100以上 | 檢視問題、建立故障單並在出現新問題或問題需要注意時派單 |
| 硬體錯誤（硬體強制崩潰） | 使用syslog viewer每天檢視系統日誌消息第2層支援完成 | 優先順序0、1和2的任何發生次數級別3或以上的100以上 | 檢視問題、建立故障單並在出現新問題或問題需要注意時派單 |
| 協定錯誤（僅限IP路由協定） | 使用syslog viewer每天檢視系統日誌消息第2層支援完成 | 每天有10條優先消息0、1和2，第3級或以上的事件超過100次 | 檢視問題、建立故障單並在出現新問題或問題需要注意時派單 |
| 媒體控制錯誤（僅限FDDI、POS和快速乙太網） | 使用syslog viewer每天檢視系統日誌消息第2層支援完成 | 每天有10條優先消息0、1和2，第3級或以上的事件超過100次 | 檢視問題、建立故障單並在出現新問題或問題需要注意時派單 |
| 環境資訊（電源和溫度） | 使用syslog viewer每天檢視系統日誌消息第2層支援完成 | 任何消息 | 為新問題建立故障單和派單 |
| 精度錯誤（連結輸入錯誤） | 5分鐘間隔的SNMP輪詢由NOC接收的閾值事件 | 輸入或輸出錯誤任何鏈路上的任何5分鐘間隔內都有一個錯誤 | 為新問題建立故障單並派遣至第2層支援 |
其他類別的主動服務級別定義適用於效能和容量。真正的效能和容量管理包括例外管理、基準和趨勢分析以及假設分析。服務級別定義僅定義將啟動調查或升級的效能和容量異常閾值和平均閾值。然後，這些閾值可能會以某種方式應用於所有三個效能和容量管理過程。
容量和效能服務級別定義可分為幾個類別：網路鏈路、網路裝置、端到端效能和應用效能。在這些領域開發服務級別定義需要有關裝置容量、媒體容量、QoS特性和應用要求等特定方面的深入技術知識。因此，我們建議網路架構師使用供應商輸入，制定與效能和容量相關的服務級別定義。
與網路錯誤類似，為容量和效能定義服務級別時，首先要全面瞭解這些問題是如何被檢測的，由誰來檢視這些問題，以及這些問題發生時會發生什麼。如果需要，可將特定事件定義新增到服務級別定義中。為確保成功，您還需要在以下方面做更多工作：
-
清楚地瞭解應用程式效能要求
-
根據業務需求和總成本，深入調查對組織有意義的閾值
-
預算週期和週期外升級要求
-
第1級、第2級和第3級支援職責
-
網路管理資訊的優先順序和重要性，與運營團隊可以有效地處理的主動工作量保持平衡
-
培訓要求，以確保支援人員理解報文或風險通告並能有效處理定義的條件
-
事件關聯方法或過程，確保不會針對同一根本原因問題生成多個故障單
-
有關特定消息或警報的文檔，可幫助在第1層支援級別確定事件
下表顯示了鏈路利用率的服務級別定義示例，通過該示例可以清楚地瞭解誰負責主動網路錯誤警報，如何發現問題，以及發生問題時會發生什麼。為確保成功，本組織可能仍需做出上述更多努力。
| 網路區域/媒體 | 檢測方法 | 閾值 | 已採取的行動 |
|---|---|---|---|
| 園區LAN主幹和分佈連結 | 5分鐘間隔的SNMP輪詢核心和分佈鏈路上的RMON異常陷阱 | 50%的利用率（5分鐘間隔）90%的利用率（通過異常陷阱） | 向效能電子郵件別名組傳送電子郵件通知，以評估QoS要求或計畫升級以解決重複問題 |
| 國內WAN鏈路 | 5分鐘間隔的SNMP輪詢 | 在5分鐘間隔內實現75%的利用率 | 向效能電子郵件別名組傳送電子郵件通知，以評估QoS要求或計畫升級以解決重複問題 |
| Extranet WAN鏈路 | 5分鐘間隔的SNMP輪詢 | 在5分鐘間隔內實現60%的利用率 | 向效能電子郵件別名組傳送電子郵件通知，以評估QoS要求或計畫升級以解決重複問題 |
下表定義了裝置容量和效能閾值的服務級別定義。確保您建立對防止網路問題或可用性問題有實際意義且有用的閾值。這是一個非常重要的方面，因為未檢查的裝置控制平面資源問題可能會對網路造成嚴重影響。
| Cisco 7500 | CPU、記憶體、緩衝區 | -5分鐘間隔的SNMP輪詢CPU的RMON通知 | 5分鐘間隔內CPU使用率為75%，通過RMON通知時為99%在5分鐘間隔內CPU使用率為50%緩衝區使用率為99% | 通過電子郵件通知效能和容量電子郵件別名組以解決問題或計畫以99%的速度升級RMON CPU，新增故障單和第2層頁面支援頁 |
| Cisco 2600 | CPU、記憶體 | 5分鐘間隔的SNMP輪詢 | 5分鐘間隔內CPU使用率為75%5分鐘間隔內50%的記憶體 | 通過電子郵件通知效能和容量電子郵件別名組，以解決問題或規劃升級 |
| Catalyst 5000 | 底板利用率，記憶體 | 5分鐘間隔的SNMP輪詢 | 利用率達50%的底板記憶體利用率達75% | 通過電子郵件通知效能和容量電子郵件別名組，以解決問題或規劃升級 |
| LightStream® 1010 ATM交換器 | CPU、記憶體 | 5分鐘間隔的SNMP輪詢 | CPU利用率達到65%記憶體利用率達到50% | 通過電子郵件通知效能和容量電子郵件別名組，以解決問題或規劃升級 |
下表定義了端到端效能和容量的服務級別定義。這些閾值通常基於應用要求，但也可用於指示某種型別的網路效能或容量問題。大多數為效能定義服務級別的組織只建立極少數的效能定義，因為從網路中的每個點到其他每個點測量效能需要大量資源，並且會產生大量的網路開銷。這些端到端效能問題還可能出現在鏈路或裝置容量閾值中。我們建議按地理區域進行一般定義。如有必要，可能會新增一些關鍵站點或連結。
| 網路區域/媒體 | 測量方法 | 閾值 | 已採取的行動 |
|---|---|---|---|
| 園區LAN | 無預計無問題難以測量整個LAN基礎架構 | 10毫秒的往返響應時間或在所有時間小於 | 通過電子郵件通知效能和容量電子郵件別名組，以解決問題或計畫升級 |
| 國內WAN鏈路 | 當前從SF到NY和SF到Chicago的測量，僅使用網際網路效能監視器(IPM)ICMP回應 | 在5分鐘內平均往返響應時間為75毫秒 | 向效能電子郵件別名組傳送電子郵件通知，以評估QoS要求或計畫升級以解決重複問題 |
| 舊金山至東京 | 使用IPM和ICMP echo從舊金山到布魯塞爾的當前測量 | 5分鐘內的平均往返響應時間為250毫秒 | 向效能電子郵件別名組傳送電子郵件通知，以評估QoS要求或計畫升級以解決重複問題 |
| 舊金山至布魯塞爾 | 使用IPM和ICMP echo從舊金山到布魯塞爾的當前測量 | 在5分鐘內平均往返響應時間為175毫秒 | 向效能電子郵件別名組傳送電子郵件通知，以評估QoS要求或計畫升級以解決重複問題 |
服務級別定義的最後一個領域是應用程式效能。應用程式效能服務級別定義通常由應用程式或伺服器管理組建立，因為伺服器本身的效能和容量可能是影響應用程式效能的最大因素。網路組織可以通過為網路應用效能建立服務級別定義來實現巨大的好處，因為：
-
服務級別定義和測量有助於消除組之間的衝突。
-
如果為關鍵應用配置了QoS，並且認為其他流量是可選的，則各個應用的服務級別定義非常重要。
如果選擇建立和測量應用程式效能，則最好不要測量伺服器本身的效能。這有助於區分網路問題和應用程式或伺服器問題。使用在Cisco路由器和Cisco IPM上運行的探測器或系統可用性代理軟體來控制資料包型別和測量頻率。
下表顯示了應用程式效能的簡單服務級別定義。
| 應用程式 | 測量方法 | 閾值 | 已採取的行動 |
|---|---|---|---|
| 企業資源規劃(ERP)應用TCP埠1529布魯塞爾至SF | 使用IPM測量埠1529往返效能布魯塞爾到SFO網關2的網關 | 在5分鐘內平均往返響應時間為175毫秒 | 向效能電子郵件別名組傳送電子郵件通知，以評估問題或規劃針對重複問題的升級 |
| ERP應用TCP埠1529 Tokyo到SF | 使用IPM測量埠1529往返效能布魯塞爾到SFO網關2的網關 | 5分鐘內的平均往返響應時間為200毫秒 | 向效能電子郵件別名組傳送電子郵件通知，以評估問題或規劃針對重複問題的升級 |
| 客戶支援應用程式TCP埠1702 Sydney到SF | 使用IPM測量埠1702往返效能雪梨至舊金山SFO網關1的網關 | 5分鐘內的平均往返響應時間為250毫秒 | 向效能電子郵件別名組傳送電子郵件通知，以評估問題或規劃針對重複問題的升級 |
第6步：收集指標和監視
除非組織收集度量並監控成功，否則服務級別定義本身毫無價值。在建立關鍵服務級別定義時，定義如何衡量和報告服務級別。衡量服務級別可以確定組織是否達到了目標，還可以確定可用性或效能問題的根本原因。在選擇衡量服務級別定義的方法時，還要考慮目標。有關詳細資訊，請參閱建立和維護SLA。
監視服務級別需要定期召開審查會議（通常每個月）來討論定期服務。討論所有指標及其是否符合目標。如果他們不符合要求，則確定問題的根本原因並實施改進。您還應介紹當前在改善個人情況方面的舉措和進展。
建立和維護SLA
服務級別定義是一個極好的構建塊，因為它有助於在整個組織內建立一致的QoS並有助於提高可用性。下一步是SLA，這是一項改進，因為它們將業務目標和成本要求與服務品質直接聯絡起來。然後，構建完善的SLA通過為網路問題或問題維護清晰的流程和程式，成為使用者群和支援小組之間效率、品質和協同作用的模型。
SLA提供以下幾個好處：
-
SLA建立了雙向服務責任制，這意味著使用者和應用組也對網路服務負責。如果他們不幫助建立特定服務的SLA並與網路組溝通業務影響，則他們實際上可能要對問題負責。
-
SLA有助於確定滿足業務需求所需的標準工具和資源。在沒有SLA的情況下，決定使用多少人以及使用哪些工具通常是預算猜測。服務可能設計過度，導致過度支出；也可能設計不足，導致無法實現業務目標。調整SLA有助於實現平衡的最佳級別。
-
有文檔記錄的SLA為設定服務級別期望值提供了更清晰的工具。
我們建議在建立服務級別定義後生成SLA的以下步驟：我們建議在建立服務級別定義後生成SLA的以下步驟：
7.滿足SLA的先決條件。
8.確定SLA中涉及的各方。
9.確定服務要素。
10.瞭解客戶的業務需求和目標
11.定義每個組所需的SLA。
12.選擇SLA的格式
13.開發SLA工作組
14.舉辦工作組會議並起草SLA。
15.協商SLA。
16.測量並監測SLA遵守情況。
第7步：滿足SLA的前提條件
IT SLA開發專家確定了成功完成SLA的三個先決條件。遺憾的是，不滿足這些目標的組織可能會遇到SLA流程的問題，應該考慮SLA流程涉及的潛在問題。如果網路組織能夠構建滿足一般業務要求的服務級別定義，則未能實施SLA不會造成不利影響。以下是SLA流程的前提條件：
-
您的企業必須具有以服務為導向的文化。
組織必須首先滿足客戶的需求。您需要自上而下的服務優先承諾，以便全面瞭解客戶的需求和看法。進行客戶滿意度調查和客戶驅動的服務計畫。
另一個服務指標可能是組織將服務或支援滿意度作為企業目標。這種情況並不罕見，因為IT組織現在與組織的整體成功密切相關。
服務文化非常重要，因為SLA流程從根本上講是根據客戶需求和業務需求進行改進。如果組織過去沒有這樣做，他們會發現SLA流程很困難。
-
客戶/業務計畫必須推動所有IT活動。
公司的願景或使命陳述必須與客戶和業務計畫保持一致，然後這些計畫推動所有IT活動，包括SLA。網路經常用於實現特定目標，但網路組卻忽略了該目標及後續的業務要求。在這些情況下，為網路分配一個固定的預算，這可能會對當前需求做出過度反應或嚴重低估需求，從而導致故障。
當客戶/業務計畫與IT活動相匹配時，網路組織可以更輕鬆地適應新應用程式的推出、新服務或其他業務需求。關係以及實現企業目標的共同總體關注點已經存在，所有團隊都作為一個團隊來執行。
-
您必須承諾遵守SLA流程和合約。
首先，必須承諾學習SLA流程以制定有效的協定。其次，您必須遵守合約中的服務要求。不要期望在沒有相關人員的大量投入和承諾的情況下建立強大的SLA。此承諾還必須來自管理層以及與SLA流程關聯的所有個人。
第8步：確定SLA中涉及的各方
企業級網路SLA在很大程度上取決於網路元素、伺服器管理元素、服務檯支援、應用程式元素以及業務或使用者要求。通常，SLA流程將涉及每個區域的管理。當組織構建基本被動支援SLA時，此方案可以很好地發揮作用。在SLA過程中，可用性要求較高的企業組織可能需要技術援助，以幫助解決可用性預算、效能限制、應用程式分析或主動管理功能等問題。要獲得更主動的管理SLA，我們建議網路架構師和應用程式架構師組成技術團隊。技術援助可以更接近網路的可用性和效能能力以及實現特定目標所需的內容。
服務提供商SLA通常不包括使用者輸入，因為它們建立的唯一目的是獲得其他服務提供商的競爭優勢。在某些情況下，高層管理人員會以非常高的可用性或高效能級別建立這些SLA，以提升其服務並為內部員工提供內部目標。其他服務提供商將專注於通過建立內部測量和管理的、強大的服務級別定義來提高可用性的技術方面。在其他情況下，兩種努力同時進行，但不一定同時進行，或者目標相同。
選擇SLA中涉及的各方應基於SLA的目標。一些可能的目標是：
-
滿足被動支援業務目標
-
通過定義主動式SLA提供最高級別的可用性
-
促銷或銷售服務
第9步：確定服務元素
主要服務/支援SLA通常包含許多元件，包括支援級別、如何衡量SLA、SLA協調升級路徑以及總體預算問題。高可用性環境的服務要素應包括主動服務定義以及被動目標。其他詳細資訊包括：
-
現場支援工作時間和非工作時間支援流程
-
優先順序定義，包括問題型別、開始解決問題的最長時間、解決問題的最長時間以及上報過程
-
要支援的產品或服務，按業務關鍵程度排序
-
支援專業知識期望、效能級別期望、狀態報告以及使用者解決問題的責任
-
地理或業務部門支援級別問題和要求
-
問題管理方法和程式（呼叫跟蹤系統）
-
幫助台目標
-
網路錯誤檢測和服務響應
-
網路可用性測量和報告
-
網路容量和效能測量與報告
-
衝突解決程式
-
為已實施的SLA提供資金
基於使用者組要求和業務關鍵性，網路應用程式或服務SLA可能有其他需求。網路組織必須密切關注這些業務需求，並開發適合整體支援結構的專業解決方案。融入整體支援文化至關重要，因為重要的是不要建立僅針對某些個人或群體的高級服務。在許多情況下，這些附加要求可劃分為「解決方案」類別。例如，基於業務需求的白金、金和銀解決方案就屬於這種情況。有關特定業務需求的SLA要求，請參閱以下示例。
註：支持結構、上報路徑、幫助台程式、衡量標準和優先順序定義應基本保持不變，以保持和改進一致的服務文化。
-
突發流量所需的頻寬要求和功能
-
效能要求
-
QoS要求和定義
-
構建解決方案矩陣的可用性要求和冗餘
-
監測和報告要求、方法和程式
-
應用程式/服務元素的升級條件
-
預算外所需經費供資或交叉收費方法
例如，您可以為WAN站點連線建立解決方案類別。白金解決方案將同時提供到站點的兩個T1服務。不同的運營商將提供每條T1線路。該站點將配置兩台路由器，這樣在任何T1或路由器發生故障時，站點不會出現中斷。Gold服務有兩個路由器，但將使用備份幀中繼。此解決方案在中斷期間可能具有有限的頻寬。銀級解決方案將只有一個路由器和一個運營商服務。任何這些解決方案都將被考慮用於問題單的不同優先順序。如果停機需要優先順序為1或2的票證，有些組織可能需要白金或金級解決方案。然後，客戶組織可以為其所需的服務級別提供資金。下表顯示了一個組織示例，該組織根據企業對外網連線的需求提供三種級別的服務。
| 解決方案 | 白金 | 金牌 | 銀牌 |
|---|---|---|---|
| 裝置 | 用於廣域網連線的冗餘路由器 | 用於在核心站點進行備份的冗餘路由器 | 無裝置冗餘 |
| WAN | 冗餘T1連線，多個運營商 | 使用幀中繼備份的T1連線 | 無WAN冗餘 |
| 頻寬要求和突發 | 冗餘的T1，具有突發負載分擔功能 | 無負載共用，僅針對關鍵應用程式的幀中繼備份；僅幀中繼64K CIR | 最多T1 |
| 效能 | 一致的100毫秒往返響應時間或更短 | 響應時間100毫秒或更短，預期為99.9% | 響應時間100毫秒或更短，預期為99% |
| 可用性要求 | 99.99% | 99.95% | 99.9% |
| 關閉時的服務檯優先順序 | 優先順序1:關鍵業務服務關閉 | 優先順序2:影響業務的服務中斷 | 優先順序3:業務連線中斷 |
步驟10:瞭解客戶的業務需求和目標
此步驟為SLA開發人員帶來了極大的可信度。通過瞭解各個業務組的需求，初始SLA文檔將更接近業務需求和期望的結果。嘗試瞭解客戶服務的停機成本。以生產率、收入和客戶商譽損失來估計。請記住，即使與少數人建立簡單的聯絡也會嚴重影響收入。在這種情況下，一定要幫助客戶瞭解可能出現的可用性和效能風險，以便組織更好地瞭解其所需的服務級別。如果您錯過此步驟，可能會讓許多客戶要求百分之百的可用性。
SLA開發人員還應瞭解組織的業務目標和增長，以便適應網路升級、工作負載和預算編制。瞭解將要使用的應用程式也非常有用。希望組織能夠瞭解每個應用程式的應用程式配置檔案，但如果沒有，則考慮對應用程式進行技術評估，以確定與網路相關的問題。
步驟11:定義每個組所需的SLA
主要支援SLA應包括關鍵業務單位和功能組表示，如網路操作、伺服器操作和應用程式支援組。應根據業務需要及其在支援過程中的作用來確認這些組。由許多群體代表也有助於在沒有群體偏愛或優先考慮的情況下建立一個公平的整體支援解決方案。這會導致支援組織向各個組提供高級服務，這可能會破壞組織的整體服務文化。例如，客戶可能堅持認為其應用程式在公司內是最關鍵的，而實際上，該應用程式的停機成本在收入損失、工作效率損失以及客戶商譽損失方面遠遠低於其他應用程式。
組織內不同的業務部門將有不同的要求。網路SLA的一個目標應該是就一種適合不同服務級別的總體格式達成一致。這些要求一般是可用性、QoS、效能和MTTR。在網路SLA中，處理這些變數的方法是：為業務應用程式排定優先順序，以便進行潛在QoS調整；為不同網路影響問題的MTTR定義幫助台優先順序；開發有助於處理不同可用性和效能要求的解決方案矩陣。企業製造公司的簡單解決方案矩陣的示例可能類似於下表。您可以新增有關可用性、QoS和效能的資訊。
| 業務部門 | 應用程式 | 停機成本 | 關閉時的問題優先順序 | 伺服器/網路要求 |
|---|---|---|---|---|
| 製造業 | ERP | 高 | 1 | 最高冗餘 |
| 客戶支援 | 客戶服務 | 高 | 1 | 最高冗餘 |
| 工程 | 檔案伺服器，ASIC設計 | 中 | 2 | LAN核心冗餘 |
| 市場行銷 | 檔案伺服器 | 中 | 2 | LAN核心冗餘 |
步驟12:選擇SLA的格式
SLA的格式可能因組願望或組織要求而異。以下是網路SLA的推薦示例大綱：
-
協定的目的
-
參與協定的各方
-
協定的目標和目的
-
-
提供的服務和支援的產品
-
幫助台服務和呼叫跟蹤
-
基於MTTR定義的業務影響的問題嚴重性定義
-
QoS定義的業務關鍵型服務優先順序
-
根據可用性和效能要求定義解決方案類別
-
培訓要求
-
容量規劃要求
-
上報要求
-
報告
-
提供的網路解決方案
-
新解決方案請求
-
不受支援的產品或應用程式
-
-
業務策略
-
在工作時間提供支援
-
工時後支援定義
-
假日保險
-
聯絡人電話號碼
-
工作負載預測
-
申訴解決
-
服務授權標準
-
使用者和組安全責任
-
-
問題管理程式
-
呼叫發起（使用者和自動）
-
一級響應和呼叫修復率
-
呼叫跟蹤和記錄儲存
-
呼叫方責任
-
問題診斷和呼叫關閉要求
-
網路管理問題檢測和服務響應
-
問題解決類別或定義
-
慢性問題處理
-
嚴重問題/異常呼叫處理
-
-
服務品質目標
-
品質定義
-
度量定義
-
品質目標
-
按問題優先順序開始解決問題的平均時間
-
按問題優先順序解決問題的平均時間
-
按問題優先順序更換硬體的平均時間
-
網路可用性和效能
-
管理容量
-
管理增長
-
品質報告
-
-
人員配置和預算
-
人員配備模式
-
運營預算
-
-
協定維護
-
一致性稽核計畫
-
業績報告和審查
-
報告指標的調節
-
定期SLA更新
-
-
批准
-
附件和展覽
-
呼叫流程圖
-
升級矩陣
-
網路解決方案矩陣
-
報告示例
-
步驟13:開發SLA工作組
下一步是確定SLA工作組中的參與者，包括組領導。工作組可包括來自業務單位或職能組的使用者或經理或來自地理位置的代表。這些人員會將SLA問題傳達給各自的工作組。能夠就關鍵SLA要素達成一致的管理人員和決策者應參與其中。這些人員可能包括管理和技術人員，他們可以幫助定義與SLA相關的技術問題並制定IT級別的決定（例如，服務檯經理、伺服器運營經理、應用程式經理和網路運營經理）。
網路SLA工作組還應包括廣泛的應用和業務表示，以便就包含許多應用和服務的網路SLA達成一致。工作組應有權對網路的業務關鍵型流程和服務以及各個服務的可用性和效能要求進行排名。此資訊將用於為影響業務的不同問題型別確定優先順序、確定網路中關鍵業務流量的優先順序，並根據業務需求建立未來的標準網路解決方案。
步驟14:召開工作組會議並起草SLA
工作組最初應建立一個工作組章程。憲章應闡明SLA的目標、計畫和時間框架。接下來，小組應制定具體的任務計畫，並確定制定和實施SLA的時間表和時間表。該小組還應制定報告程式，根據支助標準衡量支助水準。最後一步是建立SLA協定草案。
網路SLA工作組最初應每週舉行一次會議以制定SLA。在建立和批准SLA後，組可以每月甚至每季度進行SLA更新。
步驟15:協商SLA
建立SLA的最後一步是最終協商和簽核。此步驟包括：
-
審閱草稿
-
協商內容
-
編輯和修訂文檔
-
獲得最終批准
這個稽核草案、協商內容和進行修訂的週期可能需要多個週期才能將最終版本傳送給管理層批准。
從網路管理者的角度來看，協商可衡量的可實現結果非常重要。嘗試備份與其他相關組織的效能和可用性協定。這可能包括品質定義、測量定義和品質目標。請記住，新增的服務相當於額外費用。確保使用者組瞭解附加服務級別會花費更多成本，並讓使用者組決定它是不是一項關鍵的業務需求。您可以輕鬆對SLA的許多方面執行成本分析，例如硬體更換時間。
步驟16:測量和監視SLA一致性
衡量SLA一致性和報告結果是SLA流程的重要方面，有助於確保長期一致性和結果。我們通常建議SLA的任何主要組成部分都是可測量的，並且在SLA實施之前應先制定測量方法。然後，在使用者和支援小組之間召開月度會議，以審查衡量結果、確定問題根本原因，並提出滿足或超過服務級別要求的解決方案。這有助於使SLA過程類似於任何現代品質改進計畫。
下一節提供了更多詳細資訊，說明組織內的管理層可以如何評估其SLA及其總體服務級別管理。
服務級別管理績效指標
服務級別管理績效指標提供了一種機制，可以監控和改進服務級別，以此作為衡量成功的標準。這使組織能夠更快地響應服務問題，並更輕鬆地瞭解影響其環境中服務或停機成本的問題。不衡量服務級別定義也會否定任何積極主動的工作，因為組織被迫採取被動的姿態。沒有人會打電話說服務運行良好，但許多使用者會打電話說服務不符合他們的要求。
因此，服務級別管理績效指標是服務級別管理的主要要求，因為它們提供了充分瞭解現有服務級別並根據當前問題做出調整的方法。這是提供主動支援和提高品質的基礎。當組織對問題進行根本原因分析並改進品質時，這便可能是改善可用性、效能和可用服務品質的最佳方法。
例如，請考慮以下真實場景。X公司收到大量使用者投訴，稱網路經常中斷很長時間。通過衡量可用性，該公司發現主要的問題是幾個WAN站點。對這些景點的進一步調查發現，大多數問題都發生在幾個WAN站點。找到根本原因，組織解決了問題。然後，組織為可用性設定服務級別目標，並與使用者組達成協定。由於不符合SLA，將來的測量將快速發現問題。然後，網路團隊被視為具有更高的專業性、專業知識以及組織的整體資產。本集團有效地從被動轉向主動，幫助實現公司盈利。
遺憾的是，如今大多數網路組織的服務級別定義有限，而且沒有效能指標。因此，他們將大部分時間用於應對使用者投訴或問題，而不是主動發現根本原因並構建滿足業務要求的網路服務。
使用以下SLA績效指標確定服務級別管理流程的成功：
-
記錄的服務級別定義或SLA包括可用性、效能、被動服務響應時間、問題解決目標和問題升級
-
效能指標指標，包括可用性、效能、按優先順序劃分的服務響應時間、按優先順序劃分的解決時間以及其他可衡量的SLA引數
-
每月召開網路服務級別管理會議，審查服務級別合規性並實施改進
記錄的服務級別協定或服務級別定義
第一個績效指標只是詳述SLA或服務級別定義的文檔。服務級別定義的主要目標應該是可用性和效能，因為這些是主要的使用者要求。
次要目標很重要，因為它們有助於定義如何實現可用性或效能級別。例如，如果組織制定了嚴格的可用性和效能目標，則防範問題發生並在問題發生時快速修復問題將非常重要。次要目標有助於定義實現所需的可用性和效能級別所需的流程。
被動輔助目標包括：
-
按呼叫優先順序的被動服務響應時間
-
問題解決目標或MTTR
-
問題上報程式。
主動輔助目標包括：
-
裝置關閉或鏈路關閉檢測
-
網路錯誤檢測
-
檢測容量或效能問題。
主要目標、可用性和效能的服務級別定義應包括：
目標
-
如何衡量目標
-
負責衡量可用性和效能的各方
-
負責可用性和績效目標的各方
-
不符合項進程
如果可能，我們建議負責衡量工作的各方和負責結果的各方應該不同，以防止利益衝突。由於新增/移動/更改錯誤、未檢測到的錯誤或可用性度量問題，您有時可能需要調整可用性編號。服務級別定義還可包括用於修改結果以幫助提高準確性和防止不適當的調整的處理。請參見下一節，瞭解測量可用性和效能的方法。
被動輔助目標的服務級別定義定義了確定網路或IT範圍的問題後，組織將如何應對，包括：
-
問題優先順序定義
-
按呼叫優先順序的被動服務響應時間
-
問題解決目標，或MTTR
-
問題上報程式
一般而言，這些目標明確規定了誰在任何給定時間負責問題，以及責任人應該在多大程度上放棄當前任務來處理已定義的問題。與其他服務級別定義一樣，服務級別文檔應詳細說明如何衡量目標、負責衡量的人員，以及不符合項的流程。
主動輔助目標的服務定義定義組織如何提供主動支援，包括識別網路故障、鏈路故障或裝置故障情況、網路錯誤情況以及網路容量閾值。設定促進主動管理的目標，因為高品質的主動管理有助於消除問題並幫助更快地解決問題。這通常是通過設定一個目標，即無需使用者通知即可建立和解決多少主動案例。許多組織在幫助台軟體中設定標誌，以識別主動案例與被動案例。服務級別文檔還應包含有關如何衡量目標、負責衡量的人員，以及不符合項流程的資訊。
績效指標度量
我們始終建議應可衡量任何已定義的服務級別目標，讓公司可以測量服務級別，確定妨礙可用性和效能這一主要目標的根本原因服務問題，並針對具體目標進行改進。總而言之，度量只是一個工具，它使網路經理能夠管理服務級別一致性，並根據業務需求做出改進。
遺憾的是，許多組織沒有收集可用性、效能和其他指標。組織將此歸因於無法提供完整的準確性、成本、網路開銷和可用資源。這些因素可能會影響衡量服務級別的能力，但企業或機構應關注管理和提高服務級別的總體目標。許多組織已經能夠建立低成本、低開銷的指標，這些指標可能無法提供完整的準確性，但確實滿足了這些主要目標。
衡量可用性和效能是服務級別度量中經常忽略的一個方面。成功使用這些度量的組織使用兩種非常簡單的方法。其中一種方法是將網際網路控制訊息通訊協定(ICMP)Ping封包從網路中的核心位置傳送至邊緣。還可以使用此方法獲得效能。成功使用此方法的組織還將類似裝置劃分為「可用性組」，例如LAN裝置或國內現場辦公室。這也很有吸引力，因為組織通常針對網路的不同地理區域或業務關鍵領域有不同的服務級別目標。這樣，度量組就可以對具有可用性組的所有裝置求平均值，以獲得合理的結果。
計算可用性的另一種成功方法是使用故障單和稱為「受影響的使用者分鐘數」(IUM)的衡量標準。 此方法將受服務中斷影響的使用者數製表，並將其乘以服務中斷的分鐘數。如果用該時間段內總分鐘數的百分比表示，則可以將其輕鬆轉換為正常運行率。無論哪種情況，識別和測量故障時間的根本原因都非常有用，這樣可以更容易地確定改進的目標。根本原因類別包括硬體問題、軟體問題、鏈路或運營商問題、電源或環境問題、更改故障和使用者錯誤。
可衡量的被動支援目標包括：
-
按呼叫優先順序的被動服務響應時間
-
問題解決目標，或MTTR
-
問題升級時間
通過從服務檯資料庫生成報告來衡量被動支援目標，包括以下欄位：
-
最初報告呼叫（或輸入到資料庫）的時間
-
處理此問題的人員接受呼叫的時間
-
問題升級的時間
-
問題關閉的時間
這些度量可能需要管理影響才能始終如一地輸入資料庫中的問題並即時更新問題。在某些情況下，組織能夠自動生成網路事件故障單或電子郵件請求。這有助於準確地確定問題的開始時間。從這種度量生成的報告通常會按優先順序、工作組和個人對問題進行分類，以幫助確定潛在的問題。
測量主動支援流程更加困難，因為這要求您監控主動工作並計算其效率的某些度量。這方面的工作很少。但是，很顯然，只有一小部分人確實會向服務檯報告網路問題，並且當他們確實報告了問題時，顯然需要花一些時間解釋問題或確定問題是否與網路相關。並非所有主動預防性案例都會立即影響可用性和效能，原因可能是冗餘裝置或鏈路故障對終端使用者影響不大。
實施主動預防性服務級別定義或協定的組織這樣做是出於業務需求和潛在可用性風險的原因。然後根據主動案例的數量或百分比進行測量，而不是使用者生成的被動案例。最好衡量每個領域的主動案例數量。這些類別包括故障裝置、故障鏈路、網路錯誤和容量違規。也可以使用可用性建模和主動案例完成一些工作，以確定通過實施主動服務定義對可用性產生的影響。
服務級別管理審查
衡量服務級別管理成功的另一個標準是服務級別管理審查。無論SLA是否到位，都應這樣做。在與負責衡量和提供已定義服務級別的人員每月開會時，執行服務級別管理審查。涉及SLA時也可能存在使用者組。會議的目的是審查所衡量服務級別定義的效能並做出改進。
每次會議應有一個確定的議程，其中包括：
-
對給定期間測量的服務級別進行稽核
-
審查為各個領域確定的改進舉措
-
當前服務級別指標
-
根據當前的一組指標討論需要哪些改進。
隨著時間的推移，組織還可以對服務級別合規性進行趨勢分析，以確定組的有效性。此過程與品質循環或品質改進過程並無不同。此會議有助於確定個別問題，並根據根本原因確定解決方案。
服務級別管理摘要
總之，服務級別管理允許組織從被動支援模式轉變為主動支援模式，在此模式中，網路可用性和效能級別由業務需求（而不是最新的一組問題）決定。該流程有助於建立一個不斷提高服務級別和增強業務競爭力的環境。服務級別管理也是主動網路管理最重要的管理元件。因此，強烈建議在任何網路規劃和設計階段都進行服務級別管理，而且應該從任何新定義的網路體系結構開始。這使組織能夠在第一時間以最少的中斷時間或返工時間正確實施解決方案。
意見