可用性 : 高可用性

服务级别管理:最佳实践白皮书

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 22 日) | 反馈


目录


简介

本文描述服务级别管理和service-level agreements (SLA)高可用性网络的。它包括服务级别管理和指示器的重要成功因素能帮助评估成功。本文为遵从高性能的服务团队识别的最佳实践指南的SLA也提供大量详细信息。

服务级别管理概述

网络组织通过反应构建固定的网络基础设施和工作处理独立服务问题历史上满足展开网络要求。当中断发生了,组织将构建更新过程、防止一特定的中断再发生的管理功能或者基础设施。然而,由于一更高的更改速率和不断增长的可用性需求,我们当前需要一个改善的型号主动地防止意外停机和迅速修复网络。许多service-provider和企业尝试改善定义了服务要求的级别达到商业目标。

重要成功因素

SLA的重要成功因素用于定义关键要素成功建立的可获得的服务级别和维护的SLA。要合格作为重要成功因素,进程或进程步骤必须一般来说改进SLA和好处网络可用性的质量。重要成功因素应该也是可测量的,因此组织能确定多么成功是相对定义步骤。

欲了解更详细的信息请参阅实现服务级别管理

指示器

指示器提供组织测量重要成功因素的机制。您每月典型地查看这些保证服务级别定义或SLA很好工作。网络操作组和必要的工具组可执行以下量度。

注意: 除量度之外,对于没有SLA的组织,我们推荐您执行服务级别定义和服务级别复核。

指示器包括:

  • 包括可用性、性能、响应式服务响应时间、问题解决目标和问题上报的描述的服务级别定义或SLA。

  • 查看服务级别标准和实现改进的每月网络服务级别评审会议。

  • 性能指示器度量,包括可用性、性能、响应时间由优先级,时刻由优先级解决和其他可测量的SLA参数。

欲知更多信息,请参阅实现服务级别管理

服务级别管理进程流

服务级别管理的高级流程包含两个主要的组:

  1. 定义网络服务级别

  2. 创建和维护SLA

点击对象在以下图表中查看该步骤的详细信息。

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/15117-highlevel.gif

实现服务级别管理

实现服务级别管理包括十六个步骤分开成以下两个主要类别:

定义网络服务级别

网络管理器需要定义网络支持的主要规则,管理和测量。服务级别为所有网络人员提供目标,并且可以使用作为量度进入整体服务的质量。您也能我们服务级别定义,预算的网络资源一个工具和作为证据对需要资助更加高的QoS。他们也提供一个方式评估供应商和载波性能。

没有服务级别定义和测量,组织没有清楚目标。服务满意度可能由有小的差异化的用户管理在应用程序、服务器/客户端操作或者网络支持之间。预算可以是更加困难,因为最终结果不是清楚的对组织,并且终于,网络组织倾向于是反应,不积极的,在改善网络和支持模型。

我们推荐建立和支持的服务级别型号以下步骤:

  1. 分析技术目标和约束。

  2. 确定可用性预算。

  3. 创建选派的应用配置文件重要应用网络特性。

  4. 定义可用性和性能标准并且定义普通的期限。

  5. 创建包括可用性、性能、服务响应时间、解决问题的平均时间、故障检测、升级阈值和升级路径的服务级别定义。

  6. 收集量度并且监控服务级别定义。

步骤 1:分析技术目标和约束

开始分析的最佳方法技术目标和约束是群策群力或研究技术目标和需求。有时,因为这些个人有与他们的服务,涉及的特定目标它帮助邀请其他IT技术副本到此讨论。技术目标包括可用性级别、吞吐量、抖动、延迟、响应时间、可扩展性需求、新特性介绍、新应用介绍、安全、可管理性和均等开销。组织应该然后调查限制条件到达到给的那些目标可用资源。您能创建每个目标的工作表与限制条件的说明。最初,它可能似乎,好象大多目标不可达成的。然后开始优先处理目标或能仍然符合商业需求的降低期望。

例如,您也许有可用性级99.999百分比或者5分钟停机时间每个年。有许多限制条件对达到此目标,例如硬件中的单点故障、平均修复时间(MTTR)损坏的硬件在远程位置,载波可靠性、积极的故障检测功能、高更改速率和当前网络容量局限。结果,您可以调节目标到一个更加可达成的级别。在下一部分的可用性模型可帮助您集可实现的目标。

您可以也考虑提供高性能在有少量限制条件网络的某些区域。当网络组织发布可用性的时服务标准,在组织内的商业集团可能认为级别不可接受。这是然后开始SLA讨论或资助/能达到商业需求的预算的型号的一个自然点。

工作识别在达到技术目标或风险涉及的所有限制条件。确定优先级限制条件根据最巨大的风险或影响对于希望的目标。这帮助组织优先安排网络改进计划和确定多么限制条件可以容易地寻址。有三限制条件:

  • 网络技术、弹性和配置

  • 生命周期实践,包括规划、设计、实施和操作

  • 当前数据流负载或应用程序行为

