系统可靠性定义：系统在规定的时间内及规定的环境条件下，完成规定功能的能力，就是系统无故障运行的概率。    
根据国家标准《软件工程产品质量 第1部分：质量模型》(GB/T 16260.1—2006)的规定，系统可靠性包括：成熟性、容错性、易恢复性和可靠性的依从性4个子特性。  

可靠性设计原则

1.模块化设计原则：把复杂的系统拆成一个个 “独立小模块”，每个模块只干一件事，模块间只通过固定接口沟通，降低故障连带伤害故障影响可控：就算应收应付模块出故障，总账模块也能正常处理其他账务，不会让整个财务系统停摆。故障好修：定位到某个模块出问题后，不用改整个系统，只修这个模块就行，还能单独替换或升级模块，不影响其他功能。

技术落地与例子

• 模块划分：按财务业务功能拆成 “总账管理”“应收应付”“报表生成” 等模块，比如总账模块只管账务核心计算，不插手应收应付的明细管理。

• 接口设计：模块间只通过预设接口传数据，比如总账模块和应收模块之间，只传 “应收金额汇总”“对账日期” 等固定格式数据，不直接访问对方的内部数据。

实际价值

• 故障影响可控：就算应收应付模块出故障，总账模块也能正常处理其他账务，不会让整个财务系统停摆。

• 故障好修：定位到某个模块出问题后，不用改整个系统，只修这个模块就行，还能单独替换或升级模块，不影响其他功能。

2.冗余设计原则：对系统里 “不能停” 的关键部分（比如数据存储、核心服务），准备 “备用方案”，应对突发故障。避免 “单点故障”：不会因为一个数据库、一个服务器坏了，就导致整个系统停摆。扛住高并发：多服务器实例能一起分担请求。

技术落地与例子

• 数据存储冗余：用 “主从数据库”，主库负责日常读写（比如处理财务转账数据），从库实时同步主库数据；主库一旦崩了，系统自动切到从库，用户完全没感觉，数据也不会丢。

• 服务部署冗余：多部署几个 “应用服务器”，比如财务系统的报销服务，同时跑 3 个服务器实例，通过负载均衡器把用户请求分到不同实例上；就算其中 1 个服务器坏了，另外 2 个还能接着处理，不会让报销功能中断。

实际价值

• 避免 “单点故障”：不会因为一个数据库、一个服务器坏了，就导致整个系统停摆，尤其适合财务这种 “不能断” 的业务。

• 扛住高并发：多服务器实例能一起分担请求，比如月底报销高峰期，也不会因为用户太多导致系统卡壳。

3.失效安全原则：提前设计 “故障应对预案”，就算系统出问题，也能自动进入 “安全状态”，给故障 “设底线”，保障核心安全，确保出问题时不丢数据、不闯祸。

技术落地与例子

• 业务回滚机制：财务转账时，如果网络突然断了、系统崩了，自动把没完成的转账 “撤回去”（回滚），比如用户转 1 万元给供应商，没转完就断网，系统会自动取消这笔交易，不让钱卡在中间或转错。

• 故障日志记录：不管是转账回滚，还是其他故障，系统都会详细记录 “故障时间、故障环节、操作内容”，比如 “2024-10-01 14:30，转账模块因网络中断回滚交易，交易号 XXX”，方便后续排查问题。

实际价值

• 保障核心安全：就算出故障，也不会出现 “钱转丢了”“账单算错了” 这种财务系统的致命问题，守住业务安全底线。

• 方便问题排查：详细的故障日志能帮工程师快速找到 “哪里出了问题”，不用瞎猜，加快修复速度。

可靠性设计技术

常见的可靠性设计技术有容错设计、检错设计、降低复杂度设计等技术。，这些技术可以分成三大类：“出问题能扛住”“出问题能发现” 和 “从源头减少问题”。

一、容错设计技术

“出问题能扛住”：这类技术的核心是 “就算某个部分坏了，系统也能接着用”，专门用在失效后果严重的场景（比如医疗设备、金融交易软件）。

