用QC手法提升故障处理效率：排列图、鱼骨图与控制图实战

简介：一份围绕“提高故障处理效率”的QC课题成果文档，面向通信行业运维人员、QC小组成员及IT运维管理者。内容完整呈现广东X动故障处理运维小组从现状调查、目标设定、原因分析、要因确认到对策制定与实施验证的全过程，重点介绍了针对中间件故障场景，通过编写不同功能执行脚本并接入运维管理平台，实现一键故障诊断、辅助运维人员快速定位问题的思路与做法。资源为1个docx文件，共约604KB，内容结构完整，包含小组概况、名词解释、课题选择、现状调查、目标设定、原因分析、要因确定、对策实施、效果检查及巩固措施等章节，可作为同类QC课题立项、方案设计与成果汇报的参考模板。已有242人学习下载，适合需要撰写QC报告或优化故障处理流程的读者借鉴。

1. 故障处理效率上不去，问题多半不在“处理”而在“派”和“找”

很多团队拿到“提高故障处理效率”这个QC课题，第一反应是让处理环节的人跑得更快、加班更多。但我自己对着工单系统拉过几个月流水后发现，真正吃掉时间的往往不是动手修障那一步，而是工单在派发环节的等待、在定位环节反复登录网管试探。以某省X动的无线故障工单为例，平均每单处理时长85分钟，其中从告警产生到工单派到处理班组就花了约30分钟，定位环节又占掉将近40分钟，真正操作设备的时间不到20分钟。也就是说，想提升效率，不能只盯着排障动作本身，要把“派得准、找得快”当成研究重点。

QC课题的本质就是用质量管理工具把这类模糊问题量化、圈定主要矛盾、制定可验证的对策，再用统计过程控制手段守住成果。这篇文章我会按“指标口径→现状调查→原因分析→对策实施→避坑→成果固化”的顺序，把从立项到落地最常见的完整做法讲清楚。适合做网络运维一线管理、负责QC推进、或者想规范故障流程的从业者，手上有三个月以上的工单流水，照着这篇就能启动。

2. 用排列图圈定主要矛盾：先算清哪几类故障吞掉了80%的处理时长

2.1 先定口径再拉数：两个核心指标的表达式与时间戳来源

故障处理效率不是单一数值，课题启动前必须把口径钉死，不然各团队对同一个“处理时长”会吵出完全不同的结果。我一般把指标拆成两层：第一层是“工单平均处理时长”，从派单时间算到结单时间，反映的是运维流程内部环节的流转效率；第二层是“故障平均历时”，从告警产生时间算到业务恢复时间，反映的是用户可感知的故障影响。前者适合做内部考核，后者适合做课题目标值，缺一不可。

如果给不出权威的时间字段，就先拉取工单系统的操作流水确认每个时间字段的写入逻辑，避免错用“改派时间”当“首次派单时间”，或者把“恢复时间”和“结单时间”混为一谈。口径统一后，建议把取数SQL固化成模板，课题期间每次刷新数据都用同一个脚本，避免Excel手工拼接带来的口径漂移。这一步看起来没有技术含量，但它是后面所有分析的底座，底座歪了，排列图、鱼骨图全都会跟着歪。

2.2 分层统计工单数据，画出故障处理时长的排列图

排列图是QC七大手法里最直接的一招：把故障类型按“总处理时长”降序排列，看哪几类累计贡献超过80%。做法是先取近三个月的已结工单明细，按故障类型分组统计工单数和平均处理时长，再算出每组的总处理时长和累计占比。下面这个示例数据不是某个特定网络的真实统计，用来帮你看清楚组织方式：

画图可以交给Python脚本，一次跑出柱状图加累计占比折线。脚本需要准备一个ticket_stats.csv，里面有fault_type、ticket_count、avg_minutes三个字段，单位是分钟：

