研究实现互联网互联互通故障定位的新方法

1、研究互联网互联互通故障定位新方法中国移动通信集团福建有限公司泉州分公司Speed QC小组2010年3月目 录1小组概况- 2 -2选择课题- 4 -3确定目标- 7 -4提出各种方案并确定最佳方案- 9 -5对策制定- 24 -6对策实施- 25 -7效果检查- 35 -8标准化- 36 -9.总结打算- 38 -1小组概况1.1小组概况Speed QC小组成立于2009年2月，是一个具有扎实QC理论基础知识和丰富交换、IT实践经验的QC小组，小组成员均为IT和交换专业技术骨干。小组的主要任务是弘扬自主创新文化，开展各项专题技术攻关，提升网络质量，不断为用户提供优质、满意的网络服务。小组名称

2、Speed QC小组成立时间2009年2月课题名称研究互联网互联互通故障定位的新方法课题类型创新型组长金鹏活动时间2009.22009.12活动次数11次成员情况注册号CMFJQZ2009036姓 名性别文化程度小组分工职 称职 责叶育文男本科顾问高级工程师活动指导金鹏男本科组长高级工程师活动指导王亦淳男硕士副组长工程师方案制定 组织实施王瑞斌男硕士组员中级工程师原因分析 具体实施洪昭明男本科组员工程师数据收集 具体实施王东龙男硕士组员中级工程师资料整理 报告整理吴韦力男硕士组员工程师资料整理 实施验证陈夤男本科组员工程师资料整理表 1-1：小组概况 制表人：金鹏 制表时间：2009年2月1.

