软件支持 SLA（服务水平协议）是一份书面协议，约定支持覆盖哪些范围、问题要在多长时间内处理，以及各方分别负责哪些部分。有了它，企业和支持团队对“谁负责维护这套系统”就有了可以核对的共同依据。
SLA 涵盖什么
一份实用的 SLA，除了响应时间，通常还会写明：
- 支持范围：包括哪些应用、环境、集成和设备，以及哪些不在范围内。
- 响应时间与修复时间：响应时间指多久内有人确认并开始处理；修复（或解决）时间指多久内恢复服务或提供临时解决办法。两者是不同的目标，应按严重程度分别约定。
- 服务时间：何时可以报障、团队何时需要处理，以及法定节假日如何安排。
- 发布窗口：计划内的变更何时可以上线、如何提前通知，以及紧急修复与常规发布有什么区别。
- 报告：报告包含哪些内容，例如已处理的事件、未完成事项和反复出现的问题。
定制系统中的责任边界
定制系统最容易因为责任不清而耽误处理。建议在事件发生前，先写下以下三个问题的答案：
- 代码归谁所有？确认谁持有源代码仓库、云账号、域名和软件许可，以及谁有权授予访问权限。
- 谁可以变更生产环境？约定由谁批准变更、谁负责部署，以及出问题时如何回滚。
- 第三方 API 故障由谁跟进？支付、消息或地图等服务，由其供应商负责。支持团队可以发现故障、通知用户、执行事先约定的应对办法，并向供应商提交工单，但通常无法承诺供应商何时修复。SLA 应把这一点写清楚。
接手遗留系统前的交接清单
支持团队接手继承来的系统前，至少应检查以下项目：
- 源代码、构建步骤，以及能否顺利部署到测试环境
- 服务器托管、域名、证书，以及费用由谁承担
- 管理员账号、密钥和访问名单，包括已离职员工和以往的供应商
- 数据库、备份，以及是否做过成功的恢复测试
- 第三方服务、API 密钥和续期日期
- 现有文档、已知缺陷和以往的事件记录
- 业务繁忙时段，以及对公司最重要的工作流程
这个阶段发现的缺口，比系统出故障时才发现更容易处理。部分系统可能需要先经过一段稳定期，SLA 的目标才切合实际。
SLA 如何配合监控和自动化测试
SLA 能否落实，取决于背后有没有可靠的信号。监控系统可用性、错误、备份和集成失败，能让团队比用户更早发现问题；与严重程度规则挂钩后，正确的告警就能触发相应的处理。自动化测试针对关键操作流程，可以检查修复或新版本有没有影响其他功能，让发布窗口更安全、更短。两者都不能取代支持流程，但都有助于达成和衡量响应与修复目标。
technine.io 在托管支持及 SLA页面介绍了具体做法，包括如何评估、界定、稳定系统，然后提供持续支持。
常见问题
有 SLA 就等于 24x7 支持吗？
不是。服务时间是协议的一部分，可以只限办公时间、延长时间，或只为指定的关键服务提供全天候待命。应根据系统故障对业务的影响和可承受的预算来选择，并确认非服务时间的报障如何处理。
紧急和一般问题如何区分？
通过定义清晰的严重程度分级。例如系统无法使用，或导致支付、出入受阻，属于紧急；界面外观瑕疵或报表格式调整，则属于一般。每个级别各有响应和修复目标，SLA 也应说明由谁判定级别，以及如何调整。
响应时间等于修复时间吗？
不等于。快速响应只代表问题已被确认并开始处理。修复可能需要更长时间，特别是成因在第三方时，所以两者应分开约定。