import pandas as pd import matplotlib.pyplot as plt from matplotlib.ticker import PercentFormatter df = pd.read_csv("ticket_stats.csv") df["total_minutes"] = df["ticket_count"] * df["avg_minutes"] df = df.sort_values("total_minutes", ascending=False).reset_index(drop=True) df["cum_percent"] = df["total_minutes"].cumsum() / df["total_minutes"].sum() * 100 fig, ax1 = plt.subplots(figsize=(10, 6)) bars = ax1.bar(df["fault_type"], df["total_minutes"], color="#5B9BD5") ax1.set_ylabel("总处理时长（分钟）") ax1.set_xticklabels(df["fault_type"], rotation=30) ax2 = ax1.twinx() ax2.plot(df["fault_type"], df["cum_percent"], "o-", color="#ED7D31") ax2.set_ylabel("累计占比（%）") ax2.yaxis.set_major_formatter(PercentFormatter()) for i, v in enumerate(df["cum_percent"]): if v <= 80: ax2.annotate(f"{v:.1f}%", (i, v), textcoords="offset points", xytext=(0, 10), ha="center") plt.tight_layout() plt.savefig("pareto.png", dpi=150)

这段代码里最关键的是total_minutes和cum_percent两列：前者是“工单数×平均处理时长”，代表该类故障对整体效率的绝对贡献；后者是排完序后的累计百分比，用来圈定“关键少数”。排序之后还要reset_index，否则后面按位置绘图时索引会乱。保存图片用dpi=150，放到课题汇报材料里足够清晰。

数据这一步可以直接写SQL从工单表聚合，字段名按你们系统的实际命名替换：

SELECT fault_type, COUNT(*) AS ticket_count, ROUND(AVG(EXTRACT(EPOCH FROM (close_time - create_time)) / 60.0), 1) AS avg_minutes FROM fault_ticket WHERE create_time >= '2025-01-01' AND create_time < '2025-04-01' AND status IN ('closed', 'resolved') GROUP BY fault_type ORDER BY avg_minutes DESC;

EXTRACT(EPOCH FROM …)返回秒数，除以60转成分钟，ROUND保留一位小数。create_time和close_time分别是首次派单时间和结单时间，status里closed和resolved是已正常关闭的工单状态，如果你们的系统还有别的终态，记得一并加进去，别把“已取消”这种非故障单混入统计。

2.3 排列图的读法与目标值设定：别把改进资源撒胡椒面

累计占比到80%为止的那几类，就是课题要正面进攻的主力。上表里前三类占了74.8%，加上第四类刚到80%出头，意味着改进动作只要覆盖这四类，就能影响绝大多数故障处理时长。排列图读到这里，课题方向就从“提升故障处理效率”收窄成“干掉基站退服、传输中断、板卡异常这三类故障的处理时耗”，汇报时一句话就能讲清资源投入的理由。

目标值不是拍脑袋定的，要能从对策里算出来。我一般按“现状基线－各项对策预估收益”来推导：告警压缩预计减少派单等待10分钟，自动派单规则预计减少错派返工8分钟，定位脚本预计减少定位耗时12分钟。如果主要故障平均处理时长是85分钟，目标值就可以定在55到60分钟，对应35%左右的削减幅度，既激进又不至于不可实现。这样设定目标，评审时别人追问“为什么是这个数”，你手里有对策收益清单，而不是一句“我们觉得能到”。

3. 鱼骨图拆到末端原因，再用要因验证法定“真凶”

3.1 鱼骨图的五个维度怎么拆：把“处理效率低”拆成可核对的末端原因

鱼骨图是QC课题做原因分析的标准动作，但很多人把它画成了“装饰品”：几条箭头一股脑指向问题，每条分支写个词就没有下文了。正确的做法是把“故障处理效率低”作为主干，按人、机、法、料、环五维拆到末端原因，而且末端原因必须能对应到某个具体数据字段或者可观测行为，否则后续没法验证。这个要求直接决定原因分析是真的找根因，还是在做文字游戏。

举例来说，“人”的维度可以拆出值班人员技能差异大、夜班排障经验少；“机”的维度可以拆出网管告警重复上报多、自动派单只判断告警级别、知识库检索慢；“法”的维度可以拆出跨专业转单要经过多次人工审批、故障升级机制不明确、结单审核宽松；“料”的维度可以拆出备件没有前置到区域库房；“环”的维度可以拆出工程施工频繁导致光路闪断、雷雨季节告警密度高。每个末端原因编上号，比如“机-1 告警风暴淹没主故障”“法-3 跨专业转单人工审批长”，后面评审时直接喊编号，不用每个人对同一条原因各说各话。

3.2 要因验证表：每条末端原因必须用数据给出“确认/排除”结论

