先把维护拆成四个工作篮子
“软件维护”这个词太宽，供应方可能理解为修复程序问题，甲方却可能同时期待改页面、导数据、配置账号和增加功能。更可执行的做法是把请求先放入四个篮子：缺陷修复、运行保障、内容与数据操作、新增或变更。每个篮子使用不同的判断方式、负责人、费用口径和验收证据。
分类依据必须来自上线时确认的需求、原型、规则和验收记录，而不是谁先说“这应该包含”。同一个现象也可能涉及多类工作，例如报表打不开可能是程序缺陷、服务器异常、第三方接口停用，也可能是用户提出了原范围没有的新统计口径。先定位原因，再决定由哪一条服务规则处理。
- 缺陷修复：结果不符合已确认的交付基线
- 运行保障：让既有系统持续可访问和可恢复
- 内容数据：由人员执行配置、录入、导入或整理
- 新增变更：改变原有页面、流程、规则或接口
- 待调查项：证据不足时先定位，不提前归类
缺陷修复要对照基线和复现条件
缺陷不是“使用者不满意”的同义词，而是系统在约定环境和输入条件下，没有产生已经确认的结果。报修时至少记录账号角色、操作步骤、输入数据、发生时间、实际结果和期望结果，并保护客户与业务数据。供应方复现后，应说明影响范围、临时规避办法、修复版本和回归检查结果。
若上线后浏览器、操作系统、第三方接口或业务规则发生变化，不能直接沿用原来的缺陷结论。双方应先判断原系统是否承诺兼容新环境，以及变化发生在哪一方。属于原实现错误的按缺陷处理；属于外部变化适配或新业务规则的，进入影响评估。这样既避免把真正问题推成收费需求，也避免把所有变化都变成无限保修。
- 问题能够用脱敏步骤稳定复现
- 期望结果可在需求或验收记录中定位
- 运行环境和输入条件没有超出约定范围
- 修复没有破坏相关的既有流程
- 修复版本、发布时间和验证人留有记录
运行保障要覆盖发现、恢复和预防
系统运维服务不只是服务器续费。协议要说明谁负责主机、数据库、对象存储、域名、HTTPS 证书、日志、监控、备份和依赖升级，哪些资源由甲方账号持有，哪些告警由供应方接收。没有责任表时，证书到期、磁盘占满或备份失败很容易在故障发生后才发现。
备份也不能只写“每天备份”，还要写清备份对象、保留周期、存放位置、加密与访问权限、失败告警，以及多久进行一次恢复验证。监控应覆盖用户真正依赖的关键路径，而不只检查服务器进程存在。升级运行环境或组件前，应评估兼容性、保留回滚版本，并在约定窗口完成验证。
- 域名、证书、云资源的续费责任和提醒方式
- 应用、数据库、磁盘和关键业务路径监控
- 数据与附件备份、保留和恢复演练
- 日志保存、告警接收及故障定位权限
- 依赖升级、安全修补和回滚安排
- 资源扩容与第三方服务费用的批准流程
内容和数据操作需要单独约定工作量
上传商品、修改文章、开通账号、调整基础配置、整理表格和批量导入，往往不需要修改程序，但仍然需要人员时间和业务判断。它们是否包含在维护费中，应按次数、工时、数据量或固定清单约定，不能因为“后台已经有功能”就默认供应方长期代操作。
涉及数据的请求还要确定授权人、数据来源、格式校验、执行环境、备份和结果抽查。供应方不应自行推断缺失字段或替甲方决定业务口径；甲方也应提供经过确认且不含无关敏感信息的文件。一次导入完成的证据包括处理条数、失败条目、抽样核对和可恢复版本，而不是只回复“已经操作”。
- 哪些内容或配置由甲方后台自行维护
- 哪些代操作包含在固定服务额度中
- 批量数据的模板、校验规则和授权人
- 失败数据如何返回并由谁修正
- 操作前备份与操作后抽样如何留证
- 超出次数、工时或数据量后如何处理
新增需求不能塞进故障工单
新增页面、字段、流程分支、权限规则、报表口径、第三方接口或移动端适配，都会改变原交付范围，应进入需求变更流程。即使改动在界面上只有一个按钮，也可能涉及数据库、权限、历史数据、测试和部署。维护人员可以先帮助澄清，但不应在没有影响分析时口头承诺完成时间。
一个假设示例是：原系统只导出当前列表，甲方上线后希望导出多年度明细并按部门汇总。如果原需求和验收标准没有这些数据范围与统计规则，这不是修复“导出按钮”，而是新增报表能力。双方应确认字段来源、权限、数据量和验收样例，再决定排期及费用。该示例仅用于说明分类方法，不代表真实客户项目。
- 是否改变已确认的业务结果或使用角色
- 是否新增字段、数据来源、计算或权限规则
- 是否需要兼容历史数据和旧版本
- 是否影响接口、报表、通知或移动端
- 是否需要调整费用、排期和验收标准
响应等级要写成双方都能测量的时间点
维护协议常把“快速响应”写得很醒目，却没有定义什么时候开始计时、响应代表什么、非工作时间如何处理。更清楚的方式是按影响程度分级，并分别记录受理时间、首次响应、开始处理、临时恢复和最终关闭。首次响应只表示已确认收到和开始判断，不能等同于问题已经解决。
级别应由业务影响决定，而不是提出人的职位。核心流程完全不可用、数据持续异常与普通样式问题不能使用同一时限；计划内维护、第三方故障和甲方迟迟未提供复现材料，也应有暂停计时或重新评估规则。具体时间需要结合系统重要程度、值守方式和预算协商，不能照抄与自身资源不匹配的数字。
- 服务时间、节假日和紧急联系渠道
- 各等级对应的业务影响和判定人
- 首次响应、临时恢复与最终解决分别计时
- 等待甲方资料或第三方处理时如何记录
- 超过约定时限后的升级和通知路径
- 工单关闭前由谁验证恢复结果
用一张维护范围表完成签约和验收
签约前可以逐行列出服务项、包含动作、触发条件、服务时间、责任人、交付证据、费用口径和排除项。例如“数据库备份”不能只占一行名称，还要对应备份对象、频率、保留、失败告警与恢复验证；“缺陷修复”要对应基线版本、提交材料和回归范围。范围表应与项目资产清单、账号交接和上线验收记录保持一致。
每月或每个结算周期汇总工单数量、未关闭原因、备份和恢复检查、资源告警、版本变化及下期风险。维护期结束或更换供应方时，交付最新代码版本、部署说明、配置清单但不在文档中写明文密码、备份位置、未结事项和账号移交记录。需要梳理真实系统的维护边界时，可回到 5656AI 首页提交脱敏后的系统范围，由技术人员先帮助分类。
- 每项服务有明确包含动作和排除内容
- 甲乙双方的账号、资料和审批责任已列明
- 固定费用与按次评估部分能够区分
- 每次处理都有工单、版本和验证证据
- 维护期满的代码、数据、文档和账号可交接
- 未解决事项和持续风险不会因结算被隐藏