互联网业务故障投诉系统的设计与实现

 随着互联网业务大范围的普及，由于访问量过高、黑客攻击等原因使得纷繁复杂的网络故障频繁发生，用户投诉量高居不下。运营商由于缺乏有效的投诉管理机制，导致用户投诉的故障信息杂乱、不完整；维护人员消极怠工，责任划分不明确；网络结构复杂，设备众多，定位故障源难度加大。最终导致投诉处理不及时，客户体验度大大降低。
本文根据课题研究背景及国内外发展现状，结合运维管理部门的需求，基于B/S架构，设计开发了一个投诉流程清晰、功能完善的互联网业务故障投诉系统。投诉系统主要由Web平台、后台逻辑控制模块、数据库服务器三个部分组成。本文主要工作内容如下。
首先，针对处理投诉效率低的问题，本文对故障投诉的流程、功能进行优化，配合多个功能模块，使投诉处理过程成为闭环：
1. 设计工单管理模块对投诉故障信息进行分类采集，支持多种附件（文字、图片、抓包文件）上传，完成案例收集、工单处理、结果反馈等工作；
2. 设计告警管理模块对工单处理的时效性进行约束，检测未及时处理的故障工单，并对相关工作人员发送短信、邮件进行告警提示；
3. 设计报表管理模块生成多维度（故障区域、故障类型等）统计报表，便于运营商对员工工作绩效及设备商服务质量进行考评；
4. 设计系统管理模块方便管理员对用户信息及系统数据进行管理。
其次，针对网络故障源定位过程繁琐的问题，本文设计了故障定位模块辅助工作人员完成故障源的预定位。本文在当前运营商定位、处理网络故障流程的基础上，学习网络爬虫、网络监听、域名解析等关键技术，将其结合自动完成故障预处理并收集相关故障信息。通过对相关算法研究，选择基于案例推理的网络故障定位算法进行故障定位。在案例检索过程中，本文将加权KNN算法与系统相结合，在案例库中搜索出与新故障最相似的历史案例，给出解决建议。
最后，本文设计测试方案对系统进行功能和性能测试。测试结果表明，系统基本达到预期目标，能够稳定运行。但是由于网络故障种类繁多，故障定位的难度较大，其准确率还有待改善。

关键词：故障投诉系统，Web平台，告警模块，故障定位

Abstract
With the widespread popularity of Internet services, due to high traffic, hacker attacks and other reasons, complex network failures occur frequently, and the number of users’ complaints remains high. Because of the lack of an effective complaint management mechanism by operators, the failure information of users' complaints are cluttered and incomplete. The operator's maintenance personnel are passively absent, and the division of responsibilities are not clear. Due to the complex network structure and numerous equipments, there are more difficult to locate fault sources. Eventually the complaints were not handled in a timely manner and the customer’s experience was greatly reduced.
According to the research background and the development status at home and abroad, combined with the needs of operation and maintenance management department, based on the B/S architecture, thesis designs and develops an Internet business complaint system with clear complaint process and complete functions. The complaint system is mainly composed of three parts: Web platform, background logic control module and database server. The main work of thesis is as follows.
First of all, in order to solve the problem of low efficiency in dealing with complaints, thesis optimizes the process and function of fault complaints, combines multiple functional modules to make the complaint handling process closed.
1. Design work order management module to classify and collect fault information, support multiple attachments upload (text, pictures, capture files), complete case collection, work order processing, result feedback and so on.
2. Design alarm management module to constrain timeliness of work order processing. It detects the fault tickets which are not processed in time, send short messages and e-mails to alerts the relevant staff.
3. Design report management module to generate multi-dimensional (fault area, fault type, etc) statistical reports so that operators can evaluate employee performance and equipment vendor service quality.
4. Design system management module, it is convenient for administrators to manage users’ information and system data.
Secondly, aiming at the difficulty of locating the fault source of the network, thesis designs an automatic fault location module to assist the staff to complete the pre-positioning of the fault source. Based on the current process of locating and dealing with network failures by operators, thesis studies key technologies such as web crawlers, network monitoring, domain name system and so on, combines them to automatically complete fault preprocessing and collect relevant fault information. Through the research of related algorithm, thesis chooses case-based reasoning network fault location algorithm to locate the fault. In the case retrieval process, thesis combines the weighted KNN algorithm with the system to search out the historical case which is most similar to the new fault in the case base, and outputs solution advice.
Finally, thesis designs the test program to test the function and performance of the system. The test results show that the system basically meets the expected goals and can operate stably. However, due to the wide variety of network failures, it is difficult to locate faults, and it still needs to be improved.