网络技术、弹性和配置限制条件是所有限制或风险关联与提交技术、硬件、链路、设计或者配置。技术限制包括技术摆在的所有限制条件。例如,提交技术不允许在冗余网络环境的分秒的收敛时间,可能是关键为在间网络的持续的语音连接。另一示例可能是数据在陆地链接能横断,是大约每毫秒100英里的原始速度。

网络硬件弹性风险调查应该集中硬件拓扑、层级、模块化、冗余和MTBF沿定义路径网络的。网络链路限制条件应该着重网络链路和载波连接企业的。林克限制条件可能包括链路冗余和差异,媒体限制,配线基础设施、于本地环路连接和长途连接。设计限制与网络的物理或逻辑设计关连并且从设备的可用空间包括一切对路由协议实施的可扩展性。应该关于配置、可用性、可扩展性、性能和产能考虑所有协议和媒介设计。应该也考虑网络服务限制条件例如动态主机配置协议(DHCP)、域名系统(DNS)、防火墙、协议转换器和网络地址转换器。

生命周期实践定义了用于的网络的进程和管理一致部署解决方案,检测和修复问题,防止产能或性能问题和配置一致性和模块化的网络。因为专业技术和进程典型地是对未利用率的最大的投稿人您需要考虑此区域。网络生存周期是指周期规划、设计、实施和操作。在这些区域中的每一个内,您必须了解网络管理功能例如性能管理、配置管理、故障管理和安全。网络生命周期评估从Cisco NSA显示当前网络可及性限制的高可用性服务(HAS)服务是可得到关联与网络生命周期实践。

当前数据流负载或应用程序限制条件参考当前流量和应用程序影响。

不幸地,许多应用程序有要求仔细管理的重大的限制条件。抖动、延迟、吞吐量和带宽需求当前应用程序的典型地有许多限制条件。应用程序写入的方式可能也创建限制条件。应用程序描出帮助您改善了解这些问题;下一部分报道此功能。调查的当前可用性、流量、产能和性能所有也帮助网络管理器了解当前服务级别期望和风险。这用呼叫网络基线的进程典型地完成,帮助定义网络性能、可用性或者产能平均数定义的时间时间期,通常大约一个月。此信息通常使用容量规划和趋向,但是可能也使用了解服务级别问题。

以下工作表使用上述目标/限制条件方法防止安全攻击或服务拒绝(DoS)攻击目标示例。您能也使用此工作表帮助确定最小化的安全攻击服务保赔。

里斯克或限制条件 限制条件的类型 潜在影响
可用的DoS检测工具不能检测DOS攻击的所有类型。 技术/弹性 海伊
请勿有需要的员工和进程起反应到警报。 生命周期实践 海伊
当前网络访问策略不到位。 生命周期实践 介质
如果带宽拥塞使用攻击,当前更小带宽互联网连接可能是要素。 网络容量 介质
目前帮助的安全配置防止攻击可能不是详尽的。 技术/弹性 介质

步骤 2:确定可用性预算

可用性预算是网络的预计理论上的可用性在两定义的点之间的。准确理论上的信息是有用的在几个方式:

  • 当内部可用性和偏差的一个目标可以迅速定义和被补救,组织能使用此。

  • 信息可以由网络规划者使用在确定系统的可用性帮助保证设计将符合商业需求。

造成未利用率或停机时间的要素包括硬件故障、软件故障、电源和环境问题、链路或者载波故障、网络设计、人为错误或者缺乏进程。当评估网络的时,整体可用性预算您应该严密评估这些参数中的每一个。

如果组织当前测量可用性,您不可能需要可用性预算。请使用可用性评定作为基准预计用于服务级别定义的当前服务级别。然而,您可以是对比较两个了解潜在的理论上的可用性感兴趣与实际被测量的结果比较。

