服务水平管理和服务水平协议SLA.doc

资源描述

服务水平管理和服务水平协议（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工作组还应了解如何测量业务标准。以前服务水平定义环节的结果可以帮助制定标准。这时，网络公司应明确了解当前网络所面临的风险和限制因素及应用行为，并进行理论上的可用性分析或制定可用性基准。 · 定义业务标准合用的地理区域或应用领域，也许涉及园区LAN、本国WAN、外联网及合作伙伴连接等。在某些情况下，公司在相同区域内的服务水平目的也许有所不同。这对公司或服务器供应商来说并不罕见。这时，它们通常基于各自的业务规定制定不同的服务水平标准。这些在同一地理区域或服务区域中的标准有金牌、银牌和铜牌之分。 · 定义业务标准参数。可用性及往返延迟是最常见的网络业务标准。根据需要，还可以涉及最大吞吐量、最低带宽承诺、抖动、接受的错误率以及可扩展性功能。当审核用于测量方法的业务参数时要特别谨慎。无论参数是否涉及在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特性及应用规定的特定领域相关的渊博技术知识。出于这个因素，我们建议网络设计师通过供应商输入的信息制定与性能和容量相关的服务水

展开阅读全文