Keywords: fault complaint system, Web platform, alarm module, fault location

目录
图录 IX
表录 XIII
注释表 XV
第1章 绪论 1
1.1 互联网业务故障投诉系统的研究背景与意义 1
1.2 互联网投诉系统国内外研究现状 1
1.2.1 国内外研究现状 2
1.2.2 当前存在的主要问题 2
1.3 研究内容 3
1.3.1 本课题拟解决的关键问题 3
1.3.2 本文的主要研究内容 4
1.4 论文章节安排 5
第2章 系统需求分析 7
2.1 系统整体需求 7
2.1.1 系统整体需求分析 7
2.1.2 系统体系结构 8
2.2 各功能模块需求分析 11
2.2.1 工单管理模块需求分析 11
2.2.2 报表管理模块需求分析 12
2.2.3 系统管理模块需求分析 13
2.2.4 系统告警模块需求分析 13
2.2.5 故障源定位模块需求分析 14
2.3 系统性能指标分析 14
2.4 开发工具选择 15
2.4.1 开发语言选择 15
2.4.2 数据库选择 16
2.5 本章小结 16
第3章 故障定位关键技术及算法研究 17
3.1 网络故障定位技术 17
3.1.1 基于规则推理的网络故障定位方法 17
3.1.2 基于密码本关联模型的网络故障定位方法 18
3.1.3 基于案例推理的网络故障定位方法 20
3.2 案例推理算法研究 21
3.2.1 案例检索算法比较 21
3.2.2 加权KNN算法 23
3.2.3 属性指标权重确定 26
3.3 本章小结 29
第4章 系统设计与实现 31
4.1 系统整体设计 31
4.1.1 系统整体框架设计 31
4.1.2 系统业务流程设计 32
4.2 数据库及接口文档设计 34
4.2.1 数据库设计 34
4.2.2 接口文档设计 38
4.3 Web平台子模块设计 39
4.3.1 工单管理模块 39
4.3.2 告警查询模块 44
4.3.3 报表查询模块 44
4.3.4 参数配置模块及日志管理模块 46
4.3.5 系统管理模块 48
4.4 系统告警模块设计 50
4.4.1 告警模块主体设计 50
4.4.2 告警详细流程设计 52
4.5 故障源定位模块设计 55
4.5.1 网页类故障信息收集 56
4.5.2 软件类故障信息收集 59
4.5.3 故障案例匹配设计 62
4.6 本章小结 66
第5章 软件测试与结果分析 67
5.1 测试方案分析与选择 67
5.1.1 测试方法选择 67
5.1.2 测试流程设计 68
5.1.3 测试内容 68
5.2 测试环境搭建 69
5.3 测试内容及结果分析 70
5.3.1 互联网故障投诉平台测试 70
5.3.2 告警模块测试 93
5.3.3 故障源定位模块测试 97
5.4 本章小结 101
第6章 总结与展望 103
6.1 全文总结 103
6.2 展望 104
参考文献 105
致谢 109
攻读硕士学位期间从事的科研工作及取得的成果 111