原因分析最忌讳头脑风暴出什么就信什么。鱼骨图上的每一条末端原因，下一步都要过要因验证：用历史工单做统计分析、查看系统日志、或者做短周期的现场小实验，判定它到底是不是主要影响因素。验证方法我之前在某个模拟项目X里用过一套很实用的模板，每条原因一行，写清验证方法、验证样本和结论，写完之后原因分析部分基本不用反复改。

人-1这种原因在数据上往往不显著，或者样本量不够支撑结论，就该果断排除，不给课题增加一堆不好落地的对策。验证样本量太少的要补，比如某个原因对应的工单不到30张，结论基本没有说服力，宁可拉长统计周期也不能用拍脑袋的“应该是”。

要因验证结果的用途很直接：鱼骨图上十几条原因，最后确认要因可能只有三四条，对策实施阶段只需围绕这几条设计动作。这能避免课题团队最常见的消耗——把资源平均分配到所有原因上，最后哪条都没做透。

4. 对策实施三件套：告警压缩、自动派单、定位脚本

4.1 告警风暴抑制：按“网元+告警类型+时间窗口”压缩重复告警

告警风暴是故障处理效率的第一杀手。同一个网元短时间内重复上报同一类告警，重要告警被淹没在告警海里，派单系统也被大量重复工单拖慢。常见做法是按“网元+告警类型+时间窗口”做压缩：同一窗口内的同类告警只保留前几条触发派单，其余标记为冗余。下面这段代码可以直接在数据处理环节跑：

import pandas as pd raw = pd.read_csv("alarm_raw.csv", parse_dates=["create_time"]) raw["group_key"] = raw["ne_name"] + "|" + raw["alarm_type"] raw = raw.sort_values(["group_key", "create_time"]).reset_index(drop=True) raw["suppress"] = 0 window_min = 5 max_per_window = 10 within = 0 prev_key, prev_time = None, None for idx, row in raw.iterrows(): key = row["group_key"] if row["alarm_level"] in ("严重", "紧急"): prev_key, prev_time = key, row["create_time"] within = 0 continue if key != prev_key: within = 0 elif (row["create_time"] - prev_time).total_seconds() / 60 > window_min: within = 0 within += 1 if within > max_per_window: raw.loc[idx, "suppress"] = 1 prev_key, prev_time = key, row["create_time"] alarm_triggering = raw[raw["suppress"] == 0]

这里window_min和max_per_window是两个关键参数。窗口设得太短，压缩率低，风暴依然会淹没主告警；设得太长，比如超过10分钟，又可能把有先后关联的多个真实故障误当成重复。max_per_window同理，阈值太小会漏掉需要跟进的多节点故障，太大压缩效果不明显。我一般先用历史一周数据多组参数回放，看“压缩率”和“严重告警命中率”两个指标选参数。

这段代码里有几个细节容易踩坑。第一，严重和紧急级别的告警必须跳过压缩，并且要重置within计数器，否则风暴窗口会错误延续到下一个重要告警上。第二，循环里每次都要更新prev_key和prev_time，漏掉continue分支的更新会让下一个窗口的起点错误。第三，压缩不是删数据，suppress标记要留在原表里随时可回溯，alarm_triggering只是拿去触发派单的视图。

4.2 自动派单规则：按影响面把工单分三档，规则写在配置里

派单的目标不是“快”，而是“第一次就派对人”。自动派单经常翻车，原因就是规则只判断告警级别：一个“严重”告警被分到无线班组，处理时才发现是传输光缆问题，工单转派一次就多耗掉几十分钟。我习惯把派单规则收敛成可维护的配置，按影响面分P1/P2/P3三档，每档对应不同响应时限和通知对象。配置文件用YAML写，调整参数不用动代码：

dispatch_rules: - priority: P1 conditions: alarm_level_in: ["严重", "紧急"] impact_scope: ["基站批量退服", "传输环路中断", "核心网元不可用"] target_group: "无线维护班" notify_level: "班长+组长" sla_minutes: 30 - priority: P2 conditions: alarm_level_in: ["严重", "紧急", "重要"] impact_scope: ["单小区退服", "单网元不可用"] target_group: "无线维护班" notify_level: "值班员" sla_minutes: 120 - priority: P3 conditions: alarm_level_in: ["重要", "提示"] impact_scope: ["性能劣化", "软故障"] target_group: "优化班" notify_level: "值班员" sla_minutes: 1440