3、2小组合影1.3术语解释序号名 词含 义1故障定位历时出现故障到发现并定位故障原因所经历的时间2PINGPing 是Windows自带的一个可执行命令。利用它可以检查网络是否能够连通，用好它可以很好地帮助我们分析判定网络故障。3HTTP超文本传输协议(HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。4FTPFile Transfer Protocol 文件传输协议，用于Internet上的控制文件的双向传输5SMTPSimple Mail Transfer (or Transport) Protocol，简单邮件传输协议，用于电子邮件的传

4、输。8DNSDomain Name System 域名系统，用于命名组织到域层次结构中的计算机和网络服务。表1-2：名词解释 制图人：王瑞斌 制图时间：2009年2月2选择课题2.1问题提出1、现状分析 2008年以来，泉州分公司互联网宽带业务得到了快速发展。截至2009年1月，宽带用户近1.2万户。但是，1月份宽带用户投诉量剧增，公司要求采取有效措施降低宽带用户投诉量。小组分析了08年8月至09年1月移动宽带业务发展和客户投诉情况，如图2-1所示：图2-1：宽带业务发展情况 制图人：洪昭明 制图时间：2009年2月通过对比发现，最近三个月宽带用户投诉增长速度明显大于用户发展速度并呈快速增长趋

5、势。2、宽带用户投诉分析小组进一步提取了08年11月至09年1月宽带用户投诉工单，对用户投诉的故障原因进行了分析，结果如下：图2-2：宽带用户投诉原因分析 制图人：洪昭明 制图时间：2009年2月根据上述分析，QC小组认为，互联互通故障是产生客户投诉的主要类别，已成为宽带业务发展的瓶颈问题。解决互联互通故障问题迫在眉睫！ 3、互联互通故障投诉分析 小组对08年11月至09年1月有关互联互通故障投诉单进一步分析，发现影响互联互通故障投诉的因素是多方面的，具体分析数据见下表：序号项目频数累计累计百分比（%）1电信端口设限47547538.42电信路由设限40788271.33移动故障定位历时长23

6、0111289.94电信故障处理不及时891201975移动出口带宽不足26122799.26其它101237100表2-1：互联互通故障投诉原因分析 制表人：洪昭明 制表时间：2009年2月根据上表数据做出排列图：图2-3：互联互通故障投诉原因分析排列图 制表人：洪昭明 制图时间：2009年2月（1）由图2-3可以看出，影响互联互通故障投诉的主要因素有电信端口设限、电信路由设限、移动故障定位问题和电信故障处理问题，这四个因素占比高达97%。如果能够解决这几方面的问题，那将大大降低互联互通故障投诉！（2）解决电信端口设限、电信路由设限和电信故障处理问题，显然非QC小组力所能及。主要的问题还在于

7、取证困难，无法及时向电信及通管局进行申告，同时鉴于通管局在互联互通问题上的压力，电信一般不重复对已申告成功的端口或路由重新设限，若能加快解决故障定位历时及尽快收集举证材料，将有助于降低互联互通类投诉。因此，小组认为应该围绕这如何解决故障定位历时这方面入手，通过有效的技术手段实现故障的快速定位和快速申告，从而加速故障问题的处理。4、互联互通故障定位历时 小组成员提取了2008年11月至2009年1月三个月的与互联互通故障有关的客户投诉工单，统计如下：月 份互联互通故障工单平均故障定位历时（min）20081123046.220081248640.920090177344.6平 均496.743.

8、9表2-2：互联互通故障定位历时统计表 制表人：洪昭明 制表时间：2009年2月小组通过调查分析发现，由于缺乏有效的技术手段定位互联互通故障，导致故障定位历时过长。5、移动故障定位历时与电信故障处理历时关系1）小组抽取08年1109年1月互联互通故障工单，对我方有提交申告工单，电信方解决时长和我方无法提交申告工单、电信解决时长进行对比，结果如下：月 份互联互通故障工单30分钟内提交申诉工单数（条）电信方24小时解决率超半小时及未提交申诉工单数（条）电信方24小时解决率20081123012065.211038.320081248623972.424741.5%20090177334169.8%

9、33234.2%平 均496.769.138表2-2-1：电信24小时解决率及我方24小时提交工单统计表 制表人：洪昭明 制表时间：2009年2月结论：从表2-2-1的统计可以看出，移动方未能在半小时实现故障定位，电信方24小时故障解决率同比下降30左右，小组据此推测，移动故障定位历时缩短将有助于电信方加快解决其限制问题，24小时解决率将提高近30。据此可以推出，通过缩短移动故障定位历时一定程度上有助于推动电信方面相关互联互通故障问题的解决。通过对全部50个数据的比较分析，据测算，通过有效控制移动故障定位历时将分别解决电信端口设限、电信路由设限及电信故障处理不及时等三个问题的38、21、30。

10、据此，小组成员一致认为，移动故障定位历时的解决将解决总体互联互通故障投诉的45，有助于进一步减少投诉量。6、故障定位方法 小组围绕这如何缩短互联互通故障定位历时这个问题展开讨论和调查，分析发现由于互联互通故障多样，技术人员需要通过多种手段逐一分析，传统的人工故障定位方法存在诸多不足，如表2-2所示：序号存在不足1对维护人员有专业水平和故障处理经验要求高2无法24小时实现故障监测定位3故障监测定位的范围有限4占用系统资源多，存在安全隐患5故障定位不及时；6历史信息不易查询，取证困难7无法自动申告表2-2-2：传统故障定位方法主要不足 制表人：洪昭明 制表时间：2009年2月 如果能够通过新方法实

11、现主动监测故障、定位故障成因，实现自动预警，争取能够在第一时间精确锁定互联互通故障问题所在，将有助于缩短故障定位历时，加快互联互通故障问题的解决！但是，小组成员咨询了集团及其他兄弟省市的同事，并查询了集团的成果库，均没有发现相关的成果。同时查阅了相关专业资料，也没有发现存在相关技术或方法。因此，小组成员决定研发实现互联互通故障定位的新方法！2.4选定课题图2-3：选题理由 制图人：洪昭明 制图时间：2009年2月2.小组活动进度计划表 2-3活动进度计划制表人：金鹏 制表时间：2008年3月3确定目标3.1课题目标：通过技术手段实现互联互通的故障监测及智能定位，第一时间定位故障及其原因，缩短互

12、联互通故障定位历时，降低故障处理时长，改善宽带业务网络质量，提升客户满意度。3.2 目标值：考虑到多种因素，我们将目标值设为：故障定位历时8分钟。图 3-1：投诉及故障定位情况柱状图制表人：王瑞斌 制表时间：2009年3月3.3目标设定的依据：1、逻辑推理整个故障定位过程包含两个阶段：1） 故障监测：故障发生到发现故障所经历时间。通过应用新方法后，可以模拟用户的上网行为，从而实现主动实时监测故障，从业内经验看，定期以不同IP段完成对本地100个固定网站进行监测，监测任务的执行时间为2分钟计，新方法若可以通过系统实现并发测试，故障监测历时可以缩短到2分钟。2） 故障定位：发现故障到定位到故障发生

13、原因所经历时间；通过应用故障定位新方法可以全面定位故障并保证故障定位的准确性，通自动化处理可以现有的平台（操作系统：windows XP，CPU:2GHZ,内存：1G）和目前常见软件的计算能力，6分钟就可以完成了对全部故障点的扫描，所以以定位故障可控制在6分钟内。图 3-2：互联互通故障定位过程图：王瑞斌 制表时间：2009年3月因此，QC小组将互联互通故障定位历时的目标设定为2+6=8分钟！2、历史经验经验表明，在常见故障定位上，一个技术熟练的人员在没有任何外界干扰且判断精确的情况下，6-10分钟可以定位故障。所以，应用新的方法还是有可能完成的。3、人员保障小组成员均接受过的技术培训，并且拥

14、有公司最顶尖的数据网维护、IT系统研发人才，且小组成员QC活动经验丰富。图 3-3：目标可行性示意图：王瑞斌 制表时间：2009年3月4提出各种方案并确定最佳方案4.1方案提出 针对我们设定的目标，小组成员集思广益，结合严谨的理论知识和广泛的群众分析，利用“头脑风暴法”，提出了一系列解决意见并通过亲和图整理如下： 图4-1：方案讨论亲和图制图人：王东龙 制图时间：2009年3月经过归纳整理，QC小组初步明确了实现互联互通故障定位新方法必须包含三个部分来研究。而通过对三大研究方向展开来分析讨论，我们又分别确定了三大部分的可选方案：图4-2解决方案分解树图制图人：王东龙制图时间：2009年3月4.

15、2方案选择一、互联互通故障监测（一）可行方案提出：在互联互通故障监测上小组是如何进行的呢？小组成员结合日常的维护经验以及同厂家进行交流，分析总结了三种解决方案： 表4-1故障监测解决方案制表人：王东龙制表时间：2009年3月（二）方案简介1、基于协议分析的测试方法简介：通过对互联网应用进行协议分析，将复杂的互联网应用分解成若干个步骤，对每个步骤的连接时长进行统计，通过连接时长衡量互联互通是否正常。互联网由TCP/IP协议构成，所有互联网应用程序都是基于TCP/IP协议开发出来。以此为出发点，每一种协议都可以细化为多个连接步骤。而只要我们能够对协议进行细化，由此即可反映出应用连接。图4-3基于协

16、议分析的测试方法简介制图人：洪昭明制图时间：2009年3月通过分析HTTP协议等网络协议的连接全过程，细化每个阶段的连接时间，并为其设置报警阀值，检测互联互通故障。2、基于传输连接的测试方法简介：利用现有的网络承载网管设备，计算每个互联网应用在传输电路层面的连接时间，以此来测试互联网业务是否正常。图4-4基于传输连接的测试方法简介制图人：洪昭明制图时间：2009年3月3、基于应用加载的测试方法利用系统模拟互联网应用程序，记录应用程序的加载时间，以此来衡量互联互通是否正常。图4-5基于应用加载的测试方法简介制图人：洪昭明制图时间：2009年3月（三）方案选择：1 、方案准确性测试经过分析，互联互

17、通故障监测最重要的功能就是要能真正的模拟用户的上网体验，并先于用户发现问题，因此QC小组认为首先要评估的参数即监测方法的准确性。检测的准确性主要考虑两个指标，一是误报率，太高的误报会导致值班人员浪费精力处理不存在的故障。二是漏报率，太高的虚报率会导致经常无法提前检测到故障。QC小组选取最常出现故障的前100个网站，并对这100个网站进行长时间互联互通故障告警测试。图4-6基于应用加载的测试方法模拟测试 制图人：洪昭明制图时间：2009年3月测试结果如下：方案名称泉州网泉州地税漏报率误报率故障次数报错次数误报次数漏报次数故障次数报错次数误报次数漏报次数基于协议分析的测试方法6600910103%

18、4%基于传输连接的测试方法6501982113%5%基于应用加载测试方法671099115%11%表4-2互联互通故障监测方案对比 制表人：洪昭明制表时间：2009年3月2 、测试结论l 基于传输连接的测试方式，由于存在的端口限制导致的互联互通故障，对这类限制该方式无法判定，因此漏报率较高。l 基于应用加载测试方式，由于现有测试软件无法精确测算应用加载时间，经常得到过高的加载时间，产生了大量的误报。同时由于部分站点经过缓存，因此测试的漏报率也较高。l 基于协议分析的测试方法，通过多阶段的分析减少了两种方式的弱点带来的误报和漏报，故障定位的精确性最高。3、方案评价方案名称优缺点评价标准评价结论可

19、行性分析基于协议分析的测试方法l 优点：1、定位精确，与用户实际体验几乎没有误差2、自动监测不占用终端资源l 缺点：必须对各种应用协议有清楚的认识准确性精确可行研发难度较难扩展性扩展功能丰富基于传输连接的测试方法l 优点：故障发生时，可以第一时间发出警报l 缺点：1、 准确性较差，出现网速慢的情况不易定位；2、 部分端口障碍无法监测；准确性漏报率较高不可行研发难度一般扩展性不易扩展基于应用加载测试法l 优点：较容易实现；l 缺点：1、由于应用加载存在资源缓存，因此存在较大的误差2、对终端要求较高，占用资源准确性误报率较高不可行研发难度一般扩展性一般表4-3第一部分方案可行性分析制表人：洪昭明制

20、表时间：2009年3月4、 结论图4-7第一部分的最优方案选择制图人：洪昭明制图时间：2009年3月二、互联互通故障定位新方法的研究：（一）可行方案分析：第二部分方案是整个QC课题的难点，小组成员充分利用了所学知识并结合自身工作经验，展开了热烈的讨论，最终确定了三个可行方案：图4-8第二部分解决方案树图制图人：王瑞斌制图时间：2009年3月（二）方案简介：小组成员于4月份，针对三种方法进行100次模拟测试，并统计正确定位出故障点的次数。以下为三种方案的详细对比分析：1、 基于ICMP的测试方法：通过对网络中的关键节点进行时延测试，来判断故障点。图4-9 ICMP测试方案示意图 制图人：王瑞斌

21、制图时间：09年3月2、 基于SNMP的网管监测方法：利用网管系统，对网络中的关键节点进行流量监控，通过分析网络流量的方法，来定位出故障点所在：图4-10 SNMP测试方案示意图 制图人：王瑞斌 制图时间：09年3月3、 基于规则判定的互联互通故障定位：通过一组算法，运用多种测试工具来组合定位故障。首先测试网站能否解析，判断DNS是否有问题；接着利用ICMP协议测试故障节点；最后利用端口扫描的办法，确定是否端口被限制。图4-11：自动关联定位方法示意图 制图人：王瑞斌 制图时间：09年3月利用服务器下发应用连接任务，通过收集连接过程中每个步骤的运行情况，与内置的判定条件进行比对，触发故障判定动

22、作，并根据动作的结果进行故障定位（三）方案选择：1、模拟测试为确定方案，QC小组模拟了故障环境，并将三种方法置入4种模拟环境中分别进行25次测试。测试、时间、人员和地点（50次）图4-12： 模拟试验现场 制图人：王瑞斌 制图时间：09年3月测试结果如下：方案名称测试环境测试结果路由限制端口限制设备、服务器故障流量限制定位成功次数定位平均时间（分钟）定位成功次数定位平均时间（分钟）定位成功次数定位平均时间（分钟）定位成功次数定位平均时间（分钟）定位成功次数定位平均时间（分钟）基于ICMP的自动循环测试方法254.91416.7255.2167.9808.675基于网络设备SNMP的网管监测方法

23、257.32314.6252184.2917.025基于规则判定的互联互通故障定位方法254.9255.3255.2245.1995.1252、测试结论 小组成员在定位能力测试的基础上，综合考虑了研发难度和研发可行性，一致认为虽然“基于规则判定的互联互通故障定位方法“研发难度较高，但是定位能力较强，后续又可以通过规则库的扩展提升能力，因此将互联互通故障定位的方案选定为”基于规则判定的互联互通故障定位方法”。图4-13第二部分的最优方案选择制图人：王瑞斌制图时间：2009年3月三、整体实现方法研究：（一）可行性方案分析：小组成员再一次利用脑力风暴，针对如何实现自动化故障监测和故障定位的问题是展开

24、讨论，基于日常工作实际要求，总结了四个可以实现互联互通故障定位的新方法： 图4-14第二部分的最优方案选择制图人：吴韦力制图时间：2009年3月1、 基于B/S架构的应用系统即Browser/Server架构，这种方式只需要IE浏览器即可模拟一个用户进行故障监测及定位，测试人员无需安装任何软件。图4-15B/S架构示意图 制图人：吴韦力制图时间：2009年3月2、 基于C/S架构的应用系统即Client/Server架构，这种方式需要测试人员在测试终端上安装客户端软件，客户端将测试数据搜集归纳至服务端。图4-16C/S架构示意图 制图人：吴韦力制图时间：2009年3月3、 基于手持仪器仪表的方

25、式通过与仪器仪表厂商合作，将故障监测及定位的方法制订成手持设备的操作系统。图4-17手持仪器表 制图人：吴韦力制图时间：2009年3月4、 基于设备自动化脚本的实现方法利用脚本的方法，登录网络设备进行测试，无法研发新的系统。（二）方案评价：QC小组针以系统的易用性、扩展性、经济性以及厂家支持四个方面入手，制定了三个等级的评估标准，以此来对四套方案进行综合评估：评估项目（9-10分）（6-8分）（1-5分）易用性简单易用一般使用较困难扩展性系统后期扩展性强提供基本的扩展扩展困难经济性投入较少投入一般投入较多厂家支持自主研发部分依赖厂家完全依赖厂家表4-5方案评估标准制表人：吴韦力制表时间：200

26、9年3月方案评估见下表：方案名称方案描述优缺点项目评估得分综合得分可行性分析B/S架构研发基于浏览器/服务器架构的系统，用以实现互联互通的监测及故障定位l 优点：1、 有浏览器的终端均可开始互联互通测试及定位；2、 图表功能较齐全；3、 扩展性高，可与其它系统对接l 缺点：需要投入较多开发力量易用性1033可行扩展性10经济性6厂家支持7C/S架构研发基于客户端/服务器架构的系统，用以实现互联互通的监测及故障定位l 优点：1、 图表功能强大；2、 使用起来相对简单l 缺点：1、 终端需要安装软件，不利于引导用户；2、 客户端软件开发需要较大的费用投入易用性724不可行扩展性6经济性5厂家支持6

27、仪器仪表将故障定位方法固化至仪器仪表系统l 优点：方便维护人员上门处理故障；l 缺点：1、 定制的系统，几乎无法进行扩展性；2、 自动监测功能较差，一般用于故障定位；3、 仪器仪表无法自行生产，依赖厂家的系统开发易用性518不可行扩展性3经济性6厂家支持4自动化脚本将故障定位方法编制成脚本，并配合服务器及相关网络设备自动化运行l 优点：1、 无法额外的费用投入，经济性高；2、 无需厂家支持；l 缺点：1、 脚本编制效率较低，且不利于扩展；2、 无图表功能易用性426不可行扩展性3经济性10厂家支持9表4-6第三部分方案可行性分析制表人：吴韦力制表时间：2009年3月（三）评价结论：由下表可以发

28、现，B/S架构的实现方法的可行性最高，因此我们选择B/S架构作为实现互联互通故障定位的实现平台：图4-18第三部分最优方案选择制图人：吴韦力制图时间：2009年3月4.3最佳方案确定：综上所述，我们已经明确了研发互联互通故障定位新方法的具体实施细节：图4-19整体最佳解决方案树图制图人：洪昭明制图时间：2009年3月5对策制定5.1制定对策表按照”5W1H”，小组设计制定了如下对策表：步骤对策目标措施负责人地点时间1按网络协议连接时长的基准值设置互联互通故障告警参数故障检出率达到90%以上1、 根据协议分析原理，对部分应用的连接时间进行详细分析；2、 利用特定算法，计算出不同互联网应用类型每个

29、时间段的监测告警门限值；3、 定时采集网络应用协议连接时长并与告警门限值进行比对，根据比对结果发出告警洪昭明泉州圣湖六楼机房2009年4月2基于规则判定的互联互通故障定位的关联测试方法研究研发出故障定位的规则引擎1、 采集历史故障告警数据，对告警数据进行训练，形成故障定位的规则库2、 利用告警规则库研发出故障定位规则引擎；王瑞斌泉州圣湖六楼机房2009年5月3基于B/S架构故障自动定位系统开发融合自动监测以及故障定位B/S系统1、将两种实现方法模块化；2、用户自服务功能设计；3、其它接口开发吴韦力泉州旧办公大楼四楼2009年7月表 2：对策表制表人：洪昭明 制表时间：2009年4月6对策实施小

30、组成员使用了PDPC法提供研发过程中不可预料问题的解决方案，有效的降低研发过程中遇到的风险，确定了对策实施的关键路线，即图6-1的A0-A1-A2-A3-A4-A5：图6-1：对策实施图制图人：王东龙 制图时间：2009年4月6.1对策实施一：按网络协议连接时长的基准值设置互联互通故障告警参数【实施措施1】：根据协议分析原理对部分应用的连接时间进行详细分析（一）用户关心的应用协议：QC小组通过调查09年第一季度的用户投诉工单，可以发现，用户投诉最多的前三种应用分别是：HTTP（92%）、FTP（5%）以及SMTP（1%），总共投诉占比达92%，如图6-2所示：图6-2：第一季度互联网应用投诉占

31、比制图人：洪昭明制图时间：09年5月基于上图的分析，我们认为HTTP协议是主要的网络应用和投诉来源，如果可以解决HTTP协议的故障检测，就可以达到我们缩短故障定位时间、提高故障定位率、覆盖90%投诉比的目标。（二）HTTP协议分析：1、客户端向DNS服务器发送DNS查询请求WEB服务器的IP地址，DNS服务器返回查询结果。这段时间为DNS查询时间。2、客户端获得WEB服务器IP地址后，向该WEB服务器发送TCP SYN包，要求建立连接；WEB服务器做出应答，完成三次握手，连接建立。这段时间为建立连接时间。3、客户端向WEB服务器发送GET请求，在收到服务器的ACK后，开始下载页面。这段时间为首

32、字节传输时间。4、客户端从收到第一个字节到接收完整的HTML文件的时间为页面下载时间，页面的大小为传输字节数，吞吐量等于传输字节数和下载时间的比值。由此，我们可以将HTTP连接时间分解为：DNS查询时间、连接建立时间以及传输总时间三个部分：图6-3HTTP协议连接时间分析图2制图人：王瑞斌制图时间：09年5月由此可见，QC小组在对策一中基于协议分析方法实现了对HTTP的故障自动监测，解决92%应用程序监测，达成我们设定的覆盖90%投诉比的目标！ 【实施措施2】：计算出不同互联网应用类型每个时间段的监测告警门限值QC小组定义了一种门限基准值测试方法，用来分析每个小时的网络情况，我们将这种方法称为

33、95%法则，以下以对泉州网的测试为例进行说明：1、 基于HTTP协议分析方法，开启不间断的HTTP自动监测任务，每5分钟记录一次访问该网站的最高连接时间；2、 去除一天内5%的最高时延，避免突发情况发生；3、 记录每个小时的最高时延，由此可以组成一条最高时延的曲线图：4、 将告警门限值设置为每小时最大连接时间的120%，图6-4的连接时间趋势图制图人：洪昭明制图时间：09年5月经过这样测算，每个小时将设置针对泉州网这个网站设置一个门限值，经过一周的数据采样，我们得出，泉州网该网站一周内的告警门限值：4月5日4月6日4月7日4月8日4月9日4月10日4月11日23:00 - 24:0010914

34、 10875 10889 11048 10889 10874 11198 22:00 - 23:0017508 17574 17914 17727 17939 17962 17603 21:00 - 22:0017508 17199 17622 17537 17582 18024 17456 20:00 - 21:0017508 17727 17747 17650 17494 17307 17696 19:00 - 20:008484 8498 8710 8339 8550 8497 8555 18:00 - 19:002628 2664 2701 2694 2661 2579 2647 17

35、:00 - 18:006828 6868 6854 6970 6872 6881 6910 16:00 - 17:007482 7425 7700 7593 7410 7628 7706 15:00 - 16:005766 5757 5694 5690 5860 5688 5849 14:00 - 15:006246 6296 6423 6362 6336 6258 6334 13:00 - 14:003654 3679 3619 3741 3598 3732 3737 12:00 - 13:002484 2516 2549 2536 2442 2527 2533 11:00 - 12:004

36、224 4172 4214 4252 4289 4233 4264 10:00 - 11:004662 4647 4603 4671 4771 4695 4661 9:00 - 10:0023042288 2352 2345 2355 2295 2288 8:00 - 9:002742 2730 2751 2801 2781 2710 2800 7:00 - 8:002682 2683 2660 2637 2668 2724 2724 6:00 - 7:004452 4429 4536 4464 4398 4580 4436 5:00 - 6:004350 4308 4407 4301 441

37、5 4266 4355 4:00 - 5:002436 2449 2396 2479 2509 2396 2463 3:00 - 4:002244 2279 2215 2286 2229 2228 2284 2:00 - 3:002604 2554 2614 2632 2664 2673 2644 1:00 - 2:002292 2298 2267 2318 2279 2265 2275 0:00 - 1:002520 2480 2569 2526 2548 2536 2532 表6-2的告警门限值制表人：洪昭明制表时间：09年5月【效果检查】：设置完每个时间段的告警门限后，QC小组马上将自动

38、监测系统开启应用，一旦网站连接时间超过门限值，将触发告警系统。据统计，4月份启用自动监测系统后，故障预警次数达到360次，而用户申告的故障有69次已经被提前预知，即检出率达到了93.24%，达到了对策设定的目标！周统计自动监测系统预警次数用户申告次数检出率次数检出率1231515100.00%97252392.00%56131292.31%84211990.48%4月份总计360746993.24%对策二的目标达成了！表6-3对策2的效果检查表制表人：洪昭明制表时间：09年5月6.2对策实施二：基于规则判定的互联互通故障定位的关联测试方法研究【实施措施1】：故障定位规则库：通过对09年以来的互

39、联互通告警数据进行分析，我们得出了一组告警数据，通过对告警数据进行数据训练，得出了基于故障定位的规则库：图6-5 故障定位规则库举例制图人：王瑞斌制图时间：09年5月【实施措施2】：根据故障定位研发出故障定位规则引擎：根据故障定位规则库，我们研发了故障定位的规则引擎：图6-6 故障定位规则库规则引擎流程图 制图人：王瑞斌制图时间：09年5月【效果检查】：QC小组于6月份成功整理出历史告警信息的故障定位规则引擎，并成功将规则引擎固化至自动监测系统，一旦出现告警将会自动关联至故障定位引擎：图6-7 互联网协议连接时间监测图制图人：王瑞斌制图时间：09年5月对策二的目标达成了！6.3对策实施三：自动

40、化的B/S架构系统研究QC小组通过对策实施箭条图对B/S架构研究的各步骤进行管理和控制，同时根据三点估计法（乐观估计时间（a）/悲观估计时间（b）/正常估计时间（m）/经验估计作业时间（a+4m+b/6）计算各个工序的经验估计作业时间以及总里头，确定关键路线：0-1-2-6-8-10（红色路径），预计在关键路线上实施总时间为121天。图6-8系统研发实施箭条图 制图人：王东龙制图时间：09年5月根据需求统计，我们将整个B/S架构的系统，分成测试层、综合管理层、和其他系统的北向接口三大层次。详细的系统架构如下图所示：图6-9互联互通故障定位系统的系统结构图 制图人：王东龙制图时间：09年5月(A

41、)测试层：通过测量Agent、测试管理程序等制订、执行测试任务，实现对互联互通电路的实时测试；测试层还完成所有测试任务的统一调度；图6-10测试层架构图制图人：王东龙制图时间：09年5月图6-11自动监测任务图制图人：王东龙制图时间：09年5月图6-12自动测试AGENT界面制图人：王东龙制图时间：09年5月（B）综合管理层l 对测量获得的数据进行处理，获得最终的测量结果，并生成测试报表；l 提供测试数据的呈现界面；l 对测试测量结果进行存储管理；l 提供北向数据接口；l 提供告警前转；图6-13综合管理层界面展示制图人：吴韦力制图时间：09年6月（C）其他系统的北向接口l 提供告警数据、性能

42、数据和报表数据；l 提供互联网IP 地址运营商归属查询数据；l 提供告警前转；图6-14综合管理层界面展示制图人：吴韦力制图时间：09年6月【效果检查】：通过对各项功能模块的开发，互联互通故障监测及定位系统实现了以下功能：l 实现了故障自动发现功能l 实现故障自动定位功能；l 实现了用户自测试功能；对策三的目标达成了！l 实现了与其它系统的对接；7效果检查7.1目标实施效果检验1）互联互通故障定位历时表 7-1：互联互通故障定位历时情况统计表 制表人：王东龙 制表时间：2010年1月通过本次QC活动，互联互通故障定位历时幅度下降明显,小组对2009年8-9月泉州地区互联网用户投诉情况进行了跟踪

43、分析，平均互联互通定位历时下降到5.3分钟，完全达到了并超过了我们当初设定的预期目标。巩固期平均故障定位历时为5.47分钟。目标顺利达成了！2）网宽带客户投诉情况为验证QC活动效果，小组成员检查了宽带业务发展情况与投诉情况的关系，发现自从09年4月份开始进行各种故障检测和定位以来，宽带业务的投诉量逐步下降，活动达到了预期的目标！ 图 7-3：宽带业务发展与投诉情况对比 制图人：洪昭明 制图时间：2009年12月7.2效益分析一、 社会效益通过本次活动，小组较好地解决了如何减少互联网互联互通故障投诉以及快速排障的问题，社会效益显著,主要体现在以下几方面:1、 提升移动宽带业务服务质量,提高用户满意度实现网络质量及各种业务的自动拨测及定位，有利于及时发现故障，提升处理效率，避免以往用户投诉先于故障告警的不良局面;2、提供了互联互通技术监测手段，净化互联网竞争环境目前，基于该方法所建立的互联网服务质量监控平台已推荐通信管理局进行测试，可解决以往监测手段缺乏的问题，规范互联网互联互通保障行为；3、提高工作效率，节约