Day30-01｜9.1.1 软件可靠性定义：理解系统在规定条件下持续正确运行的能力

一、教材定位

软件可靠性是系统架构设计师必须掌握的基础质量属性，也是后续可靠性建模、可靠性管理、可靠性设计、可靠性测试和可靠性评价的概念基础。很多人把“可靠”简单理解为系统不宕机，实际上可靠性既包括持续运行，也包括在规定条件、规定时间和规定功能范围内正确完成任务。一个服务进程虽然没有停止，但持续返回错误数据，也不能认为是可靠的。

二、软件可靠性的定义

软件可靠性是软件系统在规定的条件下、规定的时间内完成规定功能的能力。这个定义包含四个必须同时明确的部分：系统对象、运行条件、时间范围和规定功能。

第一，软件系统可能是一个程序、服务、平台、嵌入式软件或由多个软硬件部件组成的整体。第二，规定条件包括输入分布、负载、硬件、网络、操作环境和外部依赖。第三，规定时间可以是一次任务持续时间、连续运行周期或某个服务窗口。第四，规定功能不仅是“接口返回成功”，还包括业务结果正确、数据完整和约束得到满足。

如果缺少这些限定，“系统可靠性很高”就无法被客观判断。同一个系统在测试环境中运行稳定，在高峰负载、网络抖动或数据规模增长后可能表现完全不同。

三、可靠性与相关概念的区别

1. 可靠性与可用性

可用性关注系统在需要时是否处于可使用状态，常用可用率、故障时间和恢复时间衡量；可靠性关注系统在一段时间内无故障、正确完成任务的能力。一个系统可以通过快速重启保持较高可用率，但频繁发生错误和短暂故障，可靠性并不一定高。

2. 可靠性与正确性

正确性关注系统在特定输入下是否给出符合规范的结果，可靠性关注系统在规定条件和时间内持续正确运行。正确性是可靠性的基础，但可靠性还包含连续运行、异常处理、恢复和故障概率。

3. 可靠性与安全性

安全性关注系统抵抗未授权访问、攻击、破坏和数据泄露的能力。安全漏洞可能导致系统不能正常提供服务或产生错误结果，从而影响可靠性；但两者关注角度不同，安全测试不能替代可靠性测试。

4. 可靠性与容错性

容错性是系统发生故障时仍能继续提供部分或全部正确服务的设计能力，属于提高可靠性的手段。可靠性是目标属性，容错是实现该目标的策略之一。

四、软件故障、错误和失效

可靠性分析常区分故障、错误和失效。故障是软件或环境中的缺陷、异常或不正确状态来源；错误是系统内部进入不正确状态；失效是系统对外表现出未能完成规定功能的行为。

例如，配置文件中把超时时间写成负数属于故障；程序读取配置后进入非法状态属于错误；服务持续拒绝合法请求属于失效。一个故障可能长期没有触发错误，一个错误也可能被校验、回滚或容错机制隔离，只有当错误传播到外部并影响规定功能时才表现为失效。

这种区分有助于架构师选择防护措施：通过评审和静态检查减少故障，通过校验和隔离阻止错误传播，通过容错、降级和恢复减少失效影响。

五、可靠性与时间因素

软件可靠性具有明显的时间属性。系统刚上线时可能缺陷较多，经过修复后失效概率下降；频繁修改和复杂环境变化又可能引入新缺陷。软件不像硬件那样自然磨损，但运行环境、数据规模、配置、依赖和版本变化会改变失效条件。

可靠性目标必须说明时间范围，例如“连续运行30天内核心交易失败率不超过某阈值”“单次任务在规定时间内完成的概率达到某水平”“升级后连续运行一周无重大故障”。没有时间范围，可靠性指标就缺少意义。

六、软件可靠性的影响因素

影响可靠性的因素包括需求质量、设计结构、实现质量、测试覆盖、运行环境、数据质量、外部依赖、运维过程和变更管理。

需求如果存在歧义，系统可能在技术上运行正常却不满足业务；架构如果存在单点和强耦合，局部故障容易扩大；实现如果缺少边界校验，异常输入可能造成失效；测试如果只覆盖正常流程，隐藏故障不会被发现；运行环境如果配置不一致，生产行为可能与测试不同；变更如果没有灰度和回滚，稳定系统也可能被新版本破坏。

