服务水平管理和服务水平协议

服务水平管理和服务水平协议（SLA）

•服务水平管理概述

网络公司一直以来都通过构建坚实的网络基础设施及积极解

决每个业务问题来满足不断扩展的网络规定。当业务异常中断

时，公司将构建新流程、管理功能或基础设施来防止此类故障

再次发生。然而，由于快速变更及日益增长的可用性规定，我

们现在需要改善模式来预先防止意外故障并快速修复网络。许

多服务供应商和公司一直都试图更好地定义服务水平以便实

现商业目的。

关键成功因素

SLA的关键成功因素用来定义支持成功构建可获得的服务水平

及维护SLA的重要要素。要成为合格的关键成功因素，流程或

流程环节必须可以改善SLA质量并从整体上提高网络的可用

性。关键成功因素还应具有可测量性，以便使公司可以判断：

与定义的程序相比，它所取得的成功限度。

性能指标

性能指标提供了公司测量关键成功因素的机制。您通常需要每

月审查一次，以保证服务水平定义或SLA运营良好。网络运营

小组及必要的工具组可实行以下测量标准。

注意：对于没有SLA的公司，我们建议您同时实行服务水平定

义、服务水平审核及测量标准。

性能指标涉及：

•记录的服务水平定义或SLA,涉及可用性、性能、积极业务应

答时间、排障目的及问题升级等。

•月度网络服务水平审核会议，审核对服务水平的执行情况并实

行改善。

•性能指标测量标准，涉及可用性、性能、按优先级划分的业务

应答时间、按优先级划分的排障时间以及其他可测量的SLA参

数。

•服务水平管理流程

面向服务水平管理的高级别流程重要涉及两组：

1.定义网络服务水平

2.创建并维护SLA

实行服务水平管理

实行服务水平管理涉及十六步，分为以下两个重要范畴：

•定义网络服务水平一环节1-6

•创建并维护SLA一环节7-16

•定义网络服务水平

网络管理人员需要定义支持、管理并测量网络的重要规则。服

务水平为所有网络人员提供目的并可用作整体业务质量的测

量标准。您也可将服务水平定义用作网络资源预算工具以及投

资于更高服务质量的证据。它们还提供评估供应商及运营商的

表现的方法。

假如没有服务水平定义和测量，公司不也许制定明确的目的。

服务是否满意由用户决定，在应用、服务器/客户机运营或网

络支持方面并无明显差距。由于公司对最终结果没有把握，因

此很难作预算。最终，网络公司在提高网络及支持模式方面都

趋向于选择被动应答，而非积极防止的方式。

我们建议采用以下环节来构建并支持服务水平模式：

•分析技术目的及限制因素。

•拟定可用性预算。

•创建具体记录关犍应用网络特性的应用资料库。

•定义可用性、性能衡量标准及通用术语。

.创建服务水平定义，涉及可用性、性能、业务应答时间、排障

平均时、故障检测、升级门限及上报途径。

•收集测量标准并监控服务水平定义。

•第1步：分析技术目的及限制因素

开始分析技术目的和限制因素的最佳方式是集体讨论或研究

技术目的与规定。由于这些人都有特定的业务目的，所以有时

这有助于规定其他IT技术人员参与讨论。技术目的涉及可用

性级别、吞吐量、抖动、延迟、应答时间、可用性规定、新特

•当前的话务负载或应用行为

网络技术、故障恢复能力及配置限制

因素是指与当前技术、硬件、链路、

设计或配置相关的任何限制因素或风

险。技术限制因素指技术自身导致的

任何限制。例如，当前没有一种技术

允许冗余网络环境中实现少于1秒的

聚合时间，而这恰恰是维持整个网络

上的话音连接的关键。另一个例子是

数据通过地面链路时的原始速度，大

约是100英里/毫秒。

限制因素类型潜在影响

网络硬件故障恢复能力风险调查应集

中在硬件拓扑、分级体系、模块化、

冗余、MTBF及定义的途径这几方面。

网络链路限制因素应强调公司网络链

路及运营商连接。链路限制因素也许

涉及链路冗余和多样性、媒介限制、

布线基础设施、本地环路连接性以及

长距离连接性。设计限制因素与网络

的物理或逻辑设计相关，涉及从为设

备可用空间到路由协议实行的可扩展

性等各个方而。您应在配置、可用性、

可扩展性、性能及容量方面考虑所有

协议和媒介设计动态主机配置协议

(DHCP)、域名系统(DNS)、防火墙、

协议转换及网络地址转换等网络业务

限制因素也应列入考虑之列。

生命周期方案定义用于实现解决方案

的统一部署、检测和修复故障、防止

容量或性能问题以及配置一致性和模

块化的网络流程和管理。您需要认真

考虑这个领域，由于专业技术和流程

通常是导致不可用性的最大影响因

素。网络生命周期指规划、设计、实

行和运营周期。在每个阶段中，您都

必须了解性能管理、配置管理、故障

管理及安全性等网络管理功能。思科

NSA高可用性服务部(HAS)提供网络

生命周期评估服务，拟定与网络生命

周期方案相关的当前网络可用性限制

因素。

当前的话务量或应用限制因素只是指

当前话务和应用的影响。

不幸的是，许多应用都带有大量需要

