通过SLA 改善网络应用性能

摘要

　　成功的服务水平管理（SLM）需要一种前瞻性的手段，但是现今大多数的管理工具主要工作在激励响应的模式。在这篇文档里，我们描述了通过合适的工具，让您的团队从像消防员一样去解决网络故障，转变成高级网络规划人士。

　　做为把IT 资源与商业目标结盟的一个方法，SLM 正受到普遍的关注。服务水平管理（SLM）帮助您控制服务水平（始终如一的满足客户的需要），持续的改善运营效率。它提供了一种方法来衡量IT 收益率，这比衡量IT 总资产要好。

　　本白皮书讨论了实施一个成功的SLM 需要考虑的事情和决定，详细设计了如何用服务水平目标（SLO）来定义服务水平认证（SLA），完成商业目标。本白皮书展现了SLA 的常见的陷阱以及如何避免他们；探究选择和衡量SLO 的细节；采用已有的工具前瞻性的工作。

　　合适的SLO 选择是SLA 成功的关键。本白皮书描述了如何选择测量参数进行测试，判定重点是在客户，服务器或者网络。它解释了选择统计值，平均值或者百分比对管理策略的实际影响，以及如何选择确定一致性的标准。同时对不同商业解决方案进行评估，突出不同方案的长处、短处和潜在的商业影响。

　　通过服务水平管理（SLM）基线，认识到如何在您的企业成功执行正确的SLA。

介绍

　　传统的服务水平管理（SLM）基本只是单独依靠有效性进行监测。服务（网络、服务器或者应用）必须99.999%的时间“UP”。这个度量标准容易理解，看起来好像为最终用户提供了真正的价值。然而，该度量标准不能满足关键的SLM 目标、客户的需求、并进行持续的改进。它不能满足客户的需求，因为服务在“UP”状态的同时，很可能只有很低的、几乎不能使用的性能。它不能推动持续地改进运营效率；更确切地说，它更多地关注于很少发生的事件。

　　为了功效最大化，SLM 除了可用性之外，必须牢固地扎根于性能。它必须把最终用户的体验搁在心上，而不仅仅是架构的状态。而且，它必须这么做。幸运的是，SLM 工具最终朝着能够满足这些需求的方向发展。今天的SLM 工具将积极地鼓励网络管理从被动方式转变为前瞻性方式，通过提供4 个关键关键领域的功能：多级报告，早期检测，快速定位，以及机会发现。除了这些之外，它必须是方便配置，方便管理，方便使用的架构。

　　SLM 为了高效必须仔细定义服务水平目标（SLO）。有3 个关键变量应该被测量：最终用户响应时间，服务器响应时间，和网络时延。但是如何测量这3 个变量，主动的还是被动的，是成功了还是没有达到期望的结果。SLO 可以基于时间平均数，时间平均数百分比，或者基于事件百分比。很多市场上的工具，采用时间平均为基础的SLO 进行跟踪，然而，这种方法有一个缺陷，对个人用户来说，大多数用户的平均值，可能并不必要。基于事件百分比跟踪方式的SLO，技术门槛较高，它精确地捕捉了用户的体验。然而，现在运行的、穿过一个企业网的解决方案，很少可以有效地实现这个方法。

　　SLO 门限的配置，应该根据用户的需求来定。这些需求根据应用和网络接入方式而变化。通常，2 个门限应该被指定。第一门限，应该是反映用户感到不满意的位置。第二门限，应该是系统性能较差，导致的重大的商业损失的位置。如果SLO支持百分比门限，应该随着时间调整他们，从而连续地改善运营、控制时延变化。

通过SLM 前瞻性管理

　　要达到SLM 目标必须改变惯性思维。大多数IT 团队现在都运行在一种被动模式。他们大多数的时间都用在进行危机处理，尽力去抑制和解决故障。通过SLM 管理IT 资源，IT 部门可以预见问题、快速地解决，让IT 团队从被动做出反映，转变为主动的、前瞻的团队。这个行为模式上的变化，无疑需要部门培训，但是，合适的工具可以提供一个临界的跳跃，来帮助人们用一种新的观点评估网络性能。

