研发平台运维手册要能直接指导值班和变更，关键在于把平台自身的运行维护拆成可执行条目。本文以一套假设的自建研发管理平台为背景，给出一份已填写的运维手册片段，覆盖组件清单、巡检、告警、变更、备份、权限和故障复盘，并说明哪些字段需要按实际环境替换。手册中的巡检、变更与复盘条目，可以对应到 ONES 工作项与文档的管理动作，便于把运维记录沉淀在同一处。
要点总览（TL;DR）
- 手册的核心交付物是已填写的条目：组件清单、巡检表、告警分级、变更记录、备份恢复、账号权限和故障复盘，每项都要落到可观察判据和明确接手人。
- 巡检项写“检查方法+正常判据”，告警按影响范围而非组件分级，变更记录必须含回滚方式与审批人，备份条目单列恢复演练结果。
- 编写顺序从组件与责任人开始，再写巡检与告警，最后补变更与复盘；手册本身要版本化，明确谁改、何时改、改后通知谁。
- 示例中的平台名称、人员、频率、时限、保留份数均为演示值，上线前必须替换为真实信息。
- 这套写法适用于单套自建或私有化部署平台；多环境、多租户、跨地域部署以及云托管组件需要扩展条目。
这份运维手册示例要解决什么问题
很多团队写运维手册时容易写成组件说明书：列出服务器、数据库、中间件，却说不清每天该看什么、出现异常找谁、变更前要确认哪些条件。这份示例要解决的是“手册写完之后能不能用”的问题，把平台运行维护拆成值班人员可以照着执行、交接时可以核对的固定条目。
示例假设的平台是一套自建或私有化部署的研发管理平台，包含应用服务、数据库、缓存、文件存储等组件，供研发团队日常使用。这个假设决定了手册的关注点：平台自身是否可用、数据是否可恢复、变更是否可控。读者对象包括三类角色：平台运维负责人负责手册整体维护和条目审定；值班工程师按巡检表和告警响应表执行日常动作；变更审批人依据变更记录表判断窗口、回滚方式和影响范围。
示例覆盖范围限定在平台自身的运行维护。业务流水线的交付与发布流程设计、通用服务器与网络操作系统运维教程，属于相邻主题，本文不展开。读者可以从本文拿走的产出是一份手册骨架：把示例中的平台名称、组件数量、责任人、频率、时限替换成真实信息后，可以直接作为自己平台手册的初稿。
完整示例：一份研发平台运维手册的已填写片段
以下内容为演示情景，平台名称、人员、数值均为假设值，用于展示填写方式，不代表任何真实客户环境。
平台概览页
| 字段 | 填写示例 |
|---|---|
| 系统名称 | 研发管理平台（示例代号 RDP） |
| 部署方式 | 私有化部署，单集群，内网访问 |
| 组件清单 | 应用服务 3 节点、数据库主备 2 节点、缓存 2 节点、文件存储 1 套、反向代理 2 节点 |
| 责任人 | 平台负责人：张工；值班轮换：运维组 A/B 班；变更审批：李工 |
| 依赖的外部系统 | 企业 LDAP 目录、内部邮件网关、统一监控平台 |
| 手册版本 | v1.2，2025-03 修订，修订人张工 |
日常巡检表
| 巡检项 | 频率 | 检查方法 | 正常判据 | 异常升级路径 |
|---|---|---|---|---|
| 应用服务进程与端口 | 每日 09:00 | 查看服务状态页与端口监听 | 3 个节点均为运行状态，端口可访问 | 单节点异常通知值班工程师；两节点以上异常升级平台负责人 |
| 数据库主备同步 | 每日 09:00 | 查看复制状态与延迟指标 | 备库同步正常，延迟在设定阈值内 | 延迟超阈值通知 DBA 接口人，持续 30 分钟升级平台负责人 |
| 缓存命中与内存占用 | 每日 09:00 | 查看缓存监控面板 | 内存占用低于告警线，无大量淘汰 | 通知值班工程师排查热点键 |
| 文件存储剩余空间 | 每周一 | 查看存储容量报表 | 剩余空间高于预留线 | 低于预留线提交扩容申请，抄送平台负责人 |
| 备份任务执行结果 | 每日 10:00 | 查看备份任务日志 | 前一周期备份成功且文件可读 | 失败当日重跑，连续两次失败升级平台负责人 |
告警分级与响应时限表
| 级别 | 定义（按影响范围） | 通知对象 | 首次响应 | 恢复目标 |
|---|---|---|---|---|
| P1 | 平台整体不可用，或登录、核心数据读写全部受阻 | 值班工程师、平台负责人、变更审批人 | 15 分钟内 | 2 小时内恢复或给出降级方案 |
| P2 | 部分功能不可用，影响一个以上团队但平台整体可访问 | 值班工程师、平台负责人 | 30 分钟内 | 4 小时内恢复 |
| P3 | 单节点异常或性能下降，用户可继续使用 | 值班工程师 | 当班内 | 下一个工作日处理完毕 |
| P4 | 提示类问题，不影响使用 | 值班工程师记录 | 按排期 | 纳入例行维护 |
变更与发布记录表
| 变更类型 | 窗口 | 回滚方式 | 审批人 | 记录示例 |
|---|---|---|---|---|
| 应用版本升级 | 每周四 20:00–22:00 | 保留上一版本镜像，回滚脚本 10 分钟内完成 | 李工 | 2025-03-13 升级至 v3.4.1，验证登录与核心页面正常 |
| 配置调整 | 工作日 18:00 后 | 变更前导出配置快照 | 张工 | 2025-03-11 调整会话超时参数，观察 24 小时无异常 |
| 数据库结构变更 | 周六 09:00–12:00 | 变更前全量备份，保留回滚 SQL | 李工与 DBA 接口人 | 2025-03-08 新增索引，执行前后对比查询耗时 |
| 紧急修复 | 随时，事后补记录 | 按修复方案预设回滚步骤 | 平台负责人事后确认 | 2025-03-05 修复登录异常，次日补录变更单 |
备份与恢复记录
| 备份对象 | 周期 | 保留份数 | 恢复演练结果 |
|---|---|---|---|
| 数据库全量 | 每日一次 | 保留 14 份 | 2025-03-01 在测试环境恢复成功，耗时 40 分钟 |
| 文件存储 | 每周一次增量 | 保留 8 份 | 2025-02-22 抽样恢复 100 个文件，校验一致 |
| 应用配置 | 每次变更前 | 保留最近 10 次 | 2025-03-11 配置快照回滚验证通过 |
账号与权限管理条目
- 申请：申请人提交账号用途、所需角色和预计使用周期，由直属负责人确认。
- 审批：平台负责人审批高权限角色，普通角色由值班工程师按角色清单开通。
- 定期复核：每季度导出账号与角色清单，由各团队负责人确认在职与权限匹配情况。
- 离场处理：人员离职或转岗当日停用账号，保留操作记录备查。
故障处置与复盘模板
| 字段 | 填写示例 |
|---|---|
| 现象 | 部分用户登录后页面加载缓慢，持续约 20 分钟 |
| 影响范围 | 两个研发团队，约 60 名用户，核心数据读写未受影响 |
| 时间线 | 10:05 告警触发；10:12 值班确认；10:20 定位缓存节点异常；10:35 恢复 |
| 根因 | 缓存节点内存不足导致频繁淘汰，热点数据回源数据库 |
| 改进项 | 调整缓存内存告警线；补充热点键巡检项；更新巡检表并通知值班组 |
逐项解释：每个字段为什么这样写
巡检项写成“检查方法+正常判据”，是为了让不同值班人员得到同一个判断。只写“检查数据库”无法执行，也无法交接；写明查看哪个状态页、延迟在什么范围内算正常，新人按表操作就能得出可比较的结论，异常时也知道该通知谁。
告警分级按影响范围划分，而不是按组件划分。组件出问题时，值班人员最先需要判断的是“有多少人不能用、能不能继续工作”，这决定了响应优先级。按组件分级容易让一个不影响使用的单节点异常和整体不可用获得同样的紧迫感，反而拖慢真正紧急事件的处理。
变更记录必须包含回滚方式与审批人，原因是变更的风险集中在“出问题能不能退回去”和“谁对这次变更负责”。回滚方式写清楚，执行人不必临场设计退路；审批人留名，事后复盘时能追溯决策依据。缺少这两项，变更记录只剩时间流水，无法支撑复盘。
备份条目单列恢复演练结果，是为了区分“备份任务成功”和“数据真的能恢复”。备份文件损坏、恢复步骤缺失、恢复耗时过长，都只有在演练中才会暴露。把演练结果写进手册，等于给备份有效性加了一道可核验的证据。
示例中的平台名称、人员姓名、节点数量、巡检频率、响应时限、保留份数均属于假设值，上线前必须替换为真实信息。组件清单要按实际部署核对，责任人要落到具体岗位或人员，频率和时限要结合业务影响确定。这些字段照抄示例没有意义，替换过程本身就是梳理平台现状的过程。
从示例到自用手册：可迁移的写法规律
编写顺序建议从组件与责任人开始，再写巡检与告警，最后补变更与复盘。先有组件清单，巡检项才有对象；先有责任人，异常升级路径才有落点；先有巡检和告警，变更窗口和复盘模板才能对应到真实的运行节奏。反过来先写模板框架，容易出现条目齐全但无人对应的空壳手册。
每条运维动作都要落到可观察的判据和明确的接手人。判据是“看到什么算正常、看到什么算异常”，接手人是“异常之后谁来处理”。这两项缺一，条目就停留在描述层面。可以用一个简单检查：把任意一条巡检项交给未参与编写的人，看他能否独立完成判断并知道下一步找谁。
手册条目要与值班、审批、复盘等管理动作对应。巡检表对应值班交接，变更记录表对应审批，故障复盘模板对应改进项跟踪。条目之间形成闭环，手册才不只是查阅文档，而是日常工作的依据。以 ONES 为例，巡检发现的问题、变更单和复盘改进项可以分别建成工作项，按状态流转跟踪；手册本身作为文档维护版本，修改后通知相关角色。这样运维记录和平台使用记录在同一处沉淀，复盘时不必跨系统拼凑信息。
手册本身也需要版本化维护。明确谁负责修改、什么情况下修改、修改后通知谁。常见触发修改的情形包括：组件增减、责任人变更、巡检项调整、复盘产生新改进项。每次修改记录版本号和修订说明，值班人员按最新版本执行。
适用边界：这套示例在什么情况下需要调整
这套示例适用于单套自建或私有化部署平台的运维场景，组件数量有限、责任角色清晰、变更频率可控。平台规模扩大或部署形态变化时，条目需要相应扩展。
多环境、多租户或跨地域部署时，组件清单要按环境分别列出，巡检表要区分生产与测试环境，告警分级要考虑租户隔离和地域故障的传播范围，备份条目要明确各环境的数据保留策略。跨地域部署还需要补充链路检查和故障切换的验证条目。
云托管服务与自建组件在巡检和备份条目上存在差异。托管服务的基础设施巡检通常由服务商承担，手册应转向关注服务配额、连接配置和账单异常；备份条目要确认托管服务的备份能力与恢复方式，避免沿用自建环境的操作习惯。自建组件则需要保留完整的进程、磁盘和同步状态检查。
示例中的频率、时限、保留份数均为演示值，需要按实际业务影响确定。核心业务时段的平台不可用影响更大，响应时限应更短；数据变更频繁的平台，备份保留份数可能需要增加。这些数值没有通用标准，应以团队能够承受的损失范围为起点倒推。
手册不能替代监控系统与应急预案本身。监控负责发现异常，手册负责规定发现之后怎么做，应急预案负责重大故障时的组织与决策。三者各司其职，手册写得好，也需要监控覆盖到位、应急演练定期进行，才能在真实故障中发挥作用。
常见问题
手册里的巡检频率和告警响应时限应该怎么定？
示例中的“每日 09:00”“15 分钟内响应”都是演示值，不能直接照搬。确定频率时看两件事：该组件出问题后多久会影响到用户，以及团队能在多长时间内发现并处理。核心登录链路和数据库同步可以每日检查，容量类指标可以每周检查。
响应时限从业务能承受的不可用时长倒推：平台整体不可用影响所有团队，首次响应就要短；单节点异常用户仍可继续使用，可以放到当班处理。定完之后写进告警分级表，并和值班排班对齐，避免时限写了但没人值守。
平台组件增减或责任人变动后，手册怎么同步更新？
把手册本身当作需要版本化的文档管理，明确修改触发条件和通知范围。常见触发情形包括组件增减、责任人变更、巡检项调整、复盘产生新改进项。每次修改记录版本号和修订说明，并通知值班组和变更审批人。
建议在平台概览页保留“手册版本”字段，写明修订日期和修订人。值班人员按最新版本执行，旧版本归档备查。如果团队使用 ONES Wiki 维护手册，可以用页面版本记录变更，配合工作项跟踪待落实的修改项。
备份任务每天成功，还需要单独做恢复演练吗？
需要。备份任务成功只说明文件生成了，不能说明数据可以恢复。备份文件损坏、恢复步骤缺失、恢复耗时超出预期，这些问题只有在实际恢复时才会暴露。
示例把恢复演练结果单列在备份记录表中，就是为了留下可核验的证据。演练可以在测试环境进行，记录恢复对象、耗时和校验结果。演练频率按数据重要程度确定，核心数据库建议定期演练，配置类备份可以在每次变更后验证回滚。
多环境或多租户部署时，这份示例要改哪些地方？
组件清单要按环境分别列出，生产、测试、预发各自成表，避免混在一起导致巡检遗漏。巡检表要区分环境，生产环境的检查项和判据更严格。告警分级要考虑租户隔离，一个租户受影响和平台整体不可用的优先级不同。
备份条目要明确各环境的数据保留策略，测试环境可以缩短保留周期。跨地域部署还需要补充链路检查和故障切换验证条目。这些扩展都建立在原有结构上，不需要推翻重写。
手册和监控系统、应急预案之间是什么关系？
三者分工不同。监控系统负责发现异常，手册规定发现异常之后按什么步骤处理、通知谁、什么条件下升级，应急预案负责重大故障时的组织决策和对外沟通。
手册不能替代监控覆盖，也不能替代应急演练。手册写得再完整，如果监控没有覆盖关键指标，异常仍然发现不了；如果从不演练，故障发生时按手册执行也会生疏。建议把手册中的巡检项和告警项与监控配置对照检查，确保条目有对应的数据来源。