慎重管理的限制因素。当前应用的抖

动、延迟、吞吐量及带宽规定通常带

有许多限制因素。编写应用的方式也

也许产生一些限制因素。汇编应用资

料库可帮您更好地了解这些问题；下

文将介绍这一特性。研究当前的可用

性、话务、容量及性能还可帮助网络

管理人员了解当前的服务水平目的及

风险。这一工作常通过名为网络基准

制定的流程来完毕，该流程可帮您定

义规定期段内（通常是一个月）的平

均网络性能、可用性或容量。这些信

息通常用于容量规划和趋势分析，但

也可用来了解服务水平问题。

下面的工作表使用了上述目的/限制

因素方法来实现防止安全性袭击或拒

绝服务袭击（DoS）的目的。您也可使

用该工作表来决定可最大限度地减少

安全性袭击的业务范围。

风险或限制因素

可用的DoS检测工具无法检测出所有DoS袭击类型。技术/故障恢更能力高

不具有对告警做出相应所需的人员和流程。生命周期方案高

当前网络接入策略未加执行。牛.命周期方案一般

假如运用带宽拥塞来发动袭击，则当前的低带宽互联网连

接成为限制因素。网络容量一微

帮助防止袭击的当前安全性配理不完善。技术/故障恢复能力一般

•第2步：拟定可用性预算

可用性预算是盼望在定义的两点间出现的、理论上的网络可用

性。准确的理论信息可在多个方面发挥作用：

•公司可将其视为内部可用性目的，并且可以立刻定义偏离并进

行补救。

•网络规划人员可使用这些信息来拟定系统的可用性，以保证设

计满足商业规定。

.导致不可用性或故障停机的因素涉及软硬件故障、电源和环境

问题、链路或运营商故障、网络设计、人为错误或缺少流程等。

在评估网络的整体可用性预算时，您必须严格评估上述的所有

参数。

假如公司目前正在测量可用性，则也许不需要可用性预算。用

可用性测量标准作为基准来评估服务水平定义使用的当前服务

水平。然而，您可将两者进行对比，以便了解潜在的理论可用

性与实际测量结果间的差距。

可用性指产品或业务在需要时投入运营的也许性。参见以下定

义：

a.可用性

-1-（总的连接中断时间）/（总服务连接时间）

,*I-［总和（业务中断期间受影响的连接数量X业务中断时

间）］/（运营的连接数量X运营时间）

b.不可用性

1-由以下因素导致的可用性或总的连接中断时间：软硬件故障、

电源和环境问题、链路和运营商故障、网络设计、用户错误及

流程故障等。

c.硬件可用性

一方面需要研究的领域是潜在硬件故障及其对不可用性的影

响。要拟定这方面的影响，公司应了解所有网络组件的MTBF

以及MTTR,以拟定两点间的途径中所有设备的潜在硬件问题。

假如网络采用模块化和分级体系结构，则几乎任意两点间的硬

件可用性都是相同的。MTBF信息可用于所有思科组件，并且可

根据请求、向本地客户经理提供。CiscoNSAHAS项目还使用

一种工具来帮助拟定硬件可用性及网络途径，即使在系统中存

在模块冗余、机底冗余及途径冗余时也可以使用这种工具。硬

件可靠性的一个重要因素是MTTRO公司应评估它们修复故障硬

件的速度。假如公司未制定备用方案，只依赖于标准Cisco

SMARTnet?协议，则潜在的评估硬件更换时间为24小时。在带

有核心冗余但不带有接入。

冗余的典型LAN环境中，适当的可用性是99.99%,平均修复

时间是4-小时。

d.软件可用性

下一个需要研究的领域是软件故障。出于测量的目的，思科将

软件故障定义为由软件错误引发的设备冷启动。思科已经开发

出许多流程来帮助了解软件的可用性；然而，更新的版本尚需

一段时间进行测量，并且我们认为它的可用性不及一般的部署

软件。IOS11.2版（18）等一般部署软件经测量，证明具有

99.9999%的可用性。这个数字是基于修复时间为六分钟（路由

器重新装载的时间）的思科路由器的实际冷启动次数来计算的。

采用不同版本的公司，可用性将随着复杂性的增长、互操作性

的增强以及排障时间的缩短略有减少。采用最新软件版本的公

司，不可用性将有所提高。不可用性的分派也相称广泛，这意

味着客户将感觉到很高的不可用性或接近一般部署版本的可用

性。

e.环境和电源的可用性

您还必须考虑环境和电源的可用性问题。环境问题与将设备保

持在特定的运营温度范围内的冷却系统的故障相关。当温度大

大超过技术指标时，许多思科设备只是停止运转，而不会损害

所有硬件。出于可用性预算的目的，您必须将电源考虑在内，

由于它是导致本领域中不可用性的重要因素。

虽然电源故障是导致网络不可用性的重要因素，但对它的讨论

还是受到限制，这是由于无法进行准确的、理论上的电源分析。

公司必须基于所在地区的经验、电源备份功能以及实行的流程,

对其设备的电源可用性的大约测量结果进行评估，以保证为所

有设备提供具有一致质量的电源。

基于保守的估计，我们可以认为配备了备用发电机、不间断供

电电源（UPS）系统并采用合格电源实行流程的公司，可实现高

