可靠计算系统设计分析与验证课程笔记 3，内容对应 Session 6：Reliability Technology Overview，讨论故障预防、故障屏蔽、容错、故障排除和故障预测，以及奇偶校验与纠错码的基本原理

可靠性技术总览

前两篇分别介绍了故障、错误、失效的基本概念，以及如何用解析模型计算可靠性和可用性。这一篇转向系统设计中的可靠性技术：怎样减少故障，怎样限制已经发生的错误，又怎样恢复服务和消除根因？

沿用前面的故障链：

$$\text{故障 Fault}\longrightarrow\text{错误 Error}\longrightarrow\text{失效 Failure}$$

不同技术作用于这条链的不同位置。设计时需要先明确目标是降低故障概率、避免错误传播、恢复服务，还是修复故障本身，再选择对应机制

可靠性技术怎样分工

课程把可靠性技术分为五类，它们作用于故障链的不同位置：

例如，重启一个因软件缺陷而挂起的进程，可以暂时恢复服务，但相同缺陷仍可能再次触发。重启属于恢复机制，修复造成挂起的代码才是在排除故障

有冗余机制不代表可靠性一定提高

容错是能力或机制，可靠性是给定任务和条件下的结果。是否增加副本、是否配置恢复逻辑，不能代替定量分析

以三模冗余（TMR）为例，假设三个组件独立、每个在任务期间正确工作的概率都是 $R$，且投票器完美，多数表决的可靠性为

$$R_{\mathrm{TMR}}=R^3+3R^2(1-R)=3R^2-2R^3$$

与单组件相比，

$$R_{\mathrm{TMR}}-R=R(1-R)(2R-1)$$

所以在上述模型下，只有 $R>1/2$ 时表决才提高可靠性。如果组件经常同时出错，或者投票器也会失效，就必须修改模型。这个例子说明，冗余的效果依赖组件质量、独立性和辅助机制

信息冗余：奇偶校验与纠错码

讲义先用编码说明冗余怎样支持检测和屏蔽。核心思想是：只允许一部分比特串作为合法码字，使错误有机会把合法状态带到可识别的非法状态

奇偶校验能看见什么

以四个数据位 $d_0,d_1,d_2,d_3$ 和一个偶校验位 $P$ 为例，合法码字满足

$$d_0\oplus d_1\oplus d_2\oplus d_3\oplus P=0$$

若有奇数个位发生翻转，异或结果变成 $1$，可以检测到错误；若有偶数个位翻转，异或结果仍为 $0$，单个奇偶校验位就可能漏检

校验失败只能说明码字不再满足约束，不能仅凭一个校验位判断具体哪个位置出错。因此，奇偶校验本身主要提供检测能力；要在上层不感知错误的情况下恢复原数据，还需要纠错或重读等机制

最小码距决定检测与纠正能力

两个比特串的 Hamming 距离是对应位置不同的比特数，例如

$$d_H(1011,0110)=3$$

设合法码字集合为 $C$，其最小码距为

$$d_{\min}=\min_{x\neq y,\ x,y\in C}d_H(x,y)$$

若要求检测所有不超过 $d$ 位的翻转，必须保证错误不足以把一个合法码字变成另一个合法码字，因此

$$\boxed{d_{\min}\geq d+1}$$

若要求纠正所有不超过 $c$ 位的翻转，每个码字周围半径为 $c$ 的错误集合必须互不相交，因此

$$\boxed{d_{\min}\geq2c+1}$$

若要求纠正最多 $c$ 位错误，同时把总错误位数不超过 $t$、其中 $c<t$ 的情况检测为不可纠正，则还要避免这些错误落入另一个码字的纠正范围，需要

$$\boxed{d_{\min}\geq c+t+1}$$

例如单比特纠正、双比特检测（SECDED）取 $c=1,t=2$，需要最小码距至少为 $4$。讲义将 $t$ 写成“可纠正的 $c$ 位之外再增加 $d$ 位”，于是同一条件写作 $d_{\min}\geq2c+d+1$

这里必须区分检测模式和纠正模式：最小码距为 $3$ 的码在只做合法性检查时可以检测两位错误，但若自动按单比特错误纠正，就可能把两位错误误纠正为另一个码字

容错：检测、遏制与恢复

容错是在故障发生后仍保持或恢复服务的能力。讲义把它展开为几个相互衔接的环节：

• 故障／错误检测：识别已经发生的异常
• 故障定位：确定故障所在的组件或范围
• 故障／错误遏制：隔离影响，阻止错误继续传播
• 恢复：使系统保持运行或重新回到可运行状态

在冗余系统中，可以把组件划分为故障遏制区域（Fault Containment Region，FCR）。模型通常假设各区域独立失效，一个区域中的故障不会直接使另一个区域失效。实际设计需要通过资源隔离、接口约束和冗余布局来支撑这一假设

常见恢复机制包括重启、检查点与回滚、向前恢复，以及副本切换。它们依赖不同的恢复基础：重启需要重新建立运行状态，回滚需要可信检查点，副本切换则要求备用实例及其状态满足接管条件

一次检测之后还要决定如何处置。如果错误结果已经提交到服务接口，仅仅记录告警可能已经无法避免当前请求失效。因此检测点、遏制边界和恢复动作需要一起设计

故障排除：从恢复服务到修复根因

故障排除关注故障本身，包括定位范围、识别根因、理解错误传播过程，再实施修复。这些步骤在调试和故障排查中常常交错进行

修复也可以发生在不同层次：修改源代码、调整配置、替换组件，或者改变系统设计。例如进程因缺陷反复死锁，重启可以暂时恢复服务，修复同步逻辑才会消除导致死锁的故障

恢复服务和修复根因具有不同的时间目标，可以先采取切换或重启降低停机损失，再根据保留的日志与状态完成诊断。恢复方案还应考虑证据保留，避免把分析故障所需的信息一并清除

故障预测使用哪些信息

软件缺陷预测可以使用函数规模、分支数量、嵌套深度和 McCabe 圈复杂度等特征。圈复杂度刻画的是控制流中线性独立路径的数量，而不是所有可能执行路径的总数

运行期预测则使用网络吞吐量、往返延迟、丢包率、CPU 和内存使用率、请求超时数量及日志等数据，将它们组织为时间序列或特征向量，再建立统计或机器学习模型。预测结果表达未来风险，不能直接代替当前错误状态的确认

从技术分类到具体检测机制

可靠性设计需要把几类技术组合起来：预防降低故障发生概率，屏蔽限制局部错误的可见影响，容错组织检测、遏制与恢复，故障排除消除根因，故障预测为后续维护和风险处置提供依据

其中错误检测是许多恢复机制的入口。下一篇将围绕看门狗、心跳、数据审计、控制流检查和操作系统级检测，讨论怎样获得异常信号，以及如何评价检测覆盖率、延迟、误报和开销