研发平台运维手册要能直接拿来填，关键是把平台自身运行维护的记录拆成固定表格。本文给出一套由平台台账、日常巡检、变更与发布、故障处置、备份恢复、账号权限、容量与版本、交接记录八张表组成的空白模板，并说明字段口径、必填取舍和填写示例。手册范围限定在管理平台自身的运行维护，业务流水线的交付过程另归持续交付管理。手册中的巡检、变更、故障记录可以在 ONES 中作为工作项和文档承载，便于按同一套编号追溯。
要点总览（TL;DR）
- 手册由平台台账、日常巡检、变更与发布、故障处置、备份恢复、账号权限、容量与版本、交接记录八张表组成，平台台账为主表，其余表通过平台编号关联。
- 字段口径统一写时间格式、状态词表和责任人写法；变更单号与故障单号互为引用，一次事件的前因后果可在两张表之间串起来。
- 必填字段以能否追溯、交接和复盘为判断标准；平台数量少、人员固定时可把复核人、审批人列为选填，多人轮值时升为必填。
- 示例演示了巡检发现容量异常、发起变更、变更失败回滚、登记故障并关闭的完整记录链，可直接对照填写首版。
- 手册上线后按平台增减、部署变化、重大故障复盘等条件修订，每季度评审一次，交接时按平台编号核对未闭环事项。
研发平台运维手册空白模板（可直接复制）
八张表以平台台账为主表，其余七张表通过“平台编号”与主表关联；变更、故障、备份、交接之间再通过“变更单号”“故障单号”互相引用。复制时以一张表为一个填写单元，先填主表，再填依赖主表的记录表。以下表头可直接复制到文档或表格工具中使用。
表1 平台台账（主表）
| 平台编号 | 平台名称 | 用途说明 | 部署方式 | 访问地址 | 责任团队 | 平台负责人 | 上线日期 | 当前状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
表2 日常巡检记录
| 巡检日期 | 平台编号 | 巡检项 | 检查结果 | 异常描述 | 处理动作 | 巡检人 | 复核人 |
|---|---|---|---|---|---|---|---|
表3 变更与发布记录
| 变更单号 | 平台编号 | 变更类型 | 变更内容 | 影响范围 | 计划时间 | 实施人 | 审批人 | 执行结果 | 回滚方案 | 关联故障单号 |
|---|---|---|---|---|---|---|---|---|---|---|
表4 故障处置记录
| 故障单号 | 平台编号 | 发现时间 | 发现方式 | 故障现象 | 影响范围 | 处置人 | 处置动作 | 恢复时间 | 根因 | 关闭状态 | 关联变更单号 |
|---|---|---|---|---|---|---|---|---|---|---|---|
表5 备份与恢复记录
| 记录编号 | 平台编号 | 备份对象 | 备份方式 | 备份时间 | 存放位置 | 保留期限 | 恢复演练日期 | 演练结果 | 执行人 |
|---|---|---|---|---|---|---|---|---|---|
表6 账号与权限记录
| 记录编号 | 平台编号 | 账号类型 | 使用人 | 所属团队 | 权限角色 | 开通日期 | 变更说明 | 回收日期 | 操作人 |
|---|---|---|---|---|---|---|---|---|---|
表7 容量与版本记录
| 记录编号 | 平台编号 | 记录日期 | 当前版本 | 存储使用量 | 用户数 | 容量预警 | 升级计划 | 记录人 |
|---|---|---|---|---|---|---|---|---|
表8 交接记录
| 交接编号 | 平台编号 | 交接类型 | 交出人 | 接收人 | 交接日期 | 交接内容 | 遗留事项 | 确认状态 |
|---|---|---|---|---|---|---|---|---|
每张表的字段说明与填写口径
字段口径统一，才能让不同人填出的记录可以互相对照。下面按表说明关键字段的含义与取值方式，时间、状态、责任人三类字段的写法在各表中保持一致。
通用写法约定
- 时间统一写“YYYY-MM-DD HH:MM”，跨时区团队在表头注明时区。
- 状态字段使用固定词表，例如变更执行结果取“成功／失败／已回滚”，故障关闭状态取“处理中／已恢复／已关闭”。
- 责任人写姓名加团队，例如“张明（基础平台组）”，避免只写昵称。
- 平台编号采用“PL-序号”格式，一经分配不再复用。
关键字段说明
| 表 | 字段 | 含义 | 取值示例 | 常见填错点 |
|---|---|---|---|---|
| 平台台账 | 部署方式 | 平台当前的部署形态 | 私有化部署／公有云 | 把测试环境与生产环境混填为一条 |
| 平台台账 | 当前状态 | 平台是否在提供服务 | 运行中／维护中／已下线 | 下线后未更新，台账与实际不符 |
| 日常巡检 | 巡检项 | 本次检查的具体对象 | 服务可用性、磁盘空间 | 只写“巡检正常”，无法追溯检查了什么 |
| 变更与发布 | 变更单号 | 一次变更的唯一标识 | CHG-2024-018 | 同一变更拆成多条记录，编号不统一 |
| 变更与发布 | 回滚方案 | 变更失败时的恢复步骤 | 恢复上一版本镜像 | 留空或写“视情况”，事后无法执行 |
| 故障处置 | 发现方式 | 故障如何被察觉 | 巡检发现／用户反馈／告警 | 只记处置过程，不记发现渠道 |
| 故障处置 | 根因 | 导致故障的根本原因 | 配置项误改 | 把现象当根因填写 |
| 备份与恢复 | 恢复演练日期 | 最近一次验证可恢复的时间 | 2024-05-20 | 只记备份不记演练，无法确认可恢复 |
| 账号与权限 | 回收日期 | 账号或权限失效的时间 | 2024-06-30 | 人员离场后长期不填 |
| 容量与版本 | 容量预警 | 是否接近容量上限 | 正常／预警 | 只填数值不填判断结论 |
| 交接记录 | 遗留事项 | 交接时尚未完成的工作 | 待完成版本升级 | 写“无”但实际存在未闭环问题 |
跨表字段的对应关系
平台编号是全部记录表的外键，任何一条巡检、变更、故障、备份、账号、容量、交接记录都必须能回指到台账中的一行。变更单号与故障单号互为引用：由变更引发的故障，在故障记录中填写关联变更单号；故障处置中执行的修复变更，在变更记录中填写关联故障单号。这样一次事件的前因后果可以在两张表之间串起来。
哪些字段必填、哪些可以选填
必填字段的判断标准是：缺少该字段会导致记录无法追溯、无法交接或无法复盘。其余字段按平台重要程度和团队规模决定是否纳入。字段过多会让填写变成负担，首版手册宜先保证追溯链路完整。
| 表 | 必填字段 | 选填字段 | 选填适用场景 |
|---|---|---|---|
| 平台台账 | 平台编号、平台名称、部署方式、责任团队、平台负责人、当前状态 | 用途说明、访问地址、上线日期、备注 | 平台数量多、需要区分用途时补用途说明 |
| 日常巡检 | 巡检日期、平台编号、巡检项、检查结果、巡检人 | 异常描述、处理动作、复核人 | 巡检由单人完成时可暂不设复核人 |
| 变更与发布 | 变更单号、平台编号、变更内容、计划时间、实施人、执行结果、回滚方案 | 变更类型、影响范围、审批人、关联故障单号 | 小团队变更量少时可简化审批人字段 |
| 故障处置 | 故障单号、平台编号、发现时间、故障现象、处置人、关闭状态 | 发现方式、影响范围、根因、关联变更单号 | 重大故障复盘时补根因与影响范围 |
| 备份与恢复 | 记录编号、平台编号、备份对象、备份时间、存放位置、执行人 | 备份方式、保留期限、恢复演练日期、演练结果 | 有合规要求时补保留期限与演练记录 |
| 账号与权限 | 记录编号、平台编号、使用人、权限角色、开通日期、操作人 | 账号类型、所属团队、变更说明、回收日期 | 账号数量多、需要定期审计时补回收日期 |
| 容量与版本 | 记录编号、平台编号、记录日期、当前版本、记录人 | 存储使用量、用户数、容量预警、升级计划 | 平台承载用户多时补容量相关字段 |
| 交接记录 | 交接编号、平台编号、交出人、接收人、交接日期、确认状态 | 交接类型、交接内容、遗留事项 | 人员变动频繁时补交接内容与遗留事项 |
调整必填范围可以按两个维度判断。平台数量在三个以内、维护人员固定的团队，可把巡检的复核人、变更的审批人列为选填，减少日常填写量；平台数量多、多人轮值时，应把复核人、审批人、关联单号升为必填，保证任何一条记录都能找到第二个人核对。涉及生产环境的变更与故障，回滚方案和关闭状态建议始终必填，这两项直接决定事件能否闭环。
一份填好的运维手册示例
以下示例中的平台名称、编号、时间与人员均为演示情景，用于说明八张表如何联动填写，不代表真实环境。
平台台账与巡检记录
| 平台编号 | 平台名称 | 部署方式 | 责任团队 | 平台负责人 | 当前状态 |
|---|---|---|---|---|---|
| PL-001 | 研发管理平台 | 私有化部署 | 基础平台组 | 张明（基础平台组） | 运行中 |
| 巡检日期 | 平台编号 | 巡检项 | 检查结果 | 异常描述 | 处理动作 | 巡检人 |
|---|---|---|---|---|---|---|
| 2024-06-03 09:00 | PL-001 | 磁盘空间 | 异常 | 数据盘使用率接近上限 | 提交扩容变更 CHG-2024-018 | 李华（基础平台组） |
一次变更从申请到回滚的记录链
| 变更单号 | 平台编号 | 变更内容 | 计划时间 | 实施人 | 执行结果 | 回滚方案 | 关联故障单号 |
|---|---|---|---|---|---|---|---|
| CHG-2024-018 | PL-001 | 数据盘扩容 | 2024-06-04 22:00 | 李华（基础平台组） | 已回滚 | 恢复扩容前磁盘快照 | INC-2024-007 |
这条记录说明：巡检发现容量异常后发起变更，变更执行失败触发回滚，并关联到随后登记的故障单。回滚方案在变更申请阶段就已写明，执行时按方案操作，事后可核对。
一次故障从发现到关闭的记录链
| 故障单号 | 平台编号 | 发现时间 | 发现方式 | 故障现象 | 处置人 | 恢复时间 | 根因 | 关闭状态 | 关联变更单号 |
|---|---|---|---|---|---|---|---|---|---|
| INC-2024-007 | PL-001 | 2024-06-04 22:20 | 变更实施中发现 | 扩容后服务无法启动 | 李华（基础平台组） | 2024-06-04 23:10 | 扩容后挂载配置未同步更新 | 已关闭 | CHG-2024-018 |
故障记录与变更记录通过单号互指，复盘时可以还原“巡检发现问题—发起变更—变更失败—回滚恢复—登记根因”的完整链路。备份与恢复表、账号与权限表、容量与版本表、交接记录表按同样方式以平台编号挂到 PL-001 下，形成该平台的完整运维档案。
手册的调整与长期维护方法
模板上线后需要有人负责修订，否则表格会逐渐与实际脱节。维护工作集中在三件事：什么情况下改、谁来评审、交接时检查什么。
修订触发条件与版本记录
出现以下情况时应修订手册：新增或下线平台、部署方式发生变化、必填字段调整、状态词表增删、发生重大故障后复盘提出字段补充。每次修订在手册末尾登记版本，记录修订日期、修订人、修订内容和影响范围，旧版本保留可查。
| 版本号 | 修订日期 | 修订人 | 修订内容 | 影响范围 |
|---|---|---|---|---|
| V1.0 | 首版发布 | 全部八张表 | ||
评审角色与周期
手册由平台负责人维护，责任团队负责人评审，涉及账号权限和备份恢复的字段调整应请安全或基础设施相关角色共同确认。建议每季度评审一次，重大故障复盘后即时评审。评审的输出是修订记录和更新后的空白模板，而不是口头结论。
交接时的检查项
- 平台台账中该平台的状态、负责人、部署方式是否为最新。
- 未关闭的变更单和故障单是否逐条列出并说明进展。
- 备份与恢复记录中最近一次演练结果是否可查。
- 账号与权限记录中离场人员的权限是否已回收。
- 容量与版本记录中是否有待执行的升级计划。
- 交接记录本身是否由交出人与接收人双方确认。
这些记录如果分散在个人文档里，交接时容易遗漏。把巡检、变更、故障作为工作项，把手册和字段说明作为文档沉淀在 ONES 中，可以让每条记录带着编号、责任人和状态流转，交接时按平台编号筛选即可核对。ONES 支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署；采用高可用集群部署时，基于高可用架构运行，可实现故障转移、数据容灾、零停机服务升级。手册中的操作说明和复盘记录可放在 ONES Wiki 中，与工作项记录相互引用，形成可长期维护的运维档案。
常见问题
平台数量很少、只有一两个人维护，八张表都要填吗？
可以按实际情况裁剪。平台数量在三个以内、维护人员固定的团队，可先把巡检的复核人、变更的审批人、故障的影响范围列为选填，保留平台编号、变更单号、故障单号等追溯字段。生产环境的变更回滚方案和故障关闭状态建议始终填写，这两项决定事件能否闭环。平台数量增加或改为多人轮值后，再把复核人、审批人和关联单号升为必填。
巡检、变更、故障记录放在文档表格里，和放在工作项系统里有什么区别？
文档表格适合快速起步，复制表头就能填。记录量变大后，表格里的状态、责任人和单号需要人工同步，容易与实际脱节。把巡检、变更、故障作为工作项管理，每条记录带着编号、责任人和状态流转，交接时按平台编号筛选即可核对；手册和字段说明作为文档沉淀，与工作项相互引用。ONES 中可用工作项承载记录、用 ONES Wiki 沉淀操作说明和复盘文档，两种方式也可以并行，先用表格跑通口径，再逐步迁移。
变更执行失败触发回滚，故障单和变更单应该怎么关联？
由变更引发的故障，在故障记录中填写关联变更单号；故障处置中执行的修复变更，在变更记录中填写关联故障单号。示例中 CHG-2024-018 扩容变更执行失败并回滚，随后登记故障单 INC-2024-007，两张表通过单号互指，复盘时可以还原“巡检发现问题—发起变更—变更失败—回滚恢复—登记根因”的链路。回滚方案要在变更申请阶段写明，执行时按方案操作，事后才能核对。
备份记录只记了备份时间，还需要补恢复演练吗？
建议补。备份记录能证明数据被复制过，恢复演练记录才能证明数据可以恢复。模板中恢复演练日期和演练结果在首版可列为选填，有合规要求或平台承载核心研发数据时应升为必填，并约定演练周期。演练结果按“成功／失败／部分恢复”等固定词表填写，失败时在异常描述中写清原因和后续动作。
人员交接时，除了填交接记录表，还要核对哪些内容？
交接记录表本身只是确认凭证，实际核对要回到其他七张表：平台台账中该平台的状态、负责人、部署方式是否为最新；未关闭的变更单和故障单是否逐条列出并说明进展；备份与恢复记录中最近一次演练结果是否可查；账号与权限记录中离场人员的权限是否已回收；容量与版本记录中是否有待执行的升级计划。这些检查项逐条确认后，再由交出人与接收人在交接记录上双方确认。
