核心内容
可靠性
相关基本概念
可靠性指标
MTTD是MTTR前面的一部分，就是故障已经出现了，但是还没有被发现
串联系统与并联系统
R表示可靠性
1-R=λ 失效率
失效率公式可以近似估计整个系统的失效率，属于一种近似方法
先预先搞一些bug，然后看测试人员能够发现多少，比如搞了10个bug，测试发现了7个，那么我们可以认为还有30%的概率没有被发现
系统可靠性模型
影响软件可靠性的主要因素
避错技术：主动测试，减少问题
可靠性设计
N版本程序设计
对同一个功能块开发多个版本，比较适合军工中非常严谨的项目
表决算法（全等表决）：全部一样才算
恢复块方法
恢复块是串行的，前面有问题，后备块补上
- 若主块验证不合格，系统会放弃主块的错误执行结果，回退到「主块执行前的正确初始状态」，然后启动后备块1执行；所以它是后向恢复
防卫式程序设计
try{}catch{}
双机容错
备用系统只有当主系统挂掉才使用
思维导图
思维导图
系统可靠性分析与设计
│
├── 1️⃣ 可靠性相关基本概念 (★★)
│ ├── 可靠性定义
│ │ └── 在规定的时间内和规定条件下，有效实现规定功能的能力
│ │ ├── 三要素：规定时间、规定条件、规定功能
│ │ ├── 本质：能力度量
│ │ └── 📌 软件可靠性强调：在特定的、预先规定的条件和时间范围内完成功能
│ ├── 可用性定义
│ │ └── 系统能够正常运行的时间比例
│ ├── 📌 补充知识：健壮性定义
│ │ └── 健壮性（Robustness）是指软件系统在非正常情况（如用户进行了非法操作、
│ │ 相关的软硬件系统发生了故障等）下仍能够正常运行的能力
│ ├── 软件可靠性 ≠ 硬件可靠性
│ │ ├── 复杂性：软件复杂性比硬件高，大部分失效来自软件失效
│ │ │ └── 📌 软件内部逻辑高度复杂
│ │ ├── 物理退化：硬件存在物理退化，软件不存在
│ │ ├── 唯一性：软件每个COPY版本都一样，硬件不可能完全一样
│ │ │ └── ⚠️ 修正说明：任何两个软件都可以通过复制实现绝对相同
│ │ └── 版本更新周期：硬件较慢，软件较快
│ └── 软件失效的主要原因
│ └── 📌 设计错误是导致软件失效的主要原因
│
├── 2️⃣ 系统可靠性分析 (★★★★)
│ ├── 可靠性指标
│ │ ├── MTTF（平均无故障时间）
│ │ │ └── 系统无故障运行的平均时间（纯正常段）
│ │ ├── MTTR（平均故障修复时间）
│ │ │ └── 从出现故障到修复成功的时间
│ │ ├── MTBF（平均故障间隔时间）
│ │ │ ├── MTBF = MTTR + MTTF（实际中MTTR很小，常认为MTBF≈MTTF）
│ │ │ └── ⚠️ 常见陷阱：MTBF ≠ 相邻故障之间的"正常"时间段
│ │ │ ├── 字面歧义："相邻两次故障之间"容易被理解为"纯正常段"
│ │ │ ├── 工程定义：指从本次故障发生到下次故障发生的完整周期（含修复时间）
│ │ │ └── 考题判断：看到"也称为平均故障间隔"→ 选 MTBF
│ │ ├── MTTD（平均检测时间）
│ │ │ └── 故障发生到被检测出来的时间（潜伏期）
│ │ ├── 可靠度 R(t)
│ │ │ ├── 定义：系统在规定工作时间内无故障的概率
│ │ │ ├── 数学表达：R(t) = P(T > t)
│ │ │ ├── 性质：R(0)=1，R(∞)=0，单调递减
│ │ │ ├── 恒失效率下：R(t) = e^(-λt)
│ │ │ └── 与可用性的区别：不考虑修复 vs 考虑修复
│ │ ├── 可靠性时间概念分类
│ │ │ ├── 执行时间（Execution Time）
│ │ │ │ ├── 定义：CPU执行程序指令所用的时间总和
│ │ │ │ ├── 特点：不是从启动到结束的时间段，而是CPU真正干活的时间累加
│ │ │ │ └── 用途：用于精确度量CPU密集型系统的可靠性
│ │ │ ├── 运行时间（Run Time）
│ │ │ │ ├── 定义：软件从启动开始到运行结束的时间段
│ │ │ │ ├── 特点：连续的自然时间段（含等待、I/O等）
│ │ │ │ └── 用途：MTTF/MTBF 通常基于运行时间计算
│ │ │ └── 自然时间（Calendar Time）
│ │ │ ├── 定义：日历时间，包括年、月、周、日等自然流逝的时间段
│ │ │ ├── 特点：包含停机、待机、维护时间
│ │ │ └── 用途：用于可用性计算、合同履约、系统运营统计
│ │ ├── 可靠性度量的数值特性
│ │ │ ├── 可靠性度量结果均为数值（时间、概率、百分比）
│ │ │ ├── 架构演化评估需量化对比
│ │ │ └── 示例：MTBF=2000h、可靠度=0.9999、可用性=99.99%
│ │ └── 系统可用性
│ │ └── MTTF/(MTTR+MTTF) × 100%
│ │
│ ├── 串联系统与并联系统
│ │ ├── 串联系统
│ │ │ ├── 特点：所有部件必须正常，系统才正常
│ │ │ ├── 可靠性公式：R = R₁ × R₂ × ... × Rₙ
│ │ │ └── 失效率近似公式：λ = λ₁ + λ₂ + ... + λₙ
│ │ │ └── 前提：各部件相互独立，且λᵢ·t 较小
│ │ └── 并联系统
│ │ ├── 特点：至少一个部件正常，系统就正常
│ │ └── 可靠性公式：R = 1 - (1-R₁) × (1-R₂) × ... × (1-Rₙ)
│ │
│ ├── 混合系统
│ │ ├── 计算原则：先并联，后串联
│ │ │ ├── 步骤1：将每个并联组合视为一个整体，计算其等效可靠性
│ │ │ ├── 步骤2：将等效后的单元按串联方式计算总可靠性
│ │ │ └── 步骤3：如有嵌套结构，从最内层并联向外逐层计算
│ │ ├── 示例
│ │ │ ├── 结构：R --- (并联块1) --- (并联块2)
│ │ │ ├── 并联块1：3个相同部件并联，可靠度 = 1 - (1-R)³
│ │ │ ├── 并联块2：2个相同部件并联，可靠度 = 1 - (1-R)²
│ │ │ └── 总可靠度 = R × [1-(1-R)³] × [1-(1-R)²]
│ │ └── 通用公式：R_total = R_串联₁ × R_并联等效₁ × R_串联₂ × ...
│ │
│ └── 可靠性模型（10类）
│ ├── 种子法模型：预先播种错误"种子"，看种子发现比例
│ ├── 失效率类型模型：如Jelinski-Moranda、Schick-Wolverton模型
│ ├── 曲线拟合类型：回归分析研究软件复杂性、缺陷数、失效率
│ ├── 可靠性增长模型：用增长函数描述软件可靠性改进
│ ├── 程序结构分析模型：分析程序、子程序及调用关系，形成可靠性网络
│ ├── 输入域分类模型：选取输入样本点，推断软件使用可靠性
│ ├── 执行路径分析方法模型：计算逻辑路径和执行概率，综合可靠性
│ ├── 非齐次泊松过程模型：预测累计失效数
│ ├── 马尔可夫过程模型：如完全/不完全改错的线性死亡模型
│ │ └── 主要用于描述软件失效和修复的状态转换
│ └── 贝叶斯分析模型：利用失效率试验前分布和当前测试信息评估
│
├── 3️⃣ 软件可靠性设计 (★★★★)
│ ├── 📌 补充知识：可靠性设计的优先级定位
│ │ └── 可靠性设计应排在功能性、用户需求和开发费用之后考虑，而非优先考虑
│ ├── 影响软件可靠性的主要因素
│ │ ├── ① 软件的开发方法和开发环境
│ │ │ ├── 开发方法：结构化方法、面向对象方法、敏捷开发等
│ │ │ └── 开发环境：编译器、调试工具、测试框架、配置管理
│ │ ├── ② 运行环境
│ │ │ ├── 硬件环境：CPU、内存、存储、网络等
│ │ │ ├── 软件环境：操作系统、中间件、数据库、依赖库
│ │ │ └── 物理环境：温度、湿度、电磁干扰、供电稳定性
│ │ ├── ③ 软件规模
│ │ │ ├── 代码行数（LOC）
│ │ │ ├── 模块数量
│ │ │ ├── 函数/接口数量
│ │ │ └── 规模越大，缺陷密度越高，可靠性越难保证
│ │ ├── ④ 软件内部结构
│ │ │ ├── 架构复杂度：耦合度、内聚性、层次深度
│ │ │ ├── 控制流复杂度：分支数、循环嵌套深度
│ │ │ ├── 数据流复杂度：全局变量、共享资源、并发访问
│ │ │ ├── 结构越复杂，潜在故障点越多
│ │ │ └── 📌 补充知识：降低复杂度设计思想
│ │ │ └── 在保证实现软件功能基础上，简化软件结构、缩短程序代码长度、
│ │ │ 优化软件数据流向、降低软件复杂度、提高软件可靠性
│ │ └── ⑤ 软件的可靠性投入
│ │ ├── 时间投入：开发周期、测试周期、评审周期
│ │ ├── 人力投入：开发团队、测试团队、质量保证团队
│ │ ├── 技术投入：可靠性设计技术、测试技术、分析工具
│ │ └── 资金投入：培训、工具采购、第三方测试服务
│ │
│ ├── 可靠性设计技术
│ │ ├── ① N版本程序设计
│ │ │ ├── 核心思想：多个相异版本独立实现，表决输出
│ │ │ ├── 恢复类型：✅ 前向恢复
│ │ │ │ └── 直接从多个结果中选择正确结果，继续执行
│ │ │ ├── 新增三个阶段
│ │ │ │ ├── 相异成分规范评审
│ │ │ │ ├── 相异性确认
│ │ │ │ └── 背对背测试
│ │ │ ├── 关键技术点
│ │ │ │ ├── N版本程序的同步
│ │ │ │ ├── N版本程序之间的通信
│ │ │ │ ├── 表决算法（全等表决、非精确表决、Cosmetie表决）
│ │ │ │ ├── 一致比较问题
│ │ │ │ └── 数据相异性
│ │ │ └── 优缺点
│ │ │ ├── 优点：容错能力强，能屏蔽设计错误，无回滚开销
│ │ │ └── 缺点：开发成本高（N倍），表决器可能成为单点故障
│ │ │
│ │ ├── ② 恢复块方法
│ │ │ ├── 核心思想：主块 + 备块 + 验收测试
│ │ │ │ └── 📌 补充：选择一组操作作为容错设计单元，包含多个功能相同但设计差异的程序块文本
│ │ │ ├── 恢复类型：✅ 后向恢复
│ │ │ │ └── 回滚到上一个恢复点，执行备块重新尝试
│ │ │ ├── 工作流程
│ │ │ │ ├── 步骤1：保存恢复点（状态快照）
│ │ │ │ ├── 步骤2：主块执行
│ │ │ │ ├── 步骤3：验收测试判断结果是否正确
│ │ │ │ ├── 步骤4：若验收失败，回滚并执行备块
│ │ │ │ └── 步骤5：重复尝试，直到成功或资源耗尽
│ │ │ ├── 关键要素
│ │ │ │ ├── 主块（Primary Block）：首选执行的模块
│ │ │ │ ├── 备块（Alternate Block）：替代执行的模块（可多个）
│ │ │ │ ├── 验收测试（Acceptance Test）：判断结果是否正确的机制
│ │ │ │ └── 恢复点（Recovery Point）：回滚的状态保存点
│ │ │ └── 优缺点
│ │ │ ├── 优点：比N版本成本低，灵活性高
│ │ │ └── 缺点：验收测试可能不完善，状态保存/回滚开销大
│ │ │
│ │ ├── ③ 防卫式程序设计
│ │ │ ├── 核心思想：不信任任何外部输入，主动检测异常
│ │ │ ├── 恢复类型：❌ 不属于前向/后向恢复（属于防御性容错）
│ │ │ ├── 实现框架：错误检测 → 破坏估计 → 错误恢复
│ │ │ │ ├── 错误检测
│ │ │ │ │ ├── 输入验证：检查参数范围、类型、格式
│ │ │ │ │ │ └── 📌 补充知识：系统输入设计中的输入验证方法
│ │ │ │ │ │ ├── 数据类型检查：确保输入了正确的数据类型
│ │ │ │ │ │ ├── 自检位：用于对主关键字进行基于校验位的检查
│ │ │ │ │ │ ├── 域检查：验证数据是否位于合法的取值范围
│ │ │ │ │ │ └── 格式检查：按照已知的数据格式对照检查输入数据的格式
│ │ │ │ │ ├── 断言（Assertion）：在关键位置检查不变量
│ │ │ │ │ ├── 边界检查：数组越界、缓冲区溢出防护
│ │ │ │ │ ├── 空指针检查：防御性判空
│ │ │ │ │ ├── 心跳检测：监控组件存活状态
│ │ │ │ │ ├── 📌 补充知识：检错技术的关键要素
│ │ │ │ │ │ ├── 检测对象：检测什么（输入、状态、资源、时序等）
│ │ │ │ │ │ ├── 检测延时：何时检测（实时、周期性、事件触发等）
│ │ │ │ │ │ ├── 实现方式：如何检测（硬件、软件、混合）
│ │ │ │ │ │ └── 处理方式：检测到后如何操作（上报、重试、降级、切换、终止等）
│ │ │ │ │ └── 📌 补充知识：检错技术的适用场景
│ │ │ │ │ └── 对于无须在线容错或不能采用冗余设计技术的部分，
│ │ │ │ │ 如果对可靠性要求较高，一般采用检错技术来及时发现故障并报警
│ │ │ │ ├── 破坏估计
│ │ │ │ │ ├── 错误传播分析：评估错误影响范围
│ │ │ │ │ ├── 数据完整性校验：检查数据是否被污染
│ │ │ │ │ ├── 状态一致性检查：验证系统状态是否合法
│ │ │ │ │ └── 损害隔离：将错误限制在最小范围内
│ │ │ │ └── 错误恢复
│ │ │ │ ├── 异常处理：try-catch-finally，优雅处理错误
│ │ │ │ ├── 重试机制：临时故障时自动重试
│ │ │ │ ├── 降级服务：关闭非核心功能，保证核心可用
│ │ │ │ ├── 资源清理：RAII、自动释放、防止泄漏
│ │ │ │ └── 失败安全（Fail Safe/Fail Secure）：故障时进入安全状态
│ │ │ ├── 设计原则
│ │ │ │ ├── 最小权限原则
│ │ │ │ └── 契约式设计（前置条件、后置条件、不变量）
│ │ │ └── 优缺点
│ │ │ ├── 优点：提高健壮性，预防性思维，实现成本低
│ │ │ └── 缺点：可能增加代码量，过度防御影响性能
│ │ │
│ │ └── ④ 双机容错
│ │ ├── 核心思想：两台机器协同工作，一台失效则另一台接管
│ │ ├── 恢复类型：⚠️ 取决于具体实现（热备通常为前向恢复）
│ │ ├── 三种模式
│ │ │ ├── 双机热备模式
│ │ │ │ ├── 双机热备模式（Active/Standby方式）
│ │ │ │ ├── 主系统运行，备用系统待机
│ │ │ │ ├── 心跳检测，主系统故障时备用接管
│ │ │ │ └── 切换时间：秒级到分钟级
│ │ │ ├── 双机互备模式
│ │ │ │ ├── 两台同时提供不同服务
│ │ │ │ ├── 互为备用，心跳丢失则接管对方服务
│ │ │ │ └── 资源利用率高
│ │ │ └── 双机双工模式
│ │ │ ├── 两台同时提供相同服务
│ │ │ ├── 负载均衡，共享存储
│ │ │ └── 集群的雏形
│ │ ├── 定位：双机模式是集群的前身
│ │ └── 📌 补充知识：服务器集群
│ │ └── 服务器集群通过内部局域网通信，故障节点应用会被集群内其他节点自动接管，无需人工干预
│ │
│ └── 四种技术对比
│ ├── N版本程序设计：多版本并行 → 表决输出 → 前向恢复
│ ├── 恢复块方法：主备串行 → 验收测试 → 后向恢复
│ ├── 防卫式程序设计：单版本 → 错误检测→破坏估计→错误恢复 → 防御性容错
│ └── 双机容错：双硬件并行 → 故障切换 → 取决于实现
│
├── 4️⃣ 软件可靠性测试 (★★★)
│ ├── 狭义软件可靠性测试
│ │ ├── 定义原文：在预期使用环境中，按预先确定的测试用例进行，目的是获取可靠性数据
│ │ ├── 逐句解析
│ │ │ ├── ① 在预期使用环境中 → 模拟真实部署环境（操作系统、网络负载、数据流量等）
│ │ │ ├── ② 按预先确定的测试用例进行 → 基于运营概貌/使用概率分布设计，非随机执行
│ │ │ └── ③ 目的是获取可靠性数据 → 定量评估 MTTF/MTBF/失效率，而非定性找bug
│ │ ├── 核心性质：📊 定量测试（输出数值型可靠性指标）
│ │ │ └── 区别于定性测试（仅输出通过/失败、bug列表）
│ │ └── 与其他测试的对比
│ │ ├── vs 功能测试：不找bug，找数据
│ │ ├── vs 压力测试：不找极限，找常态
│ │ └── vs 随机测试：不探索，按计划
│ │
│ ├── 广义软件可靠性测试
│ │ ├── 定义：包括建模、统计、试验、分析和评价等一系列手段
│ │ ├── 核心性质：📊 定量测试
│ │ ├── 四大手段解析
│ │ │ ├── ① 建模 → 建立可靠性模型（如JM模型、NHPP模型）
│ │ │ ├── ② 统计 → 收集故障数据，进行统计分析
│ │ │ ├── ③ 试验 → 执行可靠性测试，获取失效数据
│ │ │ └── ④ 分析与评价 → 评估可靠性指标，判断是否达标
│ │ └── 狭义 vs 广义
│ │ ├── 狭义：聚焦"试验"环节，强调环境+用例+数据
│ │ └── 广义：覆盖全流程（建模→统计→试验→分析→评价）
│ │
│ ├── 📌 在测试阶段首次引入了可靠性建模活动
│ │
│ └── 📌 补充知识
│ ├── 某公司正在开发一个大型分布式系统。项目经理想要提高软件的可靠性，应该重点关注运行环境（刨面）
│ ├── 对于无须在线容错或不能采用冗余设计技术的部分，如果对可靠性要求较高，一般采用检错技术来及时发现故障并报警
│ └── 检错技术相比容错技术的主要特点：实现代价更低，但不能自动解决故障
│
├── 5️⃣ 软件可靠性管理
│ └── 贯穿全生命周期的共同活动
│ └── 📌 收集可靠性数据
│ ├── 需求分析：确定可靠性的目标
│ │ └── 在软件可靠性管理过程中，需求分析阶段应完成的是：
│ │ ├── (1) 确定软件的可靠性目标
│ │ ├── (2) 分析可能影响可靠性的因素
│ │ ├── (3) 确定可靠性的验收标准
│ │ ├── (4) 制定可靠性管理框架
│ │ ├── (5) 制定可靠性文档编写规范
│ │ ├── (6) 制订可靠性活动初步计划
│ │ └── (7) 确定可靠性数据收集规范
│ ├── 概要设计：可靠性设计
│ ├── 详细设计：可靠性设计
│ ├── 编码阶段：可靠性测试（含单元测试）
│ ├── 测试阶段：失效时间、失效间隔
│ │ └── 📌 在测试阶段首次引入了可靠性建模活动
│ └── 实施阶段：可靠性测试（含验收测试）
│
├── 6️⃣ 常见考题示例
│ ├── MTBF 陷阱题
│ │ ├── 题目：MTBF的正确定义是？
│ │ ├── 正确答案：C（相邻两次故障之间的平均时间，也称为平均故障间隔）
│ │ ├── 常见错选：A（那是MTTF）
│ │ └── 避坑口诀：MTBF = 从坏到下回坏（含修复），不是纯正常段
│ │
│ └── 可靠性三要素强调题
│ └── 📌 软件可靠性强调：在特定的、预先规定的条件和时间范围内完成功能
│
└── 7️⃣ 灾难恢复(DR)层次（SHARE78标准）(★★)
├── 标准来源：1992年 Anaheim SHARE78会议定义的国际标准
├── 核心定位：衡量数据保护和灾难恢复能力的七个等级
├── 📌 与可靠性设计的关系：容灾备份、高可用性、RPO/RTO核心指标
│
├── Tier 0：无异地备份
│ ├── 特点：数据仅在本地备份，无DR计划
│ ├── 成本：最低
│ ├── RPO：极大（取决于本地备份周期）
│ ├── RTO：极长（需重建全部环境）
│ └── 缺陷：不具备真正灾难恢复能力
│
├── Tier 1：实现异地备份
│ ├── 操作：关键数据备份到磁带等介质，送往异地存储
│ ├── 限制：异地无备份中心或数据处理系统
│ ├── 恢复：依赖于硬件平台的重新搭建
│ ├── RPO：大（取决于磁带运送频率）
│ └── RTO：长（需重建硬件）
│
├── Tier 2：热备份站点备份
│ ├── 特点：异地有热备份站点
│ ├── 能力：可快速接管应用，恢复生产
│ ├── 风险：数据可能存在延迟（非实时同步）
│ ├── RPO：中等（有数据延迟）
│ └── RTO：较短（站点接管）
│
├── Tier 3：在线数据恢复
│ ├── 方式：通过网络备份关键数据至异地
│ ├── 效果：提高恢复速度
│ ├── 代价：对网络要求较高，成本增加
│ ├── RPO：较小（网络备份频率决定）
│ └── RTO：短
│
├── Tier 4：定时数据备份
│ ├── 方式：自动化软件定时备份数据至异地
│ ├── 指标：数据丢失量和恢复时间取决于备份策略
│ ├── 关键词：定时、策略依赖
│ ├── RPO：取决于定时策略（分钟~小时级）
│ └── RTO：取决于恢复策略
│
├── Tier 5：实时数据备份
│ ├── 技术：镜像技术 + 数据复制技术
│ ├── 效果：数据丢失极小
│ ├── 恢复时间：缩短至分钟或秒级
│ ├── RPO：极小（秒~分钟级）
│ └── RTO：分钟~秒级
│
└── Tier 6：零数据丢失
├── 最高级别，实现零数据丢失和快速业务接管
├── 技术：专用存储网络同步镜像数据至备份中心
├── RPO：0（零数据丢失）
├── RTO：极短（秒级业务接管）
└── 📌 对应双机热备 + 同步复制 + 集群架构思维导图
系统可靠性分析与设计
│
├── 1️⃣ 可靠性相关基本概念 (★★)
│ ├── 可靠性定义
│ │ └── 在规定的时间内和规定条件下，有效实现规定功能的能力
│ │ ├── 三要素：规定时间、规定条件、规定功能
│ │ ├── 本质：能力度量
│ │ └── 📌 软件可靠性强调：在特定的、预先规定的条件和时间范围内完成功能
│ ├── 可用性定义
│ │ └── 系统能够正常运行的时间比例
│ ├── 📌 补充知识：健壮性定义
│ │ └── 健壮性（Robustness）是指软件系统在非正常情况（如用户进行了非法操作、
│ │ 相关的软硬件系统发生了故障等）下仍能够正常运行的能力
│ ├── 软件可靠性 ≠ 硬件可靠性
│ │ ├── 复杂性：软件复杂性比硬件高，大部分失效来自软件失效
│ │ │ └── 📌 软件内部逻辑高度复杂
│ │ ├── 物理退化：硬件存在物理退化，软件不存在
│ │ ├── 唯一性：软件每个COPY版本都一样，硬件不可能完全一样
│ │ │ └── ⚠️ 修正说明：任何两个软件都可以通过复制实现绝对相同
│ │ └── 版本更新周期：硬件较慢，软件较快
│ └── 软件失效的主要原因
│ └── 📌 设计错误是导致软件失效的主要原因
│
├── 2️⃣ 系统可靠性分析 (★★★★)
│ ├── 可靠性指标
│ │ ├── MTTF（平均无故障时间）
│ │ │ └── 系统无故障运行的平均时间（纯正常段）
│ │ ├── MTTR（平均故障修复时间）
│ │ │ └── 从出现故障到修复成功的时间
│ │ ├── MTBF（平均故障间隔时间）
│ │ │ ├── MTBF = MTTR + MTTF（实际中MTTR很小，常认为MTBF≈MTTF）
│ │ │ └── ⚠️ 常见陷阱：MTBF ≠ 相邻故障之间的"正常"时间段
│ │ │ ├── 字面歧义："相邻两次故障之间"容易被理解为"纯正常段"
│ │ │ ├── 工程定义：指从本次故障发生到下次故障发生的完整周期（含修复时间）
│ │ │ └── 考题判断：看到"也称为平均故障间隔"→ 选 MTBF
│ │ ├── MTTD（平均检测时间）
│ │ │ └── 故障发生到被检测出来的时间（潜伏期）
│ │ ├── 可靠度 R(t)
│ │ │ ├── 定义：系统在规定工作时间内无故障的概率
│ │ │ ├── 数学表达：R(t) = P(T > t)
│ │ │ ├── 性质：R(0)=1，R(∞)=0，单调递减
│ │ │ ├── 恒失效率下：R(t) = e^(-λt)
│ │ │ └── 与可用性的区别：不考虑修复 vs 考虑修复
│ │ ├── 可靠性时间概念分类
│ │ │ ├── 执行时间（Execution Time）
│ │ │ │ ├── 定义：CPU执行程序指令所用的时间总和
│ │ │ │ ├── 特点：不是从启动到结束的时间段，而是CPU真正干活的时间累加
│ │ │ │ └── 用途：用于精确度量CPU密集型系统的可靠性
│ │ │ ├── 运行时间（Run Time）
│ │ │ │ ├── 定义：软件从启动开始到运行结束的时间段
│ │ │ │ ├── 特点：连续的自然时间段（含等待、I/O等）
│ │ │ │ └── 用途：MTTF/MTBF 通常基于运行时间计算
│ │ │ └── 自然时间（Calendar Time）
│ │ │ ├── 定义：日历时间，包括年、月、周、日等自然流逝的时间段
│ │ │ ├── 特点：包含停机、待机、维护时间
│ │ │ └── 用途：用于可用性计算、合同履约、系统运营统计
│ │ ├── 可靠性度量的数值特性
│ │ │ ├── 可靠性度量结果均为数值（时间、概率、百分比）
│ │ │ ├── 架构演化评估需量化对比
│ │ │ └── 示例：MTBF=2000h、可靠度=0.9999、可用性=99.99%
│ │ └── 系统可用性
│ │ └── MTTF/(MTTR+MTTF) × 100%
│ │
│ ├── 串联系统与并联系统
│ │ ├── 串联系统
│ │ │ ├── 特点：所有部件必须正常，系统才正常
│ │ │ ├── 可靠性公式：R = R₁ × R₂ × ... × Rₙ
│ │ │ └── 失效率近似公式：λ = λ₁ + λ₂ + ... + λₙ
│ │ │ └── 前提：各部件相互独立，且λᵢ·t 较小
│ │ └── 并联系统
│ │ ├── 特点：至少一个部件正常，系统就正常
│ │ └── 可靠性公式：R = 1 - (1-R₁) × (1-R₂) × ... × (1-Rₙ)
│ │
│ ├── 混合系统
│ │ ├── 计算原则：先并联，后串联
│ │ │ ├── 步骤1：将每个并联组合视为一个整体，计算其等效可靠性
│ │ │ ├── 步骤2：将等效后的单元按串联方式计算总可靠性
│ │ │ └── 步骤3：如有嵌套结构，从最内层并联向外逐层计算
│ │ ├── 示例
│ │ │ ├── 结构：R --- (并联块1) --- (并联块2)
│ │ │ ├── 并联块1：3个相同部件并联，可靠度 = 1 - (1-R)³
│ │ │ ├── 并联块2：2个相同部件并联，可靠度 = 1 - (1-R)²
│ │ │ └── 总可靠度 = R × 1-(1-R)³ × 1-(1-R)²
│ │ └── 通用公式：R_total = R_串联₁ × R_并联等效₁ × R_串联₂ × ...
│ │
│ └── 可靠性模型（10类）
│ ├── 种子法模型：预先播种错误"种子"，看种子发现比例
│ ├── 失效率类型模型：如Jelinski-Moranda、Schick-Wolverton模型
│ ├── 曲线拟合类型：回归分析研究软件复杂性、缺陷数、失效率
│ ├── 可靠性增长模型：用增长函数描述软件可靠性改进
│ ├── 程序结构分析模型：分析程序、子程序及调用关系，形成可靠性网络
│ ├── 输入域分类模型：选取输入样本点，推断软件使用可靠性
│ ├── 执行路径分析方法模型：计算逻辑路径和执行概率，综合可靠性
│ ├── 非齐次泊松过程模型：预测累计失效数
│ ├── 马尔可夫过程模型：如完全/不完全改错的线性死亡模型
│ │ └── 主要用于描述软件失效和修复的状态转换
│ └── 贝叶斯分析模型：利用失效率试验前分布和当前测试信息评估
│
├── 3️⃣ 软件可靠性设计 (★★★★)
│ ├── 📌 补充知识：可靠性设计的优先级定位
│ │ └── 可靠性设计应排在功能性、用户需求和开发费用之后考虑，而非优先考虑
│ ├── 影响软件可靠性的主要因素
│ │ ├── ① 软件的开发方法和开发环境
│ │ │ ├── 开发方法：结构化方法、面向对象方法、敏捷开发等
│ │ │ └── 开发环境：编译器、调试工具、测试框架、配置管理
│ │ ├── ② 运行环境
│ │ │ ├── 硬件环境：CPU、内存、存储、网络等
│ │ │ ├── 软件环境：操作系统、中间件、数据库、依赖库
│ │ │ └── 物理环境：温度、湿度、电磁干扰、供电稳定性
│ │ ├── ③ 软件规模
│ │ │ ├── 代码行数（LOC）
│ │ │ ├── 模块数量
│ │ │ ├── 函数/接口数量
│ │ │ └── 规模越大，缺陷密度越高，可靠性越难保证
│ │ ├── ④ 软件内部结构
│ │ │ ├── 架构复杂度：耦合度、内聚性、层次深度
│ │ │ ├── 控制流复杂度：分支数、循环嵌套深度
│ │ │ ├── 数据流复杂度：全局变量、共享资源、并发访问
│ │ │ ├── 结构越复杂，潜在故障点越多
│ │ │ └── 📌 补充知识：降低复杂度设计思想
│ │ │ └── 在保证实现软件功能基础上，简化软件结构、缩短程序代码长度、
│ │ │ 优化软件数据流向、降低软件复杂度、提高软件可靠性
│ │ └── ⑤ 软件的可靠性投入
│ │ ├── 时间投入：开发周期、测试周期、评审周期
│ │ ├── 人力投入：开发团队、测试团队、质量保证团队
│ │ ├── 技术投入：可靠性设计技术、测试技术、分析工具
│ │ └── 资金投入：培训、工具采购、第三方测试服务
│ │
│ ├── 可靠性设计技术
│ │ ├── ① N版本程序设计
│ │ │ ├── 核心思想：多个相异版本独立实现，表决输出
│ │ │ ├── 恢复类型：✅ 前向恢复
│ │ │ │ └── 直接从多个结果中选择正确结果，继续执行
│ │ │ ├── 新增三个阶段
│ │ │ │ ├── 相异成分规范评审
│ │ │ │ ├── 相异性确认
│ │ │ │ └── 背对背测试
│ │ │ ├── 关键技术点
│ │ │ │ ├── N版本程序的同步
│ │ │ │ ├── N版本程序之间的通信
│ │ │ │ ├── 表决算法（全等表决、非精确表决、Cosmetie表决）
│ │ │ │ ├── 一致比较问题
│ │ │ │ └── 数据相异性
│ │ │ └── 优缺点
│ │ │ ├── 优点：容错能力强，能屏蔽设计错误，无回滚开销
│ │ │ └── 缺点：开发成本高（N倍），表决器可能成为单点故障
│ │ │
│ │ ├── ② 恢复块方法
│ │ │ ├── 核心思想：主块 + 备块 + 验收测试
│ │ │ │ └── 📌 补充：选择一组操作作为容错设计单元，包含多个功能相同但设计差异的程序块文本
│ │ │ ├── 恢复类型：✅ 后向恢复
│ │ │ │ └── 回滚到上一个恢复点，执行备块重新尝试
│ │ │ ├── 工作流程
│ │ │ │ ├── 步骤1：保存恢复点（状态快照）
│ │ │ │ ├── 步骤2：主块执行
│ │ │ │ ├── 步骤3：验收测试判断结果是否正确
│ │ │ │ ├── 步骤4：若验收失败，回滚并执行备块
│ │ │ │ └── 步骤5：重复尝试，直到成功或资源耗尽
│ │ │ ├── 关键要素
│ │ │ │ ├── 主块（Primary Block）：首选执行的模块
│ │ │ │ ├── 备块（Alternate Block）：替代执行的模块（可多个）
│ │ │ │ ├── 验收测试（Acceptance Test）：判断结果是否正确的机制
│ │ │ │ └── 恢复点（Recovery Point）：回滚的状态保存点
│ │ │ └── 优缺点
│ │ │ ├── 优点：比N版本成本低，灵活性高
│ │ │ └── 缺点：验收测试可能不完善，状态保存/回滚开销大
│ │ │
│ │ ├── ③ 防卫式程序设计
│ │ │ ├── 核心思想：不信任任何外部输入，主动检测异常
│ │ │ ├── 恢复类型：❌ 不属于前向/后向恢复（属于防御性容错）
│ │ │ ├── 实现框架：错误检测 → 破坏估计 → 错误恢复
│ │ │ │ ├── 错误检测
│ │ │ │ │ ├── 输入验证：检查参数范围、类型、格式
│ │ │ │ │ │ └── 📌 补充知识：系统输入设计中的输入验证方法
│ │ │ │ │ │ ├── 数据类型检查：确保输入了正确的数据类型
│ │ │ │ │ │ ├── 自检位：用于对主关键字进行基于校验位的检查
│ │ │ │ │ │ ├── 域检查：验证数据是否位于合法的取值范围
│ │ │ │ │ │ └── 格式检查：按照已知的数据格式对照检查输入数据的格式
│ │ │ │ │ ├── 断言（Assertion）：在关键位置检查不变量
│ │ │ │ │ ├── 边界检查：数组越界、缓冲区溢出防护
│ │ │ │ │ ├── 空指针检查：防御性判空
│ │ │ │ │ ├── 心跳检测：监控组件存活状态
│ │ │ │ │ ├── 📌 补充知识：检错技术的关键要素
│ │ │ │ │ │ ├── 检测对象：检测什么（输入、状态、资源、时序等）
│ │ │ │ │ │ ├── 检测延时：何时检测（实时、周期性、事件触发等）
│ │ │ │ │ │ ├── 实现方式：如何检测（硬件、软件、混合）
│ │ │ │ │ │ └── 处理方式：检测到后如何操作（上报、重试、降级、切换、终止等）
│ │ │ │ │ └── 📌 补充知识：检错技术的适用场景
│ │ │ │ │ └── 对于无须在线容错或不能采用冗余设计技术的部分，
│ │ │ │ │ 如果对可靠性要求较高，一般采用检错技术来及时发现故障并报警
│ │ │ │ ├── 破坏估计
│ │ │ │ │ ├── 错误传播分析：评估错误影响范围
│ │ │ │ │ ├── 数据完整性校验：检查数据是否被污染
│ │ │ │ │ ├── 状态一致性检查：验证系统状态是否合法
│ │ │ │ │ └── 损害隔离：将错误限制在最小范围内
│ │ │ │ └── 错误恢复
│ │ │ │ ├── 异常处理：try-catch-finally，优雅处理错误
│ │ │ │ ├── 重试机制：临时故障时自动重试
│ │ │ │ ├── 降级服务：关闭非核心功能，保证核心可用
│ │ │ │ ├── 资源清理：RAII、自动释放、防止泄漏
│ │ │ │ └── 失败安全（Fail Safe/Fail Secure）：故障时进入安全状态
│ │ │ ├── 设计原则
│ │ │ │ ├── 最小权限原则
│ │ │ │ └── 契约式设计（前置条件、后置条件、不变量）
│ │ │ └── 优缺点
│ │ │ ├── 优点：提高健壮性，预防性思维，实现成本低
│ │ │ └── 缺点：可能增加代码量，过度防御影响性能
│ │ │
│ │ └── ④ 双机容错
│ │ ├── 核心思想：两台机器协同工作，一台失效则另一台接管
│ │ ├── 恢复类型：⚠️ 取决于具体实现（热备通常为前向恢复）
│ │ ├── 三种模式
│ │ │ ├── 双机热备模式
│ │ │ │ ├── 双机热备模式（Active/Standby方式）
│ │ │ │ ├── 主系统运行，备用系统待机
│ │ │ │ ├── 心跳检测，主系统故障时备用接管
│ │ │ │ └── 切换时间：秒级到分钟级
│ │ │ ├── 双机互备模式
│ │ │ │ ├── 两台同时提供不同服务
│ │ │ │ ├── 互为备用，心跳丢失则接管对方服务
│ │ │ │ └── 资源利用率高
│ │ │ └── 双机双工模式
│ │ │ ├── 两台同时提供相同服务
│ │ │ ├── 负载均衡，共享存储
│ │ │ └── 集群的雏形
│ │ ├── 定位：双机模式是集群的前身
│ │ └── 📌 补充知识：服务器集群
│ │ └── 服务器集群通过内部局域网通信，故障节点应用会被集群内其他节点自动接管，无需人工干预
│ │
│ └── 四种技术对比
│ ├── N版本程序设计：多版本并行 → 表决输出 → 前向恢复
│ ├── 恢复块方法：主备串行 → 验收测试 → 后向恢复
│ ├── 防卫式程序设计：单版本 → 错误检测→破坏估计→错误恢复 → 防御性容错
│ └── 双机容错：双硬件并行 → 故障切换 → 取决于实现
│
├── 4️⃣ 软件可靠性测试 (★★★)
│ ├── 狭义软件可靠性测试
│ │ ├── 定义原文：在预期使用环境中，按预先确定的测试用例进行，目的是获取可靠性数据
│ │ ├── 逐句解析
│ │ │ ├── ① 在预期使用环境中 → 模拟真实部署环境（操作系统、网络负载、数据流量等）
│ │ │ ├── ② 按预先确定的测试用例进行 → 基于运营概貌/使用概率分布设计，非随机执行
│ │ │ └── ③ 目的是获取可靠性数据 → 定量评估 MTTF/MTBF/失效率，而非定性找bug
│ │ ├── 核心性质：📊 定量测试（输出数值型可靠性指标）
│ │ │ └── 区别于定性测试（仅输出通过/失败、bug列表）
│ │ └── 与其他测试的对比
│ │ ├── vs 功能测试：不找bug，找数据
│ │ ├── vs 压力测试：不找极限，找常态
│ │ └── vs 随机测试：不探索，按计划
│ │
│ ├── 广义软件可靠性测试
│ │ ├── 定义：包括建模、统计、试验、分析和评价等一系列手段
│ │ ├── 核心性质：📊 定量测试
│ │ ├── 四大手段解析
│ │ │ ├── ① 建模 → 建立可靠性模型（如JM模型、NHPP模型）
│ │ │ ├── ② 统计 → 收集故障数据，进行统计分析
│ │ │ ├── ③ 试验 → 执行可靠性测试，获取失效数据
│ │ │ └── ④ 分析与评价 → 评估可靠性指标，判断是否达标
│ │ └── 狭义 vs 广义
│ │ ├── 狭义：聚焦"试验"环节，强调环境+用例+数据
│ │ └── 广义：覆盖全流程（建模→统计→试验→分析→评价）
│ │
│ ├── 📌 在测试阶段首次引入了可靠性建模活动
│ │
│ └── 📌 补充知识
│ ├── 某公司正在开发一个大型分布式系统。项目经理想要提高软件的可靠性，应该重点关注运行环境（刨面）
│ ├── 对于无须在线容错或不能采用冗余设计技术的部分，如果对可靠性要求较高，一般采用检错技术来及时发现故障并报警
│ └── 检错技术相比容错技术的主要特点：实现代价更低，但不能自动解决故障
│
├── 5️⃣ 软件可靠性管理
│ └── 贯穿全生命周期的共同活动
│ └── 📌 收集可靠性数据
│ ├── 需求分析：确定可靠性的目标
│ │ └── 在软件可靠性管理过程中，需求分析阶段应完成的是：
│ │ ├── (1) 确定软件的可靠性目标
│ │ ├── (2) 分析可能影响可靠性的因素
│ │ ├── (3) 确定可靠性的验收标准
│ │ ├── (4) 制定可靠性管理框架
│ │ ├── (5) 制定可靠性文档编写规范
│ │ ├── (6) 制订可靠性活动初步计划
│ │ └── (7) 确定可靠性数据收集规范
│ ├── 概要设计：可靠性设计
│ ├── 详细设计：可靠性设计
│ ├── 编码阶段：可靠性测试（含单元测试）
│ ├── 测试阶段：失效时间、失效间隔
│ │ └── 📌 在测试阶段首次引入了可靠性建模活动
│ └── 实施阶段：可靠性测试（含验收测试）
│
└── 6️⃣ 常见考题示例
├── MTBF 陷阱题
│ ├── 题目：MTBF的正确定义是？
│ ├── 正确答案：C（相邻两次故障之间的平均时间，也称为平均故障间隔）
│ ├── 常见错选：A（那是MTTF）
│ └── 避坑口诀：MTBF = 从坏到下回坏（含修复），不是纯正常段
│
└── 可靠性三要素强调题
└── 📌 软件可靠性强调：在特定的、预先规定的条件和时间范围内完成功能