　　SLM 工具不只是监测和分析的手段。它确保了必要资源的提供，与商业用户的需求结合起来。SLM 工具的第一需求是保证策略行动的自由时间。一些工具部署、管理是如此的麻烦，使用他们并不能重大的节约IT 团队的时间。SLM 工具的选择必须是容易使用和着眼于真正有效的功能。

　　SLM 工具的易用性代表了该工具被部署管理和使用的成功程度。这是由SLM 的架构、将要部署该工具的环境细节决定的。一个在全球性企业管理起来很麻烦的工具，可能对一个稍小的企业就很合适。一个对mesh 网络的离谱的工具，可能对一个hub-and-spoke 环境是合理的价格。一个需要在不同的IT 团队 (举例来说，管理桌面支持的或者广域网应用的团队) 之间不断协调的工具，可能是一个强烈压力来源，也可能是一个机会⋯⋯，但是它经常是压力和无效率的来源。

　　一个SLM 工具必须鼓励从被动性管理转变到前瞻性管理。达到这一点通过提供4 个关键领域的功能：多等级报告，早期检测，快速定位，机会发现。这些领域将在这篇文档的后面讨论。

价值变量

　　部署一个SLA 最初的决定之一包括选择变量。SLA 将采用什么变量做测量参数？最终用户的期望和IT 团队所能提供的指标经常是一个冲突。最终用户需要有直观意义的测量参数，典型的就是最终用户响应时间。IT 团队需要一个他们能够管理的测量参数（举例来说，如果他们不控制服务器簇，他们不愿意测量服务器问题）。一个好的折衷是多选一些参数，就不会选错了；检测有共同理解的参数，就减少了出错的责任。

最终用户性能

　　不管现有的SLA 是否测试最终用户应用的响应时间，都应该测试该参数。这个变量表明最终用户真正的感觉，推动IT团队和最终用户之间的交流。表达最终用户体验最常用的方法是通过测量处理事务次数及其组成成分。

　　测量最终用户体验最终的决定是测量什么事务和如何测量他们。应该测量每一种不同的事务处理还是仅仅选择一些？以前的模型要求可量测性的集成，结果是有点丢失了可视性。后来是选择很少的通用的、代表性的、重要的事务。2 种方法的结合通常可以产生满意的结果。换句话说，2 种方法的需求并不是排斥的。

　　实际用户应该进行被动监测，还是采用综合性的探针主动监测？以前要求绝对达到SLM 目标。后来要求提供对故障解决非常有用的确定基线。最好的途径是结合被动监测和少量综合探针；采用这个方式，2 种途径的好处都可以有效地实现。

服务器性能

　　SLA 服务器响应时间无论如何也应该被监测。服务器响应时间对快速定位是否因为服务器的原因引起了最终用户响应时间恶化非常有用。这个度量标准也可以用来跟踪数据中心的服务水平质量（QOS）。服务器响应时间也是网络优化和规划的基础。

　　一些重要的问题与如何测量服务器响应时间有关。如果综合探针被重复性的用来处理同样的事务，就可能在客户端或者服务器端缓存结果。缓存的作用影响了测试结果，它没有代表实际的用户体验。如果服务器缓存信息，它还不能选择清除。如果事务处理是随机的，那么综合探针就不可避免的失去了作用。缓存的影响，致使终合探针给服务器响应时间的测量带来误差。针对所有事务和所有系统用户，被动的监测服务器性能，能够消除这个问题，并且还能在监测一段时间以后，提供一个有用的性能基线。

网络性能

　　网络时延是另一个必须监测的SLA 衡量标准。与服务器性能相同，网络性能对快速判定是否因为网络问题导致最终用户响应时间恶化，是非常有用的。网络性能度量标准－比如环回时间（RTT）－可以用来衡量从网络服务提供商获得的服务水平。对网络时延连续性的监测，对网络优化和规划也是非常基本的。

