网站上线后的维护边界：日常巡检、故障响应与功能调整
问题通常在交付三个月后才显现
网站上线时，双方关注的是页面是否正常、功能是否跑通。过一段时间，问题会变成另一种样子：某个栏目打不开了，手机端某处按钮点不动，之前能收到的表单通知突然没了。这时常出现分歧：甲方认为“才上线没多久，应该在维护范围内”，乙方认为“这属于新增需求，需要另外安排”。
分歧多半不是因为谁不守约定，而是因为“维护”这个词在双方心里指的不是同一件事。把范围说清楚，比在合同里多写一句“提供维护”更有用。
范围说不清，往往来自三个原因
- 合同用“维护”概括了运行保障、内容更新、故障修复和功能调整，这四类事情的投入差别很大，却被压缩在一个词里。
- 交付时只交接了账号和页面，没有交代哪些地方容易出问题、出了问题找谁。
- 故障和需求混在同一个沟通渠道里，一句“帮我改一下”既可能是修复缺陷，也可能是新增功能。
第一类原因最常见。运行保障是持续的、可预期的；故障修复是偶发的，需要较快的响应；功能调整则要逐次评估工作量。三者混在一起谈，任何一方都会觉得对方的理解不合理。
先按三层把事项分开
与其争论某件事“算不算维护”，不如先把所有事项归到三个层次，再逐层约定处理方式。
- 运行环境层：服务器与域名状态、证书有效期、备份是否正常、人员离岗后账号权限是否仍被保留。这一层必须有固定节奏，不能等出问题才看。
- 内容与数据层：新闻、案例、产品信息的上架与下架，图片替换，表单提交记录的查看与导出。这一层多数可以由甲方自己完成，前提是后台权限和操作说明交接清楚。
- 功能与代码层：页面交互、接口调用、数据处理逻辑。这一层出问题，通常表现为原本正常的操作失效，需要技术人员介入。
分层之后，不少争议会自行消解。比如“帮忙发一篇新闻”落在第二层，属于日常操作而非技术要求；“首页轮播图加一个视频”落在第三层，即使工作量不大，也改变了原有页面结构，需要单独确认。三层的处理节奏不同，混在一起谈只会让每次沟通都从头开始。
判断属于修复还是变更，看四个问题
功能与代码层最容易产生分歧，可以用一组固定的问题来判断。
- 原本是否正常工作过。此前能正常使用、现在失效，优先按缺陷处理；如果从未实现过，则属于新增。
- 是否改变已确认的交互或数据结构。字段增减、流程顺序调整、页面结构重排都会扩大测试范围，不能当作小修。
- 是否引入新的第三方依赖。支付、地图、短信、推送这类能力，接入方规则变化不受项目控制，需要单独评估。
- 能否在约定工时内完成。这一条只是辅助，不能只看工作量来定性，否则容易把复杂问题拆碎，绕过确认。
把判断过程写进沟通记录，比事后回忆“当时说的是哪种”更可靠。尤其是口头提出、临时处理的事项，最好当天补一句确认：本次按缺陷修复处理，不改变功能范围。
把约定变成可以对照的条目
约定不需要写得很厚，但必须能对照执行。可以从四个方面入手。
- 响应分级：按影响范围分档。整站不可访问、核心功能失效、局部显示异常、一般咨询，各自对应什么响应节奏，事先写清楚。分档的意义是让紧急的事真的被优先处理。
- 处理边界：明确维护包含巡检、备份核查、证书更新提醒、既有功能缺陷修复；不包含新增模块、第三方服务采购、内容代运营、服务器迁移。
- 记录方式：每次问题记录时间、现象、处理结果，以及是否改变了范围。积累一段时间后，能看出哪些问题反复出现，也方便判断是否需要一次性优化。
- 周期回顾：按约定周期核对一次清单，把已解决、待确认、需要单独立项的事项分开，避免零散需求一直悬着。
有些事项不适合放进维护
维护的作用是让已交付的系统稳定运行，而不是承接所有后续工作。内容长期代运营、第三方接口因对方规则调整而需要重写、服务器搬迁、性能重构、新增业务模块，这几类事项涉及的时间跨度、责任归属和验收标准都不同，放进维护会让双方都难以判断进度。
更合适的做法是单独列项，写清目标、范围、完成条件和验收方式，再决定是否安排。这样做不是推卸责任，而是让每件事按它本来的复杂度被处理。
回到开头那种分歧：如果在交付时就带着这份分层清单和判断规则，很多争论会在问题提出的当下结束，而不必拖到双方都不愉快的时候。