1. 恢复块设计：相当于给核心功能 “多备几个替补”。

   • 把关键操作做成 “恢复块”，里面除了正在用的程序（运行文本），还藏着好几个功能一样、写法不同的备份。一旦正在用的程序出故障，立刻切换到备份，全程自动完成，用户几乎没感觉。

2. N 版本程序设计：相当于 “多个人算同一道题，少数服从多数”。

   • 用 “少数服从多数” 避免错判。让多个团队用不同方法开发同一个功能模块，同时运行后对比结果，选出现次数最多的结果作为最终输出，防止单个模块出错。

3. 冗余设计：相当于给系统 “装个备用发动机”。

   • 在主系统之外，单独做一套功能相同但实现路径不同的备份系统（比如主系统用 A 算法，备份用 B 算法）。主系统故障时，直接切换到备份系统，但缺点是会多花开发时间和成本。

---

二、检错技术

“出问题能发现”：这类技术的核心是 “不直接解决问题，但能立刻报警”，用在没法做冗余、但又怕故障扩大的场景。

• 比如软件里加一些 “检查点”，定期核对数据是否正常（像财务软件核对收支是否平衡）。

• 一旦发现异常，马上弹出警告或记录日志，提醒工作人员处理，但不能自己修复故障。

---

三、降低复杂度设计

“从源头减少问题”：这类技术的核心是 “让软件更简单，从根上少出故障”，是所有设计的基础。

• 复杂的软件结构、绕弯的数据流向，很容易藏 bug。所以设计时尽量简化，比如减少多余的代码、让数据路径更直接。设计时通过 “简化结构”（比如把大功能拆成小模块，每个模块只干一件事）、“优化数据流向”（让数据传递路径更直接）、“缩短代码”（去掉多余逻辑），降低软件复杂度，从根本上减少缺陷。

可靠性分析方法

在软件可靠性设计过程中，都需要采用软件可靠性分析方法，来确定当前系统中的主要可靠性因素、目标，专门找系统哪里会坏、坏了有什么后果、怎么规避。

FMEA 故障模式与影响分析

这种方法像 “提前做安全检查”，：“从源头预判风险”，聚焦未发生的潜在问题。SFMEA 是 Failure Mode and Effects Analysis 的缩写，直译就是 “软件失效模式与效应分析”。

从下往上、逐个排查：先找每个零件 / 模块会怎么坏（故障模式）→ 分析坏了造成什么后果（故障影响）→ 评估风险，提前整改。 归纳法：单个故障 → 整体影响。在软件开发早期就主动找可能出问题的环节（失效模式），分析后果并提前预防，避免问题落地后造成损失。

FMEA 三大核心活动（填空必背）

1. 识别系统所有故障模式（哪里会坏）
2. 分析每种故障的故障影响（坏了会怎样）
3. 评估风险，制定改进措施（怎么修）

• 核心步骤：先定义分析的系统 / 模块 → 找可能的失效模式 → 查失效原因 → 评失效影响 → 定改进措施。

1. 识别潜在失效模式：组织开发、测试、运维等多部门人员，结合系统架构和业务流程，梳理出可能出现的失效情况。例如，数据库死锁、服务接口超时、数据校验失败等，共识别出 32 种潜在失效模式。​
2. 分析失效影响：针对每种失效模式，评估其对系统功能、性能和业务流程的影响程度。如数据库死锁会导致所有依赖该数据库的业务无法正常进行，影响程度为 “严重”；服务接口超时可能导致部分业务响应缓慢，影响程度为 “中等”。​
3. 确定失效原因：深入分析导致失效的原因，包括代码缺陷、环境因素、配置错误等。例如，数据库死锁可能是由于事务操作不当、锁机制不合理导致；服务接口超时可能是因为网络延迟、服务器负载过高。​
4. 计算风险优先级数（RPN）：根据失效模式的发生频率（O）、影响程度（S）和检测难度（D），计算 RPN = O × S × D。对 RPN 值较高的失效模式（如数据库死锁，RPN 值达到 120），优先制定预防和改进措施。针对数据库死锁问题，优化事务处理逻辑，采用乐观锁和悲观锁相结合的方式，降低死锁发生概率，并增加死锁检测和自动解锁机制，提高系统的可靠性。​
5. 持续监控与改进：在系统运行过程中，持续收集失效数据，分析失效模式的实际发生情况，评估改进措施的有效性。根据反馈结果，不断调整和优化可靠性设计，进一步提升软件可靠性。​