　　有几种通用的方法测量网络时延。主动的方法包括执行ICMP ping 或者TCP session 连接。被动的方法包括测量TCPsession 连接或者更多终合的应用数据包。每一种方法，网络时延测量基于观察终合的应用数据包，提供最精确的性能表现。理解网络时延的组成是非常重要的，对识别每一种方法的优点和缺陷非常重要。网络延时包含5 个组成：传输、排队、传播、处理和协议时延，如下所述。

　　字节封包传送或者传输时延是把所有比特打成包在传输媒介之上的时间要求。它是依赖于包尺寸和链路接入速率。一个64 字节的包在56Kbps 链路上有18.3 毫秒的环回时延。256Kbps 链路有4 毫秒，1.5Mbps 链路有7 毫秒。一个1500 字节的包相应的分别有428.6 毫秒，93.8 毫秒，16 毫秒的连载长篇的时延。TCP session 连接主要是64 字节包。结果导致，测试其他的应用时延的时候，基于TCP session 测量经验，将通常低估网络时延。ICMP ping 可以配置为各种尺寸的包，但是包尺寸在来回2 个方向是相同的。我们依靠经验从用ICMP 精确捕获的传输时延，大多数的应用并没有这种对称性。注意，默认的ICMP 包尺寸也是64 字节。

　　排队延迟是在包在缓存里等待自己的发送开始所要花费的时间。它依赖于包先前用到的包传输时延，缓存大小，拥塞程度，和路由器、交换机的排队机制的配置。拥塞能够以毫秒级别变化，而一个TCP session 可以按秒、小时、甚至按天保持。因而，依靠TCP session 连接的排队时延明显的不同于主要应用。同样的是任何预定的探针例如ICMP，排队时延与应用的经验有很少的类同之处，甚至早60 秒。另外，路由器或者交换机可以把ICMP 包放进优先级（不是好一些就是差一些）队列处理。在拥塞时期，在应用包等待时，ICMP 包首先被丢弃－因此，时延更长的话ICMP 就测不到了。ICMP 包可以优先的移至队列头，从而经历了短的时延；ICMP 也可以选择性的移至队列的后面，从而经历了长的时延（如果不被丢弃的话）。

　　传播或者距离时延是沿着顺着物理路径传输所花的时间。它仅仅依靠距离和媒体类型。如果TCP session 连接和ICMP包做为主要的应用通过同样的物理路径传送，那么传播时延是一样的。然而，它并不保证同样的传送路径。

　　处理时延是路由器或者交换机准备传递包所花的时延。它依赖于很多因素，但通常是无关紧要的。注意TCP session连接可能比流里面其他的包需要更多的处理，ICMP 需要更少的处理。

　　协议时延是基于协议基础的包等待时间。举例来说，在一个共享媒体，包必须等待它的轮训才可获得接入。这类时延影响根据协议的不同，变化很大。

　　总的来说，用ICMP ping 包测量网络时延只是展现了对网络的简单印象。基于TCP session 连接的网络时延测量，仅仅展现了64 字节大小的包在会话建立的时候（秒，小时，甚至几天前）经历的延迟。采用被动的观察通常的应用包的方法，是最有效的测量网络时延的手段，它放映了用户实际的感觉。

服务可用性

　　做为SLM 策略的一部分，服务可用性应该明确地被监测。传统的方法进行故障管理要求网络跟踪、测试服务器设备可用性。这能够通过激活代理软件，或者用探针周期性的测试所选事务实现。如果探针按15 分钟周期运行，从开始以后，能够检测到一个持续的大概7.5 分钟的运转中断。然而，间歇性的简短中断将不能被检测，也不能根据SLO 跟踪。更频繁的检测应该可以检测到更短的运转中断，但是会给系统带来负载开销的增加。

难以捉摸的统计

　　无论是否意识到，当执行SLM 的时候，下一个重要的决定是统计。SLA 应该基于时间平均还是事务百分比？一个基于时间平均的SLA 应该要求，举例来说，平均最终用户响应时间应该小于3 秒。一个基于百分比的SLA 也应该要求，举例来说，95％的事务处理时间应该小于3 秒。