达六个九（99.9999%）的可用性，而未配备这些系统的公司，其

可用性仅为99.99%,或者说每年有36分钟的故障停机时间。

当然，您可根据公司的观测或实际数据来调整这些数值，使其

更真实地反映公司的具体情况。

f.链路或运营商故障

链路和运营商故漳是影响WAN环境中的可用性的重要因素,牢

记：WAN环境只是同公司网络遭遇同样可用性问题的其他网络,

涉及：软硬件故障、用户错误及电源故障等。

许多运营商网络都已经开始对系统进行可用性预算，但获得这

些信息并不容易。牢记，运营商的可用性保证级别很少基于或

主线不基于实际可用性预算。这些保证级别有时只是用来提高

运营商知名度的营销和销售方法。在某些情况下，这些网络还

公布看似互相突出的可用性记录数据。牢记，这些记录数据也

许只合用于完全冗余的核心网络，而不作为导致不可用性的因

素（不可用性由本地环路接入引起），本地环路接入才是WAN

网络中不可用性的重要因素。

对WAN环境进行可用性评估应基于实际的运营商信息以及WAN

连接的冗余级别。假如公司拥有多个大楼入口设施，冗余本地

环路供应商、同步光网络（SONET）本地接入、以及分布在多个

地区的冗余长途运营商，则WAN的可用性将得到明显增强。

电话业务是WAN环境中、非冗余网络连接相称准确的可用性预

算。使用类似于本文所描述的可用性预算方法进行测量，电话

业务的端到端连接的可用性预算大约为99.94%o这种方法业己

成功应用于数据环境中，结果基本相同，目前正被用作服务供

应商有线网络中分组有线规程的预算。假如将该数值用于完全

冗余的系统，则我们可以假定，WAN可用性会接近99.9999%。

当然，由于成本及可用性问题，目前很少有哪家公司部署了分

布在多个地区且完全冗余的WAN系统，所以应使用适当的判断

方法测定这种功能。

LAN环境中不太也许发生链路故障，然而，规划人员也许希望

假定连接器断开或松动会引发短时间的故障停机。对LAN网络

而言，保守的可用性估计约为99.9999%,或大约30秒故障停

机/年。

g.网络设计

网络设计是影响可用性的另一个重要因素。不可扩展的设计、

设计错误及网络聚合时间都会对可用性产生负面影响。

注意：出于本文的目的，我们将在下面的篇幅中描述不可扩展

的设计或设计错误。

网络设计被限定在可测量的数值上（基于网络中导致话务重新

路由的软硬件故障）。这些数值通常被称作“系统故障切换时

间”，并且是系统中自治愈协议功能的影响因素。

使用与系记录算相同的方法便可计算可用性。然而，它只有在

网络故障切换时间满足网络应用规定期才有效。假如故障切换

时间可以接受，则不把它计算在内。假如故障切换时间不能接

受，则计算时必须将其考虑在内，例如：估计或实际的故障切

换时间为30秒的环境中卜的IP话音（VoIP）。在这个例子中,

用户只是挂断电话，并有也许重新拨叫。用户肯定会将这30

秒看作是非可用时段，但在可用性预算时却未加考虑。

根据系统故障切换时间来计算不可用性时耍着眼于理论的软硬

件可用性以及冗余途径，由于故障切换将出现在这个领域。您

必须了解也许发生故障并导致冗余途径中出现故障切换的设备

数量，这些设备的MTBF以及故障切换时间。一个简朴的例子就

是，冗余的相同设备中，每台设备的WTBF为35433小时，故障

切换时间为30秒。用35,433除以8766（年平均小时数，涉

及闰年），我们可以看出该设备每四年出现一次故障。假如使

用30秒作为故障切换时间，我们便可以假设：由于故障切换，

每台设备每年平均停机7.5秒。由于用户也许会跨两条途径，

因此需要将此结果乘以2,即：每年15秒。当以秒/每年进行

计算时，这个简朴系统中由于故障切换引起的可用性的计算结

果为99.99999785%。由于也许出现故障切换的网络中的冗余设

备数量，在其他环境中，这个数字也许还要略高些。

h.用户错误和流程

用户错误和流程可用性问题是导致公司和运营商网络中不可用

性的重要因素。约80%的不可用性问题是由于无法检测错误、

变化故障及性能问题导致的。

公司在制定可用性预算时:不乐意接受用户错误和流程引发的

不可用性是其他所有理论上的不可用性的四倍这一实行，然而,

各种证据一致表白，这种情况存在于许多环境中。下面我们将

具体阐述不可用性的这个方面。

由于您无法从理论上计算由用户错误和流程引发的不可用性数

量，我们建议您在制定公司力求完美的可用性预算时不将其考

虑在内。但公司必须了解其流程和专业技术水平中现在所面临

的可用性风险。透彻地了解了这些风险及克制因素之后，网络

规划人员便有也许将这些问题引发的一定数量的不可用性考虑

在内。CiscoNSAHAS项目进一步研究了这些问题，并可帮助

公司了解由于流程、用户错误或专业技术问题引发的不可用性。

L制定最终的可用性预算

您可将以前定义的所有领域的可用性相乘来决定整个可用性预

算。这种方法通常合用于任意两点间的连接相类似的同机种环

