研发平台运行维护的对象是管理平台自身：账号权限、项目配置、插件集成、通知投递、附件存储和页面可用性。本文给出一套可直接套用的机制，包括服务清单、分层巡检、变更与故障处置流程、角色分工和验收清单，帮助平台负责人把维护工作从“出问题再处理”转为按计划执行、有记录可查。巡检项、变更单和故障记录也可以在 ONES 中作为工作项流转与留痕。
要点总览（TL;DR）
- 维护对象是管理平台自身：账号与权限、项目配置、插件集成、通知投递、附件存储、性能与可用性；业务流水线交付和通用服务器运维不纳入。
- 先输出平台服务清单，逐项标注依赖、责任人、影响面和维护级别，高维护级别项必须有备份人。
- 巡检按日、周、月、季度分层；变更走申请、影响评估、维护窗口、回滚预案、执行记录五步；故障先临时恢复再定位根因，复盘结论转为巡检项。
- 四类角色分工：平台负责人决策与复盘，运维执行人执行与记录，变更审批人把关影响与回滚，业务联络人接收通知并确认影响。
- 验收看记录是否连续可查：服务清单覆盖、巡检表齐全、变更单完整、故障复盘已转化、季度健康报告有约定口径的指标。
先划清维护边界：哪些属于研发平台运行维护
维护边界不清，最常见的结果是平台团队被拉进业务流水线排障，真正影响平台可用性的问题反而没人持续跟踪。划定边界的做法是先列服务项，再逐项确认责任人，最后明确哪些事项不在本文范围内。
研发平台运行维护的对象可以按六类归集：账号与权限（用户开通、角色调整、单点登录对接）、项目与工作项配置（字段、状态流、模板、项目归档）、插件与集成（第三方应用、Webhook、回调）、通知与邮件（站内通知、邮件投递、消息通道）、存储与附件（附件上传下载、容量占用、备份）、性能与可用性（页面加载、接口响应、登录成功率）。每一类都要落到具体服务项，而不是停留在类别名称上。
业务流水线的设计、持续交付流程的编排、通用服务器与网络操作系统的运维教程，属于其他工作范畴，不纳入本文的维护清单。这样划分的依据是：平台团队对管理平台的配置与可用性负责，流水线交付质量由对应的研发与交付团队负责。边界写清楚后，跨团队请求可以按服务清单判断归属，减少范围蔓延。
输出物是一份平台服务清单，建议包含以下字段：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 服务项 | 具体到可检查的动作或对象 | 单点登录（LDAP）登录链路 |
| 依赖 | 该服务项依赖的系统、组件或外部服务 | 企业 LDAP 目录服务、平台认证模块 |
| 责任人 | 唯一责任人，可另设备份人 | 平台运维执行人 A，备份人 B |
| 影响面 | 该服务不可用时受影响的用户与业务 | 全体研发人员无法登录平台 |
| 维护级别 | 按影响面和恢复难度分为高、中、低 | 高：登录、核心页面；中：通知投递；低：历史项目归档 |
清单完成后做一次核对：每个高维护级别服务项是否都有责任人和备份人，依赖是否写全。完成标志是清单经平台负责人确认，并在团队内可查。
核心操作步骤：分层巡检、变更与故障处置怎么落地
维护流程分四段：日常巡检发现异常，周期性维护处理积累问题，变更管理控制改动风险，故障处置兜住突发中断。四段共用同一套记录，避免信息散落在聊天工具里。
日常巡检：每天固定动作，输出巡检表
输入是前一日遗留的异常项和当日值班人；做法是按固定顺序逐项检查；输出是当日巡检表；完成标志是全部检查项有结论，异常项已建单并指派。
- 登录与单点登录：用普通账号和对接账号各登录一次，确认认证链路正常。
- 首页与核心页面加载：打开首页、项目列表、工作项详情，记录加载是否明显变慢。
- 任务与通知投递：触发一条测试通知，确认站内消息与邮件均送达。
- 附件上传下载：上传一个小文件并下载校验，确认存储链路可用。
- 集成回调状态：查看集成回调记录，确认无持续失败或积压。
周期性维护：按周、月、季度分层
周期性维护处理日常巡检覆盖不到的问题。周度做账号与权限清理、项目归档检查；月度做存储与附件容量盘点、日志与备份校验；季度做版本升级评估，结合厂商发布说明判断是否需要升级、升级影响哪些集成。每项维护的完成标志是记录中写明了检查结果、处理动作和遗留事项。
变更管理：五步走，每次留痕
输入是变更需求与影响范围；做法按申请、影响评估、维护窗口、回滚预案、执行记录五步执行；输出是变更单；完成标志是变更后验证通过、结果已通知业务联络人。
- 变更申请：写明变更内容、涉及服务项、期望时间。
- 影响评估：对照服务清单判断影响面，确认是否需要提前公告。
- 维护窗口：选择使用低峰时段，公告起止时间。
- 回滚预案：明确回滚触发条件、回滚步骤和所需备份。
- 执行记录：记录实际执行时间、操作人、验证结果和偏差。
故障处置：先恢复，再定位，最后转巡检项
故障按影响面和用户范围分级，高等级故障设定更短的首响时限，具体时限由团队在机制中约定。处置顺序是先临时恢复可用性，再定位根因；故障结束后完成复盘，把结论转化为新的巡检项或配置调整。完成标志是故障记录中包含影响时段、处置动作、根因和后续动作，且后续动作已进入巡检表或变更计划。
角色与交付物：谁来做、交什么、怎么交接
维护机制需要四类角色，职责边界按“决策、执行、审批、知情”划分，避免同一件事多人负责或无人负责。
| 角色 | 职责 | 交付物 | 时点 | 交接对象 |
|---|---|---|---|---|
| 平台负责人 | 确认服务清单与维护级别，审批高等级变更，主持故障复盘 | 服务清单、季度健康报告 | 季度初更新清单，季度末出报告 | 业务联络人、变更审批人 |
| 运维执行人 | 执行日常巡检与周期性维护，提交变更申请，执行故障临时恢复 | 巡检表、变更单、故障处置记录 | 每日巡检当日提交，变更执行后当日记录 | 平台负责人、下一班值班人 |
| 变更审批人 | 评估变更影响与回滚预案，批准或退回变更 | 变更单审批意见 | 维护窗口前完成 | 运维执行人 |
| 业务联络人 | 接收变更与故障通知，反馈业务侧影响 | 影响确认与恢复确认 | 变更公告后、故障恢复后 | 平台负责人 |
交接规则要写进机制：变更前由运维执行人向业务联络人发出窗口公告，变更后发出结果通知；故障期间由平台负责人统一对外同步信息，避免多头传递；值班与代班安排提前排定，代班人接手时以巡检表和未关闭的故障记录作为交接依据。完成标志是每个交付物都有明确的提交时点和接收人，交接不依赖口头说明。
示例：一次版本升级与一次登录故障的完整走法
以下两个情景用于说明前述流程如何串联，情景中的时间与角色为演示设定。
版本升级示例
输入：厂商发布新版本说明，运维执行人在季度升级评估中判断需要升级。动作：提交变更单，写明涉及服务项与影响面；变更审批人核对回滚预案，确认备份已完成；平台负责人批准；运维执行人在公告的维护窗口内执行升级，先备份配置与数据，再按步骤升级，升级后逐项验证登录、核心页面、通知投递和集成回调。输出：变更单记录实际执行时间、验证结果和偏差；结果通知发给业务联络人。若验证不通过，按预案回滚并在变更单中记录回滚原因。
登录故障示例
输入：巡检或用户反馈发现登录失败。动作：运维执行人先判断影响范围，确认是全员还是个别账号；高等级故障立即通知平台负责人和业务联络人；先做临时恢复，例如切换认证通道或重启相关服务，恢复可用后再定位根因，例如证书过期或目录服务连接异常。输出：故障处置记录写明影响时段、临时恢复动作、根因和后续动作；复盘会上把根因转化为新的巡检项，例如增加证书到期检查。完成标志是新增巡检项已写入巡检表并开始执行。
两次示例产生的变更单、故障记录和新增巡检项统一归档，进入下一轮巡检和季度健康报告的统计范围，形成连续可查的记录链。
完成检查：维护机制是否真的运转起来
判断机制是否建立，看记录是否连续、责任是否到人、结论是否落地。以下清单可逐项核对：
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 服务清单覆盖度 | 六类服务项均有条目，高维护级别项有责任人和备份人 | 经确认的服务清单 | 平台负责人 |
| 巡检记录连续性 | 抽查近四周，每日巡检表齐全，异常项有闭环 | 巡检表 | 运维执行人 |
| 变更记录完整性 | 每次变更均有申请、审批、执行记录和结果通知 | 变更单 | 变更审批人 |
| 故障复盘转化 | 近期故障均有复盘记录，结论已转为巡检项或配置调整 | 故障记录与巡检表对照 | 平台负责人 |
| 季度健康报告 | 包含可用性、故障次数、变更成功率等指标，口径在团队内已约定 | 季度健康报告 | 平台负责人 |
这套机制在 ONES 中落地时，巡检项、变更单和故障记录可以作为工作项按统一字段流转，复盘结论直接关联到新增巡检项，季度健康报告所需的记录也能从平台内汇总。ONES 支持私有部署和公有云部署，私有化部署采用 K3s 容器化部署并支持对接 LDAP 等企业内部系统；高可用集群部署可实现故障转移、数据容灾和零停机服务升级。部署方式不同，平台团队承担的巡检、升级与容灾验证工作量也不同，服务清单和维护级别应据此调整。ONES Performance 可对系统内流转的研发数据做多维度分析并支持仪表盘共享，适合用于效能数据观察；平台可用性指标仍需按团队约定的口径单独统计。
常见问题
团队规模小、没有专职运维，这套维护机制怎么简化？
可以合并角色，但不能省略记录。平台负责人和变更审批人可由同一人兼任，日常巡检由值班人轮换执行，前提是服务清单里每个高维护级别项都写明了责任人和备份人。巡检频率可以按实际使用强度调整，例如把附件容量盘点从月度改为季度，但登录链路、核心页面和通知投递这类直接影响全员使用的检查项建议保持每日执行。记录仍要落到巡检表和变更单上，否则故障复盘和季度报告没有依据。
公有云部署和私有化部署，维护工作量差别在哪里？
ONES 支持私有部署和公有云部署两种方式。公有云部署按人付费、无需部署，系统层面的维护由服务方承担较多，平台团队的重点放在账号权限、项目配置、集成和通知等使用侧管理。私有化部署采用 K3s 容器化部署，并支持对接 LDAP 等企业内部系统，平台团队需要自行承担版本升级、备份校验和容量盘点的执行工作。选择高可用集群部署时，还需要定期验证故障转移和容灾能力。服务清单和维护级别应随部署方式调整，把团队实际承担的动作写进去。
变更被回滚了，变更单还要按成功流程记录吗？
要记录，而且回滚本身就是变更单的重要内容。变更单应写明回滚触发条件是否被触发、实际回滚步骤、回滚耗时和验证结果，并注明偏差原因。回滚记录是判断回滚预案是否有效的直接证据，也是下一轮升级评估的输入。如果同类变更反复回滚，应把它转为待解决的配置问题或升级评估项，而不是简单重试。
故障复盘得出的巡检项，怎么保证后续真的在执行？
关键是把巡检项写入巡检表并指定执行人，而不是只留在复盘文档里。复盘记录中应写明新增巡检项的名称、检查方法、执行频率和责任人，并在下一次巡检中体现检查结果。季度健康报告核对时，可以把近期故障记录与巡检表逐条对照，确认每条复盘结论都有对应的执行记录。巡检项、变更单和故障记录在 ONES 中作为工作项流转时，这种关联可以直接保留在平台内。
季度健康报告的指标口径怎么定，才不会每次统计都对不上？
先在团队内约定三个基础口径：可用性按什么时间范围和什么判定标准计算，故障次数是否包含低等级事件，变更成功率是否把回滚计入失败。口径写进机制文档，并在第一次报告中注明。ONES Performance 可对系统内流转的研发数据做多维度分析并支持仪表盘共享，适合观察研发过程数据；平台可用性这类指标仍需按约定口径单独统计，两者不要混用。
