用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%。做法是先取近三个月的已结工单明细按故障类型分组统计工单数和平均处理时长再算出每组的总处理时长和累计占比。下面这个示例数据不是某个特定网络的真实统计用来帮你看清楚组织方式故障类型工单数平均处理时长分钟总处理时长分钟累计占比基站退服类132851122038.2%传输中断类9876744863.6%板卡异常类6154329474.8%光功率劣化类4549220582.3%其他3938148287.3%画图可以交给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, ascendingFalse).reset_index(dropTrue) 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], rotation30) 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), textcoordsoffset points, xytext(0, 10), hacenter) plt.tight_layout() plt.savefig(pareto.png, dpi150)这段代码里最关键的是total_minutes和cum_percent两列前者是“工单数×平均处理时长”代表该类故障对整体效率的绝对贡献后者是排完序后的累计百分比用来圈定“关键少数”。排序之后还要reset_index否则后面按位置绘图时索引会乱。保存图片用dpi150放到课题汇报材料里足够清晰。数据这一步可以直接写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告警风暴淹没主故障按网元、告警类型、小时窗口统计告警集中度对比风暴时段派单延迟近3个月告警流水与工单确认要因机-2自动派单只按告警级别用新规则回放历史告警对比实际派单班组差异率1个月已关闭工单确认要因法-3跨专业转单人工审批长统计工单转派次数、每次转派等待时长近3个月工单流转日志确认要因人-1夜班技能差异大按白班/夜班分组对比平均处理时长与超时率近3个月工单差异不显著排除人-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(dropTrue) 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, encodingutf-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 故障定位脚本化把高频故障的排查路径变成可执行的代码故障定位占处理时长的大头尤其是经验依赖严重的班组。常见的做法是把排列图排在前面的故障类型做成自动初步诊断工单一创建系统就把关键指标抓出来直接给排查建议。下面这种结构是我常用的模式函数是示意函数落地时替换成网管北向接口或者你们运维平台的APIdef 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张工单子组内尽量保持同一个专业或同一个班组的数据。子组大小n5是控制图里比较常用的折中太小极差估计不稳太大会跨越多天掩盖组内波动。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 # 子组大小 n5 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_barA2和D3/D4来自控制图系数表n5时A20.577、D30、D42.114如果子组大小改成3A2要换成1.023D4换成2.574。LCL_R为0是因为n小于6时极差下控制限不适用判定极差异常只看上控制限。算控制限最好用课题效果稳定之后的20天数据别用改进前的数据当基线否则控制限过宽改进后的问题根本暴露不出来。6.2 判异规则与控制图维护节奏四条判据足够日常监控用日常监控不需要把八条判异准则全用上我用四条就够全部都是业界通用的精简版判异规则含义1个点超出UCL或低于LCL出现了特殊原因通常说明有异常事件发生连续7点在中心线同一侧整体均值发生了偏移连续6点持续上升或持续下降存在趋势性变化可能逐步劣化连续14点交替上下存在周期性干扰或数据来源混杂控制图由值班组每周五更新一次把本周每天的5个样本追加进去重算控制限并打点。触发判异规则时先检查数据是否录错再排查当天是否有施工、雷雨等环境事件确认原因后记录在案。连续四周无异常课题才算正式关闭。我以前做课题收尾吃过亏总结报告一交就认为完事了结果成果回弹被点名复盘。现在的习惯是课题方案里提前预留“控制图监控”这一节把维护责任、更新频率、判异规则全部写死。控制图不是给课题评审做样子的它是让改进水平成为新管理基线的最有效手段。希望这篇能把你们课题从立项到固化这条路铺平少走几个我走过的弯路。本文还有配套的精品资源点击获取