境，如：分级体系模块化LAN环境或分级体系标准WAN环境等。

这下面的例子中，为分级体系模块化LAN环境拟定了可用性预

算。该环境为所有网络组件都配备了备用发电机和UPS系统，

并对电源进行适当的管理。公司未使用VoIP,也不希望将软件

故障切换时间考虑在内。估算结果如下：

•两个端点间的硬件途径可用性二99.99%

•使用GD软件可靠性作为基准的软件可用性二99.9999%

•带有备用系统的环境和电源可用性=99.999%

・考虑LAN环境中的链路故障的口J用性=99.9999%

•未将系统故障切换时间计算在内的可用性二100%

•认为不存在用户错误和流程缺陷的可用性二100%

•公司希望达成的最终可用性预算是：0.9999X0.999999

X0.999999X0.999999=0.999896,或99.9896%的可用性。

假如我们将用户或流程错误引发的潜在不可用性考虑在内，并

假设其引发的不可用性是技术因素引发的可用性的四倍，则最

终可用性预算是99.95%o

对这个例子的分析使我们了解到，LAN可用性在99.95%与

99.989%之间。现在，这些数值可以用作网络公司的服务水平目

的。可以测量系统中的可用性并拟定上述六个领域分别引发的

不可用性百分率来计算其他数值。这使公司可以对供应商、运

营商、流程和人员进行适当评估。这些数值也可用来设立业务

盼望值。假如您.时99.95%与99.989%之间的可用性不满意，可

投资更多资源来获得抱负的可用性级别。

网络管理人员了解每个特定可用性级别的故障停机时间将大有

帮助。计算任何可用性级别的年故障停机时间（分钟）的公式

如下：

故障停机（分钟）/年二525600—（可用性级别X5256）

假如可用性级别是99.95%,则结果是525600o（99.95X5256）,

或者相称于222.8分钟的故障停机。对于上述可用性定义，这

等于网络中所有业务连接的平均故障停机时间。

第3步：创建应用资料库

应用资料库可帮助网络公司了解并定义每个应用的网络服务水

平规定。这有助于保证网络支持每个应用规定及整体网络业务。

当应用或服务器组指出网络存在问题时，应用资料库还可用作

网络服务支持的书面基准。最后，应用资料库可将性能及可用

性等应用规定与真实的网络业务目的或当前限制因素进行对比,

来调节网络业务目的，使其与商业规定保持一致。这不仅对服

务水平管理很重要，并且对整个网络设计也相称重要。

每次向网络中添加新应用时都应创建应用资料库。您还也许需

要在IT应用部门、服务器管理部门以及组网部门间达成协议，

以便为现有及全新业务创建应用资料库，完毕用于商业应用及

系统应用的应用资料库。商业应用也许涉及电子邮件、文献传

输、Wob浏览、医疗图象解决或制造等。系统应用也许涉及软

件分发、用户鉴权、网络备份及网络管理等。

网络分析员及应用或服务器支持应用小组应负责创建应用资料

库。新应用也许规定使用协议分析程序以及具有延迟模拟功能

的WAN模拟程序来适本地划分应用规定的特性。这有助于拟定

必要带宽、应用可用性的最大延迟及抖动规定。只要您具有所

需服务器，便可在实验室环境中开展这项工作。在VoIP等其他

情况下，涉及抖动、延迟及带宽在内的网络规定会很好地公布,

且无需再进行实验室测试。应用资料库应涉及以卜项目：

•应用名称

•应用类型

•新应用

•业务重要性

•可用性规定

•使用的协议和端口

•估计的用户带宽(kbps)

•用户数量和位置

•文献传输规定(涉及时间、量及端点)

•网络故障停机影响

•延迟、抖动及可用性规定

1.应用资料库的目的是了解应用的商业规定、业务关键性以及带

宽、延迟及抖动等网络规定。此外，网络公司还应了解网络故

障停机的影响。在某些情况下，您也许需要重启应用或服务器，

这将大幅度延长总的应用故障停机时间。完毕应用资料库后，

您可将所有网络功能进行对比，并帮助调节网络服务水平，使

其与商业和应用规定相一致。

第4步：定义可用性及性能标准

可用性及性能标准为公司制定业务盼望值。可根据不同网络区

域或特定应用进行定义这些标准。还可以拟定往返延迟、抖动、

最大吞吐量、带宽承诺及总体可扩展性等方面的性能。此外，为

了制定业务盼望值，公司还应谨慎定义每个业务标准，以便使

致力于网络工作的用户及IT工作组可以全面了解业务标准以

及他们与应用或眼务器管理规定的关系。用户及1T工作组还应

了解如何测量业务标准。

以前服务水平定义环节的结果可以帮助制定标准。这时，网络

公司应明确了解当前网络所面临的风险和限制因素及应用行为,

并进行理论上的可用性分析或制定可用性基准。

2.定义业务标准合用的地理区域或应用领域，也许涉及园区

LAN、本国WAN,外联网及合作伙伴连接等。在某些情况下，公

司在相同区域内的服务水平目的也许有所不同。这对公司或服

务器供应商来说并不罕见。这时，它们通常基于各自的业务规

定制定不同的服务水平标准。这些在同一地理区域或服务区域

中的标准有金牌、银牌和铜牌之分。

定义业

