Fluke 面试（共5篇）由网友“阿西莫耶”投稿提供，今天小编在这给大家整理过的Fluke 面试，我们一起来阅读吧!
篇1：Fluke 面试
Fluke 面试
Fluke是仪器仪表的领头羊，办公在火车站对面的嘉里不夜城，楼还不错，
是一个瘦瘦的上海man面的我，进来的时候好像很干练，虽然在他来之前我在这个小会议室等了20分钟，空调很足有点冷。
他递的名片是全国总监，开始他以为我还在上一家公司，当得知我已离开时，可以很明显感觉到的一惊，随着他的语气和语调就有了微妙的变化，态度也不对了。
他和我大侃经销商、代理商、分销商的区别，好歹我也是做渠道管理的`，对此也有着自己的看法，但是可以分明感受他的咄咄逼人的气势，我不是很喜欢，最后敷衍奉承了他两句，其实我也很敏感，刚才他的一惊后的变化已经可以看出结果了，
握手离开。
印象：
1、这个销售总监是一个经验很丰富的老手，很自信，他的直觉已经定了他的方向，过程只是想显摆一下；
2、不要太快把自己信息暴露太多，诚信固然重要，但是扬长避短是把自己劳动力价值卖好一点的必要条件，所以我必需告诉他当前在“某公司”任职；
3、待遇想必不错，和飞利浦同楼；
篇2：fluke网络测试分析报告
fluke网络测试分析报告
一、实验背景：
为了熟练掌握线缆测试的几个参数以及使用fluke测试仪器。我们制作了一根有缺陷的双绞线，测试这根双绞线的参数，看看哪几个参数能通过，哪几个会失败。这次我们小组主要测试了网线的RL回波损耗、传输时延、ACR衰减串扰比、NEXT近端串扰、接线图、电阻等等一些数据。
二、现场测试参数：
现场测试首先要确定测试时依据的国际标准或区域标准，这一点在FLUKE的设备上非常容易实现，只需要在测试之前选择一项标准即可，FLUKE已经预先将常用的标准内置于其设备之中。为了确保现场测试的准确性和认证测试的权威性，一般都要测试多项技术参数，只有这些技术参数都符合标准规定，才能给出相应的认证。
三、实验过程：
这次试验主要测试有接线图、回波损耗、Next、插入损耗、ACR—F、电阻 接线图：
接线图测试是为了测试所连通道或永久链路的双绞线其线序连接的正确性。
我们的测试结果为六号线路断开，所以接线图不合格。 回波损耗（RL）：
信号传输时，电缆阻抗的变化产生 RL ，因此，导致阻抗变化的因素都会影响RL 。这包括视频电缆的基本结构，即中心导体的尺寸、形状和组成，绝缘或介电材料的选择和制造，屏蔽方式和材料的选择，护套的打印方法也是影响回波损耗的因素。
它是反射系数的倒数，以分贝表示。RL的值在0dB到无穷大之间，回波损耗越小表示匹配越差，反之则匹配越好。0dB表示全反射，无穷大表示完全匹配。在移动通信中，一般要求回波损耗大于14dB（对应VSWR=1.5）。 回波损耗是由于阻抗不连续/不匹配所造成的反射
测量整个频率范围内信号反射的强度 产生原因：特性阻抗之间的偏离 线缆在生产过程中的变化
连接器件 安装 降低回波损耗指标的措施
降低回波损耗（RL）的措施有以下3种： 1、提高同心度 2、复合技术3、采用粘连线对技术
用回波损耗表示特性阻抗的影响更准确，用RL测量沿线路上所有位置上由于阻抗不匹配引起反射。
计算回波损耗的公式为：RL=20logU0/U1 我们的测试中回波损耗余量为负，不合格。 Next近端串扰：
“近端串扰”是指串扰的测量是在测量信号发送端进行的。这个参数在标准中是要求双向测试的，它有以下两方面的含义：1、Next是测量来自其它线对泄露过来的信号2、Next是在信号发送端进行测量近端串扰的影响：1、类似噪声干扰2、干扰信号足够大从而：·破坏原来的信号。 ·错误的被识别为信号3、影响
·站点间歇的锁死·网络的连接完全失败
此次实验我们的近段串扰余量为10.5dB,，测试通过。 插入损耗：
插入损耗是指发射机与接收机之间，插入电缆或元件产生的信号损耗，通常指衰减。插入损耗以接收信号电平的对应分贝来表示。对于光纤来说插入损耗是指光纤中的光信号通过活动连接器之后，其输出光功率相对输入光功率的比率的
分贝数。 这是现场测试中最重要的参数之一，且测试后要进行一定的分析，因为衰减都是频率的函数，它的衡量标准也比较特殊，用分贝（dB）标称。
此次测试实验中我们的'插入损耗太大，余量为-7.9dB，所以测试不通过。 ACR—F ：衰减串扰比
衰减与串扰的比率（ACR）是指由电线或电缆传输媒介说产生的信号衰减与远端串扰之间的差异，以分贝（dB）为单位。
ACR是一个定量指标，表明在一个通讯电路中，衰减过的信号比目的（接收）端的串扰强多少。
1、衰减串扰比或衰减与串扰的差（以分贝表示）
2、类似信号噪声比
3、对双绞线系统“可用”带宽的表示 信号-被衰减--->经过衰减的信号和噪声的比 噪声-近端串扰衰减串扰比ACR=近端串扰-衰减（dB） 数值越大越好 ACR=传统的信噪比
信号：来自另一端的经过衰减的有用的信号 噪声：NEXT+外部噪声
此次测试实验我们的衰减串扰比的余量为4.1dB，经过分析测试通过。
四、实验总结：
在测试时，小组遇到过不少问题，总是不那么顺利，但是经过大家的一起思考解决了问题以及了解了问题发生的原因。
通过这次实验加强了自己的团队精神以及测试经验，我们都基本学会了使用fluke仪器，掌握了线缆测试的几种标准以及测试时需要注意的事项。
篇3：英语串烧：this is no fluke 真不是省油的灯
实用英语串烧：this is no fluke 真不是省油的灯
1. this is no fluke 真不是省油的灯
fluke是一种比目鱼的名字，同时在口语中也可以指「侥幸」，也就是运气好、蒙到的'好事，所以This is no fluke!就是在赞美别人靠实力获得好的结果，绝非光凭运气。这个字还有另一个用法：
A: What a fluke! I ran into my boyfriend near the Welcome.
运气真好！我在顶好超市附近碰到我男友。
B: That's no fluke. I saw him there the other day talking to another girl!
没什么好的，
我前几天看到他在那儿跟另一个女生说话！
2. Mark my words. 记住我这句话。
mark是「做记号」，mark my words字面上是「把我说的这些字做上记号」，当然就是要人注意自己所说的话，而且还要牢牢记住。当你想加强语气时，这是个非常好用的短句。
A: Mark my words! You'll come crawling back to me!
记住我这句话！你会爬着回来求我！
B: Not even if I'm so poor I have to live on the streets.
我就算穷到露宿街头，也不会来求你。
篇4：Fluke Networks:ERP 应用疑问的快速诊断
在一个企业里，大部分的应用问题都是由用户提出的，这是因为对于应用质量一直都没有一个好方法来评估，光是对流量监测已经不能判别应用运行时的性能， 应用监测是一个比较新的网络性能监测手段，他通过长期监测，组成智能基线，方便分割应用问题的源头。以下是一个通过应用分析，对用户投诉ERP系统出现问题时，诊断时的流程实例：
第一：问题是什么？
一个ERP 系统可以由多层的服务器来支持。在出现问题时，需要知道问题是在哪一层。应用性能监测仪如福禄克网络公司的SuperAgent 可以可以同时监测多层应用的性能。在图一上，可以看到ERP 的问题，只发生在ERP System 应用上(用户界面)，与其它应用无关。
screen.width-333)this.width=screen.width-333“>
图一、应用与响应时间的关系图
第二：确认是网络、服务器还是应用出毛病呢？
这么一个简单的问题，却可能由于各个维护小组相互指责，引起浪费时间。SuperAgent的响应时间构成图，可以清楚的提供实际的证据，证明是哪一方的问题。在图二，绿色代表网络往返时间（Netwk RTT）,深蓝色代表平均的重发报时间（Retran），金色代表数据传输或网页下载时间（Data Xfer）, 红色是服务器响应时间（Srv Resp）和浅蓝色的TCP 连接建立时间（Conn Time）。 在图上可以看到在出事时9：10 左右，总响应时间是4 秒种，服务器的响应时间特长是主要原因。我们可以深入分析每一个响应时间的部件。在图三，可以看到在过去8 小时，服务器响应时间的中间值（50% percentile）是0.12 秒,平均值是0.24 秒。但出毛病时响应时间长达3 秒，增加了30 倍。要留意的是SuperAgent和大部分长期监测工具的报告都是平均值（5 分钟），所以可能只是有小量的长响应时间，影响这平均值结果，要找出根源，需要进一步确认。
screen.width-333)this.width=screen.width-333”>
图二、响应时间组成图
screen.width-333)this.width=screen.width-333“>
图三、服务器响应时间趋势图
第三：问题有意义吗（有多小有问题的情况）
究竟有很多的应用对话受影响呢？在图三上的灰色线代表SuperAgent 在计算平均值时，用上的测试个数数量。通过这灰色线，可以明确的显示问题是否由于应用率改变，影响响应时间的统计结果。如果测试个数数量在出问题前或同时突然增加，很有可能是网络资源甬塞或冲突。 如果测试个数数量大量减低，应用的衰减可能改变了正常的应用模式，也要可能只一些小的响应时间衰退，例如在3:00am，只有一个用户，他的对话比较慢，是否值得探讨呢？为了了解正常的应用模式，SuperAgent 提供4 个不同的分析时间模板的趋势图：8 小时，一天，一周和一个月，
这样让您很容易看到出问题时比正常的情况是超过还是低于，而且是否会定期发生。在我们的案例上，图2 上显示问题发生时，有一定数量（每5 分钟超过1000个测试个数），而且数量没有大的改变。
第四：问题严重吗
有多小应用对话受影响呢？SuperAgent 提供统计分析，可以提供每一个影响响应时间部分的90 百分点，75 百分点和50 百分点情况。如果在90 个百分点没有响应时间的增加，代表只有不超过10%的对话受影响。如果75 百分点又突然增加，但50 百分点却没有，哪是25%-50%的对话受影响。在图四上，我们看到ERP 的50 百分点图。服务器响应时间（红色曲线）有明显的增高，这代表超过50%的对话的性能受影响 ?C 一个严重、需要立刻处理的问题。
screen.width-333)this.width=screen.width-333”>
图四、响应时间元件统计图
第五：问题的范围
了解影响范围有多广，只有一个服务器受影响？还是影响多个服务器？SuperAgent 的性能图可以提供很有效的分析。在图五上，可以方便的看到每一个服务器个别的服务器响应时间，我们看到其中两个被SuperAgent监测的服务器的响应时间都是很长，着代表这两个服务器组都有问题，而不是单一个的服务器。另外，服务器间的响应时间差异不小，如果服务器间有基于响应时间实现负载平衡的设备的话，这设备的效能可能有问题。
screen.width-333)this.width=screen.width-333“>
图五：服务器响应时间分布图
第六：其他的分析
一些其它的分析数据，可以加速故障诊断，如流量统计、进程报告，QoS,和响应数据大小等。
screen.width-333)this.width=screen.width-333”>
screen.width-333)this.width=screen.width-333“>
总结：
对于多层ERP 应用，通过监测应用性能，很快便可分割出问题出在ERP 的用户界面，与其他后台应用层无关。（图一：应用性能表）这比动态应用性能测试方便得多。而且通过应用响应时间的分析（图二：响应时间元件图），可以定位在服务器上。然后证实问题是严重的（图三：服务器响应时间趋势图），而且影响大（图四：响应时间元件统计图）。问题不是在某一个服务器，而是其中两个ERP 服务器组。在深入了解时，发觉问题的原因不是由于用户太多（根据用户量趋势图表），也不是对话太多（根据对话量和拒绝对话量的图表），初步怀疑是负载平衡设备的问题。这些数据都是可以提交给相关的部门来处理的和做更深入的分析。回想一下如果没有如SuperAgent这样的应用响应监测工具，您会用什么方法、时间来解决这个ERP 的问题呢？
电话：北京：010-65123435 广州：020-38795800 上海：021-63548829 成都：028-85268810
网页：www.flukenetworks.com.cn
篇5：Fluke Networks:解析您的广域网怎样解析内容
虽然广域网的性能监测工具已经有接近10 年的应用，但在美国也只有少于四分之一的广域网链路被监测DD用企业自己的设备进行监测或者由企业的网络服务提供者进行监测，在美国之外，这个比率可能更低。
对网络链路进行监测的所有好处能够在价值上超过对链路的部署和监控吗？监测您的广域网链路的主要好处是什么？监测广域网链路您需要监测什么呢？
screen.width-333)this.width=screen.width-333”>
本技术白皮书将帮助您考虑线路监测的价值，帮助您考虑宕机的费用，理解服务响应慢和应用性能差的原因，帮助您更有效地管理您的网络带宽。
什么时候监测广域网链路是有意义的？
为什么某些广域网链路需要监测而某些链路却不需要监测呢？在某些案例中，监测链路的花费并没有带来充分的益处来证明监测是值得的。某些广域网技术DD例如帧中继、PPP 和ATMDD是成熟的技术，网络经理“让其无监测地运行”。这些没有被监测的链路，性能和可用性保证或多或少地转移到服务提供者，而客户对链路性能的能见度却非常的少。一些网络经理感到大多数没有被监测的链路出现问题和失效的情况不多，通常在充分数量的时间内还是保持不监测，因为部署“昂贵的”监测方案并不能证明增加收益。第2 个原因是一些网络管理员茫然不知监测广域网链路的益处何在。网络经理知道市场上有很多工具可以给出有关他们的广域网性能的数据，但是关于这些数据如何帮助自己的工作，网络经理还是不确定。从另一个方面说，是简单的成本效益（分析的）因素。有些案例，部署监测需要的时间和费用，并没有带来足够的收益和好处。有些案例，监测带来的好处并不足以证明部署监测方案的花销是值得的。
“关键使命”链路
对一条给定的广域网链路，根据应用类型和用户利用率不同，主动监测的必要性和程度也不同。如果一条广域网链路用来提供一般的企业网用户接入Internet，进行页面浏览网际冲浪，对链路性能小心翼翼地监测可能不值得花费。通信量来自一个分部的签约用户，需要访问用户记录来完成一次POS交易是关键使命的事物处理，需要进行连续的监测，确保事物处理的完美无缺。本质上说，认为对交易有明显影响的“关键使命” 广域网链路，需要被监测。
关键使命广域网链路通常分为以下几种类别：
那些绝对需要保持客户满意的链路。这些链路通常携带用户需要实时处理的数据。例如POS 交易用户记录接入、信用卡处理事务、客户呼叫中心的IP 电话呼叫和其他的关键使命的客户服务应用。
那些支持个人重要实时应用的链路。这些链路通常是指支持终端用户以及关键使命的内部操作。例如电子商务应用、Web 共享件应用、实时库存量数据接入、视频会议、电子邮件和其他实时性的操作应用。
那些支持紧急商务工具的链路。这些链路支持关键的后台办公室应用，特别的是在数据中心。例如数据交换工具、远程镜像站点数据备份交换、远程服务器软件更新和其他后台办公室应用。
计算链路监测的价值
监测一条广域网链路的价值取决于其所承载业务的关键性、现有的网络效率以及公司的组织结构。一种评价价值的方法就是应用一个简单的数学公式来评估监测链路所用的成本。通过这种方法，您简单地计算后再进行合计，所有的价值成本来源于所选的被监测链路。把这个值与部署监测方案的成本进行比较，从而决定是否值得监测。
screen.width-333)this.width=screen.width-333“>
通过表格1 的公式可以利用一个非常主观的方法计算出一个数字化的收益价值。为了说明这一点，让我们举个例子。假定有一条给定的链路现在通过一个广域网探针进行监测，依据过去的经验，网络经理观察到相对一条完全相同但没有被监测的链路来说，被实时监测的链路每年可以减少2 小时的MTTR。单独针对这个成本值，假设关键使命任务链路的价值是 $100/分钟，改善MTTR 的价值是 $12,000/每年（$100/分钟×120 分钟MTTR 改进/每年）。监测该链路的好处还可以带来其他的收益，例如节约故障查找的劳动时间和改进网络效率。显而易见，MTTR 改善带来收益的大小，与每条失效链路在其公司的价值息息相关。但是，基本价值单元和计算公式都是一样的。
计算总体宕机开销
评估部署链路监测方案的价值，取决于网络工程师是否仅仅需要简单的头痛医头、脚痛医脚的链路监测方案。决定监测一个分布式广域网监测系统的整个价值需要一个不同的方法，简单地把所有被监测链路的价值合计起来是不合适的。评估分布式广域网系统，您也许想从跟宕机有关的最高级花费开始。福禄克网络评估了一个典型的年收入1 亿美金的企业，宕机所带来的开销是十分重要的。（见图2）
screen.width-333)this.width=screen.width-333”>
图2、一个年收入1 亿美金的企业所估计的宕机开销（摘自“企业宕机开销2004：成本分析”DDInfonetics Research）
注意宕机的每个来源，广域网链路可能是一个主要的来源。不同公司宕机的来源显著地不同，因此在决定是否部署一个分布式的广域网监测方案对您是否合适之前，应该做一个关于您的企业的单独分析。在对典型的企业进行分析的基础上，不管用什么方法，广域网都可能是宕机花费的显著来源。
在您的广域网链路里，您应该监测什么？
让我们假定至少少数广域网链路被确定是关键使命链路而且是值得监测的。下一个逻辑问题就是，最需要监测的是什么？
很多的厂家都热心地把“网络可视方案”卖给IT 组织，网络经理很少抱怨缺少能提供网络性能数据的工具。终端用户通过这些厂家提供的工具，收到了大量的有关自己网络运行状况的数据。但是，大部分网管人员承认当网络故障发生或者用户抱怨网络应用性能差的时候，这些海量的数据并没有能够表现出很好的应用。
网络工程师很快指出大部分的网络分析工具缺少清晰的、方便的、快速的、精确的网络消息，来帮助解决和隔离他们遇到的各种问题。不同的厂家通常有不同的解决方案，通常擅长解决不同的“典型问题”。大多数情况下，为了能够百分之百的监测网络行为，需要多个厂家的解决方案配合，但是，网络工程师没有时间或者预算来购买、学习、维护不同厂家的解决方案。
因此，对企业网络专家来说，监测最重要的本质是什么？福禄克网络最近对网络工程师和管理员进行了一个有关他们对广域网链路的关心点和问题点的调查。这次国际性的调查显示了大多数的终端用户不仅有非常相似的广域网链路关心点，而且在不同的调查地区，用户的基本关心点都是一致的。
调查结果并不让人感到吃惊，网络工程师需要基本的链路能见度，需要具有前瞻性地管理广域网链路的带宽性能，同时需要解决广域网链路造成的服务响应过慢，了解服务中断的原因。因此，当管理广域网链路的时候，监测相关的广域网链路以获得最好的带宽管理和定位服务中断源是最值得关注的事情。
最初的时候，大家都比较关心带宽管理和基本可视性等，不同的人可能面对不同的事情。为了更好的明确和理解这些概念，福禄克网络选择了与被调查者进行面谈，
奇怪的是，面谈结果表明客户的关心点是非常一致的，对最关心的6 个问题（见图3）有相同的理解。
screen.width-333)this.width=screen.width-333“>
图3：对网络经理进行调查的结果显示的广域网链路关心点
带宽管理
带宽管理是指确保带宽是可用的，不论是对客户、服务器、应用还是其他网络设备，也无论企业网管经理是如何定义的。对少数用户来说，带宽管理意味着通过流量整形、警管或者带宽压缩来减少网络拥塞。对其他一些用户，带宽管理意味着区分流量优先级别类型，比如IP 电话，从而确保话音呼叫能够穿过数据网络的同时确保其话音质量。对大多数调查者来说，带宽管理仅仅意味着监测用户和电路的带宽消耗，从而让网络经理有适当的、实时的信息来采取行动，确保广域网链路的吞吐量并远离故障。举例来说，网络经理需要能够识别带宽瓶颈原因的信息，从而采取纠正的行为。大多数时间，这些行为并不包括设置或者改变服务水平政策、购买更多的带宽或者采用压缩技术。典型的矫正行为包括简单的网络“tweaks”（调整），例如对于一个没有授权的应用例如KAZAA（一个点对点文件共享工具）关闭一个通道、端口，或者改变到远端工作站、服务器做软件更新的固定时间。其他带宽管理的主要需求是在一个有限的带宽环境里，当新的应用部署、新的服务部署移动、增加和不断改变时，连续地观察网络的运行状况，保证网络高效地运行。
网络经理指出对关键链路进行监测统计是监测方案的一个关键。统计链路利用率、吞吐量速率、每一个分离虚电路的错误、在不同时间的规律对于性能验证都是非常有用的。（见图4）监测链路利用率是确定广域网是否成为一个瓶颈的一个快速途径。如果利用率太高，那么需要对广域网做一个更深入检查来定位根本原因。如果利用率在设计的范围内，就有了广域网运行适当的根据。
screen.width-333)this.width=screen.width-333”>
图4：监测最多的几种应用以更好地管理带宽
了解广域网链路的应用对带宽管理也是非常重要的。能够显现真正的带宽需求、瓶颈来源、发觉未经授权的应用。这种分析对确定流量是非常重要的。（见图5）
screen.width-333)this.width=screen.width-333“>
图5：通过监测响应时间来寻找服务下降的原因
服务和应用性能缓慢
服务或者应用性能缓慢可能是由一系列不同的原因造成的，包括应用本身、用户服务器主机、应用服务器主机和路由器、交换机等网络要素。网络经理需要基本的可视性来查看各种主要的性能抑制来源，从而执行矫正问题的有效方法。主要的网络和服务器瓶颈测量标准包括：
连接时间－在客户和服务器之间，开始传送数据之前，建立一个TCP 会话连接的全部时间服务器延迟－服务器开始响应一个请求的所花的全部时间数据传输延迟－服务器对一个请求从开始响应到数据传输完成的全部时间重传延迟－因为重传的原因，网络往返时间（RTT）所增加的延迟网络往返时间RTT－一个数据包穿过网络所花的全部时间
这些统计标准的可见性能够区分速度减慢的来源，是有效执行纠错方案的基础。在没有性能监测手段的时候，网络管理经理很可能推断带宽不足是问题根源。企业于是尝试补救，要么购买一条更多带宽的链路，要么购买一条更高CIR（用户约定速率）的PVC（永久虚连接）。在许多的情况下，这是金钱的浪费，因为服务减慢的原因可能在网络的其他地方。（见图6）
screen.width-333)this.width=screen.width-333”>
图6：检测响应时间来筛选造成性能下降的源
基本可视性
基本的链路可视性允许您快速地着眼于一条特定电路，确认该链路的性能。网络经理需要对此有概要性的了解，做为消除广域网链路问题的资料来源或者帮助将来定位问题的区域。通过对首页的图表信息的快速查看，能够对广域网链路的特征有一个快速的、实时的理解，知道链路正在做什么。（见图7 和8）广域网电路监测的关键图表信息包括：
电路连接－认证电路类型（如FR、PPP、ATM 等），虚电路的数目和它们两端的路由器
利用率－快速测定当前是否存在带宽瓶颈。包括对整个电路利用率的查看，也包括对消耗带宽最多的主机、应用、虚电路的查看。
设备－使用该电路的所有设备的显示，包括路由器、服务器、主机、探针
问题－通过流量探针的监测，生成的告警日志
screen.width-333)this.width=screen.width-333“>
图7：快速查看所有关键广域网性能区域
screen.width-333)this.width=screen.width-333”>
图8：通过了解有什么设备存在与网络之上可以更好地管理链路
正常运行时间/服务中断
问题告警是任何监测系统的一个基础部分。前瞻性监测能够发送基于标准的失败事件、用户定义的极限违背事件的告警。但不会产生纠正的动作，直到网络经理意识到这个问题（见图9）。
screen.width-333)this.width=screen.width-333“>
图9：问题日志具有前瞻性地警告网络管理人员广域网问题
服务提供监测
不管安装人员、技术人员和工程师如何努力，在提供服务的时候总有错误发生。因此，要谨慎地验证实际交付的链路吞吐量是您期望的。SLA 确保您基本的QOS（服务水平质量）通过广域网是可用的。监测对验证SLA 一致性是必须的。当广域网瞬间的拥塞导致流量下降的时候，您的链路吞吐量会受到影响。在时间上了解和验证链路PVC 吞吐量特征，对识别问题是由于暂时的过载、系统错误、还是由于简单的错误配置引起的非常重要。（见图10）
screen.width-333)this.width=screen.width-333”>
图10：验证您的服务提供商所承诺的线路容量
物理层问题
与谨慎地验证服务提供者的供给能力一样，对物理层问题的监测也是非常重要的。对物理层性能的反复核对能够消除在企业网和服务提供者之间的“相互推诿”，而且有助于快速隔离和消除与广域网相关的物理层问题。当物理层问题出现在一条关键使命链路上的时候，MTTR 对用户的影响极为重大。（见图11）
screen.width-333)this.width=screen.width-333" ?>
图11：监测物理层减少 MTTR 和“相互推诿”
结论
监测关键使命广域网链路证明了针对任何企业监测都会带来成本收益，虽然成本效益价值必须根据不同公司的不同规则进行评估。为了达到广域网链路的效率最大化，关键使命链路的最大无故障运行时间，必须执行对广域网链路的实时、积极地监测。网络经理在做出纠正动作之前，必须通过监测广域网链路关键性能的规律，彻底地了解链路的使用情况。监测能力的缺乏将会导致广域网链路不能很好地优化、运行和维护。
电话：北京：010-65123435 广州：020-38795800 上海：021-63548829 成都：028-85268810
网页：www.flukenetworks.com.cn
★ 英语串烧：That’s the beauty of hindsight.
★ 赛马运动英语小结
【Fluke 面试（共5篇）】相关文章：
全面了解初中议论文相关题型2022-09-07
跨专业综合实习的平台总结2023-09-29
托福听力备考怎样选择合适教材2022-10-27
详解托福阅读文章结构2023-06-17
考研英语作文预测：选择大公司还是小公司2023-06-12
有关网球运动问题解答：为什么及常见问题2023-03-14
小学生英文作文2023-12-02
体育运动分类词汇表62024-05-01
《云图》的个人观后感2023-01-07
考研英语词汇：常见热词二2023-05-12