FMEA 是全生命周期找风险： 设计阶段 → 开发 / 生产过程 → 用户使用阶段 → 后期维护服务 对应 4 类：设计、过程、使用、服务。分类为：设计 FMEA、过程 FMEA、使用 FMEA、服务 FMEA

FTA 故障树分析

从上往下、逆向推导：先定最严重的顶层事故（顶事件）→ 拆解是哪些底层故障组合导致的，用逻辑门（与 / 或）连接。 演绎法：整体事故 → 拆解底层故障。

这种方法像 “侦探破案”：“从结果倒推原因”，聚焦已发生的严重问题，从已经出现的严重故障（顶事件）出发，一步步追查根本原因，适合在故障发生后定位问题，或提前预判严重故障的可能诱因。

核心元素

1. 顶事件：最不希望发生的大事故（系统崩溃、致命故障）

2. 中间事件：中间模块故障

3. 底事件：最底层最小故障（模块死机、断电、传输错误）

4. 或门：任意一个故障发生，上层就发生

5. 与门：所有故障同时发生，上层才发生

关键步骤

• 建立故障树：把顶事件、中间原因、底事件用逻辑图（比如 “与”“或” 关系）画出来。

• 定性分析：找出所有可能导致顶事件的原因组合，明确 “哪些原因凑在一起会出问题”。

• 定量分析：如果有数据，计算每个底事件发生的概率，进而算出顶事件发生的概率，判断风险等级。

可靠性模型

 JM 模型（Jelinski-Moranda 模型）

最经典的 “错误清除型” 增长模型，是软件可靠性领域最早的定量模型之一。JM 模型有两个关键假设，这也是它逻辑的核心：

• 假设 1：软件中的错误总数是固定的（比如开发完成时，软件里藏着 N 个错误，测试的目的就是找出并修复它们）。

• 假设 2：每个错误导致故障的概率相同，且错误之间相互独立（不会因为修复了 “登录错误”，就影响 “支付错误” 的出现概率）。

• 核心逻辑：测试开始后，每发现并成功修复一个错误，软件里的剩余错误数就减少 1 个，对应的故障率（单位时间内发生故障的概率）也会按 “固定比例” 下降。比如初始故障率是 10 次 / 小时，修复 1 个错误后，故障率可能降到 8 次 / 小时，再修复 1 个降到 6 次 / 小时，以此类推。

适用场景深挖（为什么只适合 “初期、小规模项目”）

• 优势：计算极简单，只需要 “已发现错误数量” 和 “测试时间” 两组数据，不用复杂的统计工具，适合项目初期（比如单元测试）快速估算。

• 局限性：它的 “错误总数固定”“错误独立” 假设太理想化。对于大规模项目（比如 ERP 系统），开发过程中可能会新增错误（修复旧错引入新错），且错误之间可能关联（比如 “数据库连接错误” 会导致 “登录”“支付” 多个功能出问题），这时 JM 模型的预测会偏差很大。

• 典型用法：小型工具类软件（如财务部门内部的 Excel 辅助工具）的测试阶段，用它预估 “还需要测多久才能把错误降到目标数量（比如剩 2 个错误）”。

 Shooman 模型

更贴近 “修复现实” 的动态模型。该模型由学者 M. L. Shooman 提出，是在 JM 模型基础上的改进版。核心原理细节（为什么 “考虑检测率和修复率”）。Shooman 模型针对 JM 模型的 “理想化缺陷” 做了优化，因为 JM 模型只算 “修了多少”，没考虑 “找得快不快、修得快不快”。核心是引入了两个新变量：