务标准

参数。可

用性及

往返延

迟是最

常见的

网络业

务标准。可接受的

可用性平均网络应答应答时间管理

根据需管理方法最常应答

目的时间目的方法

要，还时间

可以涉

及最大

吞吐量、

最低带

宽承诺、

抖动、接

受的错

误率以

及可扩

展性功

能。当审

核用于

测量方

法的业

务参数

时要特

别谨慎。

无论参

数是否

涉及在

SLA中,

公司都

应考虑

出现问

题或业

务不一

致性时,

如何测

量并证

明业务

参数的

可行性。

完毕对

业务领

域和业

务参数

的定义

后，您

可使用

以前环

节获得

的信息

来构建

业务标

准图。公

司还需

要定义

也许使

用户和

IT工作

组产生

混淆的

区域。例

如，往

返ping

的最长

应答时

间与在

远程位

置单击

回车键

启动特

定应用

的

最长应

答时间

有很大

区别。下

表列出

了美国

采用的

性能目

的：

网名各区

域

受影响的用往返ping应

LAN99.99%5毫秒内10毫秒

户时间答

受影响的用100毫秒内（往往返ping应

WAN99.9%150毫秒

户时间返ping）答

关键

受影响的用100毫秒内（往往返ping应

WAN及99.95%150毫秒

户时间返ping）答

外联网

•第5步：定义网络业务

这是实现基本的服务水平管理的最后一步；它定义您实行用于

实现服务水平目的的被动/积极流程和管理功能。最终文献通

常被称作“运营支持计划”。大多数应用支持计划只涉及被动

支持规定。在高可用性环境中，公司必须考虑采用积极的管理

流程，以便在网络故障发生前对其进行隔离并加以解决解决。

总的来说，最终文献应：

•描述用于实现服务水平目的的被动和积极流程

•介绍业务流程的管理方式

•介绍测量业务目的和业务流程的方式

本部分将描述

许多服务供应严重级别2严重级别3严重级别4

商和公司均需

考虑的积极和

被动业务定义

的实例。构建

服务水平定义

的目的是创建

满足可用性及

性能目的的业

务。为了实现

上述目的，公

司必须构建业

务，并谨记当

前的技术限制

因素、可用性

预算及应用资

料库。特别是,

公司应定义并

构建始终可以

在可用性模式

规定的时间内

快速拟定并排

除故障的业

务。公司还必

须定义可快速

辨认并解决潜

在业务问题的

业务，假如忽

略这些问题，

将对可用性及

性能产生负面

影响。

实现抱负的服

务水平非一朝

一夕之事。专

业水准低、当

前流程限制或

人员不合格等

缺陷将妨碍公

司实现抱负的

标准或目的，

即使在完毕对

以前业务环节

的分析后也是

如此。没有一

种方法可将所

需服务水平与

抱负目的准确

匹配。为了适

应现实情况，

公司应测量业

务标准及用于

支持业务标准

的业务参数。

假如没有达成

业务目的，公

司应运用业务

测量标准来帮

助了解问题。

在许多情况

下，可适当增

长预算以改善

支持业务，并

使这些改善功

能成为实现抱

负业务目的的

必要条件。公

司也许会逐步

进行多次调节

（涉及业务目

的或业务定

义），以使网

络业务与商业

规定保持一

致。

例如，当目的

远远高于

99.9%可用性

时，公司也许

只实现了99%

的可用性。在

服务及支持测

量标准方面，

公司代表发现

硬件替换约需

要24小时,远

远高出最初的

估计的4小时。

此外，公司还

发现积极管理

功能受到忽视

且故障的冗余

网络设计没有

及时修复。公

司发现的问题

尚有缺少实行

改善的员工

等。因此，考

虑减少当前服

务目的后，公

司便投资购买

实现抱负服务

水平所需的其

他资源。业务

定义应同时涉

及积极和被动

支持定义。被

动定义规定公

司如何解决根

据用户投诉或

网络管理功能

中拟定已经发

生的问题。枳

极定义描述公

司如何拟定并

解决潜在的网

络问题，涉及

修复故障的

“备用”网络

组件、错误检

测、容量门限

问题及升级问

题等。以下提

供积极与被动

服务水平定义

实例。

被动服务水平

定义

以下的服务水

平领域通常使

用帮助台数据

库记录数据进

行测量并定期

审计。下表显

示公司故障严

重限度的实

例。请注意：

此表不涉及解

决新业务请求

的方式，这项

工作可通过

SLA或其他应

用资料库编制

及性能假设分

析来完毕。假

如通过相同的

支持流程进行

解决，新业务

请求可以数据

严重级别5o

严重级别1

严重的业务影网络功能的丢失或降某些特定的网络

对公司无业

响级对业务导致严重影功能丢失或降级，

务影响的功

LAN用户或服响，也许需要运营应如：冗余丢失等

能查询或故

务器部分停机变措施园区LAN性能受到

障

严重的WAN站园区LAN故障停机；影响LAN冗余丢

点故障停机5-99名用户受到影响失

国内WA\站点故障停

机

国际WA\站点故障停

机

严重影响性能

完毕问题

严重性级

别定义之

后，定义

或研究创

建业务应

答定义的

支持流程。职责目的

总的来说，

业务应答

定义规定

