服务水平管理概述SLA.docx
《服务水平管理概述SLA.docx》由会员分享，可在线阅读，更多相关《服务水平管理概述SLA.docx（31页珍藏版）》请在冰豆网上搜索。
服务水平管理概述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信息可用于所有思科组件，并且可根据请求、向本地客户经理提供。
CiscoNSAHAS项目还使用一种工具来帮助确定硬件可用性及网络路径，即使在系统中存在模块冗余、机底冗余及路径冗余时也可以使用这种工具。
硬件可靠性的一个主要因素是MTTR。
公司应评估它们修复故障硬件的速度。
如果公司未制定备用方案，只依赖于标准CiscoSMARTnet?
协议，则潜在的评估硬件更换时间为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%。
这种方法业已成功应用于数据环境中，结果基本相同，目前正被用作服务供应商有线网络中分组有线规程的预算。
如果将该数值用于完全冗余的系统，则我们可以假定，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%的不可用性问题是由于无法检测错误、变化故障及性能问题造成的。
公司在制定可用性预算时，不愿意接受用户错误和流程引发的不可用性是其他所有理论上的不可用性的四倍这一实施，然而，各种证据一致表明，这种情况存在于许多环境中。
下面我们将详细阐述不可用性的这个方面。
由于您无法从理论上计算由用户错误和流程引发的不可用性数量，我们建议您在制定企业力求完美的可用性预算时不将其考虑在内。
但企业必须了解其流程和专业技术水平中现在所面临的可用性风险。
透彻地了解了这些风险及抑制因素之后，网络规划人员便有可能将这些问题引发的一定数量的不可用性考虑在内。
CiscoNSAHAS项目深入研究了这些问题，并可帮助企业了解由于流程、用户错误或专业技术问题引发的不可用性。
i.制定最终的可用性预算
您可将以前定义的所有领域的可用性相乘来决定整个可用性预算。
这种方法通常适用于任意两点间的连接相类似的同机种环境，如：
分级体系模块化LAN环境或分级体系标准WAN环境等。
这下面的例子中，为分级体系模块化LAN环境确定了可用性预算。
该环境为所有网络组件都配备了备用发电机和UPS系统，并对电源进行适当的管理。
企业未使用VoIP，也不希望将软件故障切换时间考虑在内。
估算结果如下：
∙两个端点间的硬件路径可用性=99.99%
∙使用GD软件可靠性作为基准的软件可用性=99.9999%
∙带有备用系统的环境和电源可用性=99.999%
∙考虑LAN环境中的链路故障的可用性=99.9999%
∙未将系统故障切换时间计算在内的可用性=100%
∙认为不存在用户错误和流程缺陷的可用性=100%
企业希望达到的最终可用性预算是：
0.9999X0.999999X0.999999X0.999999=0.999896，或99.9896%的可用性。
如果我们将用户或流程错误引发的潜在不可用性考虑在内，并假设其引发的不可用性是技术因素引发的可用性的四倍，则最终可用性预算是99.95%。
对这个例子的分析使我们了解到，LAN可用性在99.95%与99.989%之间。
现在，这些数值能够用作网络公司的服务水平目标。
可以测量系统中的可用性并确定上述六个领域分别引发的不可用性百分率来计算其他数值。
这使公司能够对供应商、运营商、流程和人员进行适当评估。
这些数值也可用来设置业务期望值。
如果您对99.95%与99.989%之间的可用性不满意，可投资更多资源来获得理想的可用性级别。
网络管理人员了解每个特定可用性级别的故障停机时间将大有帮助。
计算任何可用性级别的年故障停机时间（分钟）的公式如下：
故障停机（分钟）/年=525600—（可用性级别X5256）
如果可用性级别是99.95%，则结果是525600。
（99.95X5256），或者相当于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小时，远远
升级会员 