　　选择基于时间平均的SLA 的优点是几乎每个SLM 厂家都支持，在工具选择的时候有很大的自由度。不幸的是，时间平均不提供用户正在感受到的体验。举例来说，假设有9 个用户每人观测到有0.5 秒的响应时间，而第10 个用户收到90 秒的响应时间。那么平均响应时间的报告是9.5 秒－这与任何一个用户的实际感受都有很大的不同。因为这种不对称的敏感性，是非常难以达到平均的。如果第10 个用户收到一个180 秒的响应时间（超过90 秒）而其他用户还是保持0.5 秒，平均值接近是刚才的2 倍－虽然只有1 个用户感到性能恶化。

　　一些厂家报告了一种能够减少这种不对称敏感性的均衡的平均值；他们丢弃了超过预设门限的测量结果。在前面的例子，针对0.5 秒的均衡平均值，预设门限将会是2 秒。这种方法的危险是很可能掩饰了非常真实的网络问题。如果问题继续发展，有7 个用户的响应时间变成了2.5 秒，而报告的均衡平均值将会仍然是0.5 秒－即使80％的用户因为性能恶化已经感到难受了。在现有大多数环境的状态都不相同的情况下，选择一个合适的门限几乎是不可能的。确实发生的是，因为这种均衡，性能最差的站点曾经被报告为性能最好的站点。

　　基于事件百分比的SLA 可能不会受到这种不对称性影响，可以直接与客户体验相关。如果95％的事务的响应时间小于3秒，剩下5％的响应时间值就不具有重大的意义。基于均衡平均值的SLA 忽略了所有超过预设门限的响应时间。如果所有的响应时间都超过了门限，那就没有度量值了。基于事件百分比的SLA 忽略了预设门限（本例中的5％）的响应时间。

　　基于事件百分比的SLA 更优于基于时间平均的SLA；然而，SLM 厂家的选择就更受限制了。事件百分比相对平均值，在监测技术上更具挑战性。因此很少有厂家支持这个选项。一些厂家选择了一个混合的方案报告平均百分比（好过比事件百分比简单）。举例来说，基于这种混合方式的SLA 将会要求，如果月平均值为5 分钟，那么95％的响应时间必须少于5 秒。总之，SLA 可以基于时间平均，基于时间平均百分比，或者基于事件百分比。基于时间平均的SLA 伴随有不对称问题；结果是可能不能体现客户的真正体验。基于事件百分比的SLA 更高级一些，但是没有广泛的执行。

定义细节

　　另一个重要的决定是确定实际目标。每一个变量有多少目标？用什么期限来确定一致性？什么门限和百分比是合适的？这些细节定义应该牢固基于用户期望来精确测量用户体验。

　　有2 个有趣的门限；微小的和痛苦的。小于“微小的门限”的时延不能引起用户注意。时延很小，属于用户的期望范围内的，不需要去暗示，他们不会产生任何烦恼。超过“痛苦门限”的时延导致用户放弃。这种时延在丢失商业机会或者员工生产力方面是非常昂贵的。在2 个门限之间的时延，典型地是应用不畅。

　　这2 个门限并不知名，但是通过实验（依靠合作的或者不知情的用户，依据某种策略）可以发现。一些通用的值经常被引用，浏览页面的2 个门限值是3 秒和8 秒。然而，门限经常依赖网络接入方式和自身的应用。举例来说，用户通过卫星接入娱乐网站入口相对通过陆地E3 电路接入技术热线，能够容许有更大的时延。针对每一种应用和接入组，将会定义一个分离的SLA。

　　门限应该基于用户需求定义。如果SLA 支持百分比，百分比应该随着运营质量改善而调整。用户倾向于对时延变化更敏感，而不是孤立的值。增长的百分比有效地控制了延迟变化。做为一个例子，假定SLA 开始规定95％事件响应时间必须小于3 秒而且98％必须小于8 秒。目标应该是把百分比增加到，比方说，经过一段时间调整，分别增加到96％和99％。降低3 秒的门限对业务可能没有什么影响，既然3 秒已经是一个可以接受的值。

