系统上线不等于项目结束。上线后的头一段时间，往往才是问题集中暴露的阶段。"尽快处理"是最常见的 SLA 写法，也是最没有约束力的一种。本文讲清缺陷责任期与运维 SLA 该怎么写，才能真的可考核。
缺陷责任期：约定"多久、管什么、怎么算"
缺陷责任期，指上线后开发方对系统缺陷承担责任的一段期限。要写清三点：
- 期限：通常按合同约定，与项目规模、复杂度相关；
- 范围：哪些属于缺陷（与需求不符、功能异常），哪些属于新增需求（另行计费）；
- 判定：缺陷的确认方式与响应流程。
最容易扯皮的是"这算缺陷还是新需求"。在合同里给出判定标准，比事后争论有效得多。
SLA：把"尽快"换成可考核的表述
可考核的 SLA 至少包含三个维度：响应时限、恢复时限、计费规则。
| 级别 | 示例定义 | 响应 | 恢复 |
|---|---|---|---|
| P0 | 系统不可用、核心业务中断 | 2 小时内响应 | 24 小时内恢复 |
| P1 | 核心功能异常、影响多数用户 | 4 小时内响应 | 约定时限内恢复 |
| P2 | 非核心功能异常 | 工作日响应 | 约定时限内修复 |
| P3 | 体验问题、优化建议 | 排期处理 | 随版本发布 |
（具体时限由双方商定。）关键是把级别定义、响应时限、恢复时限三列填满，而不是只写一句"及时响应"。
超出范围的服务怎么算
运维期常见的情形是"这不是 bug，是你们想加个功能"。合同里要提前写明：
- 哪些属于 SLA 范围内的修复；
- 哪些属于新增需求，按变更流程另行报价；
- 计费方式与响应优先级。
边界写清，运维期才不会变成无休止的免费加班。
合同里要落地的四件事
- 缺陷责任期的期限与起算时点
- 缺陷与新增需求的判定标准
- 分级 SLA 表（级别定义 / 响应 / 恢复）
- 超范围服务的计费规则
运维期的费用怎么算
缺陷责任期与长期运维，是两件事，要分开约定：
- 缺陷责任期：通常包含在项目费用中，针对的是"开发缺陷"；
- 长期运维：通常单独计费，覆盖的是"持续服务"，例如内容更新、功能小改、安全巡检、数据备份。
建议写清运维服务的范围、响应级别、计费方式与结算周期。常见的有按月服务费与按工作量结算两种，前者适合需求稳定的场景，后者适合变化频繁的场景。
一个容易被忽略的指标：可用性
除了响应与恢复时限，还可以约定可用性目标，例如"月度可用性不低于约定值"。可用性通常以"系统正常运行时间 / 总时间"衡量，是衡量长期服务质量的一个客观口径。具体目标值由双方结合业务重要性商定。
SLA 不是越严越好
一个常见的误区是把 SLA 定得极其严苛，例如"任何问题 1 小时内解决"。结果往往适得其反：对方为了不违约，会把所有问题都归类为"非缺陷"，或者干脆不接你的电话。
合理的做法是按级别分层：核心业务中断严要求，非核心问题宽松处理，优化建议走排期。这样既保住了关键场景的响应速度，也让合作能持续。
谁来判定级别
级别由谁定，是 SLA 落地时最容易吵起来的地方。建议约定：
- 双方共同确认级别定义；
- 出现分歧时，以影响范围（多少用户受影响、是否影响交易）为判定依据；
- 保留一次升级评审的机会。
级别判定的规则越客观，运维期的摩擦越少。
缺陷责任期与 SLA，决定了上线之后你能得到多快的响应。把它们写成可考核的表格，而不是一句"尽快处理"，后期的服务质量才有保障。