采用分级

支持结构,

以及帮助

台软件支

持系统来

运用故障

票跟踪问

题。同时还

应为每个

优先级故

障的应答

时间和解

决时间、按

优先级划

分的呼喊

数量以及

应答解决

质量制定

测量标准。

定义支持

流程可帮

助定义公

司内部每

个支持级

别的目的

及其任务

与责任。这

有助于公

司了解用

于每个支

持级别的

资源规定

及专业技

术水平。下

表举例说

明了分级

支持结构

及其问题

解决指导

原则。

支持级别

专职帮助台支持

第1级支接听支持甩话、发放故障票、15分钟

解决40%的入局呼喊

持内解决问题、记录故障票并上报到第

2级支持

队列监控、网络管理、工作站管理

第2级支在第2级解决所有呼

为拟定的软件故障发放故障票

持喊

实行

接听第1级、供应商的电话，并上报

到第3级支持

对呼喊负责，直到排障为止

必须立刻为第2级提供优先级为1的

第3级支所有故障所需的支持

不直接对故障负责

持批准在SLA解决期限内帮助解决所有

第2级未排除的故障

下一步是

拟定业务

应答及排

障业务定

义。它为

如何快速

排障（涉第2级应现场第2

帮助台应答硬件更换解决问题

及硬件更答级

换在内）

制定了目

的。为这

个领域制

定目的是

非常重要

的，由于

业务应答

及恢复时

间直会接

影响网络

的可用

性。问题

解决时间

也要与可

用性预算

保持一

致。假如

在制定可

用性预算

时未将大

量高严重

级别的故

障考虑在

内，则公

司随后将

需开展大

量工作来

了解此类

故障的根

源及也许

的填补方

法。详见

下表：

问题严重

级别

立刻上报到第2

级，网络运营部

15分钟2小时2小时4小时

经理

立刻上报到第2

级，网络运营部

25分钟4小时4小时8小时，

经理

315分钟2小时12小时24小时36小时

415分钟4小时3天3天6天

除业务应答

及业务排障严重级别

严重级别:1严重级别2严重级别3

外，还需制4

定上报规定。

上报表有助

于保证将可

用资源集中

用于解决严

重影响业务

的问题。总的

来说，假如

分析员集中

精力解决问

题时，他们

很少重视运

用其他资源

来解决问题。

定义何时需

要其他资源

有助于促进

管理层对问

题的结识，

并有助于促

成未来的积

极测量或防

止性测量。详

见下表：

过去的时间

网络运营部经

5分钟理、第3级支持、

联网部主管

及时告知网络及时告知网络运

运营部经理、第营部经理、第3

1小时

3级支持、联网级支持、联网部主

部主管管

上报副总裁、及

时告知主任及

2小时

网络运营部经

理

向副总裁、主

管、运营部经

上报副总裁，及

理、第3级支持

时告知主管及网

4小时提交根源分析，

络运营部经理

向CEO告知未排

除的故障

网络运营

24小时

部经理

网络运营

5天

部经理

迄今为止，服

务水平定义始

终集中在运营

支持部门如何

在问题发生后

对其采用被动

措施上。运营部

门数年前便制

定出了涉及上

述相似内容的

积极故障辨认率被动故障辨认率

运营支持计划。

然而，该方案

中忽略了部门

如何辨认问题

以及他们将辨

认哪些故障等

内容。比较成

熟的网络公司

试图制定预先

拟定的网络问

题百分率目的

来解决这个问

题，而不是通

过用户故障报

告或投诉来被

动地拟定故障。

下表列出了公

司对积极支持

功能和被动支

持功能的整体

测量目的。

网络领域

LAN80%20%

WAN80%20%

这为拟

定更多

的积极

支持定检测方5x8告7x5x8排7x24排

义开了法知24告知障障

一个好

头，由

于它测

量起来

很简朴、

也很容

易特

别在积

极检测

工具可

自动生

成故障

票。这

尚有助

于将网

络管理

工具/信

息集中

用于积

极排障,

而不是

在故障

发生后

被动地

查找根

源。然

而，这

种方法

的重要

问题在

于它无

法定义

积极支

持规定。

这通常

会导致

积极支

持管理

功能问

的差距

并导致

更大的

可用性

风险。

积极服

务水平

定义

更全面

的制定

服务水

平定义

方法涉

及，更

具体地

解释如

何7x24

全天候

地监控

网络，

以及运

营部门

如何7x

24全天

候对已

定义的

网络管

理站

(NMS)

门限做

出响应。

鉴于管

理信息

站（MIB）

数量的

不拟定

性以及

提供MIB

的网络

管理信

息数量

与网络

的运营

情况相

关，因

此这看

上去是

一项无

法完毕

的任务。

同时，

完毕这

项任务

需大量

资源且

代价非

常高昂。

不幸的

是，这

些缺陷

大大妨

碍了我

们对积

极业务

定义的

实行，

而这种

实行从

本质上

来说非

常简朴

轻松，

且只合

用于可

用性或

性能风

险极大

的网络。

假如公

司随后

看到了

基本积

极业务

定义的

价值，

那么只

要采用

分阶段

实行的

方法，

就可以

逐渐添

加更多

变量，

但不会

对业务

产生重

大影响。

所有运

营支持

方案中

