可用性

可用性是一种系统能力 + 组织能力的综合结果

可用性的第一性原理

不可违背的客观事实

  1. 故障一定会发生

    • 硬件会坏
    • 软件必然有 Bug
    • 网络一定不可靠
    • 人一定会犯错

  2. 网络分区不可避免

    • 分布式系统无法获得全局一致视图
    • 状态判断永远存在不确定性

  3. 状态决策不可能 100% 正确

    • 主备切换、多主选举一定存在误判
    • 所谓"正确"只是概率更高

  4. 可用性是概率，不是确定性

    • 高可用 ≠ 不宕机
    • 高可用 = 快速恢复 + 可控影响

  5. 人是系统的一部分

    • 既是修复者
    • 也是最大的不稳定源

高可用的本质，是与不确定性共存，而不是消灭它

高可用设计的核心权衡

权衡 来源
一致性 vs 可用性 网络分区不可避免、状态决策不可能100%正确
成本 vs 风险 越高的可用性，价格越贵——每提升一个9，成本指数增长，但风险降低边际递减
自动化 vs 可控性 人是系统的一部分，也是最大不稳定源
复杂度 vs 收益 过度设计引入新风险——只在必要处投入复杂度，追求适度复杂而非消灭所有不确定性

高可用设计7大核心原则

原则 核心思想 实践要点
少依赖原则 能不依赖就不依赖，越少越好 系统间有依赖就有风险传递，应优先考虑无依赖设计
弱依赖原则 强依赖转化为弱依赖 异步化、解耦、设置合理超时；如积分服务故障不影响交易核心链路
分散原则 鸡蛋不放一个篮子，分散风险 避免全局只有一份，数据/服务多副本部署
均衡原则 均匀分散风险，避免不均衡 负载均衡权重合理，避免某台机器过载
隔离原则 控制故障不扩散、不放大 代码/线程/进程/读写/数据隔离，隔离级别越高容灾能力越强
无单点原则 有冗余有退路，快速切换能力 冗余设计、快速止血（切换/回滚/扩容），单点限制整体可靠性
自我保护原则 少流血，牺牲一部分保护核心 限流、降级等主动保护机制，极端情况下可控损失

核心概念与指标体系

核心属性

概念 本质 关注点
可靠性（Reliability） 持续无故障运行的概率 宕机次数
可用性（Availability） 系统可被使用的时间比例 宕机时长
稳定性（Stability） 行为一致性与退化趋势 抖动、劣化

三者共同构成系统的持续服务能力

关系 说明
可靠性 → 可用性 可靠性是前置条件：频繁故障必然累积宕机时长，MTBF 缩短直接拉低可用性
稳定性 → 可靠性 性能抖动、逐步劣化意味着 MTBF 缩短，系统趋近故障边缘而不自知
高可靠性 ≠ 高可用性 系统从不宕机，但恢复耗时过长 → 可用性仍低
高可用性 ≠ 高可靠性 快速恢复能力掩盖了频繁小故障的本质，可靠性仍然差

可靠性解决"少坏"，稳定性解决"少抖"，可用性是最终结果——但任一者的短板都会拖累整体

核心指标

Availability = MTBF / (MTBF + MTTR)

业务维度：

服务级别体系

概念 全称 作用 视角
SLI Service Level Indicator 实际测量的指标 度量
SLO Service Level Objective 目标值 内部目标
SLA Service Level Agreement 对外承诺/合同 外部承诺 
SLI（实际测量） → SLO（目标值） → SLA（对外承诺）
    ↓                ↓              ↓
  我实际怎样      我要达到什么      我保证什么

与 RTO/RPO 的区别：

可用性能力分层模型

L5 组织与治理能力（文化、流程、演练）
L4 业务连续性能力（RTO / RPO）
L3 系统级可用性（MTTR）
L2 组件级可靠性（MTBF）
L1 基础设施可靠性

越往上，越偏人和组织；越往下，越偏技术

架构性手段（设计期：降低故障概率）

冗余（Availability 的基础）

关键认知：

冗余并不能保证高可用，只是提供"选择权"

状态决策的三种模式

本质问题：

状态信息本身也是不可靠的

隔离（控制故障影响面）

隔离的目标

隔离能力树

隔离能力
├─ 资源隔离
│  ├─ 线程
│  ├─ 进程
│  └─ 机器
├─ 流量隔离
│  ├─ 正式 / 压测
│  ├─ 爬虫
│  └─ 链路
├─ 数据隔离
│  ├─ 读写分离
│  └─ 多中心
├─ 机房隔离
│  ├─ 同城
│  ├─ 异地
│  └─ 跨国

存算分离（复杂度转移）

让计算节点无状态，是提升可用性的关键简化手段

运行时控制手段（故障发生时）

限流 / 熔断 / 降级的角色划分

手段 保护对象 本质
限流 服务提供方 资源保护
熔断 服务调用方 自我保护
降级 系统整体 有损服务

降级的业务哲学

降级类型抽象

降级策略
├─ 数据降级（默认值 / 静态值 / 缓存）
├─ 功能降级（关闭非核心）
├─ 流量降级（限流）
├─ 写降级（异步 / 延迟）
├─ 前端降级（静态化）

其他运行时手段

手段 时机 本质
切换（Failover） 故障后 主备/多活自动切换，提供备选路径
扩容（弹性伸缩） 故障中 增加处理能力扛住流量
重试（Retry） 故障中 失败请求自动重试，指数退避避免雪崩

变更与治理（人为风险控制）

变更是最大风险源

大部分事故不是系统设计错误，而是变更失控

变更生命周期

数据逻辑保护

数据变更是不可逆风险最高的操作

容灾与业务连续性（极端场景）

容灾的层次

DRP / BCP 的本质

容灾不是技术方案，而是组织应急能力

可观测性与健康治理

监控的四个维度

架构健康的三大对象

架构健康
├─ 应用健康
├─ 环境健康
└─ 依赖健康

目标不是"零问题"，而是：

问题可预期、可发现、可处理

评估与持续演进

FMEA：事前失败分析

SRE 文化

适用边界

可用性是成本函数，不是越高越好

每提升一个9，成本指数增长。超出业务需求的可用性是资源浪费。

服务必须分级，资源必须差异化投放

核心与非核心不等量齐观。有限资源优先保障核心链路。

低价值场景不需要高可用

内部工具、后台系统、一次性任务等非用户Facing服务，应允许中断。

过度设计的危害不亚于低可用

用微服务架构支撑小业务、用5个9保护可容忍中断的系统，这是另一种风险。

业务中断损失是决策基准

可用性目标应由业务中断损失决定，而非技术洁癖。算清账再投入。

生存期优先于可用性

PMF阶段，活着比什么都可用重要。过早的高可用设计会拖死产品。

关联内容（自动生成）