Day30-03｜9.1.3 可靠性目标：把“稳定运行”转化为可验收的系统承诺

一、教材定位

可靠性目标是对系统在规定条件、规定时间和规定功能范围内应达到的可靠程度所作的明确要求。它是可靠性需求、架构设计、测试计划、运维监控和服务承诺之间的连接点。没有清晰的可靠性目标，架构团队无法判断是否需要冗余、容灾、补偿和自动恢复，测试团队无法制定通过标准，运维团队也无法确定告警阈值和服务等级。

二、可靠性目标的组成

可靠性目标至少包含对象、条件、时间、功能、指标和边界六部分。对象说明关注整个系统、某个服务、某项任务还是某类业务；条件说明负载、环境、网络、硬件和外部依赖；时间说明运行周期或服务窗口；功能说明必须正确完成的任务；指标说明概率、时间、次数或错误率；边界说明不包含什么情况。

例如，“订单系统可靠性达到99.99%”并不完整。更完整的表达是：在正常生产环境和每秒3000笔峰值请求下，核心订单受理服务在连续30天内可用率不低于99.99%，订单状态最终正确率不低于99.999%，单节点故障后5分钟内恢复，因外部支付平台超时造成的订单必须进入可追踪的待确认或补偿状态。

三、可靠性目标的分层

可靠性目标可以分为业务目标、系统目标、子系统目标和组件目标。业务目标关注用户和组织真正感知的结果，如交易成功、账务一致、任务完成和数据不丢失；系统目标关注全局服务等级；子系统目标分解到订单、支付、消息、数据库和外部适配；组件目标关注队列、缓存、节点和存储的具体指标。

分层时要避免简单平均分配。业务层目标不能机械地拆给每个组件，因为不同组件的串联关系、冗余关系和影响范围不同。应根据业务关键路径和故障模型进行推导。

四、可靠性目标的来源

目标来源包括业务关键程度、用户体验、合同和服务等级协议、监管要求、历史故障、竞争压力、成本预算和技术能力。核心支付、医疗诊断、工业控制和政务审批的可靠性目标通常高于普通内容查询，但目标越高，所需冗余、测试、监控和运维成本也越高。

目标必须与业务损失关联。一个查询接口偶尔失败可能只影响体验，而一次重复扣款、错误放行、处方数据错误或生产控制指令错误可能造成重大损失。架构师应通过业务影响分析确定不同功能的可靠性等级，而不是让整个系统采用同一个模糊目标。

五、可靠性指标的选择

常用指标包括可靠度、失效率、故障间隔、恢复时间、可用率、任务成功率、错误率、数据完整率和业务一致率。指标应选择能够反映目标的度量，不应为了容易采集而使用无关指标。

例如，服务进程存活率不能替代支付结果正确率，消息发送成功率不能替代业务事件处理完成率，数据库备份成功率不能替代恢复可用性。关键业务应建立端到端指标和组件指标两层体系，并明确二者之间的关系。

六、目标与成本的权衡

可靠性目标不是越高越好。可用率从99%提高到99.9%、99.99%和99.999%，意味着允许的不可用时间迅速减少，对冗余、监控、自动切换、发布策略和灾备演练提出更高要求。强一致、零数据丢失和极短恢复时间也会增加硬件、网络、存储和运维成本。

架构评估要比较目标带来的业务收益和实现成本。对于低价值、低风险功能，不应采用与核心交易相同的多活和强一致方案；对于关键业务，也不能为了节省成本而把不可接受的风险留给用户。最终应形成分级可靠性策略和明确的风险接受记录。

七、可靠性目标的分解方法

分解可以沿业务流程、系统层次、故障域和时间阶段进行。沿业务流程分解为受理、处理、确认、结算和通知；沿系统层次分解为网关、服务、数据库、消息和外部依赖；沿故障域分解为进程、节点、机房、地域和供应商；沿时间阶段分解为故障检测、切换、恢复、校验和补偿。

分解后要检查是否形成完整闭环。例如目标是“订单五分钟内恢复”，就必须拆成故障检测时间、切换时间、未完成请求处理时间、数据恢复时间、业务校验时间和用户状态同步时间。各部分时间之和不能超过总体目标，还要保留一定余量。