　　针对特别用户，门限维护操作窗口可能对SLA 特别合适。门限应该是在定义阶段就确定好，好过SLA 不可达后再定义。注意，现在很少有厂家支持该特征。如果所选的厂家不支持，那么定义的百分比应该按补偿性方式向下调整。

　　总而言之，SLA 中使用的门限应该基于用户的需求。这些需求根据应用和网络接入方式的不同而不同。总的来说，2 个门限应该被详细说明的。低于最低门限低的时延对用户没有影响；高于最高门限的时延会有明显的业务开销。如果SLA 支持百分比，应该在时间上通过调整百分比，来推动运营的连续改善和控制时延变化。

选择合适的SLM 解决方案

　　向前面提到的，SLM 必须积极的鼓励从被动管理到前摄管理的转变。自动化SLM 解决方案必须提供4 个领域的功能：多级报告，早期检测，快速决定，和机会发现。这些领域在下面的章节将会详细讨论。

多级报告

　　一些厂家宣称他们的工具支持SLM，确把解释和实现留给用户。当然，对数据包的捕获支持SLM，但在有限的时间并不是总实用的。如果仅仅提供高层“管理”,但是没有提供采取合适行动的必须细节，没有一个工具是实用的。SLM 工具应该提供从高层状态到技术水平细节的方便导航，越方便越好。简短的说，应该提供多级报告。高级别总结信息，对没有技术背景的用户最重要，同时，瞄准于快速达到相关技术细节的导航也很重要。

最高级SLA 报告

　　最高级的SLA 报告（见图1）为商业用户提供了一个不同的SLA 一致性的概览。如果要求更多的细节，点击任何应用的名字，进入一个说明该应用的更详细的一致性界面。


图1、最高级SLA 报告

　　图2 展示了peoplesoft 应用的一致性测量标准。这个SLA 要求95％的peoplesoft 事件响应时间小于2 秒(标准1)，99％的响应时间小于4 秒（标准2）。Peoplesoft 服务与SLA 一致，因为99％的事件小于4 秒，99.8%的事件小于2 秒。


图2、最高级SLA 报告——PeopleSoft

　　图3 表示了更适合IT 管理或者技术用户的一致性视图。该视图提供报告和违背计数，也提供更多的修改选项来改变报告包含的信息。最高级的报告提供非常有用的故障点定位和违背，但是不提供足够的信息来指导任何矫正行为。


图3、最高级SLA 报告——所有应用

中级SLA 报告

　　中级SLA 报告提供不同时间的、空间的、逻辑的SLA 一致性总结视图。举例来说，图4 展示基于时间的SLA 一致性，周期性地展示需要更深入地研究的故障间隔时间。


图4、中级SLA 报告——根据时间的订单管理系统

　　能选择用户区的视图应该也被提供，判定不适当数量的违背，是一个单独的服务器或者特别的组用户所引起的。举例来说，如果SLA 违背是一部分客户站点引起的，在图5 中的客户区将会很明显。这些视图IT 团队理解如何把应用联系到一致性的基本帮助。


图5、中级SLA 报告——根据网络子网/用户组

低级报告

　　低级报告对快速解决出现的性能问题是很基本的，同时也帮助IT 资源的有效分配。他们提供理解错误范围和原因所要求的必要的细节，让IT 员工采取相关行动。这些低级报告包括自动调查的结果（图6），同时包括性能图表信息和统计（图7）。


图6、低级调查报告


图7、低级响应时间部件

智能基线报告

　　除了根据一个静态的SLA 门限跟踪性能，理解现在的性能与过去的性能的比较也是非常重要的。用户的期望是根据他们以前的应用－你可能很好的在你SLA 范围里面，但是仍然让客户感到不舒服，因为响应时间比他们以前的慢了。该类型的报告能够产生，提供一条计算过的应用性能的基线。这条基线应该重视最近和历史系统性能。图8 展示了一张高级视图，每一种应用性能与其历史基线的对比。图9 展示了一张中级视图，citrix 过去8 小时的应用性能与以前性能的对比。


