基础设施无关可用性/容错保障的SLA指标定义咨询

核心结论 #

完全可以定义和基础设施完全解耦的软件层可用性、容错性度量指标，这也是所有本地部署（On-Prem）模式商用软件划清责任边界的标准行业实践，不存在落地障碍。

第一步：先锁死责任边界的前置规则 #

所有指标承诺的前提必须写入合同的SLA例外条款，从根源上避免权责不清：

• 客户侧提供的基础设施（服务器、OS、k8s、DB、存储、网络）必须满足软件官方公开的《最低配置与兼容性要求清单》，低于要求的场景下出现的所有故障，不纳入SLA考核范围
• 客户侧运维操作失误（包括但不限于误改配置、误删数据、资源超卖超过阈值、私自修改软件官方组件、未按要求升级补丁）、客户二次开发逻辑导致的故障，全部排除在SLA承诺范围外
• 基础设施层面的故障（服务器宕机、网络中断、存储损坏、机房断电等）导致的服务不可用，不计入SLA违约统计

第二步：可直接沿用的通用指标（需调整度量口径） #

通用的可用率、RPO、RTO指标完全可以用，但绝对不能直接套用云服务全栈SLA的口径，必须把统计范围严格限定在软件自身责任域内：

• 软件层可用率：口径调整为（统计周期总时长 - 因软件自身代码缺陷、架构设计问题、官方发布组件bug导致的核心功能不可用时长）/ 统计周期总时长 * 100%。统计时直接剔除所有基础设施、客户操作、第三方依赖故障导致的不可用时长，只算软件本身问题导致的故障时间。
• 软件层RPO：口径限定为软件自身事务、数据一致性机制保障的、仅因软件本身缺陷触发故障时的最大数据丢失量，比如可承诺「软件自身事务提交机制保障已确认提交的业务数据RPO=0，因底层存储损坏、客户备份策略配置错误导致的数据丢失不在承诺范围内」。
• 软件层RTO：口径限定为底层资源满足配置要求、无基础设施故障的前提下，软件从自身故障状态（进程崩溃、组件OOM、逻辑死锁等）恢复到核心功能可用的最长时间，比如可承诺「软件核心组件异常时，依托编排层自愈能力的自动恢复时长RTO≤5分钟，因底层资源不足、镜像拉取失败、网络策略拦截导致的恢复超时不在承诺范围内」。

第三步：需补充的软件专属容错度量指标 #

通用指标只能覆盖结果，要完整体现软件自身的容错能力，还需要补充几个和基础设施完全解耦的适配指标：

• 故障隔离能力：度量故障扩散范围，比如可承诺「单业务模块、单租户触发软件bug导致异常时，其余核心业务模块不受影响的概率≥99.99%；底层依赖组件（DB、缓存、k8s apiserver）出现30s以内临时闪断时，软件核心链路报错率≤0.1%，无需人工介入可自动恢复」
• 降级运行能力：度量非核心故障下的核心链路可用性，比如可承诺「非核心模块（日志上报、运营统计、辅助功能）异常时，核心数据处理、业务操作链路可用性不受影响」
• 故障归因可追溯能力：这个是避免后期纠纷的关键，可要求「所有故障场景下，软件自带的监控、日志体系可明确判定故障归属（软件自身问题/基础设施问题/客户操作问题）的准确率≥95%」，防止出了问题全算在软件头上。

参考学习资料 #

• 书籍：《SRE：Google运维解密》中分层SLA定义、责任边界划分的相关章节，详细讲了不同责任域下如何拆分可用性指标；《站点可靠性工作手册》中有本地部署场景下SLA落地的具体实操流程
• 行业实践：可以参考主流企业级本地部署软件（商用数据库、企业级中间件、本地部署ERP/CRM系统）的公开SLA条款，基本都采用了这种分层定责、只承诺软件自身责任域指标的模式，不会涉及基础设施层面的数值承诺。

实操提醒：所有指标口径、排除项、基础设施最低要求一定要作为合同附件列全，不要留模糊描述，否则后期客户侧基础设施出问题很容易出现权责纠纷。

内容的提问来源于stack exchange，提问作者impulsgraw