可用性是产品或服务将操作,当需要的可能性。请参阅以下定义:

  1. 可用性

    • 1 - (总连接停机时间)/(总在职连接时间)

    • 1 - [Sigma(num connections affected in outage i X duration of outage i)]/(在服务x操作的时间的数字conns)

  2. 前不可用

    1 -可用性或者总连接停机时间由于(硬件故障,软件故障,环境和电源问题、链路或者载波故障、网络设计或者用户错误和进程故障)

  3. 硬件可用性

    调查的第一个区域是潜在硬件失败和作用对前不可用。要确定此,组织在两点之间的一个路径需要了解所有网络组件MTBF和硬件故障的MTTR所有设备的。如果网络模块化和分层的,硬件可用性将是相同的在几乎任何两个点之间。MTBF信息为所有思科组件是可用的并且对本地帐户管理器根据需要是可用的。既使当模块冗余、机箱冗余和路径冗余在系统,存在Cisco NSA HAS程序也使用一个工具帮助确定沿网络路径的硬件可用性。硬件可靠性一个主要因素是MTTR。组织应该评估多他们能快修复损坏的硬件。如果组织没有节省的规划并且依靠一标准的思科SMARTnet™协议,则潜在的平均的替换时间是大约24个小时。在与核心冗余和没有访问冗余的典型的LAN环境,大致可用性是与四小时MTTR的99.99百分比。

  4. 软件可用性

    调查的下个区域是软件故障。用于测量的目的,思科定义了软件故障作为设备冷启动由于软件错误。思科取得了重大的进度往了解软件可用性;然而,更新的版本比标准部署版本需要时间测量和被认为较少可利用。标准部署版本,例如IOS版本11.2(18),被测量了在99.9999百分率可用性。这根据在使用六分钟的Cisco路由器的实际冷启动计算作为修理时间(路由器的时刻重新加载)。与各种各样的版本的组织预计轻微有更低的可用性由于已添加复杂性、互通性和增加的故障排除时间。与最新的软件版本的组织预计有更高的未利用率。未利用率的分配也是相当宽的,含义客户可能体验重大的未利用率或可用性接近通用部署版本。

  5. 环境和电源可用性

    您必须也认为在可用性的环境和电源问题。环境问题与必要的故障的冷却系统关连保持设备在一指定的工作温度。当他们显著地在出于规格而不是冒险对所有硬件的损伤许多Cisco设备将关闭。为可用性预算的目的,电源,因为它是未利用率的主导的原因在此区域,将使用。

    虽然电源故障是确定网络可用性的一个重要方面,此讨论被限制,因为理论功率分析不可能准确地完成。组织必须评估是电源可用性的一近似测量到根据在其实现的地理区域、电源备份功能和进程的体验的其设备保证质量一致的电源到所有设备。

    对于一个保守的评估,我们能说一个组织用备用发电机, uninterruptible-power-supply (不间断电源)系统和优质电源实施进程可能体验可用性六个9s,或者99.9999百分比,而没有这些系统的组织可能体验可用性在99.99百分比,或者大约36分钟停机时间每年。当然您能调整这些值到根据组织的征收或实际数据的更加可实现的值。

  6. 林克或载波故障

    林克和载波故障是主要因素关于在广域网环境的可用性。记住广域网环境是完全是受可用性问题支配和组织网络一样,包括硬件故障、软件故障、用户错误和电源故障的其他网络。

    许多运营商网络已经执行在他们的系统的可用性预算,但是获得此信息可能是困难。记住载波频繁地也有可用性有在实际可用性预算的很少或没有基本类型的保证级别。这些保证级别有时销售和销售使用的方法促进载波。有时,这些网络也发布可用性看上去很好的统计信息。记住这些统计信息在未利用率可能仅适用于完全冗余的核心网络,并且不析因由于于本地环路访问,是对未利用率的一位主要因素在广域网网络。

    创建可用性的估计广域网环境的应该根据实际载波信息和级别WAN连接的冗余。如果组织有多个大厦入口设施、冗余于本地环路供应商、同步光网络(SONET)本地访问和冗余长途运营商以地理差异,广域网可用性将显著地被提高。

    电话服务是非冗余网络连通性的相当准确可用性预算在广域网环境。电话的端到端连通性有大致可用性99.94百分比预算使用可用性预算方法类似于描述的那个在此部分。此方法在数据环境顺利地使用了与仅轻微的变化和当前使用作为目标在service-provider有线网络的Packet Cable规格。如果我们适用于此值一个完全冗余的系统,我们能假设,广域网可用性将是接近99.9999百分比联机。当然非常少量组织有完全冗余,地理被分散的广域网系统由于成本和可用性,因此请使用关于此功能的适当的判断。

    LAN环境的链路故障是不太可能的。然而,计划程序可能要假设少量的停机时间由于残破或松散连接器。对于LAN网络,保守估计近似是99.9999百分比可用性或者大约30秒每个年。

  7. 网络设计

    网络设计是对可用性的另一位主要因素。不可升级的设计、设计错误和网络收敛时间全部负影响可用性。

    注意: 为本文,不可升级的设计或设计错误在以下部分包括。

    网络设计对根据导致数据流重路由的网络的软件和硬件故障的一个可测量的值然后被限制。此值典型地呼叫“系统切换时间”并且是自恢复性能的协议功能的要素在系统内的。

    使用系统计算的,同样方法由完全计算可用性。然而,除非网络切换时间符合网络应用程序要求,这无效。如果切换时间是可接受,请从计算删除它。如果切换时间不是可接受,则您必须添加它到计算。示例也许是在预计的或实际切换时间是30秒的环境的VoIP。在本例中,用户将挂断电话和可能再试一次。用户一定将看到此时期作为未利用率,在可用性预算方面未预计。

    计算未利用率由于系统切换时间通过查看沿冗余路径的理论上的软件和硬件可用性,因为切换在此区域将发生。您必须认识能的冗余路径失效和导致切换,那些设备MTBF和切换时间设备的数量。简单的示例是35,433个小时MTBF两个冗余相同设备和切换时间中的每一的30秒。除35,433 8766 (几小时每个年平均包括闰年),我们看到设备一次将发生故障每四年。如果我们使用30秒作为切换时间,我们能然后假设,每个设备将体验,平均,每个未利用率的年7.5秒由于切换。因为用户可能横贯任一个路径,结果然后被加倍对每个年15秒。当这计算根据秒钟每个年时,相当数量可用性由于切换可以计算作为在此简单系统的99.99999785百分比可用性。这可能是高在其他环境由于冗余设备数量在切换是可能性的网络的。

  8. 用户错误和进程

    用户错误和进程可用性问题是未利用率的主要原因在企业和运营商网络的。大约未利用率的80百分比发生由于问题例如不检测错误、更改失败和性能问题。

    组织在确定不会要使用四次其他理论上的未利用率可用性预算,证据一致建议这是在许多环境的实际情形。下一部分十分地报道未利用率的此方面。

    因为您不能理论上计算相当数量未利用率由于用户错误和进程,我们推荐您删除从可用性预算删除的这,并且组织力争完美。这一个警告是组织需要了解当前风险对于在他们自己的进程和级别的可用性专业技术。一旦改善请了解这些风险和抗化剂,网络规划者可以希望析因在某个数量未利用率由于这些问题。Cisco NSA HAS程序调查这些问题,并且可帮助组织了解由于的潜在不可用性处理,用户错误或者专业技术问题。

  9. 确定最终可用性预算

    您能通过倍增其中每一个的可用性确定整体可用性预算以前定义区域。这为连接是类似的在任何两个点之间,例如层次化模块化的LAN环境或一分层的标准的WAN环境的同源环境典型地执行。

    在本例中,可用性预算为层次化模块化的LAN环境完成。环境使用备用发电机并且向上所有网络组件的系统和适当地管理电源。组织在软件切换时间不使用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组应该也知道服务标准如何也许被测量。

