业务可用性百分比是用户真实能用、用得顺的时间占比，核心为可用时间÷总时间×100%，但“可用”须按业务场景定义，需覆盖服务连接、接口响应、前端渲染三类信号，并分层采集、加权合成，结合滑动窗口、容错机制与SLO校准。
业务可用性百分比不是简单看系统“有没有挂”，而是看用户真实能用、用得顺的时间占比。核心逻辑是：可用时间 ÷ 总时间 × 100%，但关键在“可用”怎么定义——必须紧扣业务场景，不能只盯服务器是否在线。
按业务视角定义“可用”
技术层面的“服务在线”不等于业务可用。比如电商下单接口返回200，但实际库存扣减失败、支付跳转空白页，用户任务没完成，就应计入不可用。
- 明确核心用户旅程路径（如登录→浏览→加购→下单→支付），每个环节设成功判定标准
- 将“可用”拆解为三类可采集信号：服务连接成功、关键接口响应达标（如HTTP状态码+耗时≤800ms）、前端关键元素渲染完成（如“立即支付”按钮可见且可点击）
- 对不同业务动作设置权重，例如支付失败比商品详情加载慢权重更高
分层采集与聚合计算
单一指标无法反映整体业务可用性，需分层采集后加权合成：
- 服务层：基于SLI（如API成功率、P95响应延迟），用Prometheus等工具持续采样，剔除探针误报和低频异常
- 页面层：通过真实用户监控（RUM）采集首屏时间、JS错误率、资源加载失败率，过滤爬虫和无效会话
- 业务层：埋点记录关键转化节点（如“加入购物车”按钮点击→后端订单创建成功），失败即计为业务不可用
- 按权重合并（如接口成功率占40%、支付成功率达60%），避免某一层波动掩盖整体问题
时间窗口与容错机制
直接套用“全年停机时间÷总时间”会失真，尤其对短时抖动敏感的业务：
- 采用滑动窗口计算（如最近7×24小时），每5分钟统计一次可用性，再取均值，平滑瞬时毛刺
- 设置最小不可用时长阈值（如单次故障持续≥30秒才计入），避免网络抖动、GC暂停等短暂异常拉低分数
- 区分计划内维护时间（如灰度发布、数据库升级），这部分从分母中剔除，只统计非计划中断
对标与持续校准
99.9%不是万能标准，金融、医疗、IoT等场景对“可用”的容忍度差异极大：
- 对照SLO设定基线：例如“支付接口99.95%成功率”对应年度不可用≤4.32分钟，超限触发复盘
- 每季度回顾错误类型分布，动态调整权重——若近期大量因第三方SDK崩溃导致支付失败，就提高前端稳定性指标权重
- 引入混沌工程验证：主动注入延迟或断连，观察业务链路实际降级能力，修正理论可用性与真实体验的偏差
不复杂但容易忽略——业务可用性百分比的价值不在数字本身，而在它迫使团队用用户动作代替系统日志去定义“正常”。