均应涉

及第一

个领域

的积极

业务定

义。该业

务定义

只是简

朴阐述

运营部

门如何

辨认不

同网络

区域中

的网络

或链路

故障并

对此做

出响应。

没有这

个定义

（或管

理支

持），公

司也许

碰到支

持不稳

定、无法

达成用

户盼望

等问题，

最终会

减少网

络可用

性。

下表显

示了公

司如何

针对链

路/设备

故障制

定服务

定义。该

实例中

的公司

在天天

的不同

时段及

网名各区

域方面

有着不

同的告

知和响

应规定。

网络设

备或链

路故障

SNMP设NOC创建故自动向负责NOC在15分立刻研究并排

备和链障票、向负LAN的人员钟内派出除优先级1和2

核心LAN

路轮询责LAN的人发出寻呼、LAN分析员、的故障、优先

陷阱员发出寻呼LAN负责人根据业务应级3和4的故

员为核心答定义解决障排队等候次

LAN队列创问题日上午排除

建故障票

自动向负责

立刻研究并排

WAN的人员NOC在15分

SNMP设NOC创建故除优先级1和2

发出寻呼、钟内派出

国内备和链障票、向负的故障、优先

WAN负责人WAN分析员、

WAN路轮询责WAN的人级3和4的故

员为核心根据业务应

陷阱员发出寻呼障排队等候次

WAN队列创答定义排障

日上午排除

建故障票

自动向负责

合作伙伴的

NOC在15分立刻研究并排

NOC创建故人员发出寻

SNMP设钟内派出合除优先级1和2

障票、向负呼，合作伙

备和链作伙伴分析的故障、优先

外联网责合作伙伴伴负责人员

路轮询员、根据业级3和4的故

的人员发出为合作伙伴

陷阱务应答定义障排队等候次

寻呼队列创建故

排障日上午排除

障票

•其余的积极服务水平定义可提成两类：网络错误和容量/性能

问题。只有少数网络公司拥有这两个领域的服务水平定义。因

此，这些问题常被忽视或无法得到统一解决。这对某些网络环

境的影响也许不大，但高可用性环境一般都需要一致的积极业

务管理。

网络公司希望实现积极业务定义的因素很多，重要是他们尚未

基于可用性风险、可用性规划及应用问题对积极业务定义进行

规定分析，致使积极业务定义的规定及优势不明确，这重要是

由于需要更多的资源。

第二个因素是要平衡可以运用现有及新定义的资源来实行的积

极管理数量。但生成这些告警就也许对可用性或性能产生严重

影响。您还必须考虑事件关联管理或流程，以保证不就同样的

问题生成多个积极故障票。最后一个因素在于：创建一组全新

的积极告警经常会生成以前未检测出的初始信息流。运营部门

必须为解决这些最初问题以及增长短期资源做好准备，以便解

决这些以前未检测出的问题。

第一类积极服务水平定义是网络错误。网络错误还可细分为系

统错误（涉及软硬件错误）、协议错误、媒介控制错误、准确

性错误及环境警告。制定服务水平定义一方面耍耍大体了解如

何检测出此类问题、由谁负责解决问题以及故障的影响。必要

时在服务水平定义中添加特定的信息或问题。您也许还需要在

以下领域开展更多工作以保证成功定义：

•第1.2和3级支持的责任

•运用运营部门可以有效开展的积极工作量来平衡网络管理信息

的优先级

•按规定进行培训以便保证支持人员可以有效地解决定义的告警

•拟定事件关联方法以保证不为同样的问题生成多个故障票

记录特定信息或告警，以帮助辨认属于第1级支持级别的事件

下表是用于网

络错误的服务

水平实例，帮

助您明确了解

谁负责发送积

极网络故隙告

警、如何拟定

检测方法门限采用的行动

故障以及故障

影响。根据上

文所述，公司

尚需开展更多

工作以保证成

功。

故障类型

软件故障（软天天都使用系统发生任何优先级审查问题、创建故

件导致的故障日记查看程序审0、1和2的故障障票并在新问题出

停机）核系统日记信息发生100多起优先现或问题需要特别

由第2级支持完级3（或更高）的注意时派出人员解

毕故障决

任何第0、1和2

天天都使用系统审核问题、创建故

优先级别的故障的

硬件故障（硬日记查看程序审障票并在新问题出

发生

件导致的故障核系统日记信息现或问题需要特别

发生100多起优先

停机）由第2级支持完注意时派遣人员解

级3（或更高）的

毕决

故障

使用系统日记查发生任何优先级审核问题、创建故

协议错误（只看程序每日审核0、1和2的故障障票并在新问题出

合用于IP路由系统日汜信息发生100多起第3现或问题需要特别

协议）由第2级支持完优先级（或更高）注意时派出人员解

毕故障决

任何第0、1和2

使用系统日记查审核问题、创建故

媒介控制故障优先级别的故障的

看程序每日审核障票并在新问题出

（只限于FDDI、发生

系统口汜信息现或问题需要特别

P0S及快速以发生100多起优先

由第2级支持完注意时派出人员解

太网）级3（或更高）的

毕决

故障

环境信息（电使用系统日记查对新问题创建故隙

任何信息

源和温度）看程序每口审核票并派遣相关人员

系统日汜信息解决问题

