GeoXMind

可靠性关注连续正确服务

说明可靠性如何描述一段时间内持续正确工作的能力，并与可用性、耐久性区分。

可靠性关注连续正确服务

可靠性描述系统在规定条件和时间内持续正确执行功能的能力。它与可用性相关，但并不相同：一个系统发生故障后很快恢复，可能具有较高可用性，却不一定能长时间无故障运行；另一个系统极少故障，但恢复很慢，也可能在中断时表现出较低可用性。

正确服务要先被定义

可靠性分析需要明确什么算失败。崩溃是失败，返回错误数据、重复执行操作、遗漏消息或超过允许时间也可能是失败。只统计进程退出会低估业务层错误。

失败定义还要包含任务时长和环境。设备控制系统可能要求在一次任务期间连续运行，批处理系统则关心每个作业能否最终正确完成。没有观察窗口，就无法解释“故障概率”。

故障、错误与失效位于不同层次

缺陷或外部扰动可能在系统内部形成错误状态，错误传播到服务边界后表现为失效。一个缺陷不一定每次都被触发，内部错误也可能被校验、重试或冗余机制吸收。

区分层次有助于选择措施。测试和静态检查减少缺陷，隔离和校验阻止错误传播，重试和故障转移处理已经出现的失效。把所有问题统称“服务不稳定”，难以定位改进位置。

重试可能提高成功率也可能放大故障

瞬时网络错误可以通过有限重试恢复，但请求必须可安全重复，退避策略也要避免所有客户端同时重试。对非幂等写操作盲目重试，可能造成重复扣款或重复任务。

超时定义了调用方愿意等待多久。超时过短会把正常慢请求视为失败，过长则占用资源并延迟恢复。重试、超时和熔断要作为完整调用链设计，而不是各服务独立采用默认值。

状态正确性是可靠性的核心

服务恢复运行并不证明状态正确。部分写入、乱序事件和副本延迟可能让系统继续返回错误结果。事务、幂等键、校验和、对账与修复工具用于保护状态，但每种机制都有边界。

数据复制提高容灾能力，也会引入一致性和切换问题。需要说明哪些状态允许延迟、哪些操作必须唯一，以及故障恢复后怎样确认副本重新一致。

用长期证据判断可靠性

可靠性证据来自测试、故障注入、运行事件和数据校验。平均故障间隔等指标只在故障定义和观察条件一致时可比较。样本很少时，漂亮数字可能只是尚未经历足够压力。

SEI 的质量属性资料帮助把可靠性写成可分析场景，Google SRE 则从生产运行角度连接服务目标、事件和改进。设计目标应落到具体失效模式、检测与状态保护，而不是笼统要求“永不出错”。

资料依据