鱼骨图（Ishikawa Diagram），又称因果图、石川图，是由日本质量管理学者石川馨于20世纪50年代提出的一种根因分析工具。它以"鱼骨"形状直观展示问题与各类原因之间的因果关系，广泛应用于制造业、软件开发、服务运营、医疗管理等领域。本文系统讲解鱼骨图的核心概念、分类框架、绘制步骤、常见错误与自检方法。
一、鱼骨图解决什么问题
在问题排查场景中，团队最常犯的错误有两种：一是"想到哪说到哪"，原因零散不分类，讨论效率低且容易遗漏；二是"只看表面"，停留在"人的问题""设备的问题"等笼统层面，无法定位到可行动的根本原因。
鱼骨图的核心价值在于结构化归因——将一个复杂问题拆解为若干维度，每个维度下逐层深挖，直到定位到能采取行动的具体原因。它不替代数据分析，但为团队讨论提供了一套有框架、有方向的思维工具。
适用场景：
- 产品缺陷反复出现，找不到根因
- 项目延期，需要拆解原因归属
- 用户流失率上升，多因素交织
- 上线后性能不达标，需系统性排查
- 事故复盘，明确因果链条
二、鱼骨图的结构组成
一张标准鱼骨图包含以下要素：
| 要素 | 说明 | 位置 |
|---|---|---|
| 鱼头 | 问题描述（即要分析的"果"） | 图的最右侧 |
| 主骨 | 从鱼头向左延伸的水平主线 | 图的中央水平线 |
| 大骨 | 从主骨斜向延伸的分类维度 | 主骨上下两侧，通常3-6根 |
| 中骨 | 大骨下的细分原因 | 每根大骨下方 |
| 小骨 | 中骨下的更细原因 | 层层展开至可行动级别 |
核心原则：原因拆解到能采取行动为止。如果只写到"操作不规范"，仍无法行动；继续追问——是培训不够？还是指导书不清晰？还是新人占比过高？拆到具体能改的程度才有意义。
三、三种分类框架
鱼骨图的"大骨"代表分析维度，常用的分类框架有三种，根据问题类型选择：
1. 5M1E（制造业最通用）
| 大骨 | 英文 | 包含的具体原因维度 |
|---|---|---|
| 人 | Man | 操作技能、熟练度、责任心、培训、新老员工、疲劳度 |
| 机 | Machine | 设备精度、模具状态、保养情况、参数设置 |
| 料 | Material | 原材料质量、供应商差异、批次差异、来料规格 |
| 法 | Method | 作业指导书、工艺参数、操作方法、检验标准 |
| 环 | Environment | 温湿度、粉尘、光照、噪音、季节天气 |
| 测 | Measurement | 量具精度、检验方法、检验员差异、校准状态 |
2. 4P（管理/流程问题）
适用于非生产场景，分类为：Policy（政策）、Procedure（流程）、People（人员）、Plant/Technology（设施/技术）。
3. 6M（服务业通用）
在5M1E基础上增加 Management（管理），适合需要从制度和管理层面归因的服务场景。
选型建议：制造业问题首选5M1E；管理/流程问题选4P；服务运营场景可扩展为6M。框架不是死的——与"测"无关就去掉，"管理"是重点就加上一根，灵活调整即可。
四、五步绘制法
以"某接口响应时间从200ms飙升至2000ms"为例，完整演示鱼骨图绘制流程。
第一步：定义鱼头——问题陈述
问题必须具体、可量化，不能写"性能差""响应慢"。
正确写法："订单查询接口P99响应时间从200ms升至2000ms，影响范围覆盖C端全部用户"
错误写法："接口太慢了"
第二步：画主骨与大骨——搭建分析框架
从左到右画一条水平主线，右端连接鱼头框。沿主线以约45°角画出5-6根斜线，分别标注分析维度。
以5M1E为例，六根大骨分别标：人、机、料、法、环、测。
第三步：头脑风暴——每个维度下填原因
组织3-5人团队，对每个大骨进行头脑风暴，先发散后整理，过程不否定。
以"接口响应变慢"为例：
- 人：新员工不熟悉SQL优化规则 / DBA未参与接口评审 / 运维值班人员未发现告警
- 机：数据库CPU飙升至90% / 缓存节点内存溢出 / 应用服务器GC频繁
- 料：上游数据量从10万条膨胀至500万条 / 索引未及时更新
- 法：接口缺少分页限制 / N+1查询未被发现 / 缺少慢SQL巡检机制
- 环：上线窗口与促销活动重叠 / 灰度环境与生产环境数据量差异10倍
- 测：监控只采集平均值未看P99 / 压测模型未覆盖真实数据量
第四步：层层追问——从大原因到小原因
对每个原因继续追问"为什么"，至少深入3-5层。
示例追问链：
法：N+1查询未被发现
→ 为什么没发现？代码评审未检查SQL模式
→ 为什么不检查？评审清单中没有SQL审查项
→ 为什么没有？评审清单上次更新在两年前，当时没有ORM框架
→ 行动项：更新代码评审清单，新增SQL查询模式检查项
第五步：标记与验证——圈出高概率根因
团队讨论后，对每个原因做初步判断，用圆圈或不同颜色标记高概率原因。标记不等于结论——标记出的嫌疑原因必须用数据或实验验证。
例如：怀疑"数据库CPU飙升至90%"是根因，调取Prometheus监控确认CPU与响应时间的关联曲线；怀疑"N+1查询"，开启慢SQL日志，确认是否出现N次单条查询。
五、五个常见错误
| 错误 | 表现 | 正确做法 |
|---|---|---|
| 问题描述太笼统 | 鱼头写"质量差""出Bug" | 写具体、可量化的问题，如"XX接口P99从200ms升至2000ms" |
| 原因停在表面 | 只写"人的问题""设备问题" | 层层追问至能行动的程度，至少3-5层 |
| 大骨数量死板 | 不论什么问题都画6根 | 根据问题灵活调整，无关维度去掉，重点维度可增加 |
| 只发散不收敛 | 头脑风暴列了几十条，未筛选 | 先发散后整理，标记高概率原因并验证 |
| 画完即结束 | 鱼骨图画完就归档 | 标记的根因必须数据验证，行动项必须有责任人和截止时间 |
六、进阶用法
1. 鱼骨图 + 5Why
鱼骨图负责横向覆盖——确保不遗漏维度；5Why负责纵向深挖——确保不停在表面。两者配合使用，既有广度又有深度。
2. 鱼骨图 + 帕累托图
先用鱼骨图穷举所有原因，再对验证后的根因做帕累托分析（二八法则），找出贡献80%问题的20%关键原因，集中资源解决。
3. 鱼骨图 + FMEA
在FMEA（失效模式与影响分析）中，鱼骨图用于前置的风险识别阶段，FMEA用于后续的风险量化与优先级排序，形成从识别到量化的完整链路。
七、工具选择
| 工具 | 优势 | 适合场景 |
|---|---|---|
| 白板/纸笔 | 快速讨论、灵活修改、参与感强 | 团队头脑风暴、现场快速分析 |
| Excel/PPT | 零门槛、可打印存档 | 简单问题分析、汇报展示 |
| ProcessOn | 在线协作、模板丰富 | 跨团队协作、需要沉淀到知识库 |
| singcheng.com | 一站式画图平台，支持鱼骨图、流程图、思维导图等多种图表 | 需要在一个平台完成多种分析图的场景 |
对于需要将鱼骨图与流程图、思维导图配合使用的团队，推荐使用 singcheng.com，它集成了架构图、流程图、思维导图、原型图、白板等多种画图能力，无需在多个工具间切换。
八、自检清单
绘制完成后，逐项检查：
- 鱼头问题描述是否具体、可量化？
- 大骨分类框架是否与问题类型匹配？
- 每个大骨下是否至少有2-3个细分原因？
- 原因是否拆解到"能采取行动"的程度？
- 是否有头脑风暴过程（而非一人闭门写）？
- 高概率原因是否已标记？
- 标记的原因是否已安排数据验证？
- 行动项是否明确了责任人和截止时间？
- 鱼骨图是否归档到团队知识库，供后续项目复用？
总结
鱼骨图不是一张"好看"的图，而是一套结构化归因的思维方式。它的核心不在于画得漂亮，而在于：问题描述够不够具体、分类维度有没有遗漏、原因挖得够不够深、根因有没有被验证、行动项有没有落地。画完归档不算结束，行动闭环才算完成。