图录
图2. 1 互联网故障原因 7
图2. 2 B/S体系架构 9
图2. 3 C/S体系架构 9
图2. 4 互联网业务故障投诉系统总体结构 10
图2. 5 MVC模式框架 11
图3. 1 基于规则推理的故障定位系统结构图………………………………………17
图3. 2 故障因果关系图示例 19
图3. 3 标注过的故障因果关系图 19
图3. 4 根据图3.3生成的密码本 19
图3. 5 基于案例推理的故障定位系统结构图 20
图3. 6 KNN样本分布 24
图3. 7 gaussian函数衰减趋势 25
图3. 8 KNN及加权KNN准确率变化 25
图4. 1 系统模块框架…………………………………………………………………31
图4. 2 投诉业务流程 33
图4. 3 工单状态转移图 34
图4. 4 数据库E-R图 35
图4. 5 登录接口文档 39
图4. 6 贵州省行政区域图 41
图4. 7 用户权限图 42
图4. 8 生成报表流程图 46
图4. 9 配置DNS与出口信息流程 47
图4. 10 批量导入代码示例 48
图4. 11 角色信息图 49
图4. 12 新建用户流程 49
图4. 13 告警模块结构 50
图4. 14 告警主体流程 51
图4. 15 初次告警判断流程 53
图4. 16 重复告警判断流程 54
图4. 17 网页类故障源定位流程 56
图4. 18 URL保存示意图 58
图4. 19 软件类故障定位流程 60
图4. 20 监听程序实现步骤 61
图4. 21 故障案例匹配流程 65
图5. 1 测试环境网络拓扑结构………………………………………………………69
图5. 2 系统实验室内部测试平台 70
图5. 3 用户登录测试 71
图5. 4 用户登录后查看权限 73
图5. 5 用户新建工单 74
图5. 6 用户撤回工单 74
图5. 7 用户修改工单 75
图5. 8 用户接单 76
图5. 9 用户退回工单 77
图5. 10 用户处理工单 77
图5. 11 管理员删除工单 78
图5. 12 用户导出工单 78
图5. 13 用户查看告警信息权限 80
图5. 14 类型统计报表 82
图5. 15 区域统计报表 83
图5. 16 网络环境统计报表 84
图5. 17 游戏类型统计报表 84
图5. 18 工单超时率统计报表 85
图5. 19 退回工单统计报表 85
图5. 20 IP质量统计报表 86
图5. 21 DNS与出口信息配置 88
图5. 22 系统日志管理 89
图5. 23 系统管理 91
图5. 24 ab测试结果 92
图5. 25 告警模块测试 95
图5. 26 测试工具添加工单 96
图5. 27 告警轮询计时 96
图5. 28 告警模块CPU占用率 97
图5. 29 网页类故障源定位 98
图5. 30 游戏无法登陆 99
图5. 31 软件类故障源定位 100
图5. 32 案例匹配测试 100

表录
表2. 1 常用数据库比较 16
表3. 1 数据集信息 26
表3. 2 算法匹配平均准确率 26
表4. 1 数据库表格信息 36
表4. 2 各角色操作权限表结构 36
表4. 3 地区信息表结构 37
表4. 4 行政区域与用户组缩写对应表 41
表4. 5 故障信息权重专家评定结果表 62
表4. 6 用户投诉信息权重专家评定结果表 63
表4. 7 预处理信息权重专家评定结果表 63
表5. 1 系统测试流程 68
表5. 2 系统测试内容 68
表5. 3 系统软硬件环境 70
表5. 4 用户登录测试用例 71
表5. 5 用户登录查看权限测试用例 72
表5. 6 工单投诉流程测试用例 73
表5. 7 用户查看告警信息权限测试用例 79
表5. 8 类型统计报表测试用例 80
表5. 9 DNS与出口信息配置测试用例 86
表5. 10 系统管理测试用例 89
表5. 11 不同并发连接数测试结果 92
表5. 12 告警信息产生测试用例 93

注释表
BSI 英国标准协会
B/S Browser/Server，浏览器/服务器模式
C/S Client/Server，客户端/服务器模式
MVC Model View Controller，模型视图控制器模式
URL Uniform Resource Locator，统一资源定位符
RBR Role-Based Reasoning，基于规则推理
CCR Codebook Correlation Model，基于密码本关联模型
CBR Case-Based Reasoning，基于案例推理
KNN K-Nearest Neighbor，K最邻近
UCI数据集 加州大学欧文分校提出的用于机器学习的数据库
E-R Entity Relationship Diagram，实体关系图
PID Process Identification，进程识别号

