Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 61070: 系统可用性如何”验货”——稳态可用性合规试验的工程实践
一、可用性的工程本质——不只是 MTBF 和 MTTR 的算术
在电力、通信、数据中心和过程工业中，工程师经常听到一句话：”这个系统的可用性是 99.99%。”这个数字看起来很美，但它到底是怎么来的？更重要的是——你怎么验证它是真的？
IEC 61070《稳态可用性合规试验程序》(Compliance test procedures for steady-state availability)正是为此而生。它提供了一套标准化的统计方法，用来验证系统是否真的达到了标称的稳态可用性指标。
1.1 可用性的数学定义
稳态可用性 (Steady-State Availability) 的核心公式简洁而深刻：
A = MTBF / (MTBF + MTTR)
其中 MTBF = 平均故障间隔时间 (Mean Time Between Failures)
MTTR = 平均修复时间 (Mean Time To Repair)
这个公式揭示了可用性工程的三个核心洞察：
- 可用性是可靠性与维修性的博弈结果。提高 MTBF（让设备更不容易坏）和降低 MTTR（让修复更快）都能提升可用性，但二者的成本曲线截然不同。
- 可用性是对数敏感而非线性敏感的。从 99.9% (三个9) 提升到 99.99% (四个9)，看起来只差了 0.09%，实际上年停机时间从 8.76 小时骤降到 52.6 分钟——这是数量级的差异。
- 稳态意味着系统已经进入统计平衡。可用性在系统生命初期会波动（”早期失效”期），只有进入稳定运行阶段后，”稳态”假设才成立。IEC 61070 的试验设计正是基于这一前提。
工程洞察: 如何理解”9的个数”
一个”五个9″(99.999%)的系统每年仅允许约 5.26 分钟的停机。这意味着你的 MTTR 必须被压缩到极致——如果平均每年发生 1 次故障，那么修复时间不能超过 5 分钟。这就是为什么电信核心网设备在硬件冗余之外，还必须配以热插拔、自动故障切换和无中断升级能力。
一个”五个9″(99.999%)的系统每年仅允许约 5.26 分钟的停机。这意味着你的 MTTR 必须被压缩到极致——如果平均每年发生 1 次故障，那么修复时间不能超过 5 分钟。这就是为什么电信核心网设备在硬件冗余之外，还必须配以热插拔、自动故障切换和无中断升级能力。
1.2 IEC 61070 标准的位置
IEC 61070:1991 属于 IEC 标准体系中”可靠性管理”和”可靠性验证”板块。它与下列标准形成互补：
- IEC 60605 系列 — 设备可靠性试验 (Equipment reliability testing)
- IEC 61025 — 故障树分析 (Fault Tree Analysis, FTA)
- IEC 60812 — FMEA/FMECA 分析
- IEC 60706 — 维修性 (Maintainability)
- IEC 60300 系列 — 可信性管理 (Dependability Management)
不同于单纯测 MTBF 的可靠性试验，IEC 61070 的独特之处在于它同时考察了系统的”抗故障能力”（可靠性）和”恢复能力”（维修性），并用一个综合指标——可用性——来评判系统是否达标。
二、IEC 61070 合规试验方法——如何设计一个科学的可用性验证
IEC 61070 的核心贡献是提供了一套统计上严谨的试验方案框架。它不告诉你怎么测某一个特定系统的可用性，而是给出了通用的试验规划、执行和判定方法论。
2.1 试验规划五步法
- 定义可用性目标值 A₀ — 合同或技术规范要求的稳态可用性指标（如 ≥ 0.9995）
- 定义可接受的最低可用性 A₁ — 低于此值用户将无法接受。A₁ < A₀，二者之间的差距决定了试验的鉴别比 (Discrimination Ratio)
- 选择生产者风险 α 和消费者风险 β — 典型的 α = 0.05 (5%), β = 0.10 (10%)，分别对应”误拒合格系统”和”误收不合格系统”的概率
- 选择试验方案类型 — 定时截尾 (Fixed-duration)、定数截尾 (Fixed-failure-count) 或序贯试验 (Sequential test)
- 计算所需试验时长或故障数 — 基于统计公式和 OC 曲线 (Operating Characteristic curve) 确定样本量
2.2 三种试验方案对比
下表总结了 IEC 61070 框架下常用的三种可用性合规试验方案：
| 方案类型 | 核心思路 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 定时截尾试验 (Fixed-Duration Test) |
在预定时长 T 内观察系统，记录总停机时间 D。若 D/T ≤ 限值则通过 | 试验周期可预测，易于项目管理 | 样本量较大才能达到统计置信度；可能浪费试验时间 | 项目进度严格受限，需要确定性的试验截止日期 |
| 定数截尾试验 (Fixed-Failure-Count Test) |
累计到预定故障次数 r 后停止。基于累积停机时间判定 | 统计效率高，总能获得足够的故障数据 | 试验持续时间不可预测（可靠系统可能跑很久） | 可靠性水平中等、故障率已知或可估计的产品 |
| 序贯试验 (Sequential Test) |
边测边判：根据累积的 (故障数, 停机时间) 数据点与决策边界比较，随时做出通过/拒收/继续的决定 | 平均试验时间最短（约节省30-50%），高可靠系统可快速通过 | 试验时长不确定；需要实时数据记录和绘图能力 | 昂贵或稀缺样本，希望以最小的试验代价做出判定 |
| 序贯验后加权试验 (SPRT-Generalized) |
序贯概率比检验的扩展形式，适用于复杂系统可用性验证 | 理论最优的统计效率 | 实施复杂度高，需要专业的统计软件支持 | 高价值、长周期的系统（如核电站安全系统、航空电子设备） |
2.3 关键统计考量：OC 曲线与置信区间
任何统计试验都无法做到 100% 正确。IEC 61070 要求试验设计者理解并权衡两类错误：
警惕两类统计错误
第一类错误（生产者风险 α）：系统实际合格，但试验结论判定为不合格——生产商承担了不必要的损失。
第二类错误（消费者风险 β）：系统实际不合格，但试验结论判定为合格——用户拿到的是不达标的产品。
第一类错误（生产者风险 α）：系统实际合格，但试验结论判定为不合格——生产商承担了不必要的损失。
第二类错误（消费者风险 β）：系统实际不合格，但试验结论判定为合格——用户拿到的是不达标的产品。
IEC 61070 通过 OC 曲线 (Operating Characteristic Curve) 将这两类风险可视化。好的试验方案应在 A ≥ A₀ 时高概率通过 (≥ 1-α)，在 A ≤ A₁ 时高概率拒收 (≤ β)。
OC 曲线是 IEC 61070 的核心工具之一。它绘制了”系统真实可用性”与”试验通过概率”之间的关系。一个”陡峭”的 OC 曲线意味着试验对新系统有很强的判别力——可用性稍低于目标就会大概率被拒收。
实战技巧: 如何确定试验时长
假设要验证一个系统是否达到 A₀ = 0.999（年停机 8.76h），A₁ = 0.995（年停机 43.8h），α = 0.05，β = 0.10。采用定时截尾方案，所需的近似试验时长可以用如下经验公式估算：
假设要验证一个系统是否达到 A₀ = 0.999（年停机 8.76h），A₁ = 0.995（年停机 43.8h），α = 0.05，β = 0.10。采用定时截尾方案，所需的近似试验时长可以用如下经验公式估算：
T ≈ [ (z₁₋α + z₁₋β) / (A₀ – A₁) ]² × A₀ × (1 – A₀) / MTBF
这意味着可用性目标的鉴别比 (A₀/A₁ 或 U₁/U₀) 越小（目标越接近限值），所需试验时间就越长——有时会昂贵到不切实际。合理设定 A₁ 是试验规划中最容易被低估的环节。
三、可用性工程的常见陷阱与高可用系统设计洞察
3.1 常见错误——为什么你的可用性数字可能不靠谱
在二十余年的可靠性工程实践中，以下错误屡见不鲜：
- 陷阱一：将”设计可用性”当作”实测可用性”。用供应商提供的 MTBF 和 MTTR 做算术得出 99.99%，但这是纸面数字——实际运行中的故障模式、人为差错、软件缺陷和环境应力都可能大幅偏离模型假设。
- 陷阱二：忽略隐蔽故障 (Hidden Failures)。冗余系统的备份通道可能在主通道正常时悄然失效。如果不做定期诊断测试，这些”沉睡”的故障不会被计入停机时间——直到你需要切换的那一天才发现它根本不能工作。
- 陷阱三：混淆可用性与可靠性。一个每天自动重启的服务器可以有 100% 的可靠性（从未意外故障），但可用性只有 99.3%（每次重启需要 10 分钟）。反之，一个从不断电但每年死机两次、每次需要两天修复的系统，可靠性很差但可用性可能不低。
- 陷阱四：小样本下的自欺欺人。让一个系统运行 1000 小时不出故障，就推断其 MTBF > 100000 小时（置信度 60%）。这种外推是危险的——置信区间的宽度在样本有限时非常惊人。IEC 61070 强调的正是规范的统计推断而非一拍脑袋的结论。
- 陷阱五：忽略预防性维护的停机贡献。很多可用性计算只考虑”修复性维护”的停机，而忽略了定期预防性维护 (PM) 的停机时间。对于某些流程工业系统，PM 停机可能占全年停机的 60% 以上。
致命误区: “共因故障”对高可用系统的毁灭性打击
工程中最惨痛的可用性教训几乎都涉及共因故障 (Common Cause Failure, CCF)。双冗余电源如果共用同一块背板，背板短路将同时摧毁两路供电；双机热备如果运行同一版本固件，固件 bug 会同时触发两台机器宕机。IEC 61070 的试验环境如果未能模拟真实的共因条件，测试结果就没有工程意义。设计高可用系统时，异构冗余 (Diverse Redundancy)——使用不同原理、不同供应商或不同版本的备份方案——是抵御 CCF 的最有力武器。
工程中最惨痛的可用性教训几乎都涉及共因故障 (Common Cause Failure, CCF)。双冗余电源如果共用同一块背板，背板短路将同时摧毁两路供电；双机热备如果运行同一版本固件，固件 bug 会同时触发两台机器宕机。IEC 61070 的试验环境如果未能模拟真实的共因条件，测试结果就没有工程意义。设计高可用系统时，异构冗余 (Diverse Redundancy)——使用不同原理、不同供应商或不同版本的备份方案——是抵御 CCF 的最有力武器。
3.2 高可用系统设计的工程洞察
基于 IEC 61070 的可用性思维方式，以下设计原则值得每一位系统工程师深思：
- 可用性瓶颈不在你想象的地方。用故障树对历史数据做 Pareto 分析后你会发现，80% 的停机时间通常来自 20% 的故障模式。集中资源消除这些”少数关键”比平均用力有效得多。
- MTTR 的压缩通常比 MTBF 的提升更具性价比。将 MTBF 从 10 年提升到 20 年可能需要更换所有器件为宇航级，成本暴涨 100 倍。而通过模块化设计、现场备件策略和远程诊断能力将 MTTR 从 8 小时降到 2 小时，成本可能只需增加 20%。可用性公式中的分母对这两个参数是对称的——但对成本的影响远不对称。
- “五个9″系统真正的门槛不是技术，而是运维体系。99.999% 的可用性意味着每年不超过 5 分 15 秒停机。在这个水平上，任何计划外的停机探测、诊断、响应和恢复链条中都不得有超过个位数分钟级的延迟。这需要的不仅是冗余硬件，更是一个经过严苛演练的运维团队和成熟的自动化运维平台。
- 可用性是系统的属性，不是部件的总和。即使每个部件都达到 99.9% 可用性，串联起来的系统可用性会灾难性地下降（N 个串联部件的系统可用性 ≈ A₁ × A₂ × … × A_N）。架构设计——串联 vs. 并联 vs. k-out-of-n 表决——在决定最终系统可用性时比单个部件的可靠性数据更重要。
| 架构类型 | 系统可用性公式 (近似) | 示例 | 关键洞察 |
|---|---|---|---|
| 串联系统 | A_sys ≈ A₁ × A₂ × … × A_N | 10 个 A=0.999 的部件串联 → A_sys ≈ 0.990 | 串联越多，可用性越差。长链系统的可用性灾难 |
| 并联冗余 (1oo2) | A_sys ≈ 1 – (1-A)² | 双冗余 A=0.99 → A_sys ≈ 0.9999 | 冗余是最有效的可用性提升手段，但代价是成本翻倍 |
| k-out-of-n 表决 | A_sys ≈ Σ C(n,i)·A^i·(1-A)^{n-i} | 2oo3 表决: 3 个 A=0.99 → A_sys ≈ 0.9997 | 同时实现高可用和高安全性的经典方案 |
| 串联+并联混合 | 分块计算后串联 | 数据中心：供电 2N+网络双活+存储 RAID | 真实系统的可用性由最弱块决定，逐层分析是关键 |
工程经验法则: 可用性六边形模型
系统可用性不是单一维度的工程问题，而是六股力量的平衡：
(1) 硬件可靠性 — 器件选型、降额设计、环境适应性
(2) 软件健壮性 — 内存管理、异常处理、看门狗
(3) 冗余架构 — N+1、2N、分布式共识
(4) 故障检测速度 — 健康检查、心跳、自诊断
(5) 故障恢复能力 — 自动切换、数据同步、状态重构
(6) 运维成熟度 — 告警响应、变更管理、根因分析
任何一面薄弱，可用性的”水桶”就从那里漏水。IEC 61070 的试验可以帮助你量化当前的可用性水平，但要提升它，必须从这六个维度系统地迭代改进。
系统可用性不是单一维度的工程问题，而是六股力量的平衡：
(1) 硬件可靠性 — 器件选型、降额设计、环境适应性
(2) 软件健壮性 — 内存管理、异常处理、看门狗
(3) 冗余架构 — N+1、2N、分布式共识
(4) 故障检测速度 — 健康检查、心跳、自诊断
(5) 故障恢复能力 — 自动切换、数据同步、状态重构
(6) 运维成熟度 — 告警响应、变更管理、根因分析
任何一面薄弱，可用性的”水桶”就从那里漏水。IEC 61070 的试验可以帮助你量化当前的可用性水平，但要提升它，必须从这六个维度系统地迭代改进。
常见问题 (FAQ)
Q1: IEC 61070 说的是”稳态”可用性，那系统的早期阶段（浴盆曲线的早期失效期）怎么处理？
IEC 61070 明确指出，试验应在系统完成老化/早期失效筛查 (Burn-in / Early Failure Screening) 之后、进入稳定运行阶段时进行。标准假设系统已经度过了浴盆曲线的”早期失效期”，故障率已趋于恒定。实际操作中，通常会在正式试验开始前设置一段”预调节期”(Pre-conditioning Period) 来消除早期失效数据对稳态判断的干扰。对于软件密集型系统，”早期失效”可能对应新版本上线后的磨合期，这期间的可用性数据不应纳入合规判定。
Q2: 对于运行中不断产生数据的在线系统，IEC 61070 的试验是否可以基于历史运营数据而非专门安排的试验？
可以，IEC 61070 允许使用现场数据的回顾性分析 (Retrospective Analysis of Field Data) 来代替专门的试验。但前提条件是：(a) 数据记录完整且可追溯——每次停机的起止时间、原因分类、修复动作都必须记录；(b) 运行条件在考察期内保持稳定——不能混入调试期、重大变更期或异常工况的数据；(c) 样本量足够——IEC 61070 提供的统计表格和 OC 曲线可以帮助评估已有数据是否具备统计说服力。实践中，现场数据的回顾性分析往往比专项试验更经济，但数据质量参差不齐是最大挑战。
Q3: MTBF 和 MTTR 是否必须服从指数分布，IEC 61070 才能使用？
IEC 61070 的标准试验方案主要基于指数分布假设（即故障间隔时间和修复时间均服从指数分布）。这是因为在稳态运行阶段，指数分布（恒定故障率）是对电子和机电系统最合理的近似。但如果实际数据表明分布严重偏离指数（例如机械磨损件的威布尔分布 β > 1），则需要采用非参数方法或基于特定分布的修正方案。IEC 61070 在附录中提供了偏离指数假设时的处理建议。关键原则是：如果分布不是指数型的，用基于指数假设的方法得出的置信区间可能过于乐观或过于保守。
Q4: IEC 61070 和常见的”可靠性鉴定试验”(如 IEC 60605) 有什么区别？
核心区别在于评估的维度不同：
IEC 60605 (可靠性试验) 关注的是”会不会坏” (MTBF)，完全忽略维修时间的影响。它适用于研究系统固有的故障倾向。
IEC 61070 (可用性试验) 关注的是”坏了之后多久能恢复”与”多久坏一次”的综合效果。它适用于评价系统在真实运维环境下的整体服务能力。
一个直观的例子：两个系统 MTBF 都是 1000 小时，系统 A 每次故障需要 1 小时修复 (A = 99.9%)，系统 B 每次需要 100 小时修复 (A = 90.9%)。在 IEC 60605 的视角下二者相同；在 IEC 61070 的视角下，系统 A 比系统 B 好一个数量级。对于最终用户来说，IEC 61070 的结论显然更有实际意义。