• 变量 1：错误检测率（θ）：单位时间内能够发现的错误数量（比如 1 天能发现 5 个错误），反映测试团队的 “找错效率”。

• 变量 2：错误修复率（φ）：单位时间内能够修复的错误数量（比如 1 天能修复 3 个错误），反映开发团队的 “修错效率”。

核心逻辑：软件的故障率不仅和 “剩余错误数” 有关，还和 “检测率”“修复率” 挂钩。比如测试团队找错快（θ 高）但开发团队修错慢（φ 低），就会导致 “已发现但未修复的错误积压”，这时系统故障率可能不会下降，甚至因为 “未修复错误持续触发故障” 而保持高位。

适用场景深挖（为什么适合 “优化修复策略”）

• 优势：能反映 “测试 - 修复” 流程的真实效率差异，比如发现 “检测率高但修复率低” 时，就能针对性调整（比如加派开发人员修错）。

• 局限性：依然假设 “错误相互独立”，且需要统计 “检测率”“修复率” 的历史数据，对于没有类似项目经验的团队，数据收集有难度。

• 典型用法：中型项目（如企业财务报销系统）的集成测试阶段，用它分析 “当前修复策略是否合理”—— 比如发现 “差旅费报销模块的错误修复率只有 1 个 / 天，远低于其他模块”，就优先给这个模块加开发资源，提升整体可靠性。

NHPP 模型（非齐次泊松过程模型）

贴合 “可靠性增长规律” 的主流模型。NHPP 是 Non-Homogeneous Poisson Process 的缩写，直译就是 “非齐次泊松过程”。

“非齐次” 则表示 “事件发生的频率随时间变化”（区别于 “齐次泊松过程” 的 “频率固定”）—— 比如早高峰堵车多（频率高），半夜堵车少（频率低），不是固定不变的。

“泊松过程” 是统计学中描述 “随机事件发生频率” 的模型，比如 “某路口每天发生 2 起堵车” 就是一种泊松过程。

核心原理细节（为什么 “故障发生是随时间变化的泊松过程”）NHPP 模型的核心是用 “非齐次泊松过程” 描述故障发生的规律，关键逻辑有两个：

• 规律 1：故障发生的 “强度”（单位时间内发生故障的期望数）随时间递减。测试初期，软件错误多，故障强度高（比如 1 小时发生 8 次故障）；随着测试推进，错误被修复，故障强度逐渐降低（1 小时发生 3 次、1 次……），贴合软件可靠性 “越测越高” 的实际规律。

• 规律 2：故障发生是随机的，但整体趋势可预测。虽然无法确定 “下一次故障具体什么时候发生”，但可以通过历史故障数据（比如 “第 1 天发生 10 次，第 2 天发生 7 次，第 3 天发生 5 次”）拟合出故障强度的变化曲线，进而预测未来的故障情况。

适用场景深挖（为什么适合 “中大型项目、有详细故障时间数据”）

• 优势：不要求 “错误总数固定”，能应对 “修复旧错引入新错” 的情况（比如某阶段故障强度短暂上升，可能是引入了新错），且预测精度高，是目前中大型项目的主流模型。

• 局限性：需要 “每个故障发生的精确时间”（比如 “3 月 1 日 9:23 发生登录故障，3 月 1 日 10:15 发生支付故障”），数据收集要求高；且数学计算复杂，通常需要借助专业工具（如可靠性分析软件）。

• 典型用法：大型项目（如集团级 ERP 财务系统）的系统测试阶段，用它预测 “何时能达到目标可靠性”—— 比如根据故障时间数据拟合出曲线后，发现 “再测试 10 天，故障强度就能降到 0.5 次 / 天（目标值）”，就把测试周期定在 10 天后。

马尔可夫链模型（Markov Chain Model）