因此可靠性不是测试团队单独负责，而是由需求、架构、开发、测试、安全、运维和管理共同形成。

七、可靠性目标的表达

可靠性目标应使用可验证指标表达。常见指标包括失效概率、失效率、平均无故障时间、平均修复时间、任务成功率、数据完整率、故障恢复时间和业务错误率。

在业务系统中，还应关注业务层可靠性。例如支付请求的接口成功率不代表扣款结果可靠，必须确认订单、支付、账务和通知之间的状态能够正确协调；消息系统的投递成功率不代表业务事件被正确处理，还要验证重复、乱序和补偿。

八、架构设计对可靠性的影响

架构层面的可靠性策略包括模块隔离、冗余、故障检测、超时控制、限流、熔断、降级、重试、幂等、事务、补偿、数据校验、备份恢复、审计和可观测性。

这些策略必须结合故障模型使用。重试适合暂时性网络错误，但对业务拒绝和永久性错误盲目重试会放大故障；熔断可以保护调用方，但需要降级和恢复探测；冗余可以减少节点故障影响，但如果共享数据库和配置仍是单点，整体可靠性不会自动提高；备份只有经过恢复演练，才能证明具有恢复价值。

九、案例分析：在线缴费系统可靠性

某在线缴费系统需要支持账单查询、缴费、退款和对账。系统初版只关注接口可用率，采用重试机制处理所有失败。上线后，外部支付平台超时时，系统不断重试，产生重复扣款风险；通知服务失败时，订单状态和用户提示不一致；数据库主节点切换后，部分支付记录需要人工核对。

重新进行可靠性分析后，团队区分技术故障和业务结果：支付请求使用业务幂等键，外部超时进入“待确认”状态，不直接判定失败；通过支付查询和对账任务确认最终结果；通知事件独立处理，失败进入重试和死信队列，不阻塞账务状态；数据库切换后执行数据校验和未完成事务恢复；关键操作增加审计和追踪ID。

最终可靠性目标不再是“接口成功率高”，而是“每笔缴费最终具有明确状态，重复请求不产生重复扣款，账务可对账，故障能够被发现和补偿”。

十、可靠性生命周期

可靠性应贯穿软件生命周期。需求阶段定义可靠性目标和业务影响；架构阶段建立故障模型和策略；设计阶段明确状态、事务和恢复；实现阶段落实校验、日志和错误处理；测试阶段进行可靠性测试和故障注入；部署阶段建立备份、监控和回滚；运行阶段收集失效数据并改进；退役阶段保证数据迁移和服务切换。

十一、练习题

题1

为什么“服务进程没有停止”不能直接说明系统可靠？

参考答案

可靠性要求系统在规定条件和时间内正确完成规定功能。进程虽然存在，但如果持续返回错误、产生错误数据、丢失请求或无法完成业务，也属于失效。应结合业务正确性、数据完整性和任务成功率判断。

题2

区分故障、错误和失效。

参考答案

故障是缺陷或异常来源，错误是系统内部进入不正确状态，失效是对外没有完成规定功能。故障可能被检测和隔离，错误只有传播到外部并影响服务时才表现为失效。

题3

为什么重试可能降低可靠性？

参考答案

对于非幂等业务，重复重试可能产生重复扣款、重复创建和重复通知；对于永久性错误，重试会增加负载并扩大故障。应区分暂时错误和永久错误，结合幂等、退避、熔断、死信和补偿使用。

十二、论文写作素材

论文中可以写“项目将可靠性定义为系统在规定负载和运行周期内持续正确完成关键业务的能力，而不只关注服务是否在线。团队建立故障模型，针对网络超时、节点故障、重复请求、消息失败和数据库切换设计幂等、状态机、重试、补偿、冗余和恢复策略，并通过故障注入、对账、恢复演练和运行指标验证。最终将接口可用性目标提升为业务结果正确、数据完整和故障可恢复目标。”

十三、今日复盘

软件可靠性定义的关键词是：规定条件、规定时间、规定功能、正确完成。要掌握可靠性与可用性、正确性、安全性和容错性的区别，理解故障—错误—失效链条，并能够把可靠性目标转化为架构策略、测试场景和业务指标。