研发平台维护计划要解决的是平台自身能不能稳定用、权限和数据是否可控、出问题能否及时恢复。做法是先盘点平台组件与责任人，划清维护范围，再把工作拆成日常巡检、周期维护和专项变更三层，为每项动作写明输入、执行人、输出记录和完成标志，最后用月度排期和完成检查表保证计划真正执行。
要点总览（TL;DR）
- 维护计划先划范围：覆盖平台服务、账号权限、配置与数据、集成接口和备份，业务流水线设计与通用服务器运维不纳入。
- 把工作拆成日常巡检、周期维护、专项变更三层，每项动作写明输入、执行人、输出记录和完成标志。
- 角色按职责划分：平台管理员执行、业务团队代表验证、审批人批准窗口与变更、值班人响应告警，小团队可兼任但记录不能省。
- 用月度排期把周巡检、月度备份恢复验证、季度权限复核落到日历，版本升级按申请、审批、实施、验证、回退留痕。
- 用范围、动作、角色、记录四类检查项验收计划，关键组件无责任人、备份无恢复验证、变更无回退方案属于阻断项。
维护计划先定范围：管什么、不管什么
维护计划的第一步是列清对象边界。研发平台通常由多个组件构成：代码托管、制品库、流水线引擎、需求与缺陷管理、文档与知识库、统一登录与权限服务、数据库与缓存、消息队列、对外集成接口等。维护计划针对这些组件的运行状态、配置、数据和访问控制，目标是让平台持续可用、可恢复、可审计。
与之相邻但应当排除的内容包括：业务团队在平台上如何设计流水线、如何拆分需求、如何安排发布节奏，这些属于交付管理；服务器硬件、网络设备、操作系统补丁的通用运维，属于基础设施运维。把这两类内容写进维护计划，会让计划失焦，执行人也难以界定责任。
范围清单建议用一页表格完成，字段包括：维护对象、所属组件、当前责任人、是否纳入本期计划、备注。填写时按组件逐项过一遍，对每个对象回答三个问题：它失效会影响谁；谁最了解它的配置；出问题时第一联系人是谁。回答不清楚的对象先标记为“待确认”，在计划评审时补齐，不要直接跳过。
范围清单还需要写明版本口径，例如“本期覆盖生产环境与预发环境，测试环境由各业务团队自行维护”。这类边界写清楚，后续排期和值班安排才有依据。
核心步骤：把维护计划拆成日常、周期与专项三层
三层划分的依据是触发方式和风险等级。日常巡检按固定频次重复执行，动作轻、耗时短；周期维护按周或月执行，涉及备份验证、权限复核、容量与日志清理；专项变更由具体需求触发，例如版本升级、配置调整、集成接口变更，需要申请、审批和回退预案。三层动作分开管理，避免日常巡检被临时变更挤占，也避免变更在没有记录的情况下直接上线。
每项动作都要写清四件事：输入是什么（如巡检表、变更单、备份任务清单），谁执行，输出什么记录（如巡检结果、验证报告、变更记录），完成标志是什么（如“所有检查项通过并签字”“备份恢复演练成功”）。缺少完成标志的动作，执行后无法判断是否真的做完。
| 层级 | 典型动作 | 频次 | 输入 | 输出记录 | 完成标志 |
|---|---|---|---|---|---|
| 日常巡检 | 服务健康检查、关键任务失败告警确认、磁盘与队列水位查看、登录异常排查 | 每日或每工作日 | 巡检表、监控告警 | 巡检记录、异常工单 | 全部检查项有结论，异常已建单 |
| 周期维护 | 备份任务执行与恢复验证、账号权限复核、容量评估、日志清理、证书与密钥有效期检查 | 每周、每月或每季度 | 备份清单、权限清单、容量报表 | 验证报告、复核记录、清理记录 | 恢复验证成功、权限差异已处理、容量在阈值内 |
| 专项变更 | 平台版本升级、配置调整、集成接口变更、插件安装 | 按需触发 | 变更申请、影响评估、回退方案 | 变更单、实施记录、验证结果 | 变更后核心功能验证通过，回退预案可用 |
日常巡检的重点是“发现异常并建单”，不要求在巡检环节解决所有问题。周期维护中的备份验证要真正做一次恢复，只确认备份任务成功并不等于数据可恢复。权限复核按账号清单比对实际授权，重点看离职账号、长期未使用账号和越权授权。容量与日志清理要设定阈值，例如存储使用率超过约定比例时提前扩容，避免在高峰期处理。
专项变更的关键是申请与回退。变更申请写明变更内容、影响范围、实施窗口、验证方式和回退步骤；实施前确认回退所需的前置条件，例如旧版本镜像、配置备份、数据库快照是否就绪；实施后按验证清单逐项确认，未通过则按预案回退并记录原因。
角色与交付物：谁执行、谁审批、谁验收
维护计划中的角色按职责划分，不按职级划分。平台管理员负责日常巡检、周期维护的具体执行和变更实施；业务团队代表负责确认变更对业务的影响、参与变更后的功能验证；审批人负责变更申请和窗口安排的批准；值班人负责非工作时间的告警响应和升级上报。小团队可以一人兼多个角色，但每个角色对应的记录不能省略。
| 角色 | 主要职责 | 交付记录 |
|---|---|---|
| 平台管理员 | 执行巡检与周期维护，实施变更，维护配置与账号 | 巡检记录、维护报告、变更实施记录 |
| 业务团队代表 | 确认变更影响，参与验证，反馈使用问题 | 影响确认意见、验证结论 |
| 审批人 | 审批变更申请与维护窗口，裁定风险例外 | 审批意见、窗口确认 |
| 值班人 | 响应告警，按升级路径通知责任人 | 值班日志、事件记录 |
维护窗口与变更审批要衔接：变更申请中写明计划窗口，审批人确认窗口不与业务高峰冲突后批准；窗口内未完成的变更，按预案决定回退或延期，并更新记录。记录留存方式建议统一到一个可检索的位置，按日期和对象命名，交接时以记录为准，口头说明只作为补充。
当维护任务数量增多、参与人分散时，可以把巡检、变更申请、验证任务放进统一的工作项管理：每项任务有负责人、截止时间和状态，变更单关联影响评估与回退方案，维护记录沉淀在文档中，交接时直接查看历史记录。ONES 的工作项与文档能力可以承载这类流转，让维护动作从“记得做”变成“有单可查、有状态可跟”。
示例：一个月的维护计划怎么排
以下为一个月的排期示例，适用于中等规模的研发平台，具体频次可按平台规模和业务节奏调整。
| 时间 | 动作 | 执行人 | 输出 |
|---|---|---|---|
| 每个工作日 | 服务健康检查、告警确认、水位查看 | 平台管理员 | 当日巡检记录 |
| 每周五 | 本周异常汇总、日志清理、证书有效期检查 | 平台管理员 | 周维护记录 |
| 每月第二周 | 备份恢复验证、容量评估 | 平台管理员 | 恢复验证报告、容量报告 |
| 每季度首月 | 账号权限复核 | 平台管理员与业务团队代表 | 权限复核记录 |
| 按需 | 版本升级、配置调整 | 平台管理员实施，审批人批准 | 变更单与验证记录 |
一次版本升级的完整示例：平台管理员提前一周提交变更申请，写明升级版本、影响组件、计划窗口、验证清单和回退步骤；审批人确认窗口后批准；实施前完成配置备份和数据库快照，确认旧版本镜像可用；窗口内执行升级，按验证清单检查登录、代码拉取、流水线触发、制品下载等核心功能；验证通过后通知业务团队代表确认，未通过则执行回退并记录失败原因。整个过程在变更单中留下申请、审批、实施、验证四类记录。
记录与通知的写法要具体：写清时间、对象、动作、结果和后续事项，例如“3月12日22:00至23:10完成制品库升级，核心功能验证通过，遗留问题：旧客户端兼容性待观察，负责人跟进”。通知发给受影响的业务团队和值班人，避免只在小范围口头传达。
完成检查：维护计划是否可执行
计划写完后，用四类检查项判断它是否达到可执行状态。范围类：每个维护对象都有责任人和是否纳入的结论；动作类：每项动作都有频次、输入、输出和完成标志；角色类：执行、审批、验收、值班四类职责都有人承担；记录类：每类动作都有对应的记录模板和留存位置。四类中任何一类存在空白，计划在执行中就会出现无人负责或无法追溯的环节。
阻断项包括：关键组件无责任人；备份没有恢复验证安排；变更没有回退方案；维护记录无处留存。出现阻断项时先补齐再发布计划，不带着缺口执行。通过标准可以设为：抽查任意一项动作，能在记录中找到最近一次执行结果；抽查任意一次变更，能追溯到申请、审批和验证记录。
计划复审的触发条件建议写明：平台组件发生重大变化、连续出现同类故障、业务高峰期调整、责任人变动。复审时更新范围清单和动作表，保留旧版本以便对比。维护计划本身也需要版本管理，每次调整记录变更内容和生效日期，避免执行人按过期版本操作。
常见问题
平台规模较小、只有一名管理员时，维护计划还要分这么多角色吗？
角色可以合并，职责和记录不能合并。一人兼任平台管理员、审批人和值班人时，变更申请仍要留下影响评估和回退方案，审批意见仍要单独记录，避免自己批准自己实施却没有任何书面依据。业务团队代表的验证环节建议保留，由使用平台的核心团队指定一人参与变更后验证，这能补上管理员视角看不到的业务影响。
随着平台组件和参与人增多，再把审批、值班等职责拆出去，拆分时以现有记录为交接依据。
日常巡检发现异常，应该在巡检环节直接处理还是先建单？
建议先建单再处理。巡检的目标是发现并留下结论，处理动作按影响程度分流：影响面小、有明确操作步骤的问题可以当场处理并在工单中记录；涉及配置调整、重启服务、变更版本的问题转入专项变更流程，走申请和审批。这样巡检记录与变更记录能对应上，后续复盘时能看清问题是巡检发现的还是变更引入的。
备份任务每天显示成功，还需要单独做恢复验证吗？
需要。备份任务成功只说明数据写入了备份存储，不能证明数据可以恢复。恢复验证要实际取一份备份在隔离环境还原，检查数据完整性和关键业务对象是否可用，并记录验证时间、备份批次和结果。验证频次可按数据重要程度设定，例如每月一次全量验证，重大变更前额外做一次。
版本升级的维护窗口和业务高峰期冲突时怎么处理？
优先调整窗口，把变更安排到业务低峰时段；确实无法避开时，由审批人评估影响范围后决定是否延期，或缩小变更范围分批实施。无论哪种选择，都要在变更单中写明冲突原因、决策人和新的实施时间。窗口内未完成的变更按预案回退或延期，并更新记录，避免出现半完成状态无人跟进。
维护计划制定后，什么情况下需要复审调整？
常见触发条件包括：平台组件发生重大变化，例如新增或下线核心服务；连续出现同类故障；业务高峰期或发布节奏调整；责任人变动。复审时更新范围清单和分层动作表，保留旧版本并记录变更内容和生效日期，让执行人始终按当前版本操作。