第1章 绪论
1.1 互联网业务故障投诉系统的研究背景与意义
近年来，互联网技术飞速进步，促进了互联网业务的发展。自电信重组之后，全国形成了三家具备全业务运营资质的综合性电信运营商[1]。为了争取到更多的市场份额，确立客户信心，各个运营商均提出了提高服务质量，重视客户感知的服务理念。而用户投诉又是企业服务工作的重中之重，如何高效、快速地解决用户投诉，提高用户满意度，成为各个运营商客户服务工作中的重中之重[2]。
互联网业务的快速发展为用户带来极大的便捷，但是由于黑客攻击、访问量快速增长等原因经常会引起网络故障，导致用户投诉量增多。网络投诉种类繁多，相关处理人员无法获得详细的故障信息，这使得工作人员在处理故障时会有很大的阻碍。另外，实际处理客户投诉时会涉及多个部门，处理环节复杂，造成投诉处理任务繁重，效率较低，无法满足时效性要求。
在处理互联网业务故障的过程中，处理故障的工作人员主要靠人工对相关故障进行故障源定位，需要对相关抓包文件逐个、逐步进行分析。这样使得工作人员工作量增大，处理过程繁琐，工作效率低，而且人工处理对故障源定位不够准确。在故障定位的过程中消耗大量时间，不能够第一时间对故障进行有效的处理，降低了用户满意度。
基于以上情况，本文拟设计一个供运营商内部使用的互联网业务故障投诉系统，设计较为合理的业务处理流程以及相应的告警模块、故障源定位模块，将网络监听技术、路由追踪技术、Web技术、移动互联网技术等结合，满足运营商高效处理用户投诉的需求，提升用户满意度。
1.2 互联网投诉系统国内外研究现状
本文研究的互联网业务故障投诉系统来源于校企合作项目“互联网业务故障投诉平台”，考虑到该项目管理方式和应用场景，本文依托投诉系统研究互联网业务故障投诉系统的发展现状。
1.2.1 国内外研究现状
进行投诉系统开发时，最重要的就是分析用户投诉的需求。国内外许多企业都十分重视对客户投诉的处理，以此增加客户对企业的认同感、提升客户满意度[3]。但是很多企业对无法妥善处理服务上的失误所造成的影响却不甚了解。因而，许多客户并不满意他们之前的投诉经历。
为了解决这一问题，从上世纪 90 年代开始，许多服务业很发达的国家都相继制定了客户投诉管理标准。其中比较具有代表性的有：澳大利亚的 AS 4269：1995 投诉处置标准；英国的 CMSAS 86：2000 投诉管理体系规范；日本的 JIS Z992：2000 投诉指南等。其中比较通用的标准是英国标准协会（BSI）制定的标准。2004 年，国际标准化组织（ISO）为了使投诉系统在国际上有一个通用的标准，制定了建立在 ISO 9001：2000 基础上的 ISO 10002：2004 质量管理-顾客满意-组织投诉处置指南（参见文献[4]、[5]、[6]）。
文献[7]指出，对于投诉网站而言，其性能的评价标准主要由以下几个方面组成：
（1）网络下载速度；
（2）时效性：粗略模糊保证，承诺解决的时效；
（3）介绍性：对相关功能有介绍性文字描述；
（4）可得性：明确设置各项投诉功能，页面各链接均有效；
（5）清晰性：页面、功能设置清晰。
与国外的投诉网站相比，我国投诉网站的设计在时效性、可得性与清晰性上还存在较大的差距[8]。
在进行投诉处理平台的开发与设计时，并不仅仅要求它能够完成处理投诉的基本功能，还要求它能够生成相关报表，方便统计投诉信息以改善服务质量。另外，投诉平台还应保证能够快速处理客户投诉，为其提供反馈信息。
1.2.2 当前存在的主要问题
针对高效的互联网投诉系统，一方面要求系统能够尽可能全面地传递现场处理详细信息，方便相关处理人员分析、解决故障；另一方面要有相应的告警系统，及时通知相关处理人员解决投诉故障。目前市场上的互联网故障投诉处理系统主要存在以下问题：
（1）投诉处理方式效率低，故障信息投递不完整。目前运营商处理互联网投诉的流程一般为 ：两级处理机制，地市级分公司接收到用户的投诉后先进行预处理，对互联网业务故障进行初步分析并采集相关故障信息。对于无法解决的问题通过邮件、电话等方式将相关故障信息传递给省公司，交由省公司进行处理。针对这种投诉处理方式，分公司可能对相关故障信息记录错误或不完整，导致相关故障处理不合理。
（2）投诉管理混乱，信息杂乱不易统计。目前的互联网故障投诉流程管理开环且混乱，导致处理不及时的情况时有发生，客户体验度大大降低。对故障进行投诉、处理、备案等整个过程全部都靠人工完成，效率较低、易出错。缺少对故障统计的多维度分析报表，很难统计各地州市的故障情况，不便于绩效考核，不便于对当前设备服务商进行指标考核。
（3）处理投诉的时效性难以保证。当用户产生故障投诉时，分公司将无法解决的故障信息传递给省公司进行处理，但是由于投诉量较大，省公司相关处理人员不能及时获悉投诉情况，或者省公司员工对故障处理进度较慢，进而导致无法在规定时限内有效地解决投诉故障。
（4）故障定位过程繁琐。目前针对互联网资源类故障，省公司员工主要先通过HttpWatch网络抓包文件（网页类故障）或Wireshark抓包文件（软件类、游戏类等故障）进行人工分析判断出故障服务器的源IP地址，然后通过分析相关Tracert截图找出路由路径所走出口IP地址，最后将所走出口与地址池进行比对得到相应的归属厂家。整个故障定位的过程全部都靠人工经验来完成，工作繁琐，效率比较低，而且对故障的定位存在一定误差。
1.3 研究内容
1.3.1 本课题拟解决的关键问题
1. 设计封闭的管理流程
对现有的互联网业务故障投诉流程进行分析，全面考虑投诉中可能存在的情况，对投诉流程进行优化，设计合理、完整、封闭的投诉管理流程。
2. 设计多维度报表管理模块
当前互联网业务故障投诉系统缺少对故障统计的多维度分析报表，很难统计各地市的故障情况，不便于绩效考核，也不便于对各设备服务厂商进行指标考核。设计多维度报表管理模块，可根据投诉类型、投诉地区等条件查询、统计生成相关报表，可选择生成年度报表、日报表或自定义时间报表。用于评估处理人员效率、对故障多发地区或服务厂家进行分析。
3. 告警的实时管理
分公司员工投递投诉信息后，省公司员工未及时处理的情况时有发生。在投诉处理的关键节点设计告警模块，结合合理的告警管理方法对未及时处理信息进行管理，投诉工单超过对应的告警时阀即产生告警，提醒省公司相关工作人员及时处理投诉故障，保证投诉处理故障的高效性。
4. 自动化的故障源辅助定位
当前对互联网业务故障分析定位故障源的过程比较繁琐、耗时。本文拟设计故障源定位模块，自动定位出网络故障的故障源。故障源定位模块可分别针对网页类故障和软件类故障准确定位出故障源。
1.3.2 本文的主要研究内容
本课题主要完成互联网业务故障投诉系统的设计和实现。结合项目需求及设计和实现中所预见的重难点，本文有以下五项主要研究内容：
1. 分析市场需求，进行整体架构设计
根据国内外投诉系统的结构和工作原理，结合运营商内部的实际需求，研究分析运营商解决互联网业务故障投诉的主要工作流程及系统应实现的主要功能，完成系统的框架设计。
2. 根据整体架构，进行子系统设计
根据系统整体架构，互联网业务故障投诉平台为整个系统的重点，按功能主要分为工单管理子模块、告警查询子模块、报表查询子模块和系统管理子模块四个部分。其中工单管理子模块主要完成故障信息收集、投递、处理、反馈等功能；告警查询子模块主要完成对未及时处理而产生告警的工单进行查看、处理；报表查询子系统主要根据相关筛选条件生成统计报表；系统管理子模块主要是管理员对角色权限信息、用户个人信息、系统参数等内容进行配置。
3. 后台告警模块设计
根据故障投诉的处理流程，在处理环节中的多个关键节点设计告警模块，设计合理的告警管理方法。当存在故障工单未被及时处理时，告警模块自动轮询检测超时工单，将告警信息添加至数据库，并向相关省公司员工发送短信、邮件进行告警提示。
4. 故障源定位模块设计
学习网络监听、网络爬虫、DNS域名解析、路由跟踪等网络故障定位需要应用到的关键技术，研究当前网络故障源定位的常用算法，将定位算法与关键技术相结合，设计并实现故障源定位模块。
5. 系统的功能性测试和性能测试
设计测试用例，搭建系统测试环境，对互联网业务故障投诉系统各模块的功能和性能进行专项测试。
1.4 论文章节安排
本篇论文分为六个章节，各个章节的主要内容如下：
第一章：分析互联网业务故障投诉系统的背景与意义，结合国内外投诉系统的研究现状，介绍本文的研究重点及主要工作内容。
第二章：详细描述互联网业务故障投诉系统的需求分析，包括对系统的主体框架设计以及对各个子模块的功能需求和性能需求进行分析。
第三章：介绍本系统拟采用的关键技术及相关算法，包括对网站开发关键技术、故障定位算法以及故障定位中网络爬虫、网络监听等技术进行介绍。
第四章：介绍本系统的业务流程设计、系统整体框架设计、数据库设计以及接口文档设计，并对系统各功能模块的设计与实现进行详细介绍。
第五章：通过制订测试计划、编写测试用例，对各个功能模块依次进行功能和性能的详细测试。
最后是对本论文的总结和展望。