图8、高级智能基线报告


图9、中级智能基线报告

早期检测

　　每个人都很熟悉在企业网里发现问题和危险的最普遍方法：电话响了或者收到紧急的邮件。大多数IT 团队没有时间专注于每一次单独跑进他们办公室的的不满。除非问题发现的早，团队可以花更多的时间解决问题，否则没有时间去满足商业客户的长期需求。

　　SLM 工具必须有自动发现问题酿成大错前初期征兆的能力。这种自动查找机制，能够把报告区分优先级，是前瞻操作的临界应用。当早期的工具依靠预先配置的静态门限检测问题的时候，新一代的工具采用自学习机制。新的工具在对日常的每天、每周、每月周期性捕捉的同时，学习应用、服务器和客户区“典型的“行为。他们知道一个月里最后一个星期五通常比其他时间慢；他们不会产生一个报警，除非相对学习到的这个时间的标准，性能很差。

　　智能化基线自动发现发展中的问题，在潜在问题被用户感知之前给IT 团队发出警告。这种早期发现机制减少了平均修复时间(MTTR),提高生产力，增强团队的声誉。新的工具可以穿过企业查找异常、低效率、和其他要改善的地方。他们提供对收到数据的24X7 的性能监测和分析。

图10 提供了一个交替的最高级性能视图－在过去2 个星期检测到的临界性能事件详图。


图10、高级事件报告

　　识别可用性和性能问题一样都是很基本的。积极监测对这个功能是特别有用的，但是他们有几个缺陷。按照标准的执行方式，积极监测周期性地测试可用性（和性能）。他们被计划每5 分钟、或者15 分钟、或者30 分钟运行一次。如果探针被计划每15 分钟运行一次，出现断线要平均7.5 分钟后才检测到(但也可能是15 分钟后才检测到)。轮询时间越短，探针能够越快的检测问题－但是时间缩短给网络和服务器增加了更大的压力。因为这个压力原因，积极检测只能从选择的区域选择事务测试。这种被迫的选择很普遍，以至于探针不能检测到他们希望检测到的情况。

　　一个更好的方法是把触发式的主动调查与被动性监测结合起来。仅仅在监测到没有流量的不正常情况，网络或者服务器才会激活探针－在那个时候，压力很小，只要不是真正的断线了。使用这种方法，网络中断能够很快检测到，而不需要给网络或者服务器增加压力。

　　不管实际执行情况怎么样，早期检测和可用性问题都是SLM 的基本组成部分。

快速定位

　　SLM 工具的选择不能仅仅局限于检测发现问题，也必须辅助问题的快速定位。多级报告当然很好的推动了这一点，特别是把“点击即可浏览详细信息”的导航接口集成进来的时候。以表格为基础的客户报告非常的灵活，但是他们提供痛苦和麻烦的接口。支持概览好过支持麻烦的表格。

　　自动调查能够明显的节约时间，而且需要很少的人工配置。当一个开发服务器检测到有问题的时候，增加的信息例如CPU 利用率、存储器使用、顶级进程都结合在一块了－在那时候，问题出现了。当一个开发网络确定有问题的时候，应该执行路由跟踪或者收集附加的MIB 统计。这种触发式的调查能够节省很多诊断资料的收集。

连续性改进

　　SLM 的一个主要目标是连续性改进。早期检测和快速定位问题确实改进了运营效率。然而这些行为实际上仍然是被动的。服务一定要不可接受（接近SLA 门限）或者开始恶化（被智能基线检测到）才会触发行动。如果服务在一个很稳定确效率低下的状态，就不会被注意到。SLM 工具应该提供一种机制快速发现这种低率，而且确定改进机会。

　　这种特征的一个例子，在图11－15 的报告显示。这些性能图提供了更高水平的视图，这些视图对改善性能是非常有用的。这些图选择一系列选项，包括应用、客户区域、服务器、感兴趣的测量标准、排序次序、和时间范围。

