可靠计算系统设计分析与验证(Design, Analysis and Validation of Reliable Computing Systems)课程笔记,内容对应 Sessions 1-2:Basic Concepts
可靠计算系统设计分析与验证
可靠性研究的前提是:坏事情总会发生。硬件会老化,软件会有缺陷,外部环境也会产生干扰。因此,可靠系统的目标不是假设故障不存在,而是理解故障如何演化、限制影响并尽快恢复服务
课程内容可以分成三部分:
- 基本概念:故障、错误、失效,可靠性和可用性,以及常用指标;
- 可靠性技术:故障预防、屏蔽、容错、排除和预测;
- 验证方法:解析建模、故障注入、形式化方法、故障仿真和现场数据分析
故障、错误与失效
三个层次
- Fault(故障):硬件或软件中的物理缺陷、实现缺陷或外部扰动,是潜在的原因
- Error(错误):故障被激活后,系统内部状态偏离预期状态。例如进程读取了损坏的内存单元
- Failure(失效):错误传播到系统外部,用户或其他系统观察到结果错误、服务中断或性能不满足要求
三者描述的是同一事件链上的不同阶段:
故障不一定立刻造成失效。一个缺陷只有在被执行、读取或触发时才会形成错误;如果错误被检测、屏蔽或恢复,它可能永远不会到达外部接口
错误传播与故障周期
一个典型的故障周期如下:
- 故障发生;
- 故障被激活,产生错误状态;
- 错误在系统内部传播;
- 错误到达外部接口,表现为失效;
- 系统检测错误并执行恢复;
- 系统重新运行,直到下一次故障发生
因此,可靠性技术需要尽量在链条的前面截断影响。例如 ECC 可以在错误离开存储器前进行屏蔽,检查点和回滚则可以在错误被发现后恢复到一个正确状态
故障的分类维度
课件从多个维度描述故障:
| 维度 | 类型 |
|---|---|
| 起因 | 规格错误、实现错误、外部扰动、组件缺陷 |
| 持续时间 | 永久故障、瞬态故障、间歇性故障 |
| 故障值 | 可确定、不可确定 |
| 载体 | 硬件、软件;模拟、数字 |
| 影响范围 | 局部、全局 |
其中,瞬态故障只在某个时间窗口出现,间歇性故障则可能反复出现;这两类故障通常比永久故障更难复现和定位
失效的表现形式
从服务接口观察,常见失效可以分为:
- Crash:进程或系统立即异常终止;
- Omission:应该执行的函数或应该发送的消息没有发生;
- Timing:结果虽然存在,但没有满足时间约束,可能过早或过晚;
- Incorrectness:输出错误,或系统转移到了错误状态;
- Byzantine:行为任意、不一致,甚至带有恶意性
越靠近 Byzantine 失效,系统越难通过简单的重试或超时机制处理,因为不同观察者可能看到互相矛盾的结果
可靠性技术
故障预防与故障屏蔽
**故障预防(fault prevention)**是在系统运行前降低故障发生概率的技术,例如改进规格、代码审查、制造测试和环境控制
**故障屏蔽(fault masking)**则让故障不进入系统的信息状态。典型例子是错误检测与纠正码(ECC)和 Hamming 码:存储器中的少量比特错误可以在读出时被纠正,系统外部不必观察到这次故障
容错
**容错(fault tolerance)**是系统在故障发生后仍能继续提供服务的能力,通常包含以下环节:
- 故障/错误检测:识别故障已经发生;
- 故障定位:确定故障发生在哪里;
- 错误遏制:隔离错误,防止其继续传播;
- 错误恢复:保持运行或恢复到可运行状态
在冗余系统中,常将硬件或软件划分为多个 Fault Containment Region(FCR,故障遏制区域)。基本假设是各 FCR 独立失效,一个区域中的故障不能直接导致另一个区域失效
常见恢复方式包括:
- Restart:重启进程或服务;
- Checkpoint and rollback:从最近的检查点回滚;
- Rollforward:根据已保存的信息向前重建状态;
- Replication and failover:使用副本,在主实例失效后切换到备用实例
故障排除与故障预测
**故障排除(fault removal)**包括故障定位、问题诊断和修复。问题诊断比单纯定位更进一步,需要理解错误在系统中的传播路径以及系统为何表现出当前行为
**故障预测(fault forecast)**则根据历史数据、运行状态和模型,预测未来的故障、错误或失效,从而提前维护或迁移服务
可靠性验证
可靠性不能只靠设计者的直觉判断,还需要验证:
- 解析建模:用组合模型、Markov 模型、排队论、Petri 网、状态转移图或奖励模型描述系统,并通过公式或仿真求解;
- 故障注入:在真实系统或测试床中注入故障,观察错误特征和系统响应。注入点可以位于硬件、操作系统内核、编译器、运行时、中间件或应用层;
- 形式化方法:用严格的数学方法验证可靠性性质,例如模型检查;
- 故障仿真:在系统、协议或算法实现之前,先在设计模型中模拟故障;
- 现场数据分析:收集生产系统中的运行数据,分析真实故障行为和系统韧性
故障注入实验至少要明确故障类型、注入时机、注入位置和故障分布,否则实验结果很难解释或复现
寿命随机变量与失效率
令随机变量 表示组件、设备、系统或服务的寿命,也就是从开始运行到失效的时间
分布函数
寿命的累积分布函数(CDF)为:
若 是连续随机变量,其概率密度函数(PDF)为:
失效率
失效率(failure rate)表示单位时间内发生故障的平均次数,记为 。例如某设备平均每运行 小时失效一次,则可以粗略写成:
工程中也常用 FIT(Failures In Time)表示每 小时的失效次数,或者用某些场景下的近似关系:
完整指定一个失效率模型通常需要两部分:失效时间分布,以及分布中的参数值
可靠性函数
可靠性是系统在 内持续无故障运行的概率:
相应地, 也可以称为不可靠度(unreliability):
可靠性是“从开始到现在一直没有坏”的概率,因此它适用于不可修复系统,或一次任务期间不考虑维修的系统
瞬时失效率(Hazard Rate)
在系统已经运行到 且仍然正常的条件下,下一小段时间内发生故障的条件概率为:
令 趋近于 ,得到瞬时失效率,也叫 hazard rate:
平均失效率 是一段时间或一个群体上的统计量,而 描述的是“已经活到 的对象”在此刻的风险
常用建模假设
为了让可靠性模型可解,课件中经常采用以下假设:
- 组件的失效率已经通过测试或现场数据得到较准确的估计;
- 在当前分析区间内,失效率保持常数,因此可以使用指数分布;
- 不同组件的失效相互独立;
- 不同组件的修复过程相互独立
真实系统未必完全满足这些假设,但它们可以先给出一个可计算的基线模型,再通过现场数据和故障注入结果修正模型
常见寿命分布
指数分布
若寿命服从参数为 的指数分布,则:
此时瞬时失效率为常数:
指数分布具有无记忆性:已经运行了多久,不会改变剩余寿命的分布。若 表示运行到 后的剩余寿命,则:
指数分布常用于近似作业到达间隔、服务时间、组件寿命和恢复时间。若两个相互独立、任意一个失效都会导致系统失效的组件失效率分别为 和 ,则组合系统仍可用指数分布描述,且:
低指数分布
若一个过程由多个串行阶段组成,每个阶段服从参数不同的指数分布,则总时间服从低指数分布(hypo-exponential)。以两阶段为例,, 和 的失效率为 ,其 PDF 为:
它适合描述一个任务必须依次经过多个不同组件或阶段的场景
Erlang 分布
Erlang 分布是低指数分布的特例:多个串行阶段的失效率相同。 阶 Erlang 分布的 PDF 为:
两阶段时:
它可以用来描述一个组件被重复处理多次,或者任务需要经过多个相同阶段的情况
超指数分布
若过程从多个阶段中选择一个执行,而不是依次执行所有阶段,则得到超指数分布(hyper-exponential)。若以概率 选择失效率为 的阶段,则:
典型场景是作业根据类别被分派到多个组件中的一个
Weibull 分布与浴盆曲线
Weibull 分布是可靠性分析中非常常用的参数分布。用形状参数 和尺度参数 表示时:
- 时退化为常失效率的指数分布;
- 时失效率随时间增加,常对应磨损老化;
- 时失效率随时间降低,常对应早期缺陷逐渐被淘汰
电子元件常用“浴盆曲线”描述失效率:开始是失效率下降的 burn-in period,中间是失效率近似恒定的正常工作期,最后是失效率上升的 wear-out period。为简化复杂系统的分析,很多模型只取中间的常失效率阶段
可靠性指标
平均失效前时间 MTTF
平均失效前时间(Mean Time To Failure,MTTF)就是寿命的期望:
对指数分布,有:
MTTF 通常用于不可修复组件,或者只关心一次任务从启动到首次失效的场景
恢复率与 MTTR
恢复率(recovery rate,也叫 service rate 或 repair rate)记为 ,表示单位时间能够完成的故障恢复数量。若恢复时间服从参数为 的指数分布,则平均修复时间(Mean Time To Repair,MTTR)为:
硬件通常需要更换部件或切换到备用设备,软件则可能需要重启、回滚或重新加载状态
MTBF 与故障周期
平均故障间隔时间(Mean Time Between Failures,MTBF)描述一次故障到下一次故障之间的平均时间。它包含正常运行时间和故障恢复时间:
这个关系在稳态下成立。故障周期可以画成:
可用性
可用性函数
可靠性要求从开始到 之间一直没有失效,而可用性只关心时刻 是否正在提供服务。令随机过程 为:
则瞬时可用性(point availability)为:
不可用度为:
一个组件即使之前发生过故障,只要在 之前已经修复,仍然可以在 时刻处于可用状态。因此可用性同时受到失效行为和修复行为影响
对不可修复系统:
若系统可以修复, 则一般高于可靠性函数。对于从正常状态开始、失效率为 、恢复率为 的两状态模型:
稳态可用性
系统运行足够长时间后,可用性趋于稳态值:
结合 MTTF 和 MTTR 可以写成更直观的形式:
工程上常说的“五个 9”就是 。提高可用性既可以延长 MTTF,也可以缩短 MTTR
可靠性回答“从开始运行到现在是否一直没有坏”,可用性回答“现在是否正在工作”。可用性高并不代表系统从未失效过
例如,下面两个系统的稳态可用性相同:
| 系统 | MTTF | MTTR | 可用性 |
|---|---|---|---|
| 系统 1 | 1,000,000 | 4 | 0.999996 |
| 系统 2 | 10,000 | 0.04 | 0.999996 |
但是系统 1 很少故障而每次修复较慢,系统 2 经常故障但几乎可以立即恢复;两者对用户、运维和数据一致性的影响并不相同
RTO、RPO 与其他性质
RTO 与 RPO
- RTO(Recovery Time Objective):发生重大故障后,系统必须在多长时间内恢复服务的目标;
- RPO(Recovery Point Objective):发生重大故障时,业务最多可以接受丢失多长时间的数据
RTO 关注“多久恢复”,RPO 关注“最多丢多少数据”。RTO 可以在基础设施层或应用层定义,备份、复制、检查点和灾难恢复方案都需要围绕这两个目标设计
其他可靠性相关性质
- Dependability(可依赖性):系统持续提供可以被合理信任的服务的能力;
- Serviceability(可维护性):预防性维护和纠正性维护的容易程度与速度;
- Resilience(韧性):系统面对故障并保持或恢复服务的能力,通常与容错联系在一起;
- Performance(性能):系统完成任务的能力,例如 MIPS、吞吐量、延迟、丢失概率;
- Performability(可执行性):把性能和可依赖性结合起来,描述系统在可能降级时达到某个性能水平的概率;
- Scalability(可扩展性):在应用场景中,性能随成本增加而扩展的能力;
- High Availability(高可用性):保证约定服务水平和运行时间的系统特征;
- Disaster Recovery(灾难恢复):在地震、飓风等自然灾害或人为灾害后恢复关键技术基础设施和业务的策略与流程
- Cost(成本):比较不同设计方案时需要一起考虑的因素,常用成本/性能比衡量改进是否值得
这些性质之间存在取舍。例如,增加副本可以缩短恢复时间,却会带来存储、同步和运维成本;允许服务优雅降级可以保持可用性,但降级后的性能可能已经低于正常水平
小结
可靠性分析从故障链开始:故障被激活后形成错误,错误传播到外部才成为失效。故障预防、屏蔽、容错、排除和预测分别作用于这条链上的不同位置
在数学上,寿命随机变量 的 CDF 、PDF 、可靠性函数 和 hazard rate 描述了失效随时间的行为。MTTF、MTTR、MTBF 用于描述故障周期,而可用性还要把修复过程纳入考虑。最后,RTO、RPO、可维护性、韧性和灾难恢复把这些指标连接到实际系统设计中