第2章 系统需求分析
本系统设计投诉网站，辅助工作人员解决用户故障投诉。本章首先分析系统总体需求，并据此设计系统总体框架结构及系统软件框架，然后分析系统各个模块功能及性能需求，最后在此基础上选择合适的开发语言及开发环境。
2.1 系统整体需求
2.1.1 系统整体需求分析
近年来，互联网技术飞速发展，互联网业务越来越普及。随着互联网业务量的增加，互联网各种故障也逐渐暴露出来，主要有以下几种原因：
（1）访问量快速增长。尤其对于新浪、淘宝等大型网站，每日访问量非常大，其次，还存在大量的突发访问，这都对服务器产生了极大的负担。
（2）跨运营商访问。目前国内现状是移动、联通、电信三家运营商三足鼎立，各个网站服务器部署在不同运营商的网络节点上，而当用户进行跨运营商访问时，由于从用户到该服务器所在网络地址之间的路由节点分属于不同的运营商，所以用户访问速度会很慢。
（3）黑客攻击。黑客攻击网站服务器，最严重的情况会使之崩溃，拒绝向用户提供服务，致使用户无法访问该网站。

图2. 1 互联网故障原因

基于以上种种情况，由于网络故障而产生的用户投诉量日益增加，如何高效、快速地解决用户投诉成为各个运营商客户服务工作中的重点问题。然而现在运营商传递故障信息主要是通过电话、邮件等方式进行传递，对故障信息的记录通过人工记录完成，这就使得相关故障信息在传递的过程中会出现差错，处理过程杂乱、繁琐，工作效率低。
因此，本文拟设计一个供运营商内部使用的互联网业务故障投诉系统，结合现实中运营商内部填写、投递故障投诉工单所存在的情况，设计封闭的业务处理流程；为了避免省公司相关工作人员未及时对故障工单进行处理的情况发生，设计超时告警模块督促省公司员工尽快处理故障工单；结合运营商需求，设计报表查询模块，可根据筛选条件生成各类型报表，方便评估处理人员效率、对故障多发地区或服务厂家进行分析；设计故障源定位模块帮助分公司工作人员快速定位互联网故障网络节点及所属负责厂家，提高工作效率。
互联网业务故障投诉系统的主体是故障投诉网站，系统要求其具有良好的性能：
（1）稳定性，系统应采用云服务器作为服务器，保证系统服务器能够在7*24小时正常运行。
（2）并发性，当同时访问网站的用户数达到100时，服务器的平均响应时间应不超过10ms。
2.1.2 系统体系结构
1. 系统开发框架
浏览器/服务器模式（Browser/Server，B/S）的体系架构如图2.2所示。Web浏览器为用户的客户端 [9]， Web服务器对浏览器所提交的数据进行逻辑判断，并与数据库服务器进行数据交互，将响应数据返回给浏览器进行显示。

