[转]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
• 问题上报时间

通过从帮助台数据库生成报告来测定被动式支持目标，其中包括以下内容：

• 最初生成报告的时间(或输入到数据库的时间)
• 故障负责人收到呼叫的时间
• 故障上报的时间
• 故障处理完毕的时间

这些测定标准可能要求管理部门的干预以在数据库中适当地输入故障信息，并实时对故障信息进行更新。在某些情况下，企业可以为网络事件或电子邮件请求自动生成故障票。这有助于确定生成故障的准确开始时间。

通过这种测定标准生成的报告通过根据优先权、工作组和工作人员来对故障进行分类，以帮助确定潜在问题。

由于测定主动式支持进程要求监控主动式工作并对某些效率测定值进行计算，因此难度比较大。这方面的工作还做得很少。然而，很明显，只有少部分人实际上向帮助台报告网络故障，并且很明显需要时间来对故障进行解释，或将问题归结为与网络有关的问题。因为冗余设备或链路的故障对终端用户的影响较小，所以不是所有的主动式案例都对可用性产生直接的影响。

企业因业务要求和潜在的可用性隐患而执行主动式业务级别定义或协议。然后根据主动式案例与被动式案例的数量或百分比进行测定，被动式案例是由用户生成的。测定每个部分的主动式案例数量是一个很好的理念。这些类别将包括故障设备、故障链路、网络错误和容量超限。还应通过可用性模式来进行某些工作以确定对可用性的影响，可用性是通过执行主动式业务定义来实现的。

业务级别管理审核

业务级别管理是否成功的另一个测定方法是业务级别管理审阅。无论服务水平协议是否可用，都要执行这一步。通过测定负责人和提供定义的业务级别在每月一次的例会上对业务级别管理进行审阅。当涉及到服务水平协议时，用户组也可以加入进来。会议的目的是审阅测定的业务级别定义的性能，并进行相应的整改。

每个会议应有一个确定的工作计划，其中包括：

• 指定时间段内测定的业务级别的审阅
• 某一部分所确定的改进计划的审阅
• 当前业务级别测定标准
• 需要根据当前的测定标准对改进方案进行讨论

随着时间的推移，企业还可以分析业务级别适应性趋势以确定部门的效率。此进程不属于质量范畴或质量改进程序。会议有助于针对具体问题，并根据根本原因来确定解决方案。

业务级别管理摘要

总之，业务级别管理逐渐使企业从被动支持模式变为主动支持模式，在这种模式下，网络可用性和业务级别由业务要求来确定，而不是由最近的一系列故障来确定。该进程有助于建立一个不断提高业务级别的环境，并提高企业的竞争力。另外，业务级别管理还是主动网络管理的最重要组成部分。因此，我们极力建议在任何网络规划和设计过程中都采用业务级别管理，并在最新定义的网络结构中采用。这可以使企业在开始阶段就能正确地执行解决方案，并使故障时间和重复工作量降到最低。