维护及运维费用怎么收？

结论：维护及运维不能按开发费固定比例收费；应把缺陷保修、生产运维、可靠性改进和新功能迭代分开，再按覆盖时段、系统规模、SLO、工单和变更量报价。

“维护”经常被用来同时指修 Bug、看服务器、半夜处理事故和增加功能，结果双方对同一笔年费有完全不同的期待。开发费 30 万并不能推导运维费 5 万：系统可能是低频内部工具，也可能是全天交易入口；后者需要轮值、冗余和事故沟通，成本由运行责任决定。

在形成预算、报价范围与成本假设时，还可以对照 软件项目为什么除了开发费，还会有服务器费、第三方费和运维费？ 和 CDN 一般什么时候需要启用？费用怎么计算？；这些内容补充了需要放在同一项决策中考虑的上下文。

先把四类服务边界写清楚

服务	处理什么	通常如何计价	不包含什么	关键证据
缺陷保修	基线内功能未达到已签验收标准	可包含在项目价并限定期限/范围	新规则、平台变化、体验优化	缺陷单、复现和修复版本
基础运维	监控、备份、补丁、发布、容量和工作时段故障	固定基础费 + 约定工单/变更额度	新业务功能	月报、告警、备份演练、发布记录
SLA/值守运维	非工作时段响应、事件指挥、恢复和复盘	待命覆盖 + 事件工作量 + 冗余资源	无上限的任何问题	SLO、响应/恢复时间、事件记录
可靠性工程	自动化、性能、容灾、消除重复人工	独立工作包或团队容量	日常功能迭代	改进前后 SLI、演练和节省工时
新需求迭代	新页面、流程、接口和规则	人天、阶段固定价或专属团队	原范围保修	需求、验收和发布版本

固定年费可以购买“随时有团队准备响应”的能力，即使当月没有事故也有价值；按工单计费适合非核心低频系统，但恢复时间不可预测；专属团队适合持续变更，却不自动等于 7×24 值守。合同需明确工作时间、严重级别、首次响应、恢复目标、沟通频率、排除项和超额费率。

费用由服务责任驱动

可用公式表达为：年度运维费 = 服务准备与监控基线 + 覆盖时段/轮值成本 + 约定工单和发布容量 + 工具与演练 + 超额工作量。云服务器、短信、模型、监控 SaaS 等供应商账单应单列；若运维方代购，要披露原价、加价、所有权和退出方式。

价格驱动	需要确认的数据	为什么影响成本
系统和环境数量	服务、数据库、地区、生产/测试环境	监控、补丁、备份和发布对象增加
服务时段	工作日、延长时段或 7×24	夜间轮值需要多人轮换而非一个手机号
SLO 与恢复目标	可用性、延迟、RTO、RPO 和严重度	更严格目标需要冗余、自动化和演练
变更频率	每月发布、工单、供应商升级次数	测试、发布和回滚工作量增加
历史稳定性	告警、事故、重复人工和技术债	高噪声系统需要先治理才能承诺 SLA
安全与合规	补丁窗口、审计、等保/行业要求	增加记录、扫描、整改和演练责任

Google SRE Workbook 的监控章节强调围绕用户影响的 SLI/SLO 设计监控并区分告警严重度；值班章节说明可行动告警、事件工单、分级响应与复盘如何支撑健康轮值。这些资料不规定中国服务商价格，但能证明 7×24 运维是一套人员、流程和工具能力，不是一句“有问题随时联系”。

验收运维服务看结果和证据

月报至少包含 SLO 达成、重大事件、平均发现与恢复时间、备份成功与恢复演练、漏洞与补丁、容量趋势、发布成功/回滚、第三方费用异常和未解决风险。仅报告“服务器正常”无法证明备份可恢复，也无法证明告警有人处理。

首次响应不等于恢复，恢复不等于根因修复。合同应分别定义：收到有效告警到人工确认；服务恢复到可用状态；永久修复上线；复盘与改进行动关闭。外部云或运营商故障也要明确运维方承担的是协调与降级，还是对第三方可用性做不可能的绝对担保。

滚水科技通常在上线前建立服务目录、仪表盘、告警分级、值班联系人、备份恢复和发布回滚，再根据实际业务选择工作时段支持或更高等级 SLA。客户保有生产账户和账单；缺陷保修、运维工单与新需求分别记录，不用“年费已付”掩盖范围争议。