生产级集群可用度必须可定义、可测量、可验证，需明确业务语义下的“可用”边界（如http状态码+p95延迟）、分层设定sla指标（服务可用率、rto≤25秒、rpo≤100ms、请求成功率≥99.95%）、闭环验证（独立监控+混沌演练+指标断点复盘），并匹配底层架构能力。
生产级集群的可用度不是简单标个“99.9%”就能算数的，它必须可定义、可测量、可验证。关键在于把抽象的“不宕机”拆解为具体场景下的行为承诺和数据边界。
明确“可用”的业务语义
同一套集群，在不同业务视角下“可用”含义不同：
- 对用户端来说，可用 = HTTP 请求返回 2xx/3xx 状态码且响应时间 ≤ 800ms（P95）
- 对支付系统来说，可用 = 所有事务提交成功，RPO = 0，RTO ≤ 15秒
- 对日志平台来说，可用 = 写入不丢数据、查询延迟稳定，允许短暂只读切换
- 需在 SLA 文档中写明是否排除计划内维护、灰度发布窗口、依赖方故障等免责情形
分层设定核心指标
单一百分比无法反映真实稳定性，应分层量化：
- 服务可用率：按分钟粒度统计健康检查通过率，剔除人工维护时段
- RTO（恢复时间目标）：从故障确认到流量完全切回的时间，例如“主库宕机 → 从库升主 + VIP 漂移 + 连接池刷新 ≤ 25秒”
- RPO（恢复点目标）：以最大未同步延迟为准，如 MySQL 半同步复制 RPO ≤ 100ms，ES 副本分片 RPO = 0（主分片丢失时副本立即接管）
- 请求成功率与质量：补充 5xx 错误率 ≤ 0.05%、P95 延迟 ≤ 阈值，避免“活着但不可用”
验证机制必须闭环
没有可观测性支撑的可用率是无效承诺：
- 所有指标必须由独立监控链路采集（如 Prometheus 抓取节点健康状态 + 日志系统统计请求结果）
- 定期执行混沌工程演练：模拟网络分区、节点 Kill、磁盘满等故障，验证自动切换是否符合 RTO/RPO
- 故障复盘必须回溯指标断点——不是“系统恢复了”，而是“从第 14 分 22 秒开始，连续 5 分钟请求成功率回升至 99.95% 以上”
- 集群拓扑中每个组件都要有对应 SLA，例如 etcd 集群要求 N≥3 且多数派在线，Redis Cluster 要求至少 3 个 master 节点存活
匹配架构能力的真实底线
可用度承诺必须与底层技术栈能力对齐：
- Nacos AP 模式天然支持秒级服务发现，但配置变更最终一致性延迟可能达秒级，不能承诺“配置实时生效”
- MySQL 主从 + Keepalived 架构下，RTO 受限于 VIP 漂移速度与应用连接重试逻辑，通常难低于 10 秒
- Elasticsearch 副本分片数 ≥ 2 且分片分配策略合理，才能保障单节点宕机时搜索与写入均不受影响
- MinIO 至少 4 节点启用纠删码，才具备容忍 1 节点永久故障而不丢对象的能力