“马尔可夫链” 是统计学中描述 “系统状态转移” 的模型，核心特性是 “无后效性”（系统下一个状态只和当前状态有关，和之前的状态无关）。核心原理细节（为什么 “划分状态，分析转移概率”）。马尔可夫链模型的核心是把软件系统拆成 “状态”，并计算状态之间的 “转移概率”，关键步骤：

• 步骤 1：划分系统状态。比如把 ERP 财务系统拆成 “全部正常”“总账模块故障”“应收模块故障”“总账 + 应收同时故障”4 种状态。

• 步骤 2：确定转移概率。通过历史数据或专家经验，确定从一个状态转到另一个状态的概率。比如 “从‘全部正常’转到‘总账模块故障’的概率是 5%/ 天”“从‘总账模块故障’转到‘全部正常’的概率是 90%/ 天”（修复成功）。

• 步骤 3：分析可靠性。通过计算 “系统处于‘全部正常’状态的概率” 来评估可靠性 —— 比如某时间段内，系统有 99.2% 的时间处于 “全部正常” 状态，就说明可靠性达标。

（3）适用场景深挖（为什么适合 “复杂系统（多子系统集成）”）

• 优势：能处理 “子系统故障联动” 的复杂情况（比如 “库存模块故障” 会导致 “成本核算模块故障”），可以清晰展示 “故障如何在系统内传播”，是分析大型集成系统的核心工具。

• 局限性：状态划分复杂（子系统越多，状态数呈指数级增长），且转移概率需要大量历史数据或精准的专家判断，中小项目用起来 “性价比太低”（投入的时间精力远超收益）。

• 典型用法：超大型复杂系统（如跨国集团的 ERP 系统，包含财务、供应链、人力等多个关联子系统）的可靠性评估，用它找出 “故障传播的关键节点”—— 比如发现 “财务模块故障有 80% 概率导致供应链模块停摆”，就给这两个模块之间加 “故障隔离机制”，防止故障扩散。

可靠性模型的选择方法​

根据项目的规模、复杂度、开发周期和技术特点选择合适的模型。

项目规模

• 判断你做的软件 “多大、多复杂”，如果是 “小软件”：用 JM 模型或 Shooman 模型 就够了。这类软件错误少、逻辑简单，不用复杂模型，简单算 “修了多少错、还剩多少错” 就行。
• 如果是 “大软件”，规模大、模块多、各部分还联动，就得用 NHPP 模型或马尔可夫链模型。这类软件故障更 “复杂”—— 可能今天这个模块的错影响明天那个模块，还可能修复旧错又出新政错，只有复杂模型能跟上它的变化。

数据类型

• 简单数据，比如只记录了 “今天发现 3 个错、昨天发现 2 个错”，没记 “具体几点几分发现的错”，用 JM 模型或 Shooman 模型。这俩模型只需要 “错误数量” 和 “大概时间”，不用太精细的数据。
• 详细数据，比如每发现一个错，都记了 “3 月 1 日 9:23，登录模块报错”“3 月 1 日 10:15，支付模块卡住”，有精确的 “故障时间序列”，能用 NHPP 模型。NHPP 模型就靠这些 “时间点数据” 预测故障变化，数据越细越准。
• 系统状态数据，比如能记录 “财务模块故障后，库存模块也跟着故障的概率是多少”，有 “模块间故障传递” 的信息，才能用 马尔可夫链模型。要是没这些 “状态转移数据”，马尔可夫链模型就成了 “无米之炊”，根本用不了。

评价目标

选模型最核心的是 “你想通过模型达到啥目的”

• 目标 1：想知道 “啥时候能结束测试”，用 JM 模型或 NHPP 模型。
• 目标 2：想优化 “修错策略”：比如想知道 “优先修哪类错能更快提升可靠性”，用 Shooman 模型。用 Shooman 模型发现 “发票识别错误修得慢但影响大”，就优先加人修这类错。
• 目标 3：想分析 “故障怎么扩散”：比如想搞清楚 “财务模块坏了，会不会连累其他模块”，用 马尔可夫链模型。用它发现 “总账模块故障有 80% 概率导致报表模块出错”，就提前加防护，避免故障扩散。