从上一个服务级别定义步骤的结果将帮助创建标准。这时,网络组织应该有当前风险和限制条件的清楚了解在网络,对应用程序行为的了解和理论上的可用性分析或可用性基线。

  1. 定义服务标准将应用的地理或应用程序方面。

    这可能包括区域例如园区LAN、国内广域网、外联网或者合作伙伴连接。有时,组织在一个区域之内可能有不同的服务级别目标。这为企业或服务提供商组织不是不常见。在这些情况下,创建根据独立服务要求的不同的服务级别标准是不不常见的。这些在一个地理或服务区域之内可能分类作为金,银,铜等级服务标准。

  2. 定义服务标准参数。

    可用性和往返延迟是多数通用网络服务标准。最大吞吐量、最小带宽承诺、抖动、可接受错误率和可扩展性功能可能也包括当必要时。当查看测量方法的时,服务参数小心。参数是否继续前进向SLA,组织应该考虑服务参数如何也许被测量或被辩解,当问题或服务分歧发生时。

在您定义了服务区域和服务参数后,请使用从上一个步骤的信息建立服务标准矩阵。组织也将需要定义可能是混乱的对用户和IT组的区域。例如,最大响应时间为往返ping将是非常不同的比对于点击Enter键在一特定应用程序的一远程位置。下表显示在美国内的性能目标。

网络区域 可用性目标 测量方法 平均的网络响应时间目标 接受的最大值响应时间 响应时间测定方法
LAN 99.99% 压缩的用户时间 在5毫秒以下 10 毫秒 往返ping响应
广域网 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用户或服务器分段重要广域网站点 高商业影响通过损耗或下降,可能的应急方案到位园区LAN下来;5-99个用户影响国内广域网站点下来国际WAN站点下来关键性能影响 若干特定网络功能丢失或降低,例如失去的冗余失效园区LAN性能被影响的LAN冗余 没有组织的商业影响的一个功能查询或故障

当问题严重性定义时,请定义或调查支持流程创建服务响应定义。一般来说,服务响应定义要求分级技术支持结构加上支持中心软件支持支持系统通过故障单跟踪问题。量度应该也取得到准时响应时间和呼叫解决时间每优先级的,编号由优先级和答复/解决方法质量。要定义支持流程,它帮助定义每个支持层目标在组织的和他们的角色和责任。这帮助组织了解资源需求和级别专业技术每个支持级别的。下表提供分级技术支持组织的示例问题解决方法指南。