配置加载和匹配逻辑很短，关键是匹配顺序必须固定，P1写在最前，越紧急的越先命中：

import yaml with open("dispatch_rules.yaml", "r", encoding="utf-8") as f: rules = yaml.safe_load(f) def match_rule(alarm): for rule in rules["dispatch_rules"]: cond = rule["conditions"] if (alarm["alarm_level"] in cond["alarm_level_in"] and alarm["impact_scope"] in cond["impact_scope"]): return rule return None

规则设计上至少要两个字段组合判定，不能只靠告警级别。同一网元同时存在多条告警时，要优先匹配传输类根因告警；两个条件都不能完全命中的，就别自动派，进人工分诊队列。sla_minutes这个字段不一定叫这个名字，按你们考核时限的字段来。规则上线前用历史工单模拟跑一遍，对比差异率，再把差异降到可接受范围再切换。

4.3 故障定位脚本化：把高频故障的排查路径变成可执行的代码

故障定位占处理时长的大头，尤其是经验依赖严重的班组。常见的做法是把排列图排在前面的故障类型做成自动初步诊断：工单一创建，系统就把关键指标抓出来，直接给排查建议。下面这种结构是我常用的模式，函数是示意函数，落地时替换成网管北向接口或者你们运维平台的API：

def preliminary_diagnosis(alarm): ne = alarm["ne_name"] tx_down = check_transmission(ne) rrc_users = query_rrc_users(ne) board_fault = query_board_status(ne) if tx_down: return "优先排查传输链路：光功率、误码率、光路中断" if rrc_users is not None and rrc_users < 5: return "用户数异常低：查基带板、RRU状态、是否小区退服" if board_fault: return "查板卡状态：尝试远程复位，无效则转现场更换" return "基础指标正常，转二线人工排查，附上以上三项指标快照"

这里三个check函数的返回结果可能为空或不完整，代码里先判断rrc_users is not None再比较，避免接口超时导致误判。query_board_status也建议增加异常码处理，接口不可用时返回“指标缺失”，而不是直接走“正常”分支。脚本不需要一次覆盖所有故障类型，先把三个月排列图头部那几类写进去，等新故障模式出现再补分支。

把这段逻辑接到工单详情页后，处理人员打开工单就能看到系统给出的初步判断，省掉“先登录网管看看”的无序试探。脚本累计覆盖的故障类型会越来越多，熟练度沉淀在系统里而不是人脑里，人员轮岗对效率的影响明显下降。

4.4 落地顺序建议：先做压缩，再调派单，最后铺定位脚本

对策实施别同时全量上，我吃过同时改三个环节的亏：告警压缩误伤和派单规则误派同时出现，连原因都分不清是谁引起的。建议按这个顺序推进：先上告警压缩，它只影响告警到工单的触发环节，风险可控，见效快；压缩稳定运行一周后，用回放数据调整自动派单规则，派单改动直接影响班组接单体验，最好先对一半地市灰度，观察一周误派率和超时率没有恶化再全面推开；定位脚本放在最后，它需要前两步清理出干净工单数据来沉淀排查路径。每一步都单独做效果评估，每一步的可观测性都更强，出问题也更容易定位。

5. 避坑记录：故障处理效率课题最容易翻车的五个地方

5.1 告警压缩误伤：参数调太快，把真正的主故障也压掉了

现象：压缩规则上线第二天，某个区域出现退服告警，但工单没有按预期触发，故障持续了近半小时才被人工发现。原因：退服之前网络先发生了一轮闪断，同一网元瞬间产生了几十条瞬断告警，压缩窗口把后面的真实退服告警当成重复处理了。解决：严重和紧急级别的告警永远不参与压缩，前面4.1节代码里那个白名单逻辑就是针对这个坑；压缩参数上线前用历史一周数据回放，重点看被压掉的告警里有没有真实故障，回放通过再切生产。

5.2 自动派单翻车：只按告警级别派单，工单派错班组

现象：批量退服工单自动派给了无线班组，实际是传输光缆中断，工单连转两次才到传输班组，处理时长翻了快一倍。原因：规则只匹配了alarm_level，没有把根因类型和影响面纳入判定，同一故障在网管上会同时上报多个专业的多条告警。解决：派单规则里加“根因类型优先”维度，同一网元存在传输类告警时优先匹配传输维护班组；两个条件都不能完全命中时不自动派，进入人工分诊队列，不要让系统硬猜。