八、可靠性目标与架构策略

不同目标对应不同策略。高可用目标需要冗余、故障检测和自动切换；低数据丢失目标需要同步复制、持久化、日志和备份；快速恢复目标需要自动化恢复、回滚、预案和演练；高任务成功率需要输入校验、状态机、幂等、事务和补偿；高可维护性目标需要模块边界、自动化测试和可观测性。

策略不是指标本身。采用集群不等于达到可用率目标，采用事务不等于业务结果一定一致，采用重试不等于任务一定可靠。目标必须通过场景和测试验证，策略还要考虑故障传播、资源成本和运维能力。

九、可靠性目标的验证

验证包括需求评审、架构分析、原型、性能测试、稳定性测试、故障注入、恢复演练、安全测试、数据校验和运行监控。目标制定时就要定义验证方式，避免项目最后才发现某项目标无法测量。

验证结果要区分设计承诺、测试结果和生产结果。设计上可行不等于实验满足，实验满足也不等于长期生产满足。生产运行中要持续收集故障、恢复、业务失败和数据一致性指标，并在版本、流量和环境发生变化时重新评估。

十、案例分析：医院预约平台可靠性目标

某医院预约平台包含挂号、号源、支付、取消和通知功能。业务分析后将目标分级：号源扣减和支付属于关键交易，要求重复请求不能重复扣费，预约状态必须最终正确；查询和推荐属于一般功能，允许短时降级；通知服务允许延迟，但不能导致预约状态错误。

架构上，号源服务维护权威库存，使用短事务、幂等键和超时释放；支付服务使用待确认状态和对账；通知采用异步事件、重试和死信；查询采用缓存和读扩展，缓存异常时回源或降级。测试包括峰值抢号、重复提交、支付回调乱序、数据库故障、通知积压和恢复后对账。

这个案例说明可靠性目标应按业务风险分级，而不是把所有功能都按同一标准建设。目标、策略、测试和成本之间形成了可解释的对应关系。

十一、常见问题

第一，目标使用形容词，没有数字、时间和条件。第二，只制定系统可用率，不制定业务正确性和数据完整性。第三，目标没有责任人和验证方法。第四，组件指标与业务目标脱节。第五，为追求高目标堆叠复杂技术，却没有足够运维能力。第六，目标制定后不随业务规模、版本和故障数据更新。

十二、练习题

题1

如何把“支付系统必须可靠”改写为可靠性目标？

参考答案

应明确环境、负载、时间和业务功能。例如在生产峰值负载下，支付请求不得因重复提交产生重复扣款；外部渠道超时后必须在规定时间内进入可查询的待确认状态；每日支付与账务对账一致率达到目标；支付核心节点故障后在规定时间内恢复并完成未决交易校验。

题2

可靠性目标为什么需要分层？

参考答案

业务目标需要落到系统、子系统和组件的具体设计与测试。分层可以明确责任、建立指标关系和安排验证，但不能简单平均拆分，必须结合关键路径、故障域和组件依赖进行推导。

题3

为什么高可用目标会增加系统复杂度？

参考答案

高可用需要冗余、健康检查、自动切换、状态处理、数据复制、监控、演练和恢复，可能引入一致性、配置、网络和运维复杂度。因此应结合业务价值和成本分级设定目标，不能盲目追求最高可用率。

十三、论文写作素材

论文中可以写“项目没有笼统提出可靠性要求，而是按业务风险建立分级目标：核心交易关注结果正确、数据完整和恢复时间，一般查询关注可用性和降级体验，通知功能关注可追踪和最终送达。随后将业务目标分解到服务、数据、消息和部署层，分别采用幂等、状态机、补偿、冗余和监控策略，并通过压测、故障演练、对账和运行指标验证，形成目标—策略—证据闭环。”

十四、今日复盘

可靠性目标必须包含对象、条件、时间、功能、指标和边界；目标应分层、分级并与业务损失关联；组件指标不能替代端到端业务指标；目标制定时就要明确验证方式、成本、责任人和复评机制。