研发平台出现变慢、报错或部分功能不可用时，先确定影响范围，再判断原因方向，能避免在错误的方向上消耗处置时间。本文按“用户可感知的症状—受影响的业务对象—平台内部组件与依赖”三层收敛范围，说明每层需要的数据、常见原因假设的验证证据，以及止损和恢复确认的做法。排查范围限于研发管理平台自身的运行状态，交付流水线的执行故障属于持续交付主题，不在本文展开。
要点总览（TL;DR）
- 先按“用户症状—业务对象—组件依赖”三层收敛范围：用反馈与访问日志判断全员还是局部故障，再按功能模块定位受影响业务对象，最后沿调用链核对数据库、缓存、鉴权与集成接口。
- 各层数据要用同一时间窗口对齐，建议以故障起点前后各30分钟为统一窗口，避免把不同时段的异常混在一起分析。
- 原因判断区分假设与证据：资源瓶颈看监控曲线与饱和阈值，依赖故障看依赖侧错误率与响应时间，变更引入对齐变更时间线，流量异常看请求量分布与来源。
- 处置先止损再定位根因，回滚、数据修复、重启等有破坏风险的操作须提前交代备份、影响告知与停止点，恢复后按核心功能抽查、接口耗时、错误率回落和用户回访逐项确认。
- 复盘把本次暴露的监控盲区补成具体指标与告警阈值，把用户、项目、功能维度的数据纳入日常看板，并区分已确认根因与仍待观察项。
可用性下降的典型症状与影响边界
“平台变慢了”这类描述无法直接用于排查。第一步是把用户反馈转成结构化症状，让后续的范围判断有可对齐的输入。症状采集的目标是回答四个问题：什么时间发生、谁受影响、在哪个入口出现、能否重复出现。
常见症状可以按用户动作归类，每类对应的排查方向不同：
- 页面加载失败或长时间白屏：通常指向应用服务响应异常、静态资源加载失败或网关层问题。
- 接口超时或请求报错：需要记录具体接口路径、HTTP 状态码和响应耗时，便于判断是单接口问题还是全局问题。
- 登录异常：包括无法跳转登录页、认证失败、登录后反复跳回，可能涉及鉴权服务或会话存储。
- 数据保存失败：提交工作项、编辑文档、上传附件时提示保存失败，往往与数据库写入、存储服务或事务处理有关。
- 通知延迟或缺失：站内通知、邮件、即时消息推送未按时到达，可能涉及消息队列或外部集成接口。
记录症状时，建议使用统一表格，避免不同人用不同口径描述同一现象。下表可作为模板直接填写：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 发生时间 | 精确到分钟，注明时区 | 14:05 起持续约 20 分钟 |
| 功能入口 | 页面名称或接口路径 | 迭代看板页、工作项保存接口 |
| 错误提示与错误码 | 原文记录，不转述 | “请求超时”，HTTP 504 |
| 影响人数与范围 | 反馈人数、涉及团队或项目 | 3 个团队约 40 人反馈 |
| 复现步骤 | 可重复的操作路径 | 打开迭代看板→拖动工作项状态→保存失败 |
| 是否可复现 | 必现、偶现或仅一次 | 必现 |
边界同样需要提前说清。本文讨论的是管理平台自身的可用性，包括页面、接口、登录、数据读写和通知链路。流水线任务排队、构建失败、制品发布异常属于持续交付范畴，应由对应的流水线运维流程处理。把两类问题混在一次排查里，容易让时间窗口和数据来源对不上。
先判断影响范围：从用户到组件的三层收敛
范围判断的顺序由外向内：先看用户侧受影响面，再看业务对象，最后看组件与依赖。这个顺序的价值在于，前两层的数据通常几分钟内就能拿到，足以判断是全员故障还是局部故障，从而决定是否需要立即启动止损。
第一层：按团队、项目、角色统计受影响用户
从反馈渠道、客服工单和访问日志中汇总受影响账号，按团队、项目、角色三个维度分组。如果所有团队、所有角色在同一时间段都出现异常，倾向全局性故障，优先检查共享组件，如网关、鉴权服务、主数据库。如果只有特定团队或特定项目受影响，倾向局部故障，优先检查该项目相关的权限配置、数据量异常或特定集成。
这一层需要的数据来源包括：用户反馈记录、登录日志、访问日志中的账号与来源 IP 分布。判断全员还是局部时，注意区分“没人反馈”和“没人受影响”，前者可能只是反馈渠道不畅。
第二层：按功能模块判断受影响的业务对象
把症状映射到功能模块：需求、缺陷、迭代、报表、附件、通知。每个模块背后对应的业务对象不同，例如迭代模块涉及迭代状态与工作项关联，报表模块涉及聚合查询，附件模块涉及对象存储。模块级的错误分布能快速指出哪些业务对象处于风险中，例如“工作项可以查看但无法保存”说明读路径正常、写路径异常。
数据来源主要是应用日志中的接口路径与错误码统计，以及前端埋点或网关访问日志中的页面级成功率。按模块统计错误率，比逐条看报错更高效。
第三层：沿调用链核对组件与依赖
在模块定位之后，沿调用链核对应用服务、数据库、缓存、鉴权服务和第三方集成接口。重点看两类信号：依赖侧的错误率与响应时间是否同步恶化，以及调用链中哪一段耗时占比突然升高。数据库慢查询、缓存命中率骤降、鉴权服务响应变慢、外部集成接口超时，都会在调用链上留下可观测的痕迹。
三层数据必须用同一时间窗口对齐。常见错误是把上午的慢查询日志和下午的用户报错放在一起分析，得出错误关联。建议以故障起点前后各 30 分钟为统一窗口，各层数据都截取该区间。
| 层级 | 回答的问题 | 主要数据来源 |
|---|---|---|
| 用户层 | 全员还是局部，哪些团队和角色受影响 | 反馈记录、登录日志、访问日志 |
| 业务对象层 | 哪些功能模块和业务对象受影响 | 接口错误统计、页面成功率、应用日志 |
| 组件与依赖层 | 哪一段调用链或依赖出现异常 | 调用链追踪、数据库与缓存指标、依赖侧监控 |
范围明确后，排查工作本身也需要被记录和交接。在 ONES 中，可以把故障排查作为一条工作项建立，将症状记录、影响范围结论和处置动作挂在同一条记录下，状态从“排查中”流转到“已恢复”，交接时后来者能直接看到已确认的范围和证据，减少重复询问。
原因假设与排除证据
范围确定后，进入原因判断。这里的关键纪律是：每条原因在取得证据之前只是假设，不能写进结论，也不能据此执行高风险操作。下面四类假设覆盖了多数可用性下降场景，每类都给出支持证据和排除证据。
假设一：资源瓶颈
CPU、内存、连接池、磁盘任一资源饱和都可能导致响应变慢或请求失败。支持证据是监控曲线在故障窗口内触及饱和阈值，且与错误率上升时间吻合；连接池耗尽可能表现为等待获取连接的请求堆积。排除证据是故障期间各项资源指标平稳、无明显尖峰。需要注意，资源指标正常不能单独排除该假设，还要看是否存在短时尖峰被采样间隔漏掉。
假设二：依赖故障
数据库慢查询、缓存击穿、鉴权服务异常、外部集成接口超时，都会以平台功能异常的形式表现出来。支持证据是依赖侧的错误率或响应时间在故障窗口内同步恶化，且调用链显示耗时集中在依赖调用段。排除证据是依赖侧指标平稳、调用链耗时分布正常。缓存击穿的一个典型特征是数据库查询量突增而缓存命中率骤降，两者要一起看。
假设三：变更引入
版本发布、配置修改、权限调整都可能在变更后一段时间才显现影响。支持证据是变更时间线与故障起点接近，且回滚或撤销变更后症状缓解。排除证据是故障起点之前较长时间内没有相关变更，或变更内容与受影响模块无调用关系。时间接近只是线索，不能直接当作因果，需要结合变更内容和影响路径判断。
假设四：流量突增或异常调用
批量导入、脚本轮询、异常重试风暴都可能造成请求量超出日常水平。支持证据是请求量分布显示某类请求在故障窗口内显著高于基线，且来源集中。排除证据是总请求量与来源分布与平日持平。区分正常业务高峰与异常调用，可以看请求来源是否集中在少数账号或固定路径。
| 原因假设 | 支持证据 | 排除证据 |
|---|---|---|
| 资源瓶颈 | 资源曲线触及饱和阈值，时间与错误率上升吻合 | 故障窗口内资源指标平稳，无尖峰 |
| 依赖故障 | 依赖侧错误率或响应时间同步恶化，调用链耗时集中在该段 | 依赖侧指标平稳，调用链耗时分布正常 |
| 变更引入 | 变更时间线接近故障起点，撤销后症状缓解 | 故障前无相关变更，或变更与受影响模块无调用关系 |
| 流量异常 | 某类请求量显著高于基线且来源集中 | 请求量与来源分布与平日持平 |
多条假设可能同时成立，例如流量突增触发资源瓶颈，再引发依赖超时。排查时按证据强度排序，先验证能解释最多症状的那条，避免同时展开所有方向。
按影响范围处置与恢复验证
处置的顺序是先止损、再定位根因。范围已经明确的情况下，止损动作应尽量限定在受影响范围内，避免为了恢复局部功能而影响全局。
常见的止损手段包括：对异常来源限流、回滚最近变更、将流量切换到备用依赖、临时关闭非核心功能以释放资源。选择哪种手段，取决于前面已经取得的证据。例如变更时间线高度吻合且影响面广，回滚通常是首选；依赖侧异常而平台自身正常，切换依赖或降级调用更合适。
有破坏风险的操作必须提前交代三件事：备份、影响告知、停止点。回滚前确认当前版本与数据状态可恢复；数据修复前对涉及的数据做快照；重启服务前告知受影响用户预计中断时长。停止点是指预先设定的判断条件，例如“回滚后 10 分钟内错误率未回落至基线两倍以内，则停止回滚并转入依赖排查”，避免在无效操作上反复尝试。
恢复验证不能只看监控曲线。建议按以下检查项逐条确认：
- 核心功能抽查：登录、工作项查看与保存、迭代看板加载、附件上传各操作一次。
- 关键接口响应时间回到故障前基线水平。
- 错误率回落并稳定保持一段时间，而非短暂下降后再次上升。
- 回访受影响用户，确认其实际操作已恢复正常。
- 通知与集成链路补发或确认无积压。
处置过程中同步记录时间线：每个动作的执行时间、执行人、预期效果和实际效果。这份记录既是恢复确认的依据，也是复盘时的原始材料。
复盘与复发预防
恢复之后，复盘的目标是把本次定位过程中暴露的盲区补上，让下一次同类事件的范围判断更快。复盘应聚焦可执行的改进项，而非泛泛总结。
首先补齐监控盲区。回看本次排查中哪些问题靠人工询问才得到答案，例如“哪些团队受影响”如果只能靠反馈汇总，说明缺少按团队维度的访问与错误统计。把这类缺口转成具体的指标和告警阈值，明确采集方式和触发条件。
其次，把影响范围判断所需的数据纳入日常看板。用户维度、项目维度、功能模块维度的成功率与错误率，应在平时就可见，故障时才能直接对比基线。看板的价值在于提供对照，而非事后补建。
第三，明确下次同类事件的排查入口与责任人。排查入口包括症状记录表的位置、调用链查询的入口、变更记录的查询方式；责任人包括第一响应人和各组件侧的对接人。这些信息写在团队可访问的文档中，避免故障时临时找人。
最后，区分已确认根因与仍待观察项。本次有充分证据支持的结论写入根因；证据不足但存在疑点的，列为观察项并指定后续验证动作，避免把推测写成定论，也避免过度归因到单一原因。改进项建议以清单形式跟踪，每项写明负责人、完成标志和复查时间。
在 ONES 中，复盘产出的改进项可以直接建为工作项，与本次故障记录关联，按负责人和状态跟踪到关闭；排查入口、责任分工和观察项则适合沉淀在团队文档中，与工作项互相引用。这样下一次可用性下降时，团队能从同一条记录出发，看到上次的范围结论、处置动作和仍未关闭的改进项。
常见问题
只有少数用户反馈平台变慢，还需要按全员故障的流程排查吗？
不必直接按全员故障处理，但也不能只凭反馈人数下结论。先确认反馈渠道是否畅通，再对照访问日志和登录日志看同一时间窗口内受影响账号的分布：如果集中在少数团队或项目，按局部故障优先检查该范围的权限配置、数据量异常或特定集成；如果日志显示更大范围的错误率同步上升，只是反馈的人少，仍应按全局故障处理。判断依据是数据分布，反馈数量只作线索。
故障期间监控指标看起来正常，能否直接排除资源瓶颈？
不能单独排除。资源指标正常只说明采样点上没有饱和，短时尖峰可能落在采样间隔之间被漏掉。可以结合错误率上升的时间点，查看更细粒度的曲线或请求排队情况，例如连接池等待数、请求处理耗时分布。如果这些细粒度数据也平稳，再考虑把排查方向转向依赖故障或变更引入。
回滚之后症状缓解，是否就可以把这次故障定性为变更引入？
回滚后缓解是较强的支持证据，但还不足以单独定性。回滚往往同时改变了多个因素，例如重启了服务、清空了缓存、切断了异常流量。建议再核对变更内容与受影响模块之间是否存在调用关系，并确认故障起点之前是否有其他变更或流量变化。证据链完整后再写入根因，其余疑点列为观察项并指定后续验证动作。
止损动作应该做到什么程度，什么时候转入根因定位？
止损的目标是先把影响控制在可接受范围，例如对异常来源限流、回滚最近变更、切换备用依赖或临时关闭非核心功能。建议在动手前设定停止点，例如“回滚后10分钟内错误率未回落至基线两倍以内，则停止回滚并转入依赖排查”。达到停止点或症状稳定后，再带着已取得的证据进入根因定位，避免在无效操作上反复尝试。
复盘时如何避免把推测写成根因？
把结论分成两类记录：有充分证据支持的写入根因，证据不足但存在疑点的列为观察项，并写明后续验证动作和责任人。每条根因尽量对应到具体证据，例如监控曲线、调用链耗时段或变更记录，而不是只写现象描述。改进项以清单跟踪，写明负责人、完成标志和复查时间，下次同类事件可以从同一条记录看到上次的结论和未关闭项。
