研发平台故障响应要先把“平台自身不可用或关键能力受损”定义清楚，再建立分级标准、值班与升级路径、处置动作和复盘闭环。具体做法是：列出登录与认证、代码仓库、构建与制品、需求与任务、流水线调度入口等关键服务，按影响范围和严重程度划分P1–P4；明确一线值班、平台负责人、业务接口人的职责与响应时限；为每类故障准备排查入口、止损动作和沟通模板；恢复后完成时间线复盘，把改进项转成可跟踪的工作项并验证关闭。本文适用于负责研发平台运行的管理员和平台负责人，不展开交付业务流水线本身的故障处置。
要点总览（TL;DR）
- 故障响应先统一口径：登录认证、代码仓库、构建与制品、需求与任务、流水线调度入口等关键服务不可用或降级才进入故障流程，普通咨询和单用户配置问题走常规支持。
- 分级按影响范围与严重程度交叉判定P1–P4，级别越高响应时限越短、通报范围越大；交付业务流水线故障和通用基础设施故障要提前划清边界。
- 响应责任落到一线值班、平台负责人、业务接口人、管理层通报四类角色，值班覆盖非工作时间，升级条件写明超时未定位、影响扩大、需外部团队介入等触发点。
- 处置顺序是先止损后定位：确认影响面、执行回滚或限流等止损动作、按最近变更到依赖服务排查、按级别节奏通报、平台侧与用户侧共同确认恢复。
- 恢复后完成时间线复盘，把监控、变更管理、容量、文档、流程类改进项转为有负责人、截止时间和验证方式的工作项，复发故障单独跟踪至关闭。
先界定什么算研发平台故障
故障响应的第一步是统一口径：哪些异常进入故障流程，哪些按普通工单或咨询处理。研发平台的运行范围通常包括登录与认证、代码仓库、构建与制品、需求与任务、流水线调度入口等关键服务。判断一个异常是否构成故障，看它是否导致上述服务不可用、关键能力降级，或对多个团队的工作造成持续阻塞。单个用户的配置问题、使用咨询、需求变更不属于故障，走常规支持渠道即可。
分级采用两个维度交叉判定：影响范围（全员、单团队、单人）和严重程度（不可用、降级、体验问题）。级别越高，响应时限越短、通报范围越大。下表可作为团队起步时的分级表，具体时限按团队值班能力和服务规模调整。
| 级别 | 判定条件 | 响应时限 | 通报对象 | 升级触发 |
|---|---|---|---|---|
| P1 | 登录认证、代码仓库、流水线调度入口等核心服务对全员不可用，或数据面临丢失风险 | 立即响应，15分钟内首次通报 | 平台负责人、管理层、全体用户 | 30分钟未定位或影响继续扩大 |
| P2 | 核心服务对单团队不可用，或多个团队出现明显降级（如构建排队严重、制品拉取失败） | 30分钟内响应并通报 | 平台负责人、受影响团队接口人 | 1小时未缓解或波及更多团队 |
| P3 | 单团队或单人关键能力降级，存在可用绕行方式 | 2小时内响应 | 值班人员、受影响团队接口人 | 绕行方式失效或影响扩大 |
| P4 | 体验问题，如页面加载慢、个别功能报错，不影响主要工作推进 | 1个工作日内受理 | 值班人员 | 同类问题集中出现时合并升级 |
边界要提前说清：交付业务流水线中某个项目的构建失败、测试环境配置错误，属于业务侧问题，由对应团队处理，平台团队提供平台能力层面的支持；服务器、网络、存储等通用基础设施故障由基础设施团队主责，平台团队负责确认平台侧影响并配合恢复。把边界写进分级表，可以减少故障期间的职责争议。
故障响应的角色、值班与升级路径
响应责任要落到具体角色，而不是“大家一起来”。四类角色的分工如下：一线值班负责受理告警和用户反馈、做初步确认、执行预案中的止损动作；平台负责人负责判定级别、决定是否升级、协调资源；业务接口人负责在本团队内传达影响、收集受影响范围、确认恢复效果；管理层通报由平台负责人或指定发布人完成，用于P1、P2级别的资源协调和对外说明。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 一线值班 | 接收告警与反馈，初步确认影响，执行既定止损动作，记录时间线 | 故障记录初稿、首次通报素材 |
| 平台负责人 | 判定级别，决定升级，协调厂商或基础设施团队，把关对外口径 | 级别判定结论、升级记录、恢复确认 |
| 业务接口人 | 收集本团队受影响情况，传达进展，组织用户侧验证 | 影响范围清单、用户侧确认结果 |
| 管理层通报人 | P1、P2期间向管理层同步影响与处置进展 | 进展通报、恢复通知 |
值班安排要覆盖非工作时间。常见做法是排周值班表，明确当周主值班和备值班，交接时同步未关闭的告警、近期变更和待观察项。非工作时间的响应可以设两档：P1、P2立即呼叫主值班，超时未响应转备值班；P3、P4次日受理。值班表、联系方式和交接记录放在团队都能看到的位置，避免故障时找不到人。
升级路径设置明确的触发条件，减少依赖个人判断：超过约定时间未定位根因、影响范围扩大、需要厂商或基础设施团队介入、止损动作无效时，由平台负责人发起升级。升级动作包括通知上级、拉起跨团队协同、启用备用方案。对外统一口径由指定发布人发出，其他人在故障期间不单独对外解释原因和恢复时间。
从发现到恢复的处置步骤
处置阶段的目标是先恢复可用性，再定位根因。每一步都应有输入、动作、输出和完成标志，值班人员按清单执行，避免慌乱中遗漏。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 发现与确认 | 监控告警、用户反馈 | 核对告警指标与用户描述，复现或确认影响面，判断是否进入故障流程 | 故障记录初稿、初步影响范围 | 确认属于故障并给出初判级别 |
| 止损 | 近期变更记录、预案 | 按适用条件选择回滚、限流、切换备用入口、暂停相关任务 | 止损动作记录 | 核心服务恢复可用或影响被控制 |
| 定位与协同 | 日志、变更记录、发布记录 | 按“最近变更→依赖服务→平台自身组件”的顺序排查，必要时拉起厂商或基础设施团队 | 根因假设与验证结果 | 根因确认或找到稳定绕行方案 |
| 沟通 | 处置进展 | 首次通报说明影响与已采取措施，进展更新按固定节奏发出，恢复通知说明恢复时间与后续安排 | 通报记录 | 各节点通报按时发出 |
| 恢复确认 | 功能验证清单 | 逐项验证关键服务，邀请业务接口人做用户侧确认 | 恢复确认记录 | 平台侧与用户侧均确认正常 |
止损动作要事先写明适用条件。回滚适用于近期有明确变更且变更与故障时间吻合的情况；限流适用于流量突增导致的降级；切换备用入口适用于单节点或单链路故障；暂停相关任务适用于后台任务挤占资源、影响在线服务的情况。故障期间优先恢复可用性，根因分析放到恢复之后，避免在影响扩大时做高风险操作。
沟通节奏按级别设定：P1首次通报在15分钟内发出，之后每30分钟更新一次；P2首次通报在30分钟内发出，之后每小时更新。通报内容包含影响范围、当前状态、已采取措施、下次更新时间，恢复通知补充恢复时间和后续复盘安排。模板提前准备好，故障时填空即可。
故障记录与复盘怎么落到改进项
恢复不等于结束。每次P1、P2故障都应留下完整记录，P3视情况记录。必填字段包括：时间线（发现、响应、止损、恢复各节点）、影响范围、发现方式（监控告警还是用户反馈）、处置动作、恢复时间、根因结论。记录由当班值班人员起草，平台负责人补充确认。
复盘会议在恢复后约定时间内召开，P1建议3个工作日内，P2建议5个工作日内。参与角色包括平台负责人、当班值班、相关业务接口人，涉及厂商或基础设施团队的邀请对应人员参加。复盘聚焦时间线和根因，讨论“哪个环节可以更早发现、更快止损”，避免变成追责会。
改进项按类别归集：监控（补充告警指标、调整阈值）、变更管理（增加发布前检查、灰度步骤）、容量（扩容、限流配置）、文档（预案、排查手册）、流程（值班交接、升级条件）。每项改进转为工作项，设定负责人、截止时间和验证方式。验证方式要可观察，例如“新增告警在测试环境触发成功”“回滚预案演练一次并记录耗时”。改进项完成后由提出人验证关闭，未关闭项在下次值班交接时同步。
复发故障单独跟踪：同类根因再次出现时，提升改进项优先级，并检查上次改进项是否真正落地。关闭标准是改进项验证通过且经过一个观察周期未复发。故障记录、复盘结论和改进项可以放在同一套协作工具里承载，例如用ONES的工作项跟踪改进项负责人和截止时间，用文档沉淀故障记录与复盘结论，让值班交接和复发跟踪有统一入口。具体配置方式按团队实际使用情况确定。
一个团队级故障响应的示例
以下为演示情景，用于说明分级、处置与复盘如何串联。某研发团队使用统一认证登录研发平台，周一上午部分团队反馈无法进入系统，值班人员同时收到登录失败率升高的告警。
值班人员核对告警与反馈，确认受影响的是两个团队的成员，登录服务返回错误，其他服务暂未发现异常。按分级表，核心服务对单团队不可用、且可能扩大，初判P2，30分钟内发出首次通报，通知平台负责人和受影响团队接口人。平台负责人确认级别后，安排值班人员检查认证服务日志和最近变更记录，发现前一晚有一次认证配置调整，遂执行回滚。回滚后登录恢复，值班人员逐项验证登录、代码仓库、流水线入口，业务接口人组织本团队成员尝试登录并反馈正常，发出恢复通知。
恢复后当班人员补齐故障记录：时间线、影响范围（两个团队约数十人）、发现方式（用户反馈加告警）、处置动作（回滚认证配置）、恢复时间。复盘会上确认根因为配置变更缺少验证步骤，改进项包括：认证配置变更增加双人复核、补充登录失败率告警阈值、把回滚步骤写入认证服务预案。三项改进转为工作项，分别设定负责人和截止时间，验证方式为“下一次认证配置变更按新流程执行并记录”“告警在测试环境触发成功”“预案演练一次”。观察期内未再出现同类问题后关闭。
上线前的准备与完成检查
机制建成后，用一份检查清单判断它是否真的可用。以下条目逐项核对，未达标项明确阻断条件，避免机制停留在文档层面。
| 检查项 | 达标标准 | 未达标处理 |
|---|---|---|
| 分级表 | P1–P4判定条件、响应时限、通报对象、升级触发齐全，团队内已宣贯 | 阻断故障流程上线，补齐后重新评审 |
| 值班表与交接方式 | 覆盖非工作时间，主备值班明确，交接记录有固定位置 | 阻断P1、P2响应承诺 |
| 升级路径 | 触发条件明确，厂商和基础设施团队联系方式可用 | 补齐前不对外承诺响应时限 |
| 沟通模板 | 首次通报、进展更新、恢复通知模板齐备 | 限期补齐 |
| 监控与告警 | 关键服务均有可用性监控，告警能到达当班人员 | 核心服务缺监控时阻断对应级别承诺 |
| 演练或真实故障复盘 | 最近一次演练或真实故障完成复盘，记录可查 | 上线前至少完成一次桌面演练 |
| 改进项跟踪 | 每项有负责人、截止时间和验证方式 | 无负责人的改进项不计入关闭 |
检查由平台负责人组织，值班人员和业务接口人参与确认。全部达标后机制正式运行；存在阻断项时，先在小范围团队试运行，补齐后再扩大范围。机制运行后每季度复查一次，结合期间发生的故障调整分级时限和升级条件。
常见问题
P1和P2的边界在实际判断中容易混淆，怎么处理？
关键看影响范围是否跨团队以及核心服务是否整体不可用。核心服务对全员不可用、或存在数据丢失风险时按P1处理；核心服务只影响单团队，或多个团队出现明显降级但仍可绕行时按P2处理。判断时以当前确认的影响面为准，影响面在处置中扩大就立即升级，不必等原级别时限到期。值班人员给出初判后由平台负责人确认，避免同一类故障在不同班次判出不同级别。
非工作时间发生P3、P4故障，是否必须立即响应？
可以按级别分档安排。P1、P2在非工作时间立即呼叫主值班，超时未响应转备值班；P3、P4可安排到次日受理，前提是存在可用的绕行方式且影响不再扩大。分档规则要写进值班表并提前告知业务接口人，让受影响团队知道什么情况下该走紧急呼叫、什么情况下等常规受理。若P3在夜间出现影响扩大的迹象，按升级条件转为更高一级处理。
止损动作和根因排查冲突时，先做哪个？
优先止损，恢复可用性后再定位根因。回滚、限流、切换备用入口、暂停相关任务这些动作都有适用条件，事先写进预案，故障时按条件选用，不在影响扩大时做高风险操作。根因排查放到服务恢复之后，依据日志、变更记录和发布记录按顺序推进。若止损动作本身可能带来数据不一致等副作用，由平台负责人在执行前确认并记录判断依据。
改进项经常提了但落不了地，怎么保证闭环？
把每项改进转成工作项，明确负责人、截止时间和可观察的验证方式，例如“新增告警在测试环境触发成功”“回滚预案演练一次并记录耗时”。改进项完成后由提出人验证关闭，未关闭项在下次值班交接时同步。复发故障提升改进项优先级，并检查上次改进项是否真正落地。故障记录、复盘结论和改进项可以放在同一套协作工具里承载，例如用ONES的工作项跟踪负责人和截止时间，用文档沉淀故障记录与复盘结论，让值班交接和复发跟踪有统一入口，具体配置按团队实际使用情况确定。
机制刚建立，还没有真实故障可复盘，上线前怎么验证？
用桌面演练替代。选一个典型情景，例如登录服务异常导致部分团队无法进入系统，让值班人员、平台负责人和业务接口人按分级表走一遍：判定级别、发出首次通报、选择止损动作、确认恢复、补齐记录。演练结束后检查分级表、值班表、升级路径、沟通模板是否够用，监控告警能否到达当班人员。演练记录作为上线前的复盘依据，暴露的问题同样转为改进项跟踪。
