GeoXMind

可用性从故障与恢复来定义

从服务中断、故障检测、恢复目标和降级能力理解可用性，而不是只看一个百分比。

可用性从故障与恢复来定义

可用性描述系统在需要时提供正确服务的程度。一个百分比只有在服务时间、成功条件和排除项明确时才有意义。计划维护是否计入、部分功能降级是否算可用、依赖服务故障由谁承担，都会改变最终数字。

先定义什么叫不可用

首页能够打开但无法登录，算不算系统可用，要看服务承诺。对于内容站点，公开阅读与后台发布可以有不同目标；对于交易系统，读取历史记录正常并不代表支付功能可用。可用性应按用户旅程或关键能力定义，而不是只看进程存活。

健康检查也要与真实服务对应。端口可连接只能说明进程响应，无法证明数据库写入、外部依赖和业务规则正常。深度检查更接近用户路径，却可能增加依赖压力，需要分层设计。

故障检测决定恢复何时开始

组件失效、网络分区、配置错误、资源耗尽和数据损坏需要不同检测信号。检测过慢会延长中断，检测过于敏感则可能在短暂抖动中触发不必要切换。

告警应指向可采取行动的服务影响，而不是每个异常都通知。Google SRE 资料强调从服务级目标和错误预算管理可靠性工作，这有助于把监控与用户影响连接起来。

恢复包含替换、降级与修复

冗余副本可以接管部分故障，但前提是故障相互独立、状态能够同步且流量可以切换。所有副本共享同一配置错误或数据库时，增加副本不能消除共同失效。

降级是保留核心能力的另一种恢复方式，例如搜索暂时退回关键词模式，非关键推荐关闭。降级行为要事先定义并测试，临时在故障中决定往往会产生新的不一致。

恢复时间与数据恢复不是一件事

恢复时间目标关注业务在中断后多久恢复，恢复点目标关注最多可以接受丢失到哪个时间点的数据。服务很快启动，但数据回到数小时前，可能不满足业务；备份很新但恢复步骤需要很久，也无法达到时间目标。

备份只有经过恢复演练才能成为可用性证据。演练应覆盖权限、密钥、外部依赖和人员操作，而不只是确认文件存在。

可用性通过事件历史验证

架构阶段可以分析单点、检测、切换和恢复路径，运行阶段则要记录事件开始、发现、缓解和完全恢复时间。汇总百分比之外，还应查看中断次数、持续时间、受影响能力和重复原因。

SEI 的质量属性资料把故障刺激、环境、响应和度量放入场景。可用性设计因此不是采购高可用产品，而是让指定故障发生时，系统以可验证方式维持或恢复服务。

资料依据