5.3 现状调查返工：各专业对“处理时长”口径对不上

现象：两个小组统计同一批工单，一个说平均85分钟，另一个说118分钟，拿着两套数字进评审会直接吵起来。原因：一个用“派单时间到结单时间”，另一个用“告警发生时间到业务恢复时间”，还有人把跨专业转派的等待时间剔除了。解决：课题立项第一天发布口径文档，主口径定为“首次派单时间到结单时间”，故障历时作为辅助口径单独统计；取数脚本统一版本管理，任何一次口径调整都走变更记录。先把数字对齐，再谈分析，这是避免返工最省力的一步。

5.4 控制图连报异常：子组分组方式不对，全局都在误报警

现象：巩固期控制图几乎每天都出界，值班员疲于写异常说明，最后没人愿意维护这个图。原因：把每天全部几十张工单放进同一个子组，组内既有无线专业又有传输专业，时长波动天然很大，分组方式把随机波动扩大了。解决：每个子组固定取5个样本，比如取每天结单状态正常的前5张工单；子组内尽量保持同一个专业或同一个班组的数据。子组大小n=5是控制图里比较常用的折中，太小极差估计不稳，太大会跨越多天掩盖组内波动。

5.5 课题一结束指标就回弹：缺少制度固化这一步

现象：课题关闭后两个月，平均处理时长又回到课题前水平。原因：对策只停留在系统配置层面，没有写进值班制度和交接班检查项，人员轮岗后新人不知道这些参数的含义，也不敢动。解决：把告警压缩参数、派单规则、定位脚本的维护责任落实到具体岗位，建立月度规则评审机制；控制图数据由值班组每周五更新，一旦连续两周呈上升趋势就启动原因排查。课题收尾不是交报告，是把改进动作变成日常运维的默认行为。

6. 用均值-极差控制图守住成果：课题结束后指标不回弹的做法

6.1 子组怎么取、控制限怎么算：用最近20天的样本估计

课题效果确认后，我习惯加一张均值-极差控制图作为固化的监控工具。做法是每天取5张正常结单工单的处理时长作为一个子组，连续收集20个工作日，形成20个子组。对每个子组算出均值x_bar和极差R，再对全体子组算出总均值x_double_bar和平均极差R_bar，查系数表取A2、D3、D4，最后得到均值控制限和极差控制限。下面这段计算可以直接跑：

import numpy as np # samples: list of lists，每个子列表是一天的5个处理时长样本（分钟） samples = [ [82, 79, 91, 85, 88], # ... 共20组 ] x_bar = [np.mean(s) for s in samples] R = [np.max(s) - np.min(s) for s in samples] x_double_bar = np.mean(x_bar) R_bar = np.mean(R) A2, D3, D4 = 0.577, 0, 2.114 # 子组大小 n=5 UCL_x = x_double_bar + A2 * R_bar LCL_x = x_double_bar - A2 * R_bar UCL_R = D4 * R_bar LCL_R = D3 * R_bar

A2和D3/D4来自控制图系数表，n=5时A2=0.577、D3=0、D4=2.114；如果子组大小改成3，A2要换成1.023，D4换成2.574。LCL_R为0是因为n小于6时极差下控制限不适用，判定极差异常只看上控制限。算控制限最好用课题效果稳定之后的20天数据，别用改进前的数据当基线，否则控制限过宽，改进后的问题根本暴露不出来。

6.2 判异规则与控制图维护节奏：四条判据足够日常监控用

日常监控不需要把八条判异准则全用上，我用四条就够，全部都是业界通用的精简版：

控制图由值班组每周五更新一次，把本周每天的5个样本追加进去，重算控制限并打点。触发判异规则时，先检查数据是否录错，再排查当天是否有施工、雷雨等环境事件，确认原因后记录在案。连续四周无异常，课题才算正式关闭。

我以前做课题收尾吃过亏，总结报告一交就认为完事了，结果成果回弹被点名复盘。现在的习惯是课题方案里提前预留“控制图监控”这一节，把维护责任、更新频率、判异规则全部写死。控制图不是给课题评审做样子的，它是让改进水平成为新管理基线的最有效手段。希望这篇能把你们课题从立项到固化这条路铺平，少走几个我走过的弯路。

本文还有配套的精品资源，点击获取