由第2级支持完

毕

每五分钟进行一

准确度错误输入或输犯错误对新问题创建故障

次SNMP轮询

（链路输入错任何链路上、每5票并派出笫2级支

NOC受理的门限

误）分钟出现一次错误持人员解决问题

事件

•另一类积极服务水平是性能及容量。真正的性能和容量管理涉

及例外情况管理、基准制定与趋势分析以及假设分析。服务水

平定义只定义需要调查或更新的性能及容量的例外门限以及平

均门限。随后，可以以某种方式将这些门限应用到三种性能和

容量管理流程中。

容量及性能服务水平定义可细提成几个类别：网络链路、网络

设备、端到端性能及应用性能。制定这些领域的服务水平定义

需要具有与设备容量、媒介容量、QoS特性及应用规定的特定

领域相关的渊博技术知识。出于这个因素，我们建议网络设计

师通过供应商输入的信息制定与性能和容量相关的服务水平定

义。

与网络错误相似，为容量和性能制定服务水平定义一方面应大

体了解如何检测此类故障、由谁负责排障以及故障的影响。必

要时向服务水平定义中添加特定的信息或问题。您也许还需要

在以下领域开展更多工作以保证成功：

•明确了解应用性能规定

•基于业务规定及总成本，对公司重要的门限值进行进一步的技

术研究

.预算周期以内和以外的升级规定

•第1.2和3级支持的责任

•运用运营部门可以有效开展的积极工作量平衡的网络管理信息

的优先级及危急限度

•按规定进行培训以便保证支持人员了解信息或告警，并可有效

地解决所定义的情况

•拟定事件关联方法以保证不为同样的问题生成多个故障票

记录特定信息或告警，以帮助辨认属于第1级支持的事件

下表是面向链路

使用情况的服务

水平定义实例，

帮助您明确了解

检测方法门限采用的行动

谁负责发送积极

网络故障告警、

如何拟定故障以

及故障影响。公

司仍需开展上面

定义的更多工作

以保证成功。

网络领域/媒介

向性能和容量电

五分钟进行一次每五分钟的使

子邮件别名发送

SNMP轮询用率为50%

园区LAN骨干及电子邮件告知

核心及分派链路通过例外陷阱

分派链路安排小组组解决

上的RMON例外陷实现90%的使用

问题或制定升级

阱率

计戈U

向性能电子邮件

别名发送电子邮

件告知

五分钟进行一次每五分钟的使

国内WAN链路安排工作组评估

SNMP轮询用率为75%

QoS规定或为反

复出现的故障制

定升级计划

向性能和容量电

子邮件别名发送

五分钟进行一次每五分钟的使

外联网WAN链路电子邮件告知

SNMP轮询用率为65%

安排工作组评估

QoS规定或为反

复出现的故障制

定升级计划

下表给出了设备容

量和性能门限的服

务水平定义，以保

证您创建对防止出

现网络故障或可用

性问题故意义、很

有用的门限。这是重要信息检测方法门限采用的行动

一个非常重要的领

域，由于未检测出

的设备控制板资源

问题可对网络导致

严重影响。

设备

五分钟内的向性能和容量

五分钟进行CPU使用率门电子邮件别名

一次SNMP限是75%,达工作组发送电

CPU、内

Cisco7500轮询成99%时，运子邮件告知以

存、显卡

面向CPU的用RMON发出便解决问题或

RM0N告知告知五分钟制定升级计划

内的内存使RMONCPU为

用率门限是99%,发放故障

50%、显卡使票并向第2级

用率门限是支持人员发送

99%寻呼

五分钟内的向性能和容量

CPU使用率门电子邮件别名

五分钟进行

CPU、内限是75%五分工作组发送电

Cisco2600一次SNMP

存、钟内的内存子邮件告知以

轮询

使用率门限便解决问题或

是50%制定升级计划

向性能和容量

背板使用率电子邮件别名

背板使用五分钟进行

门限是50%工作组发送电

Catalyst?5000情况、内一次SNMP

内存使用率子邮件告知以

存轮询

门限是75%便解决问题或

制定升级计划

向性能和容量

CPU使用率匚1

LightStream?1010五分钟进行电子邮件别名

限是65%

ATMCPU、内存一次SNMP工作组发送电

内存使用率

switch轮询子邮件告知以

门限是50%

便解决问题或

制定升级计划

下表给出了端到

端性能和容量的

服务水平定义。

这些门限值一般

基于应用规定，

但也可用于指示

某类网络性能或

容量问题。由于

测量网络中任意

两点间的性能需

要大量资源并会测量方法门限采用的行动

带来大量的网络

开销，所以大多

数有性能服务水

平的公司都只创

建少数性能定

义。这些端到端

的性能问题也也

许出现在链路或

设备容量门限

中。我们建议根

据地理位置制定

一般定义。必要

时需添加一些关

键站点及链路。

网络领域/媒介

向性能和容量电

无子邮件别名工作

始终保证10-毫

不会出现问题组发送电子邮件

园区LAN秒或更短的往

很难测量整个LAN基告知以便解决问

返响应时间或

础设施题或制定升级计

划

向性能电子邮件

别名工作组发送

目前只使用互联网

电子邮件告知，

监视器（IPM）和ICMP五分钟内平均