支持层 责任 目标
第1层支持 全职支持中心支持答案支持呼叫,地方故障单,在问题的工作15分钟,文档票和升级合适第2层支持 解决方法40%呼入呼叫
第2层支持 排队监听,网络管理,站点监听软件识别的问题的地方故障单实现接纳从第1层的呼叫,供应商,并且第3层逐步升级假设呼叫所有权直到解决方法的 解决方法100%在第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个小时 升级对VP,更新对导向器, Operations Manager      
4 小时 对VP的根本原因分析,导向器, Operations Manager,第3层支持,未解决要求CEO通知 升级对VP,更新对导向器, Operations Manager    
24个小时     网络操作操作管理员  
5天       网络操作操作管理员

到目前为止,服务级别定义着重操作支持组织如何反应对问题,在他们识别后。操作组织多年来创建与信息的可操作技术支持规划类似于在上面。然而,什么在这些情况下未命中是组织如何将识别问题,并且哪些问题他们将识别。更加复杂的网络组织尝试通过创建主动地识别问题的百分比的目标解决此问题,与用户问题报告或投诉反应识别的问题相对。

下个表显示组织如何可能希望测量积极的技术支持功能和积极的技术支持所有。

网络区域 预防问题识别率 反应问题识别比率
LAN 80% 20%
广域网 80% 20%

这是一个好开始在定义更多积极的技术支持定义,因为测量是简单和非常容易的,特别是如果预防工具自动地生成故障单。这也帮助重点网络管理工具/关于解决的问题的信息主动地而不是帮助与根本原因。然而,与此方法的主要问题是不定义了积极的技术支持需求。这通常创建在积极的技术支持管理功能的差距并且导致另外的可用性风险。

积极服务级别定义

创建的服务级别定义一更加全面的方法包括关于怎样网络监控,并且操作组织如何的更多详细信息反应对定义的网络根据一个7个x 24个基本类型的管理站(NMS)阈值。这可能似乎类似给的不可能的任务对网络健康是有关的管理信息库(MIB)变量的纯粹数量和相当数量网络管理信息联机。它能也是密集非常昂贵和的资源。不幸地,这些反对防止许多实现应该,天生,是简单,非常容易跟随,和仅可适用对最巨大的可用性或性能风险在网络的主动服务定义。如果组织然后看到在基本主动服务定义的值,更多变量可以随着时间的推移被添加,不用重大影响,只要您实现一被逐步采用的方法。

包括主动服务定义第一范围在所有操作支持计划。服务定义状态操作组主动地如何将识别并且响应对网络或连接在条件下用网络的不同的区域。没有此定义(或管理支持),组织能期待可变支持,不切实际的用户期望和根本地降低网络可用性。

下表显示组织如何也许创建链路/设备down情况的服务定义。示例显示可能有根据网络的每日定时和区域的不同的通知和答复需求的企业。

网络设备或林克下来 Detection Method 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.

错误类别 Detection Method 阈值 执行的操作
软件错误(软件引起的失败) 系统消息每天回顾使用第2层支持完成的系统日志浏览器 优先级的0, 1和2任何出现3级以上100出现 请查看问题,创建故障单和分派,如果新的出现或,如果问题要求注意
硬件错误(硬件引起的失败) 系统消息每天回顾使用第2层支持完成的系统日志浏览器 优先级的0, 1和2任何出现3级以上100出现 请查看问题,创建故障单和分派,如果新的出现或,如果问题要求注意
协议错误(仅IP路由协议) 系统消息每天回顾使用第2层支持完成的系统日志浏览器 每天的十个消息优先级0, 1和2 3级以上100出现 请查看问题,创建故障单和分派,如果新的出现或,如果问题要求注意
媒介控制错误(仅FDDI、POS和快速以太网) 系统消息每天回顾使用第2层支持完成的系统日志浏览器 每天的十个消息优先级0, 1和2 3级以上100出现 请查看问题,创建故障单和分派,如果新的出现或,如果问题要求注意
环境消息(电源和临时) 系统消息每天回顾使用第2层支持完成的系统日志浏览器 任何消息 创建故障单和分派新的问题的
准确性错误(链路输入错误) 在NOC接收的5分钟间隔门限值事件的SNMP轮询 输入或输出错误在任何5分钟间隔的一个错误在任何链路 创建新的问题和分派的故障单对第2层支持

其他主动服务类别级别定义适用于性能和产能。真正的性能和容量管理包括异常管理,基线和趋向和假设分析。服务级别定义定义了性能和产能例外阈值和将开始调查或升级的平均的阈值。这些阈值可能在某个方面然后适用于所有三性能和容量管理进程。

产能和性能服务级别定义可以被分解为几个类别:网络链路、网络设备、端到端性能和应用程序性能。开发服务级别定义在这些区域要求关于设备容量、媒介容量、QoS特性和应用程序需求的特定方面的详细技术知识。为此,我们建议网络设计师实施性能和涉及容量的服务级别定义与供应商输入。

