Contents
Introduction
本文描述服务级别管理和service-level agreements (SLA)高可用性网络的。它包括服务级别管理和性能指标的重要成功因素能帮助评估成功。本文为遵从高性能的服务小组确定的最佳实践指南的SLA也提供大量详细信息。
服务级别管理概述
网络组织通过反应构建固定的网络结构和工作处理独立服务问题历史上符合了扩展网络要求。当储运损耗发生了，组织将构建更新过程、防止特定的储运损耗再发生的管理功能或者基础设施。然而，由于更高的更改费率和不断增长的可用性需求，我们当前需要一个改进的型号主动地防止意外停机和迅速修理网络。许多service-provider和企业尝试更好定义要求的服务的级别达到商业目标。
重要成功因素
SLA的重要成功因素用于定义关键元素成功建立的可获得的服务级别和维护的SLA。要合格作为一个重要成功因素，进程或进程步骤必须一般来说改进SLA和好处网络可用性的质量。重要成功因素应该也是可测量的，因此组织能确定多么成功是相对被定义的程序。
欲了解更详细的信息请参阅实现服务级别管理。
性能指标
性能指标提供组织测量重要成功因素的机制。您每月典型地查看这些保证服务级别定义或SLA工作良好。网络操作组和必要的工具组可执行以下权值。
Note: 除权值之外，对于没有SLA的组织，我们推荐您执行服务级别定义和service-level复核。
性能指标包括：
- 包括可用性、性能、响应式服务响应时间、问题解决目标和问题上报的描述的服务级别定义或SLA。
- 查看service-level标准和实现改进的月度网络service-level复核会议。
- 性能指示器度量，包括可用性、性能、响应时间由优先级，时刻由优先级解决和其他可测量的SLA参数。
欲知更多信息，请参阅实现服务级别管理。
服务级别管理进程流
服务级别管理的高级流程包含两个主要的组：
点击对象在以下图表中查看该步骤的详细资料。
实现服务级别管理
实现服务级别管理包括十六个步骤分开成以下两个主要类别：
定义网络服务级别
网络管理器需要定义网络支持的主要规则，管理和测量。服务级别为所有网络人员提供目标，并且可以使用作为权值进入整体服务的质量。您也能我们服务级别定义作为预算网络资源的一个工具和作为证据对需要资助更高的QoS。他们也提供一个方式评估供应商和载波性能。
没有服务级别定义和测量，组织没有清楚的目标。服务满意度可能由有小的差异化的用户管理在应用程序、服务器/客户端操作或者网络支持之间。预算可以是更加困难的，因为最终结果不是清楚的对组织，并且终于，网络组织倾向于是反应，不积极的，在改进网络和支持模型。
我们推荐建立和支持service-level型号的以下步骤：
- 分析技术目标和约束。
- 确定可用性预算。
- 创建选派的应用配置文件重要应用的网络特性。
- 定义可用性和性能标准并且定义普通的术语。
- 创建包括可用性、性能、服务响应时间、解决问题的平均时间，故障检测、升级阈值和升级路径的一个服务级别定义。
- 收集权值并且监控服务级别定义。
步骤 1：分析技术目标和约束
开始的最佳方法分析技术目标和约束是群策群力或研究技术目标和需求。有时，因为这些单个有特定目标与他们的服务有关，它帮助邀请其他IT技术副本到此讨论。技术目标包括可用性级别、吞吐量、抖动、延迟、响应时间、可扩展性需求、新功能简介、新的应用程序引入、安全、甚而可管理性和费用。组织应该然后调查约束到达到产生的那些目标可用资源。您能用约束的解释创建每个目标的工作表。最初，它可能似乎，好象大多目标不可达成的。然后请开始优先安排目标或降低能仍然符合商业需求的期望。
例如，您也许有可用性99.999%的级别或者5分钟停工期每个年。有许多约束对达到此目标，例如硬件中的单点故障、平均修复时间(MTTR)损坏的硬件在远端位置，载波可靠性、积极的故障检测功能、高更改费率和当前网络容量局限。结果，您可以对一个更加可达成的级别调整目标。在下个部分的可用性模型可帮助您设置可实现的目标。
您可以也考虑提供高性能在有少量约束网络的某些区域。当网络组织发布可用性时服务标准，在组织内的商业集团可能认为级别不可接受。这是然后开始SLA讨论或资助/能达到商业需求的预算的型号的一个自然点。
工作识别在达到技术目标或风险涉及的所有约束。优先安排约束根据最巨大的风险或影响对期望目标。这帮助组织优先安排网络改进计划和确定多么约束可以容易地寻址。有三约束：
- 网络技术、弹性和配置
- 生命周期实践，包括计划、设计、实施和操作
- 当前数据流负载或应用程序行为
网络技术、弹性和配置约束是与提交技术、硬件、链路、设计或者配置或风险产生关联的所有限制。技术限制包括技术摆在的所有约束。例如，提交技术在冗余网络环境里不允许分秒的收敛时间，可能是重要为在间网络的持续的语音连接。另一个示例可能是数据在陆地链接能横断，是大约每毫秒100英里的原始的速度。
网络硬件弹性风险调查应该集中硬件拓扑、层次结构、模块化、冗余和MTBF沿被定义的路径在网络。网络链路约束应该着重网络链路和载波连接企业的。链路约束可能包括链路冗余和分集，媒体限制，配线基础设施、local-loop连接和长途连接。设计限制与网络的物理或逻辑设计关连并且从设备的可用空间包括一切对路由协议实施的可扩展性。应该关于配置、可用性、可扩展性、性能和容量考虑所有协议和媒介设计。应该也考虑网络服务约束例如动态主机配置协议(DHCP)，域名系统(DNS)、防火墙、协议转换器和网络地址转换器。
生命周期实践定义了用于的网络的进程和管理一致配置解决方案，发现并且修理问题，防止容量或性能问题，并且配置一致性和模块化的网络。因为专业技术和进程典型地是未利用率的，最大的纳税人您需要考虑此区域。网络生存周期是指计划、设计、实施和操作的循环。在这些区域中的每一个内，您必须了解网络管理功能例如性能管理、配置管理、故障管理和安全。网络生命周期评估从Cisco NSA显示当前网络可及性限制的高可用性服务(HAS)服务是可得到产生关联与网络生命周期实践。
当前数据流负载或应用程序约束是指当前数据流和应用程序的影响。
不幸地，许多应用程序有要求仔细管理的重大的约束。抖动、延迟、吞吐量和带宽需求当前应用程序的典型地有许多约束。应用程序被写的方式可能也创建约束。应用程序描出更好帮助您了解这些问题;下个部分包括此功能。调查的当前可用性、数据流、容量和性能所有也帮助网络管理器了解当前service-level期望和风险。这用称为网络基带的进程典型地完成，帮助定义网络性能、可用性或者容量平均数一个被定义的时间，通常大约一个月。此信息通常使用容量设计和趋向，但是可能也使用了解service-level问题。
以下工作表使用上述目标/约束方法防止安全攻击或拒绝服务攻击目标示例。您能也使用此工作表帮助确定使减到最小的安全攻击的服务保赔。
| 风险或约束 | 约束的类型 | 潜在影响 |
|---|---|---|
| 可用的DoS检测工具不能发现DOS攻击的所有类型。 | 技术/弹性 | 高 |
| 请勿有必需的人员和进程起反应到戒备。 | 生命周期实践 | 高 |
| 当前网络访问策略不到位。 | 生命周期实践 | 媒体 |
| 如果带宽拥塞使用攻击，当前更小带宽互联网连接可能是要素。 | 网络容量 | 媒体 |
| 目前帮助的安全配置防止攻击可能不是详尽的。 | 技术/弹性 | 媒体 |
步骤 2：确定可用性预算
可用性预算是网络的期望的理论上的可用性在两被定义的点之间的。准确理论上的信息是有用的在几个方式：
- 当内部可用性和偏差的一个目标可以迅速被定义和被补救，组织能使用此。
- 信息可以由网络规划者使用在确定系统的可用性帮助保证设计将符合商业需求。
造成未利用率或停机时间的要素包括硬件故障、软件故障、功率和环境问题、链路或者载波故障、网络设计、人为错误或者缺乏进程。当评估网络的时，整体可用性预算您应该严密评估这些参数中的每一个。
如果组织当前测量可用性，您不可能需要可用性预算。请使用可用性评定作为基准估计用于服务级别定义的当前服务级别。然而，您可以是对比较两个感兴趣了解潜在的理论上的可用性与实际被测量的结果比较。
可用性是产品或服务将运行，当需要的可能性。请参阅以下定义：
- 可用性
- 1 – (总连接停机时间)/(总在职连接时间)
- 1 – [Sigma(num connections affected in outage i X duration of outage i)]/(在服务x操作时间的数字conns)
- 前不可用
1 -可用性或者总连接停机时间由于(硬件故障、软件故障、环境和电源问题、链路或者载波故障、网络设计或者用户错误和进程故障)
- 硬件可用性
调查的第一个区域是潜在硬件故障和作用对前不可用。要确定此，组织需要了解所有网络组件MTBF和硬件问题的MTTR在一条路径的所有设备的两点之间。如果网络模块化和分层的，硬件可用性将是相同的在几乎任何两个点之间。MTBF信息为所有Cisco组件是可用的并且对一个本地帐户管理器根据需要是可用的。既使当模块冗余、机箱冗余和路径冗余存在于系统， Cisco NSA HAS程序也使用一个工具帮助确定沿网络路径的硬件可用性。硬件可靠性一个主要因素是MTTR。组织应该评估多他们能快修理损坏的硬件。如果组织没有节省的计划并且依靠一标准的Cisco SMARTnet™协议，则潜在的平均的替换时间是大约24小时。在与核心冗余和没有访问冗余的典型的LAN环境里，大致可用性是与四小时MTTR的99.99%。
- 软件可用性
调查的下个区域是软件故障。用于测量的目的， Cisco定义了软件故障作为设备冷启动由于软件错误。Cisco取得了重大的进展往了解软件可用性;然而，更新的版本比普遍部署软件需要时间测量和被认为较不可利用。普遍部署软件，例如IOS版本11.2(18)，被测量了在99.9999百分率可用性。这根据在使用六分钟的Cisco路由器的实际冷启动被计算作为修理时间(路由器的时刻重新载入)。与各种各样的版本的组织预计有轻微更低的可用性由于被添加的复杂性、互通性和增加的故障排除时间。与最新的软件版本的组织预计有更高的未利用率。未利用率的分配也是相当宽的，意味着用户可能体验重大的未利用率或可用性接近普遍部署版本。
- 环境和电源可用性
您必须也认为在可用性的环境和电源问题。环境问题与必要的冷却系统细分关连保持设备在指定的操作温度。当他们显著地在规格外面而不是冒险对所有硬件的损伤许多Cisco设备将关闭。为可用性预算的目的，功率，因为它是未利用率的主导的原因在此区域，将使用。
虽然电源故障是确定网络可用性的一个重要方面，此讨论是有限的，因为理论功率分析不可能准确地完成。组织必须评估是电源可用性的一近似测量到根据经验的其设备在其地理区域，功率备用能力和处理被实施保证质量一致的电源到所有设备。
对于一个保守的评估，我们能说一个组织用备用发电机， uninterruptible-power-supply (UPS)系统和优质电源实施进程可能体验可用性六个9s，或者99.9999%，而没有这些系统的组织可能体验可用性在99.99%，或者大约36分钟每年停工期。当然您能对根据组织的征收或实际数据的更加可实现的值调整这些值。
- 链路或载波故障
链路和载波故障是主要因素关于可用性在广域网环境里。记住广域网环境是完全是受可用性问题支配和组织网络一样，包括硬件故障、软件故障、用户错误和电源故障的其他网络。
许多运营商网络已经执行在他们的系统的可用性预算，但是获得此信息可能是困难的。记住载波频繁地也有可用性有在实际可用性预算的很少或没有基本类型的保证级别。这些保证级别有时销售和销售额使用的方法促进载波。有时，这些网络也发布可用性看上去很好的统计数据。记住这些统计数据在未利用率可能仅适用于完全冗余的核心网络，并且不析因由于local-loop访问，是未利用率的一位主要因素在广域网网络。
创建可用性的估计广域网环境的应该根据实际载波信息和冗余的级别WAN连接的。如果组织有多建立入口设施、冗余local-loop供应商、同步光网络(SONET)本地访问和冗余长途运营商以地理分集，广域网可用性将显著地被提高。
电话服务是非冗余网络连通性的相当准确可用性预算在广域网环境里。电话的端到端连通性有大致可用性99.94%预算使用可用性预算方法类似于在此部分描述的那个。此方法在数据环境顺利地使用了与仅轻微的变化和当前使用作为目标在service-provider有线网络的信息包电缆规格。如果我们运用此值于一个完全冗余的系统，我们能假设，广域网可用性将是接近可用的99.9999百分比。当然非常少量组织有完全冗余，地理被分散的广域网系统由于成本和可用性，因此请使用关于此功能的适当的判断。
链路故障在LAN环境里是不太可能的。然而，计划程序可能要假设少量的停工期由于残破或松散连接器。对于LAN网络，一个保守估计近似是99.9999百分比可用性或者大约30秒每个年。
- 网络设计
网络设计是可用性的另一位主要因素。不可升级的设计、设计错误和网络收敛时间全部负影响可用性。
Note: 为本文，不可升级的设计或设计错误在以下部分包括。
网络设计对根据导致数据流重路由的网络的软件和硬件故障的可测量的值然后被限制。此值典型地称为“系统切换时间”并且是自恢复性能的协议功能的要素在系统内的。
使用系统计算的同样方法由完全计算可用性。然而，除非网络切换时间符合网络应用程序要求，这无效。如果切换时间是可接受的，从计算请去除它。如果切换时间不是可接受的，则您必须添加它到计算。示例在估计的或实际切换时间是30秒的环境里也许是VoIP。在本例中，用户将挂断电话和可能再试一次。用户一定将看到此时期作为未利用率，在可用性预算方面未估计。
计算未利用率由于系统切换时间通过查看沿冗余路径的理论上的软件和硬件可用性，因为切换在此区域将发生。您必须认识能的冗余路径失效和导致切换，那些设备MTBF和切换时间设备的数量。简单的示例是35,433小时MTBF两个冗余相同设备和切换时间中的每一的30秒。除35,433 8766 (几小时每个平均的年包括闰年)，我们看到设备一次将发生故障每四年。如果我们使用30秒作为切换时间，我们能然后假设，每个设备将体验，平均，每个年7.5秒未利用率由于切换。因为用户可能横贯任一条路径，结果然后被加倍对每个年15秒。当这被计算根据秒钟每个年时，相当数量可用性由于切换可以被计算作为在此简单系统的99.99999785百分比可用性。这可能是高在其他环境里由于冗余设备的数量在切换是可能性的网络的。
- 用户错误和进程
用户错误和进程可用性问题是未利用率的主要原因在企业和运营商网络的。大约未利用率的80%发生由于问题例如不发现错误、更改失败和性能问题。
组织在确定不会要使用四次其他理论上的未利用率可用性预算，证据一致建议这是实际情形在许多环境里。下个部分十分地包括未利用率的此方面。
因为您不能理论上计算相当数量未利用率由于用户错误和进程，我们推荐从可用性预算去除此去除的您，并且组织力争完美。这一个警告是组织在他们专业技术的自己的进程和级别中需要了解当前风险到可用性。一旦更好了解这些风险和抗化剂，网络规划者在未利用率的某个数量可能希望析因由于这些问题。Cisco 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百分率可用性。如果我们在潜在不可用性析因由于用户或处理错误并且假设，未利用率是4X可用性由于技术要素，我们可能假设，可用性预算是99.95%。
此示例分析表明然后LAN可用性平均将落在99.95和99.989%之间。这些编号可能当前使用作为服务级别目标网络组织。您能通过测量在系统的可用性和确定获取另外的值百分之几未利用率归结于上述六个区域中的每一个。这允许组织适当地评估供应商、载波、进程和人员。编号可能也用于设置在事务内的期望。如果编号是不可接受的，则获取所需的级别的预算附加资源。
网络管理器了解停机时间在所有特定的可用性级别可能是有用的。停机时间以分钟一个一年周期，被测量所有可用性级别，是：
分钟停工期在一年= 525600 – (可用性第x级5256)
如果使用可用性99.95%的级别，这解决等于525600 – (99.95 x 5256)，或者262.8分钟停工期。对于上述可用性定义，这与所有连接的平均的停机时间是相等的在使用中在网络内的。
步骤 3：创建应用配置文件
网络组织了解并且定义了单个应用的网络服务级别需求的应用配置文件帮助。这帮助保证网络整体上支持单个应用需求和网络服务。应用配置文件能也起一个描述的基准作用对于服务支持，当应用程序或服务器组点到网络作为问题。最终，应用配置文件帮助与应用程序对齐网络服务目标或商业需求通过应用程序需求例如性能和可用性与可实现的网络服务目标或当前限制比较。这是重要不仅为服务级别管理，而且对整体自顶向下网络设计。
在您引入新应用给网络时候，请创建应用配置文件。您可能需要在IT应用组、服务器管理组和网络之间的一协议帮助强制执行新和现有服务的应用配置文件创建。完成商业应用和系统应用的应用配置文件。商业应用可能包括电子邮件、文件传输、Web浏览、成象或者制造。系统应用可能包括软件分配、用户认证、网络备份和网络管理。
网络分析员和应用程序或者技术支持应用应该创建应用配置文件。新应用可能要求使用协议分析程序和广域网仿真器与延迟仿真适当地分析应用程序需求。这帮助识别必要的带宽、最大延迟应用程序可用性的和抖动需求。只要您有所需的服务器，这在实验室环境里可以执行。在某些情况下，例如与VoIP，网络要求包括抖动，延迟和带宽很好发布，并且实验室测试不会是需要的。应用配置文件应该包括以下项目：
- 应用程序名称
- 应用程序的类型
- 新应用？
- 企业重要性
- 可用性需求
- 使用的协议和端口
- 估计的用户带宽(Kbps)
- 编号和位置的用户
- 文件传输需求(包括时间、容量和终端)
- 网络中断影响
- 延迟、抖动和可用性需求
应用配置文件的目标是了解应用程序、业务的重要性和网络要求的商业需求例如带宽、延迟和抖动。另外，网络组织应该了解网络中断时间的影响。有时，您将需要极大添加到整体应用程序停工期的应用程序或服务器重新启动。当您完成应用配置文件时，您可比较整体网络功能和帮助与事务和应用程序需求对齐网络服务级别。
步骤 4：定义可用性和性能标准
可用性和性能标准设置组织的服务期望。这些可能为不同的应用领域网络或特定被定义。性能可能也被定义根据往返延迟、抖动、最大吞吐量、带宽承诺和整体可扩展性。除设置服务期望之外，组织应该也保重定义其中每一个服务标准，以便用户和工作与网络的IT组充分地了解标准的服务，并且如何与他们的应用程序或服务器管理需求关连。用户和IT组应该也知道服务标准如何也许被测量。
从早先服务级别定义步骤的结果将帮助创建标准。这时，网络组织应该有对当前风险和约束的清除了解在网络，对应用程序行为的了解和理论上的可用性分析或可用性基线。
- 定义服务标准适用的地理或应用程序方面。
这可能包括区域例如园区LAN、国内广域网、外联网或者合作伙伴连接。有时，组织在一个区域之内可能有不同的服务级别目标。这为企业或服务提供商组织不是少见的。在这些情况下，创建根据独立服务需求的不同的服务级别标准是不少见的。这些在一个地理或服务地区之内可能分类为金，银，铜等级服务标准。
- 定义服务标准参数。
可用性和往返延迟是多数通用网络服务标准。最大吞吐量、最低的带宽承诺、抖动、可接受的错误率和可扩展性功能可能也包括当必要时。当查看测量方法的时，服务参数小心。参数是否继续前进向SLA，组织应该考虑服务参数如何也许被测量或被辩解，当问题或服务分歧发生时。
在您定义了服务地区和服务参数后，请使用从早先步骤的信息建立服务标准矩阵。组织也将需要定义可能是混乱的对用户和IT组的区域。例如，最大响应时间为往返ping将是非常不同的比对于击enter键在一个特定应用程序的一个远端位置。下面的表显示在美国内的性能目标。
| 网络区域 | 可用性目标 | 测量方法 | 平均的网络响应时间目标 | 被接受的最大响应时间 | 响应时间测定方法 |
|---|---|---|---|---|---|
| LAN | 99.99% | 压缩的用户时间 | 在5毫秒以下 | 10毫秒 | 往返ping响应 |
| WAN | 99.99% | 压缩的用户时间 | 在100毫秒(往返ping)以下 | 150毫秒 | 往返ping响应 |
| 重要广域网和外联网 | 99.99% | 压缩的用户时间 | 在100毫秒(往返ping)以下 | 150毫秒 | 往返ping响应 |
步骤 5：定义网络服务
这是最后一步往基本的服务级别管理;它定义了您实现达到服务级别目标的反应和主动流程和网络管理功能。最终文件典型地称为操作支持计划。多数应用程序支持计划包括仅响应式支持服务需求。在高可用性环境里，组织必须也考虑将使用查出并解决网络问题的主动管理进程，在发起前用户服务服务请求。总之，最终文件应该：
- 描述用于的反应和主动流程达到服务级别目标
- 服务流程如何将管理
- 服务目标和服务流程如何将被测量。
此部分包含响应式服务定义和积极的服务定义的示例能为许多service-provider和企业考虑。在建立服务级别定义的目标是创建将达到可用性和性能目标的服务。要完成此，组织必须提供服务想着当前技术约束、可用性预算和应用配置文件。特别地，组织应该定义和提供在可用性模型分配的时期内持续和迅速地识别并且解决问题的服务。组织必须也定义能迅速识别和解决潜在服务问题将影响可用性和性能，如果忽略的服务。
您隔夜不会达到期望服务级别。缺点例如低专业技术、当前进程限制或者不适于的人员配备等级可能防止组织达到期望标准或目标，在早先服务分析步骤以后。没有完全地匹配要求的服务供货水平的准确的方法对期望目标。为此要适应，组织应该测量服务标准和测量用于的服务参数支持服务标准。当组织不达到服务目标时，应该然后查找服务权值帮助了解问题。在许多情况下，预算增加可以做改进支持服务和使改进必要达到期望服务目标。随着时间的推移组织可能做几个调节，到服务目标或到服务定义，为了对齐网络服务和商业需求。
例如，当目标是高在99.9百分率可用性，组织也许达到99百分率可用性。当注视着服务与支援权值时，组织的代表比原始估计长期发现硬件替换耗费大约24小时，因为组织只预算四。另外，组织发现主动管理功能被忽略，并且下来冗余网络设备未被修理。他们也发现他们没有做的人员改进。结果，在降低以后当前服务目标的考虑，对附加资源预算的组织需要达到期望服务级别。
服务定义应该包括响应式支持服务定义和积极定义。反应定义定义了组织如何将反应对问题，在他们从用户投诉或网络管理功能后被识别。积极定义描述组织如何将识别并且解决潜在网络问题，包括残破的“暂挂”网络组件修理、错误检测和容量门限值和升级。以下部分提供反应和积极的服务级别定义示例。
响应式服务供货水平定义
使用服务台数据库统计数据和定期审核，以下服务级别区域典型地被测量。此表显示问题严重性示例组织的。注意图不包括如何处理要求新的服务，可能由SLA或另外的应用程序描出和性能假设分析处理。典型地严重性5可能是一个要求新的服务，如果处理通过同样支持流程。
| 严重性1 | 严重性2 | 严重性3 | 严重性4 |
|---|---|---|---|
| 严重下来商业影响下来LAN用户或服务器分段重要WAN站点 | 高商业影响通过损失或降低，可能的解决方法到位园区LAN下来;5-99个用户影响国内WAN站点下来国际WAN站点下来重要性能影响 | 若干特定网络功能丢失或降低，例如冗余失效失去的园区LAN性能被影响的LAN冗余 | 没有组织的商业影响的一个功能查询或故障 |
当问题严重性被定义了时，请定义或调查支持流程创建服务响应定义。一般来说，服务响应定义要求一个分级技术支持结构加上支持中心软件支持支持系统通过故障单跟踪问题。权值应该也取得到准时响应时间和呼叫的解决时间每优先级的，编号由优先级和回应/解决方法质量。要定义支持流程，它帮助定义每个支持层的目标在组织的和他们的角色和责任。这帮助组织了解专业技术的资源需求和级别每个支持级别的。下面的表提供分级技术支持组织的示例问题解决方法指南。
| 支持层 | 责任 | 目标 |
|---|---|---|
| 第1层技术支持 | 全职支持中心支持答案支持呼叫，地方故障单，在问题的工作15分钟，文件票和升级合适第2层技术支持 | 解决方法40%呼入的呼叫 |
| 第2层技术支持 | 排队监控，网络管理，位置监控软件识别的问题的地方故障单实现接纳从第1层的呼叫，供应商，并且第3层逐步升级假设呼叫所有权直到解决方法的 | 解决方法100%在第2层级别的呼叫 |
| 第3层技术支持 | 必须提供即时支持给第2层为所有优先级1问题同意帮助与所有问题未解决由在SLA解决方法期间的第2层 | 没有直接问题所有权 |
下一步是创建服务回应和服务解决方法服务定义的矩阵。这设置多的目标快问题是解决的，包括硬件替换。因为服务响应时间和恢复时间直接地影响网络可用性，设置目标在此区域是重要的。应该与可用性预算也对齐问题解决时间。如果很大数量的严重级别问题没有占在可用性预算方面，组织能然后运作了解这些问题和一种潜在的解决的来源。参见下面的表：
| 问题严重性 | 支持中心回应 | 第2层回应 | 现场第2层 | 硬件备件更换 | 问题解决方法 |
|---|---|---|---|---|---|
| 1 | 对第2层的立即升级，网络Operations Manager | 5 分钟 | 2小时 | 2小时 | 4小时 |
| 2 | 对第2层的立即升级，网络Operations Manager | 5 分钟 | 4小时 | 4小时 | 8小时 |
| 3 | 15分钟 | 2小时 | 12小时 | 24小时 | 36小时 |
| 4 | 15分钟 | 4小时 | 3天 | 3天 | 6天 |
除服务回应和服务解决方法之外，请建立逐步升级的一个矩阵。上报程序表帮助保证可用资源集中于严重地影响服务的问题。一般来说，当分析员集中于定象问题时，他们很少着重提供附加资源在问题。定义，当附加资源在管理方面应该是促进问题感知的被通知的帮助，并且可通常帮助导致将来积极或预防性措施。参见下面的表：
| 经过时间 | 严重性1 | 严重性2 | 严重性3 | 严重性4 |
|---|---|---|---|---|
| 5 分钟 | 网络Operations Manager，第3层技术支持，联网控制器 | |||
| 1小时 | 对网络Operations Manager的更新，第3层技术支持，联网控制器 | 对网络Operations Manager的更新，第3层技术支持，联网控制器 | ||
| 2小时 | 升级对VP，更新到导向器， Operations Manager | |||
| 4小时 | 对VP的根本原因分析，导向器， Operations Manager，第3层技术支持，未解决要求CEO通知 | 升级对VP，更新到导向器， Operations Manager | ||
| 24小时 | 网络Operations Manager | |||
| 5天 | 网络Operations Manager |
到目前为止，服务级别定义着重操作支持组织如何反应对问题，在他们被识别后。操作组织用信息创建了可操作的支持计划类似于在上面多年来。然而，什么在这些情况下失踪是组织如何将识别问题，并且哪些问题他们将识别。更加复杂的网络组织尝试通过创建主动地识别问题的百分比的目标解决此问题，与用户问题报告或投诉反应识别的问题相对。
下张表显示组织如何可能希望测量积极的技术支持功能和积极的技术支持所有。
| 网络区域 | 预防问题识别率 | 反应问题识别比率 |
|---|---|---|
| LAN | 80% | 20% |
| WAN | 80% | 20% |
这是一个好开始在定义积极的技术支持定义，因为测量是简单和非常容易的，特别是如果预防工具自动地生成故障单。这也帮助重点网络管理管理工具/关于解决的问题的信息主动地而不是帮助与根本原因。然而，此方法的主要问题是不定义了积极的支持需求。这通常创建在积极的技术支持管理功能的空白并且导致另外的可用性风险。
积极的服务级别定义
创建的服务级别定义一更加全面的方法包括关于怎样网络被监控，并且操作组织如何的更多详细资料反应对根据一个7个x 24个基本类型的被定义的网络管理位置(NMS)阈值。这可能似乎类似产生的一项不可能的任务管理信息库(MIB)变量的纯粹数量和的相当数量对网络健康是有关的网络管理有用的资料。它能也是密集非常昂贵和的资源。不幸地，这些反对防止许多实现应该，天生，是简单，非常容易跟随，和仅可适用对最巨大的可用性或性能风险在网络的积极的服务定义。如果组织然后看到在基本的积极的服务定义的值，更多变量可以随着时间的推移被添加，不用重大影响，只要您实现一被逐步采用的方法。
包括积极的服务定义第一范围在所有操作支持计划。服务定义状态操作组主动地如何将识别并且回应网络或连接在条件下用网络的不同的区域。没有此定义(或管理支持)，组织能期待可变的技术支持，不切实际的用户期望和根本地降低网络可用性。
下面的表显示组织如何也许创建链路/设备down情况的服务定义。示例显示可能有根据网络的每日定时和区域的不同的通知和回应需求的一个企业。
| 网络设备或链路下来 | 探知方法 | 5 x 8通知 | 7个x 24个通知 | 5 x 8解决方法 | 7个x 24个解决方法 |
|---|---|---|---|---|---|
| 核心LAN | SNMP设备和链路轮询，陷井 | NOC创建故障单，页局域网责任传呼器 | 自动页LAN负责寻呼， LAN负责人创建核心LAN队列的故障单 | 在15分钟内分配的LAN分析员由NOC，修理根据服务响应定义 | 优先级1和2立即调查和解决优先级3和4 Morning解决方案的队列 |
| 国内广域网 | SNMP设备和链路轮询，陷井 | NOC创建故障单，页广域网负责寻呼 | 自动页广域网负责寻呼，广域网负责人创建广域网队列的故障单 | 在15分钟内分配的广域网分析员由NOC，修理根据服务响应定义 | 优先级1和2立即调查和解决优先级3和4 Morning解决方案的队列 |
| 外联网 | SNMP设备和链路轮询，陷井 | NOC创建故障单，页伙伴负责寻呼 | 自动页合作伙伴负责寻呼，合作伙伴负责人创建合作伙伴队列的故障单 | 协力在15分钟内分配的分析员由NOC，根据服务响应定义修理 | 优先级1和2立即调查和解决;优先级3和4 Morning解决方案的队列 |
剩余的积极的服务级别定义可以分开成两个类别：网络错误和容量/性能问题。网络组织的仅小的百分比有服务级别定义在这些区域。结果，这些问题偶发地被忽略或被处理。这也许是细致的在一些网络环境里，但是高性能的环境通常将要求一致主动服务管理。
网络组织倾向于与积极的服务定义由于几个原因奋斗。这是主要，因为他们未执行根据可用性风险、可用性预算和应用程序问题的积极的服务定义的一个需求分析。特别是因为附加资源可能是需要的，这导致积极的服务定义的不清楚的需求和不清楚的好处。
第二个原因介入平衡可以执行与现有或新定义的资源的相当数量主动管理。只请生成有严重潜在影响对可用性或性能的那些戒备。您必须也考虑事件关联管理或进程保证多份积极的故障单没有为同一个问题生成。最后原因组织可能奋斗是创建新的一套一组新的预防性告警的那能经常生成以前去未被发现消息的初始溢出。必须准备操作组问题和另外的短期资源此初始溢出修正或解决这些以前未被发现的情况。
第一个主动服务类别级别定义是网络错误。网络错误可以进一步细分到包括软件错误或硬件错误、协议错误、媒介控制错误、准确性错误和环境的警告的系统错误。实施服务级别定义从一般了解对如何将发现这些问题情况，开始将查看他们，并且发生了什么，当他们发生时。如果需要出现，请添加特定消息或问题到服务级别定义。您在以下区域可能也需要额外的工作保证成功：
- 第1层，第2层和第3层支持责任
- 平衡网络管理管理信息的优先级与操作组能有效处理的事前工作量的
- 培训的需求保证支持人员能有效处理被定义的戒备
- 保证的事件关联方法多份故障单没有为同一个根本原因问题生成
- 在帮助与事件标识在第1层支持级别的特定消息或戒备的文档
下面的表显示提供清除了解对的网络错误的一个示例服务级别定义谁对预防性网络错误预警负责，问题如何将被识别，并且什么将发生，当问题发生时。组织可能还是需要另外的努力如上所定义保证成功
s.
| 错误类别 | 探知方法 | 阈值 | 执行的操作 |
|---|---|---|---|
| 软件错误(软件引起的失败) | 系统消息每日回顾使用第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层技术支持完成的系统日志浏览器 | 任何消息 | 创建故障单和调度新的问题的 |
| 准确性错误(链路输入错误) | 在NOC接收的5分钟间隔门限值事件的SNMP轮询 | 输入或输出错误在任何5分钟间隔的一个错误在任何链路 | 创建新的问题和调度的故障单对第2层技术支持 |
其他主动服务类别级别定义适用于性能和容量。真正的性能和容量管理包括异常管理，基线和趋向和假设分析。服务级别定义定义了性能和容量例外阈值和将开始调查或升级的平均的阈值。这些阈值可能在某个方面然后适用于所有三个性能和容量管理进程。
容量和性能服务级别定义可以被分解为几个类别：网络链路、网络设备、端到端性能和应用程序性能。实施服务级别定义在这些区域要求关于设备容量、媒介容量、QoS特性和应用程序需求的特定方面的详细技术知识。为此，我们建议网络设计师实施性能和涉及容量的服务级别定义与供应商输入。
类似网络错误，实施容量和性能的一个服务级别定义从一般了解对如何将发现这些问题情况，开始将查看他们，并且发生了什么，当他们发生时。如果需要出现，您能添加特定事件定义到服务级别定义。您在以下区域可能也需要额外的工作保证成功：
- 对应用程序性能需求的清除了解
- 在有组织的意义的门限值的详细技术调查根据商业需求和总成本
- 预算循环和out-of-cycle升级需求
- 第1层，第2层和第3层支持责任
- 网络管理管理信息的优先级和重要性平衡了与操作组能有效处理的事前工作量
- 培训的需求保证支持人员了解消息或戒备，并且能有效处理被定义的情况
- 保证的事件关联方法或的进程多份故障单没有为同一个根本原因问题生成
- 在帮助与事件标识在第1层支持级别的特定消息或戒备的文档
下面的表显示提供清除了解对的链路利用率的一个示例服务级别定义谁对预防性网络错误预警负责，问题如何将被识别，并且什么将发生，当问题发生时。组织可能还是需要另外的努力如上所定义保证成功。
| 网络区域/Media | 探知方法 | 阈值 | 执行的操作 |
|---|---|---|---|
| 园区LAN骨干网和分布链路 | 在5分钟间隔RMON例外陷井的SNMP轮询在核心和分布链路 | 在5分钟间隔90%利用率的50%利用率通过例外陷井 | 对性能评估QoS要求或计划升级的电子邮件别名组的电子邮件通知反复出现的问题的 |
| 国内广域网链路 | 在5分钟间隔的SNMP轮询 | 在5分钟间隔的75%利用率 | 对性能评估QoS要求或计划升级的电子邮件别名组的电子邮件通知反复出现的问题的 |
| 外联网广域网链路 | 在5分钟间隔的SNMP轮询 | 在5分钟间隔的60%利用率 | 对性能评估QoS要求或计划升级的电子邮件别名组的电子邮件通知反复出现的问题的 |
下面的表定义了设备容量和性能门限值的服务级别定义。保证您创建是有意义和有用的在防止网络问题或可用性问题的阈值。因为被不选定的设备控制层面资源问题能有严重网络影响，这是一个非常重要区域。
| Cisco 7500 | CPU，内存，缓冲区 | 在-5-minute间隔RMON通知的SNMP轮询CPU的 | 在75%的CPU在5分钟间隔期间， 99%通过在50%的RMON通知内存在99%利用率的5分钟间隔缓冲区期间 | 对解决问题的性能和容量电子邮件别名组的电子邮件通知或计划升级RMON CPU在99%，地方故障单和页等级2支持传呼器 |
| Cisco 2600 | CPU，内存 | 在5分钟间隔的SNMP轮询 | 在75%的CPU在50%的5分钟间隔内存期间在5分钟间隔期间 | 对解决问题或计划升级的性能和容量电子邮件别名组的电子邮件通知 |
| Catalyst 5000 | 底板利用率，内存 | 在5分钟间隔的SNMP轮询 | 在50%利用率内存的背板在75%利用率 | 对解决问题或计划升级的性能和容量电子邮件别名组的电子邮件通知 |
| LightStream® 1010 ATM交换机 | CPU，内存 | 在5分钟间隔的SNMP轮询 | 在65%利用率内存的CPU在50%利用率 | 对解决问题或计划升级的性能和容量电子邮件别名组的电子邮件通知 |
下张表定义了端到端性能和容量的服务级别定义。这些阈值根据应用程序需求通常，但是可能也使用指示某种网络性能或容量问题。因为测量从每个点的性能在对其他点的网络要求重要的资源并且创建顶上，极大量的网络与服务级别定义的多数组织性能的创建仅几个性能定义。这些端到端性能问题在链路或设备容量门限值可能也被捉住。我们由地理区域推荐一般定义。一些重要站点或链路可能如果需要，被添加。
| 网络区域/Media | 测量方法 | 阈值 | 执行的操作 |
|---|---|---|---|
| 园区LAN | 什么都没有问题没有期待难测量整个LAN基础架构 | 10毫秒往返响应时间或较少一直 | 对解决问题或计划升级的性能和容量电子邮件别名组的电子邮件通知 |
| 国内广域网链路 | 从SF到NY和SF的当前测量向仅芝加哥使用互联网性能监控器(IPM) ICMP回音 | 在5分钟平均的75毫秒往返响应时间 | 对性能评估QoS要求或计划升级的电子邮件别名组的电子邮件通知反复出现的问题的 |
| 旧金山向东京 | 从旧金山的当前测量向布鲁塞尔使用IPM和ICMP回音 | 在5分钟平均的250毫秒往返响应时间 | 对性能评估QoS要求或计划升级的电子邮件别名组的电子邮件通知反复出现的问题的 |
| 旧金山向布鲁塞尔 | 从旧金山的当前测量向布鲁塞尔使用IPM和ICMP回音 | 在5分钟平均的175毫秒往返响应时间 | 对性能评估QoS要求或计划升级的电子邮件别名组的电子邮件通知反复出现的问题的 |
服务级别定义的最终区域是为应用程序性能。因为服务器的性能和容量很可能是在应用程序性能的最大的要素应用程序性能服务级别定义通常是由应用程序或服务器管理组创建的。网络组织能通过创建网络应用程序性能的服务级别定义实现极大的好处，由于：
- 服务级别定义和测量可帮助排除冲突在组之间。
- 单个应用的服务级别定义是重要的，如果QoS为关键应用程序被配置，并且其他数据流被认为可选。
如果选择创建和测量应用程序性能，这很可能是最佳，如果不测量性能到服务器。这然后帮助区分在网络问题之间和应用程序或者服务器问题。请使用探测或系统可用性代理软件运行在Cisco路由器的和控制信息包类型和测量频率的Cisco IPM。
下面的表显示应用程序性能的一个简单的服务级别定义。
| 应用程序 | 测量方法 | 阈值 | 执行的操作 |
|---|---|---|---|
| 企业资源规划(ERP)应用程序TCP端口1529 SF的布鲁塞尔 | 布鲁塞尔向旧金山使用测量端口1529往返性能布鲁塞尔网关的IPM对SFO网关2 | 在5分钟平均的175毫秒往返响应时间 | 对性能评估反复出现的问题的问题或计划升级的电子邮件别名组的电子邮件通知 |
| ERP应用程序TCP端口1529 SF的东京 | 布鲁塞尔向旧金山使用测量端口1529往返性能布鲁塞尔网关的IPM对SFO网关2 | 在5分钟平均的200毫秒往返响应时间 | 对性能评估反复出现的问题的问题或计划升级的电子邮件别名组的电子邮件通知 |
| 用户技术支持应用TCP端口1702 SF的悉尼 | 悉尼向旧金山使用测量端口1702往返性能悉尼网关的IPM对SFO网关1 | 在5分钟平均的250毫秒往返响应时间 | 对性能评估反复出现的问题的问题或计划升级的电子邮件别名组的电子邮件通知 |
步骤 6：收集权值和监控程序
除非组织收集权值并且监控成功，服务级别定义独自是不值得的。在创建一个重要服务级别定义，请定义服务级别如何将被测量并且报告。测量服务级别确定组织是否符合目标并且识别可用性或性能问题的根本原因。并且，当选择方法测量服务级别定义时，请考虑目标。欲知更多信息，请参阅创建和维护SLA。
监控服务级别需要，通常每个月，举行一个定期检查会议讨论定期服务。讨论所有权值，并且他们是否依照目标。如果他们不一致，请确定问题的根本原因并且实现改进。您应该也报道当前主动性和以推动个别情况进步。
创建和维护SLA
服务级别定义是一个非常好的基本组成部分他们帮助创建在组织中的一致QoS和帮助改进可用性。下一步是SLA，是改进，因为他们对齐业务目标和成本要求直接地服务质量。良好构架的SLA然后起一个型号作用对于效率、质量和协同在用户属性之间和支持组通过维护清楚的进程和程序网络问题或问题。
SLA提供几个好处：
- SLA服务的建立双向责任制，意味着用户和应用组也是对网络服务负有责任。如果他们不帮助创建一项特定服务的SLA和与网络组传达商业影响，则他们可能实际上是对问题负有责任。
- SLA帮助确定必要的标准工具和资源符合商业需求。决定多少个人，并且哪些工具使用没有SLA经常是一个预算猜测。服务可能被额外设计，导致过度花费，或者设计中的，导致为满足的业务目标。调整SLA帮助达到该平衡最佳的级别。
- 本文SLA创建设置的服务级别期望一个更加清楚的通信工具。
在服务级别定义被创建了后，我们推荐构件SLA的以下步骤：在服务级别定义被创建了后，我们推荐构件SLA的以下步骤：
7. 满足前提对于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方面，我们推荐网络设计师和应用程序建筑师技术团队。技术协助严密能近似网络的可用性和功能，并且什么是需要的到达特定目标。
service-provider，因为他们只为了获取在其他服务提供商的竞争力被创建SLA通常不包括用户输入。有时，上面的管理将创建这些SLA在非常高可用性或高性能级别促销他们的服务和为内部员工提供内部目标。其他服务提供商将集中改进可用性的技术方面通过创建被测量并且管理得内部地的严格的服务级别定义。在某些情况下，两个努力发生同时，但是不一定一起或者在同样目标。
选择在SLA涉及的当事人应该根据SLA的目标然后。某些可能的目标是：
- 符合响应式支持服务业务目标
- 提供最高水平可用性通过定义积极的SLA
- 促销或出售服务
步骤 9：确定服务单元
主服务/支持SLA通常将有许多组件，包括技术支持的级别，如何将被测量， SLA调节的升级路径和整体预算关心。高可用性环境的服务单元应该包括积极的服务定义以及反应目标。其它细节包括以下：
- 在线支持工作时间和程序工作时间外技术支持
- 优先级定义，包括问题类型、最大时间开始在问题的工作，最大时间解决问题和升级步骤
- 将支持的产品或服务，排列按照业务的重要性的顺序
- 为专业技术期望，性能级别期望，状态报告和用户责任支持对问题解决方法
- 地理或业务部门支持级别问题和需求
- 问题管理方法和程序(呼叫跟踪系统)
- 支持中心目标
- 网络错误检测和服务回应
- 网络可用性评定和报告
- 网络容量和性能测定和报告
- 冲突解决程序
- 资助被实施的SLA
网络应用或服务SLA可能有根据用户组要求和业务的重要性的另外的需要。网络组织必须严密监听与这些商业需求和提出适合到整体支持结构的专门化的解决方案。因为不创建供一些单个或组使用，仅打算的一项高端服务是重要的适合到整体支持文化是重要。在许多情况下，这些另外的需求可以设置到“解决方案”类别。示例也许是根据商业需要的白金、金子和银色解决方案。参见SLA需求以下示例特定商业需要的。
Note: 支持结构、升级路径、帮助台程序、测量和优先级定义应该主要依然是维护和改进一致的服务文化的同样。
- 带宽需求和功能突发传输的
- 性能要求
- QoS需求和定义
- 可用性需求和冗余建立解决方案表
- 监控和报告要求、方法和程序
- 应用程序/服务单元的升级标准
- 资助out-of-budget需求或交叉填装方法
例如，您能创建WAN站点连接的解决方案类别。白金解决方案将带有双T1服务给站点。不同的载波将提供每条T1线路。站点将有两配置的路由器，以便，如果任何T1或路由器发生了故障站点不会体验储运损耗。金子服务将有两路由器，但是将使用备用帧中继。此解决方案可能有有限带宽处于储运损耗的。银色解决方案只将有一个路由器和一位承载业务。这些解决方案中的任一个为问题票的不同的优先级将设想。如果优先级1或2票对于储运损耗，是必需的一些组织可能要求白金或金等级解决方案。他们要求的用户组织能然后资助服务的级别。下面的表根据对外部网连通性的商业需要显示提供服务的三个级别组织的示例。
| 解决方案 | 白金 | 金子 | 银 |
|---|---|---|---|
| 设备 | WAN连接的冗余路由器 | 备份的冗余路由器在核心站点 | 没有设备冗余 |
| WAN | 冗余T1连接，多个载波 | 与帧中继备份的T1连接 | 没有广域网冗余 |
| 带宽需求和突发传输 | 与负载分配的冗余T1突发传输的 | 非负载分配，仅重要应用的帧中继备份;仅帧中继64K CIR | 至T1 |
| 性能 | 一致100 MS往返响应时间或较少 | 响应时间100毫秒或较少期待99.9% | 响应时间100毫秒或较少期待99% |
| 可用性需求 | 99.99% | 99.95% | 99.9% |
| 支持中心优先级，当下来 | 优先级1 ：下来商业关键服务 | 优先级2 ：事务影响服务下来 | 优先级3 ：下来商业连通性 |
步骤 10：了解客户的商业需求和目标
此步骤借SLA开发者很多可信度。通过了解多种商业集团的需要，最初的SLA文件将是离商业需求和期望的结果较近。设法了解停机代价用户服务的。根据丢失的生产率、收入和客户商誉的估计。记住与一些人的甚而简单的连接能严重影响收入。在这种情况下，请务必帮助用户了解可能发生的可用性和性能风险，以便组织更好了解需要服务的级别。如果错过此步骤，您可以获得需求许多的用户100百分比可用性。
SLA开发者应该也了解组织的商业目标和增长为了适应网络升级，工作量和预算。了解将使用的应用程序也是有用的。有希望地组织有在每个应用程序的应用配置文件，但是，如果没有，考虑执行应用程序的一个技术评估确定网络有关的问题。
步骤 11：定义对于每个组是必需的SLA
主要的支持SLA应该包括重要业务部门和功能组表示法，例如联网操作、服务器操作和应用支持组。应该根据商业需要认可这些组以及他们的在支持流程的部分。有从许多组帮助的表示法也请创建一个公平的整体支持解决方案，不用个人组首选或优先级。这可以导致支持组织到提供高端服务为个人组，可能破坏组织的整体服务文化的方案。例如，用户也许坚持他的应用程序在公司内是最重要，当实际上停机代价该应用程序的比其他极大是较少根据丢失的收入、丢失的生产率和丢失的客户商誉时。
在组织内的不同的业务部门将有不同的需求。网络SLA的一个目标应该是在适应不同的服务级别的一种整体格式的协议。这些需求通常是可用性、QoS、性能和MTTR。在网络SLA中，这些变量通过优先安排调整，定义不同的网络冲击问题MTTR的帮助台优先级和建立将帮助处理不同的可用性和性能要求的解决方案表的可能性的QoS商业应用处理。一个简单解决方案矩阵的示例企业制造企业的可能看起来某事下面的表。您能添加关于可用性、QoS和性能的信息。
| 业务部门 | 应用程序 | 停机代价 | 问题优先级，当下来 | 服务器/network需求 |
|---|---|---|---|---|
| 制造 | ERP | 高 | 1 | 最高的冗余 |
| 用户技术支持 | 用户关怀 | 高 | 1 | 最高的冗余 |
| 设计 | 文件服务器， ASIC设计 | 媒体 | 2 | LAN核心冗余 |
| 销售 | 文件服务器 | 媒体 | 2 | LAN核心冗余 |
步骤 12：选择SLA的格式
SLA的格式能根据小组的希望或组织需求变化。下列是网络SLA的一个推荐的示例分级显示：
- 协议的目的
- 参加协议的当事人
- 目标和目标的协议
- 支持的服务提供的和产品
- 帮助台服务和呼叫跟踪
- 根据MTTR定义的商业影响的问题严重性定义
- QoS定义的商业关键服务优先级
- 根据可用性和性能要求的被定义的解决方案类别
- 培训的需求
- 容量设计需求
- 逐步升级需求
- 报告
- 提供的网络解决方案
- 新的解决方案请求
- 不支持的产品或应用程序
- 商业策略
- 技术支持在工作时间
- 工作完毕后支持定义
- 假日覆盖
- 联系电话号码
- 工作量预测
- 委屈解决方法
- 服务权利标准
- 用户和组安全责任
- 问题管理程序
- 呼叫开始(用户和自动化)
- 第一层的回应和呼叫修理比率
- 呼叫跟踪和记录保持
- 呼叫人责任
- 问题诊断和呼叫关闭需求
- 网络管理问题检测和服务回应
- 问题解决方法类别或定义
- 慢性问题处理
- 重要问题/例外呼叫处理
- 服务质量目标
- 质量定义
- 测量定义
- 质量目标
- 平均时间由问题优先级起动问题解决方法
- 解决问题的平均时间由问题优先级的
- 平均时间被问题优先级更换硬件
- 网络可用性和性能
- 管理容量
- 管理增长
- 质量报告
- 雇用职员和预算值
- 人才配备模型
- 操作预算
- 协议维护
- 符合复核日程表
- 性能报告和复核
- 报告权值的调节
- 定期SLA更新
- 审批
- 附件和展览
- 呼叫流程图
- 上报程序表
- 网络解决方案表
- 报告示例
步骤 13：开发SLA工作组
下一步在SLA工作组识别参加者，包括组领导。工作组能包括用户或管理器从业务部门或功能组或者代表从一个地理基础。这些单个传达SLA问题给他们的各自工作组。能对关键SLA元素达成协议的管理器和作决策者应该参与。这些单个可能包括即可帮助定义技术问题与SLA有关和做出IT级别决策的管理和技术人(支持中心管理器、服务器操作操作管理员、应用程序管理器和网络Operations Manager)。
网络SLA工作组应该也包括包含许多应用程序和服务的清楚的应用程序和企业表示法为了获得在一个网络SLA的协议。工作组应该有排列的权限商业危急进程和服务网络的，以及可用性和性能要求的独立服务。此信息将用于创建不同的事务影响问题类型的优先级，指定优先级在网络的关键业务流量和创建根据商业需求的将来标准的网络解决方案。
步骤 14：召开工作组会议并且草拟SLA
工作组应该最初创建工作组需许可证。需许可证应该表示目标、主动性和时间段SLA的。其次组应该开发特定任务计划和确定日程表和时间表的开发和实现SLA。组应该也开发测量的支持级别报告的进程支持标准。最终步骤创建草稿SLA协议。
网络SLA工作组应该每星期一次最初见面开发SLA。在SLA被创建了并且被审批了后，组可能为SLA更新每月甚置每季度见面。
步骤 15：协商SLA
在创建SLA的最后一步最终协商和退出。此步骤包括：
- 查看草稿
- 协商内容
- 编辑和校订本文
- 获得最终的批准
在最终版本被发送到管理为获得批准前，查看草稿，协商内容和做版本的此循环可能采取多个循环。
从网络管理器的方面，协商可以被测量的可达成的结果是重要的。设法备份性能和可用性与那些的协定从其他相关组织。这可能包括质量定义、测量定义和质量目标。切记被添加的服务与额外的成本是等同的。切记用户组了解服务的另外的级别将开销更多并且让他们做出决策，如果它是重要商业需求。您可容易地执行在SLA的许多方面的一个成本分析例如硬件更换时间。
步骤 16：测量和监控程序SLA符合
测量SLA符合和报告结果是帮助保证长期一致性和结果SLA进程的重要方面。我们一般建议SLA的所有主要组件是可测量的，并且测量方法在SLA实施之前放在适当的位置。然后请举行在用户和支持组之间的月会查看评定，识别问题根本原因，并且建议解决方案符合或超出服务级别需求。这帮助使SLA进程类似于所有现代质量改进程序。
以下部分提供其它细节关于怎样在组织内的管理能评估其SLA和其整体服务级别管理。
服务级别管理性能指示器
服务级别管理性能指示器提供一个机制监控和提高服务级别作为成功测量。这允许组织快速地起反应服务问题和对更加容易地了解在其环境里影响服务或停机代价的问题。因为组织是牵强的到反应姿态，不测量服务级别定义也否定被完成的所有正积极工作。没人将呼叫说服务是工作极大，但是许多用户将呼叫说在不符合他们的要求的服务。
因为他们提供方法充分地了解现有的服务级别和做根据现期杂志的调节因此服务级别管理性能指示器是服务级别管理的一个主要需求。这是为提供积极的技术支持和做质量改进的基本类型。当组织执行关于问题的问题根源分析并且做质量改进时，这可能然后是改进可用性、性能和服务质量的最佳的方法可用。
例如，请考虑以下实际方案。公司x获得许多用户投诉网络频繁地是下来在延长时间。通过测量可用性，公司查找主要问题是一些个广域网站点。那些视域更加周密的调查表示大多问题在一些个广域网站点。找到根本原因，并且组织解决了问题。组织然后设置可用性的服务级别目标并且签署了协议以用户组。将来评定识别的问题迅速由于非一致对SLA。网络组然后查看了作为有更高的职业化、专业技术和一个整体资产对组织。组从反应有效移动向积极本质上并且帮助了公司的最后一行。
不幸地，多数网络组织今天未限制服务级别定义和性能指标。结果，他们花费起反应对用户投诉或问题的大多数他们的时间而不是主动地识别根本原因和提供符合商业需求的网络服务。
请使用以下SLA性能指标确定服务级别管理进程的成功：
- 包括可用性、性能、响应式服务响应时间、问题解决目标和问题上报的描述的服务级别定义或SLA
- 性能指示器度量，包括可用性、性能、响应时间由优先级，时刻由优先级解决和其他可测量的SLA参数
- 查看服务级别标准和实现改进的月度网络服务级别管理会议
描述的服务级别协议或服务级别定义
第一个性能指标是选派的文件SLA或服务级别定义。因为这些是主要的用户需求，服务级别定义的主要目标应该是可用性和性能。
辅目标是重要的，因为他们帮助定义可用性或性能级别如何将被达到。例如，如果组织有积极的可用性和性能目标，防止问题发生和迅速解决问题将是重要的，当他们发生。辅目标帮助定义必要的进程达到期望可用性和性能级别。
反映的次要目标包括：
- 由呼叫优先级的响应式服务响应时间
- 问题解决目标或MTTR
- 问题上报程序。
积极的辅目标包括：
- 设备down或链路down检测
- 网络错误检测
- 容量或性能问题检测。
主要目标、可用性和性能的服务级别定义应该包括：
目标
- 目标如何将被测量
- 当事人负责对测量可用性和性能
- 当事人负责对可用性和性能目标
- 不符合的流程
若可能，我们建议当事人负责对测量和当事人负责对结果是不同的防止利益冲突。时常，您可能也需要校准可用性数值由于添加/移动/更改错误的它，未被发现的错误或者可用性评定问题。服务级别定义可能也包括修改的结果一个进程帮助改进准确性和防止不正确的调节。请参阅下个部分关于方法学测量可用性和性能。
反映的次要目标的服务级别定义定义了组织如何将回应网络或IT范围问题，在他们被识别后，包括：
- 问题优先级定义
- 由呼叫优先级的响应式服务响应时间
- 问题解决目标或者MTTR
- 问题上报程序
一般来说，这些目标定义了谁对问题将负责所有给定时间间隔，并且那些负责在何种程度上应该下降他们的当前任务研究被定义的问题。类似其他服务级别定义，服务级别文件应该选派目标如何将被测量，当事人负责对测量和不符合的流程。
积极的辅目标的服务定义定义了组织如何提供积极的技术支持，包括网络下来，链路down或设备down情况、网络错误情况和网络容量门限值的证明。设置提升主动管理的目标，因为质量主动管理帮助消除问题，并且帮助快速地解决问题。这通过设置多少自发事件的目标通常完成被创建并且被解决，不用用户通知。许多组织设置在支持中心软件的一个标志位为此识别自发事件与反作用情形。服务级别文件应该也包含关于目标如何的信息将被测量，当事人负责对测量和不符合的流程。
性能指示器度量
我们总是建议所有被定义的服务级别目标是可测量的，允许组织测量服务级别，识别禁止可用性和性能的主要目标的问题根源服务问题和做是瞄准的特定目标的改进。总之，权值是允许网络管理器管理服务级别一致性和根据商业需求做改进的工具。
不幸地，许多组织不收集可用性、性能和其他权值。组织归因于此无法提供完全准确性、费用、网络开销和可用资源。这些要素能影响能力测量服务级别，但是组织应该着重整体目标管理和提高服务级别。许多组织能创建不也许提供完全准确性的便宜，低开销权值，但是满足这些主要目标。
测量可用性和性能是在服务级别权值经常忽略的一个区域。是成功的与这些权值的组织使用两个十分简单的方法。一个方法将从网络的一个核心位置发送互联网控制消息协议(ICMP) ping信息包到边缘。使用此方法，您能也得到性能。也是成功的与此方法的组织组队好象设备到“可用性组”，例如LAN设备或国内现场办公室。因为组织通常有网络的不同的地理或商业危急区域的，不同的服务级别目标这也是有吸引力的。这允许权值组平均为所有设备以可用性组得到一个合理的结果。
计算可用性另一个成功的方法将使用故障单和被呼叫的测量受影响用户记录(IUM)。此方法制成表是受储运损耗的影响的用户的数量并且乘它以储运损耗的纪录的数量。当表示为百分比总分钟用时间，这可以容易地被转换成可用性。无论如何，识别和测量停工期的根本原因可以也是有用的，以便改进可以更加容易地被瞄准。问题根源类别包括硬件问题、软件问题、链路或载波问题、功率或者环境问题、更改失败和用户错误。
可测量的响应式支持服务目标包括：
- 由呼叫优先级的响应式服务响应时间
- 问题解决目标或者MTTR
- 问题上报时间
测量响应式支持服务目标通过生成从支持中心数据库的报告，包括以下字段：
- 呼叫最初报告的时间(或加入数据库)
- 呼叫通过一单个研究接受问题的时间
- 问题被升级的时间
- 时间问题是闭合的
这些权值在数据库和更新问题在实时可能要求管理影响一致输入问题。有时，组织能自动地生成网络事件或电子邮件请求的故障单。这帮助为识别问题的启动时间提供准确性。从这种生成的报告权值将由优先级、工作组和单个通常排序问题帮助确定潜在问题。
因为要求您监控积极工作和计算其效果的某测量，测量积极的技术支持进程是更加困难的。一点工作在此区域被完成了。是确切，然而，人的仅小的百分比实际上网络问题向支持中心报告，并且，当他们报告问题，将清楚地需要时间解释问题或查出问题作为网络有关。不是所有的自发事件在可用性将有一立即效果，并且性能由于冗余设备或链路的故障对终端用户有很少的影响。
实现积极的服务级别定义或协定的组织如此执行由于商业需求和潜在的可用性风险。测量然后执行根据自发事件的数量或百分比，与是由用户生成的反作用情形相对。它是一个好想法测量相当数量自发事件在各个区域。这些类别将包括在设备下，下来链路、网络错误和容量侵害。若干工作可能也被完成使用可用性建模和自发事件确定在实现完成的可用性的效果积极的服务定义。
服务级别管理审查
服务级别管理成功另一次测量是服务级别管理审查。应该执行这SLA是否到位。执行服务级别管理审查在一个月会与单个负责对测量和提供被定义的服务级别。当SLA是包含的时，用户组可能也存在。会议的目的将然后查看被测量的服务级别定义的性能和做改进。
每个会议应该有包括的一张被定义的日程表：
- 被测量的服务级别回顾特定时期的
- 改进计划回顾为各自的区域定义的
- 当前服务级别权值
- 什么改进讨论根据当前套是需要的权值。
随着时间的推移，组织可能也趋向服务级别标准确定组的效果。此进程不是不同于质量范围或质量改进进程。会议帮助目标各自的问题并且确定根据根本原因的解决方案。
服务级别管理汇总
总之，服务级别管理允许组织从响应式支持服务型号移动向网络可用性和性能级别商业需求取决于的一个积极的支持模型，不由最新的套问题。进程帮助创建持续服务级别改进和增加的企业竞争性的环境。服务级别管理也是积极的网络管理的最重要的管理组件。为此，服务级别管理是高度推荐的在所有网络计划和设计阶段，并且应该从任何最近定义的网络体系结构开始。这允许组织正确地实现解决方案第一次，与最少量的停工期或重做。
