软件项目交付后的维护与运维周期一般是多久？

结论：没有统一的“维护多久”；保修有期限，生产运维应覆盖系统实际运行期。

缺陷保修应在合同中约定明确结束日期；只要系统仍承担业务，监控、备份、安全更新和故障响应就不能因保修到期自动停止；新增功能则应作为独立迭代安排，而不是塞进维护期。

在安排里程碑、资源与验收节奏时，还可以对照 你们会帮我运维吗？ 和 系统上线之后，你们还会继续支持吗？还是项目一交付就结束了？；这些内容补充了需要放在同一项决策中考虑的上下文。

三条时间线不能混用

“免费维护一至三个月”最多说明某家供应商的商务安排，不能成为所有项目的行业结论。一个上线两周就下线的活动页和连续运行五年的设备平台，长期责任显然不同。滚水科技先根据系统寿命、业务时段和停机损失决定服务，再讨论合同是一年一签、按月还是客户自运维。

时间线	起止依据	期内主要事项	到期以后
缺陷保修	从验收或上线日起，按合同截止	修复原交付范围内可复现缺陷	转付费维护，或由客户团队处理
生产运维	从生产启用到系统下线/移交	监控、事件响应、备份、恢复、容量和安全更新	不应裸奔；必须续约、移交或下线
功能迭代	按版本或需求包	新流程、新报表、第三方变化和性能改造	进入下一版本，不等同于缺陷修复
第三方资产生命周期	以域名、证书、云资源及平台期限为准	续费、轮换、审核和兼容升级	逾期可能直接影响服务，需单独负责人

保修边界应使用“是否偏离已确认需求和验收标准”判断，而不是由谁最先发现。交付范围内的计算错误、权限错误或稳定复现的崩溃通常属于缺陷；客户新增一个审批层级、平台 API 改版导致的适配、流量增长后的扩容通常不属于原缺陷。具体仍以 SOW、验收记录和变更单为准。

运行中的系统需要持续做什么

生产运维不是等待报修。最低限度应持续验证外部可用性、核心流程成功率、错误率、容量、备份结果、证书和高危依赖，并保持联系人与操作手册有效。Google SRE 的生产服务最佳实践建议从用户感知定义服务目标、设置错误预算，并定期演练故障处理；其事件管理指南还强调明确角色、工作记录和结构化响应。这些资料提供方法，不代表每个小系统都需要配置一支专职 SRE 团队。

维护合同要写可执行指标。例如 P1 是“核心交易完全不可用”还是“单个用户失败”，首次响应和恢复目标分别多久，夜间是否计算，第三方故障是否排除，未达标有什么后果。对非核心内部工具，工作日监控与响应可能足够；涉及收入、设备安全或连续生产的系统，则应评估 7×24 值守、冗余和恢复演练。目标越严，人员和基础设施成本越高。

DORA 的软件交付研究可帮助团队观察变更前置时间、部署频率、变更失败率和恢复表现。滚水科技不会把外部研究中的某个数字硬套成验收线，而会先测量系统自己的一个月基线，再与客户共同设目标；没有监控数据时，任何“全年稳定”都缺少证据。

续约、转交还是下线

在保修期结束前，滚水科技会复盘故障和工单，列出未来一年的运行风险、第三方续费、预计变更与推荐服务时段。客户可以选择由滚水科技继续服务、交给内部团队，或引入另一供应商。若业务已经结束，应正式下线并处理备份、个人信息、域名解析和仍在计费的资源，而不是放任无人管理的系统暴露在公网。

可移交性是验收的一部分：客户应拿到源码与版本、构建部署说明、架构和数据字典、管理员账号、密钥交接记录、监控与备份配置、未关闭问题以及第三方资产清单。滚水科技使用客户授权的具名账号工作，交接后撤销权限。选择不续约不应导致客户失去自己的系统资产。