类似网络错误,开发产能和性能的一个服务级别定义从一般了解这些问题情况如何将检测,开始将查看他们,并且发生了什么,当他们发生时。如果需要出现,您能添加特定事件定义到服务级别定义。您可能在以下区域也需要额外的工作保证成功:

  • 应用程序性能需求清楚了解

  • 在有组织的意义的阈值的详细技术调查根据商业需求和总成本

  • 预算周期和out-of-cycle升级需求

  • 第1层,第2层和第3层支持责任

  • 网络管理信息的优先级和重要性平衡了与操作组能有效处理的事前工作量

  • 培训需求保证支持人员了解消息或警报,并且能有效处理定义情况

  • 保证的事件关联方法或的进程多个故障标签没有为同一个根本原因问题生成

  • 在特定帮助与事件标识在第1层支持级别的消息或警报的文档

下表显示提供清楚了解的链路利用率的示例服务级别定义谁对预防性网络错误预警负责,问题如何将识别,并且什么将发生,当问题发生时。组织可能还是需要另外的努力如定义以上保证成功。

网络区域/Media Detection Method 阈值 执行的操作
园区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。

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方面,我们推荐网络设计师和应用程序建筑师技术团队。技术支持严密能近似网络的可用性和功能,并且什么是需要的到达特定目标。

service-provider,因为他们只为了获得在其他服务提供商的一竞争优势创建SLA通常不包括用户输入。有时,上面的管理将创建这些SLA在非常高可用性或高性能级别促销他们的服务和为内部员工提供内部目标。其他服务提供商将集中改善可用性技术方面通过创建被测量并且管理得内部地的强服务级别定义。在某些情况下,两努力发生同时,但是不一定一起或者在同样目标。

选择在SLA涉及的当事人应该根据SLA的目标然后。某些可能的目标是:

  • 符合响应式支持服务业务目标

  • 提供最高水平可用性通过定义积极的SLA

  • 促销或出售服务

步骤 9:确定服务单元

主服务/支持SLA通常将有许多组件,包括级别支持,如何将被测量, SLA调节的升级路径和整体预算注意事项。高可用性环境的服务单元应该包括主动服务定义以及反应目标。其他详细信息包括以下:

  • 现场支持工作时间和步骤工作时间外支持的

  • 优先级定义,包括问题类型,最大时间开始在问题的工作,最大时间解决问题和升级步骤

  • 将支持的产品或服务,分级按照业务的重要性的顺序

  • 为专业技术期望,性能级别期望,状态报告和用户责任支持对问题解决方法

  • 地理或业务部门支持级别问题和需求

  • 问题管理方法和步骤(呼叫跟踪系统)

  • 支持中心目标

  • 网络错误检测和服务答复

  • 网络可用性测量和报告

  • 网络容量和性能测定和报告

  • 冲突解决步骤

  • 资助被实施的SLA

网络应用或服务SLA可能有根据用户组要求和业务的重要性的另外的需要。网络组织必须严密侦听与这些商业需求和提出适合到整体支持结构的专门化解决方案。因为不创建供一些个人或组使用,仅打算的高端服务是重要的适合到整体支持文化是关键。在许多情况下,这些另外的需求可以设置到“解决方案”类别。示例也许是根据商业需要的金,银,铜等级解决方案。参见SLA需求以下示例特定商业需要的。

注意: 支持结构、升级路径、帮助台步骤、测量和优先级定义应该主要依然是维护和改善一致的服务文化的同样。

  • 带宽需求和功能突发流量的

  • 性能要求

  • QoS需求和定义

  • 可用性要求和冗余建立解决方案表

  • 监听和报告要求、方法和步骤

  • 应用程序/服务单元的升级标准

  • 资助out-of-budget需求或交叉填装方法

例如,您能创建WAN站点连接的解决方案类别。白金解决方案将带有双T1服务给站点。不同的载波将提供每条T1线路。站点将有两配置的路由器,以便,如果任何T1或路由器失败站点不会体验中断。金牌服务服务会有两路由器,但是将使用备用帧中继。此解决方案可能有有限带宽处于中断的。银色解决方案只将有一个路由器和一位承载业务。这些解决方案中的任一为问题票的不同的优先级将设想。如果优先级1或2票为中断,要求一些组织可能要求白金或金等级解决方案。他们要求的客户组织能然后资助级别服务。下表根据外部网连通性的商业需要显示提供三个级别服务组织的示例。