图2. 2 B/S体系架构

客户端/服务器模式（Client/Server，C/S）是两层架构模式[10]。客户端的主要工作是采集用户数据，并将其传递给后台服务器；服务器对数据进行管理，实现数据间的共享及系统的并发量控制。其体系架构如图2.2所示。

图2. 3 C/S体系架构

在投诉系统中，投诉平台采用B/S架构，方便用户随时都可以登录网站进行操作；而告警模块要求程序能够一直运行，故障源定位模块要求是有可视化界面的桌面应用程序，采用C/S架构更为方便。所以本系统采用B/S架构为主，C/S架构为辅的框架进行开发。
2. 系统总体结构
选择开发框架后，本文对系统的软件结构进行设计，系统总体结构如图2.4所示。

图2. 4 互联网业务故障投诉系统总体结构

本系统的UI界面主要包括故障投诉平台、告警模块和故障源定位模块的UI界面。其中故障投诉平台的UI界面包括登录界面、工单管理界面、告警管理界面等界面，用于验证用户身份信息，完成投诉处理流程；告警模块的界面用于连接本地数据库，完成对数据的访问；故障源定位模块的界面主要用于填写故障预处理信息并显示相关抓包、故障定位信息。
业务逻辑层包括功能管理、数据管理两个部分。功能管理完成各个模块业务逻辑判断；数据管理主要是对界面与数据库之间的交互信息进行解析、封装。
数据服务层对系统数据执行增、删、改、查操作，包括数据库服务器以及文件服务器中的数据。