可用性管理是什么
可用性管理确保服务实际达到约定的可用性水平，工作内容覆盖制定可用性计划、管理维护窗口、验证冗余切换能力，以及持续分析中断来源结构。它不追求全网零故障，而是在成本约束下让可用性与业务承受能力匹配，并把中断原因转化为可跟进的改进项。
基本信息
| 目标 | 达成 SLA 约定的可用性水平 |
|---|---|
| 主要工作 | 可用性计划、冗余验证、窗口管理、中断分析 |
| 输入 | SLA 目标、业务节奏、架构冗余现状 |
| 输出 | 可用性报告、中断归因、改进登记项 |
| 节奏 | 月度中断分析、季度目标复核 |
典型使用场景
- 新服务上线前确定可用性目标与冗余设计是否匹配
- 定期演练主备切换，验证备用链路与脚本未过期
- 安排维护窗口，把计划内中断与故障对用户的感受区分开
- 按月统计中断时长并归因到变更、容量、依赖与人为因素
- 架构新增依赖前评估整体可用性是否被稀释
可用性管理闭环
可用性管理闭环
# 1 定义目标：可用性从 SLA 反推，而不是先设计再算
定义目标（SLA）→ 冗余设计与切换演练
# 2 让监控覆盖核心链路，否则中断只能靠用户投诉发现
→ 监控告警覆盖核心链路与业务指标
# 3 月度归因：原因结构比总时长更有行动价值
→ 月度中断分析：变更 / 容量 / 依赖 / 人为
# 4 改进项进入登记册并指定负责人才算闭环
→ 改进项进入登记册，双周评审推进中断归因维度
| 原因类别 | 典型表现 | 优先改进动作 |
|---|---|---|
| 变更引入 | 发布或配置调整后短时间集中报障 | 强化变更评审与灰度、回退机制 |
| 容量不足 | 高峰期超时、队列积压 | 容量模型与扩容自动化 |
| 外部依赖 | 供应商接口不可用导致级联失败 | 降级预案与依赖隔离 |
| 人为操作 | 误删配置、误执行命令 | 变更留痕、权限最小化、双人复核 |
中断原因结构比中断总数更有行动价值：变更类占比高就强化变更控制，依赖类占比高就补降级预案，按比例投入才有效。