解决方案 白金服务 金牌服务 西尔弗
设备 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的一推荐的示例概述:

  1. 协议目的

    • 参加协议的当事人

    • 目标和目标协议的

  2. 支持的服务提供的和产品

    • 帮助台服务和呼叫跟踪

    • 根据MTTR定义的商业影响的问题严重性定义

    • QoS定义的商业关键服务优先级

    • 根据可用性和性能要求的定义解决方案类别

    • 培训需求

    • 容量规划需求

    • 上报需求

    • 报告

    • 提供的网络解决方案

    • 新的解决方案请求

    • 不支持的产品或应用程序

  3. 商业策略

    • 支持在工作时间

    • 工作完毕后支持定义

    • 假日覆盖

    • 联系方式电话号码

    • 工作量预测

    • 委屈解决方法

    • 服务权利标准

    • 用户和组安全责任

  4. 问题管理步骤

    • 呼叫开始(用户和自动化)

    • 第一层的答复和呼叫修复比率

    • 呼叫跟踪和记录保持

    • 呼叫方责任

    • 问题诊断和呼叫关闭需求

    • 网络管理问题检测和服务答复

    • 问题解决方法类别或定义

    • 慢性问题处理

    • 关键问题/例外呼叫处理

  5. 服务质量目标

    • 质量定义

    • 测量定义

    • 质量目标

    • 平均时间由问题优先级启动问题解决方法

    • 由问题优先级的解决问题的平均时间

    • 平均时间由问题优先级更换硬件

    • 网络可用性和性能

    • 管理产能

    • 管理增长

    • 质量报告

  6. 人员配备和预算值

    • 人才配备模型

    • 操作预算

  7. 协议维护

    • 符合复核日程

    • 性能报告和复核

    • 报告量度的调节

    • 定期SLA更新

  8. 批准

  9. 附件和展览

    • 呼叫流程图

    • 上报程序表

    • 网络解决方案矩阵

    • 报告示例

步骤 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获得许多用户投诉网络频繁地是下来在延长时间。通过测量可用性,公司查找主要问题是一些个广域网站点。那些视域更加周密的调查表示大多问题在一些个广域网站点。找到根本原因,并且组织解决了问题。组织然后设置可用性的服务级别目标并且签署了协议以用户组。快速将来评定识别的问题由于非一致对SLA。网络组然后查看了作为有更高的职业化、专业技术和一个整体资产对组织。组从反应有效移动向积极本质上并且帮助公司的最后一行。

不幸地,多数网络组织今天没有有限服务级别定义和指示器。结果,他们花费起反应对用户投诉或问题的大多数他们的时间而不是主动地识别根本原因和提供符合商业需求的网络服务。

请使用以下SLA指示器确定服务级别管理进程的成功:

  • 包括可用性、性能、响应式服务响应时间、问题解决目标和问题上报的描述的服务级别定义或SLA

  • 性能指示器度量,包括可用性、性能、响应时间由优先级,时刻由优先级解决和其他可测量的SLA参数

  • 查看服务级别标准和实现改进的每月网络服务供货水平管理会议

描述的服务级别协议或服务级别定义

第一台指示器是选派的文档SLA或服务级别定义。因为这些是主要用户要求,服务级别定义的主要目标应该是可用性和性能。

辅目标是重要,因为他们帮助定义可用性或性能级别如何将被达到。例如,如果组织有积极的可用性和性能目标,防止问题发生和迅速解决问题将是重要的,当他们发生。辅目标帮助定义必要的进程达到希望的可用性和性能级别。

反映的次要目标包括:

  • 由呼叫优先级的响应式服务响应时间

  • 问题解决目标或MTTR

  • 问题上报程序。

积极的次要目标包括:

  • 设备down或链路down检测

  • 网络错误检测

  • 产能或性能问题检测。

主要目标、可用性和性能的服务级别定义应该包括:

目标

  • 目标如何将被测量

  • 当事人负责对测量可用性和性能

  • 当事人负责对可用性和性能目标

  • 不符合的流程

若可能,我们建议当事人负责对测量和当事人负责对结果是不同的防止利益冲突。时常,您可能也需要校准可用性数值由于添加/移动/更改错误的它,未被发现的错误或者可用性评定问题。服务级别定义可能也包括正在修改的结果的一进程能帮助改进准确性和防止不正确的调整。请参阅下一部分关于方法学测量可用性和性能。

反映的次要目标的服务级别定义定义了组织如何将响应对网络或IT范围问题,在他们识别后,包括:

  • 问题优先级定义

  • 由呼叫优先级的响应式服务响应时间

  • 问题解决目标或者MTTR

  • 问题上报程序

一般来说,这些目标定义了谁对问题将负责所有给定时间,并且那些负责在何种程度上应该下降他们的当前任务研究定义问题。类似其他服务级别定义,服务级别文档应该选派目标如何将被测量,当事人负责对测量和不符合的流程。

积极的次要目标的服务定义定义了组织如何提供积极的技术支持,包括网络下来,链路down或设备down情况、网络错误错误状态和网络容量阈值的识别。设置提升主动管理的目标,因为质量主动管理帮助消除问题,并且帮助解决更加快速的问题。这通过设置多少自发事件目标通常完成创建并且被解决,不用用户通知。许多组织在支持中心软件方面设置一标志为此识别自发事件与反作用情形。服务级别文档应该也包含关于目标如何的信息将被测量,当事人负责对测量和不符合的流程。