　　接下来的3 个段落提供了如何有效地应用这些性能图表的例子。“应用无效和机会”展示了性能图表在一个多级应用里能够如何展示交互作用。“网络无效和机会”展示了性能图表如何提供企业时延组成图表，流量矩阵，方便用户做容量规划、问题的优先级别划分。“服务器无效和机会”描叙了性能图表如何能够识别问题服务器和无效的负载均衡。

应用无效和机会

　　图11“根据应用的处理时间”描述了一个多级部署的、全球性的ERP（企业资源计划）应用性能图表。Superagent 监测该应用的每一级：web 图形用户界面（ERP 系统）、用户认证（LDAP 目录）、文档交换（netbios/TCP）、和后台数据库(oracle9i DB)。通常，图形用户界面有最大的平均处理时间（1.51 秒），而后台数据库有最小的平均处理时间（0.04 秒）；用户认证有0.53 秒的时延。这个性能图表提供了每一种应用等级的快速概览，和它们之间是否是否有相互影响。如果图形用户界面和数据库时延都很高的话，那么好像一个应用受到了另一个应用的影响。在这个案例里，用户应该点击一个应用名，深入到低一级的详细报告，查看2 个应用之间的相关性，定位问题来源。


图11、中级应用事物处理时间

网络无效和时机

　　性能图表能用来产生网络时延和丢包图表。图12 展示了“客户区网络环回时延（RTT）”，给出了通过穿过完整企业网的网络性能快速概览。所有站点都被包括了，并且根据描叙做了排列，用来提供网络热点的视觉辨认。举例来说，VPN 用户有相比其他人差的性能，而所有在企业总部的用户享受着快速的性能。


图12、网络回时延图——查找关键处

　　图13 的“客户区字节丢失百分比”性能图表展示了丢包百分比最多的15 个用户区（通过图表排列比通过描述或者地址好的多）。高丢失率可能是错误或者冲突引起的；在其他案例，它表明了明显的失效和改进的时机。因为网络的状况，在匹兹堡和El Paso 的用户的生产力受到严重的限制。


图13、网络损耗图——最差站点

服务器无效和时机

　　通过服务器簇成员的对比，性能图表能用来确定问题服务器。图14 的“服务器拒绝会话”性能图表展示了ERP 服务器1 过载或者故障。图15 的“服务器响应时间”性能图表用图说明了WEB 服务器簇在提供不同的服务水平，最快的服务器提供的响应时间比最慢的快7 倍。这可能是旧的系统需要升级或者是负载均衡的问题。性能图表能够通过对比激活会话数目，流量大小，响应次数来评估负载均衡的效率。不同的工具采用不同的负载均衡标准。性能图表通过提供系统之间的流量矩阵表，对内部服务器簇优化也有帮助。


图14、服务器无响应——被决绝的会话


图14、服务器无响应——负载平衡

结论

　　服务水平管理（SLM）帮助您控制服务水平（始终如一的满足客户的需要），持续的改善运营效率。既然IT 客户是最终用户，而且IT 部门的工作推动这些用户操作业务，SLM 应该着眼于做为一种确保IT 与商业成功结盟的方法。

　　在采用一个SLM 计划的时候，有2 个成功的条件；必须仔细定义技术目标和团队必须学习运行的策略。当定义技术目标的时候，监测的服务，测量的度量参数，测量的方法，部署SLA 可用的工具，必须被重视。SLM 工具的选择应当鼓励前瞻性的管理，通过提供4 个关键领域的功能：多级的报告，早期检测，快速决定，机会发现。把团队工作从救火模式转变成战略规划模式，为了成功地执行该技术目标，要求把SLM 集成到日常工作。

　　采用SLM 让IT 专业人员能够连续地改善他们提供的服务。通过分析过去的性能和一致性，IT 人员可以确定并改善那些将会对服务水平有最大的影响的区域。IT 资源和业务性能主动结盟的的结果，能给任何企业带来高附加值的益处。
作者：美国福禄克网络公司   来源：C114(CHINA通信网)