运维范围界定指南

系统从上线那天起就开始承担实际业务。然而运维阶段的范围有时比建设范围讨论得晚，甚至等出了问题才开始商量。如果在上线前就约定好哪类需求由谁在什么时间之前处理，运维过程中的判断会更快，双方的预期也更容易一致。

01. 区分维护与优化升级

故障处理、错误修复、定期检查这类维持现有功能的工作，与新增功能、界面改版这类改变服务的工作，性质并不相同。把两者混在同一个范围里，就难以判断优先级、工期和费用。

如果建设完成后有免费质保期，要一并确认其范围和结束时间。提前定好质保期结束后的运维方式，可以减少运维空档。

需梳理的事项

通过电话、即时通讯软件、邮件分散提交的需求容易遗漏，处理进度也难以掌握。要确定受理需求的窗口和表单，让提出方和处理方都能看到从受理到完成的每个状态。

每项需求都按影响范围和紧急程度确定优先级。对于需要内部审批的变更，还要在流程中写明由谁审批、何时实施。

整个服务中断与个别界面显示出错，处理速度不可能相同。要划分故障等级，并为每个等级确定首次响应和恢复的目标时间以及报告方式。

提前确定非工作时间发生故障时的联络渠道和负责人。对接的外部系统、服务器运维服务商等需要协同处理的单位，其联系方式也要列入清单。

需梳理的事项

把服务器资源、日志、备份状态、证书和账号到期日等需要按固定周期检查的项目列成清单。记录每次检查的结果，就有了判断同类问题是否反复出现的依据。

安全更新和运行环境的版本变更可能影响服务，实施前需要经过确认流程。提前确定部署时段和回退方法，并把变更内容留作记录。

运维负责人可能会更换。把系统构成、对接信息、部署方法、常见问题及其解决记录整理成文档，新的负责人也能按同样的标准继续运维。

运维过程中积累的需求和故障记录，是确定下一步改进事项的参考资料。要定期一起回顾这些记录，把反复出现的不便转入优化升级范围加以规划。

提前梳理好以下内容，可以在初期讨论中更快地明确范围。即使尚未全部准备好，也可以先从当前情况谈起。

KPS项目指南 · 具体的技术方案和适用条件因需求而异。