性能指示器度量

我们总是建议所有定义的服务级别目标是可测量的,允许组织测量服务级别,识别禁止可用性和性能主要目标的问题根源服务问题和做是瞄准的特定目标的改进。总之,量度是允许网络管理器管理服务级别一致性和根据商业需求做改进的工具。

不幸地,许多组织不收集可用性、性能和其他量度。组织归因于此无法提供完整准确性、费用、网络开销和可用资源。这些要素能影响能力测量服务级别,但是组织应该着重整体目标管理和提高服务级别。许多组织能创建不也许提供完整准确性的便宜,低开销量度,但是满足这些主要目标。

测量可用性和性能是在服务级别量度经常忽略的一个区域。是成功的与这些量度的组织使用两个十分简单的方法。一个方法将发送从一个核心位置的互联网控制消息协议(ICMP) ping信息包网络的对边缘。使用此方法,您能也得到性能。也是成功的与此方法的组织分组好象设备到“可用性组”,例如LAN设备或国内现场办事处。因为组织通常有网络的不同的地理或商业危急区域的,不同的服务级别目标这也是有吸引力的。这准许量度组平均为所有设备以可用性组得到一种合理的结果。

计算可用性另一个成功的方法将使用故障单和呼叫的测量压缩的用户时间(IUM)。此方法制成表是受中断的影响的用户的数量并且乘它以中断的纪录数量。当表示为在时间的百分比总分钟,这可以容易地转换到可用性。无论如何,识别和测量停工期的根本原因可以也是有用的,以便改进可以更加容易地被瞄准。问题根源类别包括硬件故障、软件问题、链路或载波问题、电源或者环境问题、更改失败和用户错误。

可测量的响应式支持服务目标包括:

  • 由呼叫优先级的响应式服务响应时间

  • 问题解决目标或者MTTR

  • 问题上报时间

测量响应式支持服务目标通过生成从支持中心数据库的报告,包括以下字段:

  • 呼叫最初报告的时间(或加入到数据库)

  • 呼叫通过一单个工作接受在问题的时间

  • 问题升级的时间

  • 问题关闭的时间

这些量度可能要求管理影响一致输入在数据库和更新问题的问题在实时。有时,组织能自动地生成网元或电子邮件请求的故障单。这帮助为识别问题的开始时间提供准确性。从这种生成的报告量度将由优先级、工作组和个人通常排序问题帮助确定潜在问题。

因为要求您监控积极工作和计算其效果的某测量,测量积极的技术支持进程是更加困难。一点工作是完成在此区域。是确切,然而,人的仅小百分比实际上网络问题向支持中心报告,并且,当他们报告问题,将清楚地需要时间解释问题或隔离问题作为网络有关。不是所有的自发事件在可用性将有一立即效果,并且性能由于冗余设备或链路的失败对最终用户有很少的影响。

实现积极服务级别定义或协定的组织如此执行由于商业需求和潜在的可用性风险。测量然后执行根据自发事件的数量或百分比,与由用户生成的反作用情形相对。它是一个好想法测量相当数量在各个领域的自发事件。这些类别将包括在设备下,下来链路、网络错误和产能侵害。若干工作可能也被完成使用可用性建模和自发事件确定在实现完成的可用性的效果主动服务定义。

服务级别管理审查

服务级别管理成功另一次测量是服务级别管理审查。应该执行这SLA是否到位。执行服务级别管理审查在月会与个人负责对测量和提供定义的服务水平。当SLA是包含的时,用户组可能也存在。会议的目的将然后查看可测量的服务级别定义的性能和做改进。

每个会议应该有包括的一张定义日程表:

  • 可测量的服务级别回顾给的期限的

  • 为各自的区域定义的改进计划回顾

  • 当前服务级别量度

  • 什么改进讨论根据当前是需要的设置量度。

随着时间的推移,组织可能也趋向服务级别标准确定组的效果。此进程不是不同于质量范围或质量改进进程。会议帮助瞄准各自的问题并且确定根据根本原因的解决方案。

服务级别管理汇总

总之,服务级别管理允许组织从响应式支持服务型号移动向网络可用性和性能级别商业需求取决于的积极的技术支持型号,不由最新的套问题。进程帮助创建持续服务供货水平改进和增加的企业竞争性的环境。服务级别管理也是预防性网络管理的最重要的管理组件。为此,服务级别管理是高度推荐的在所有网络规划和设计阶段,并且应该从定义的网络体系结构其中任一最近开始。这允许组织正确地实现解决方案第一次,与最少量的停机时间或重做。

相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


相关信息


Document ID: 15117