研发平台出现打不开、变慢或部分功能报错时，先别急着重启服务。更稳妥的做法是固定症状与统一时间窗，再沿入口、服务依赖、数据配置、变更与外部依赖四条线索逐层收窄，最后把受影响的用户群、功能模块、项目与工作项范围圈定出来。范围清楚后，处置和恢复验证才有依据。在项目与工作项层面核对影响边界时，可借助 ONES 查看相关记录与状态。
要点总览（TL;DR）
- 先固定症状与统一时间窗：记录页面加载、请求超时、登录失败、功能报错、写入延迟等具体表现，区分全量不可用与局部降级，并统一入口、账号类型和观测口径。
- 按入口与网络、服务与依赖、数据与配置、变更与外部依赖四条线索逐层排查，每条原因假设都配上验证方式和排除证据，避免把猜测当结论。
- 影响范围从用户、功能、业务对象、时间四个维度交叉圈定：提取受影响账号清单，区分读写功能状态，核对项目与工作项记录，确认持续时长与数据完整性。
- 处置时先恢复入口可用，再处理局部降级；涉及数据修复、配置回滚、服务重启时先备份、先小范围验证，并预设影响面扩大、数据一致性无法确认、回滚失败等停止点。
- 恢复后在同一时间窗与同一入口复测，核对影响期间数据无丢失、无重复、无错乱，再复盘范围判断偏差，补充监控项与告警阈值。
先确认症状：可用性下降的具体表现与时间窗
“平台变慢了”无法直接用于排查。第一步是把用户描述转成可核对的现象清单，并固定一个统一时间窗，后续所有日志、监控和反馈都放进这个窗口里比对。时间窗建议从首次异常出现前10到15分钟开始，覆盖到当前时刻，便于把变更动作和异常表现对齐。
常见症状可以按表现归类记录：
- 页面无法加载或长时间白屏，通常指向入口、网关或前端资源问题；
- 请求超时、接口返回5xx，通常指向应用服务或下游依赖；
- 登录失败或反复跳转登录页，可能涉及认证服务、会话存储或证书；
- 部分功能报错而其他功能正常，属于局部降级，范围更窄；
- 数据写入延迟、保存后不显示，涉及数据库、消息队列或缓存一致性。
记录时要区分全量不可用与局部降级。判断方法很直接：换一个账号、换一种登录方式、换一个客户端或网络环境复测。如果多个团队、多种入口同时异常，倾向群体现象；如果只有个别账号或特定客户端异常，先按个体问题排查，避免把局部故障误判为平台级事故。
观测口径要统一：同一时间窗、同一入口地址、同一类账号。不同入口（内网、外网、移动端）背后的链路不同，混在一起比较会干扰判断。建议形成一张症状记录表，字段包括现象描述、首次出现时间、复现入口、报错文案与截图、影响人数初步估计、复测结果。这张表是后续所有排查的共同基准。
沿四条线索收窄：原因假设与排除证据
原因排查容易犯的错误是先有猜测再找证据。更有效的做法是把每条假设和验证方式成对写下，验证后标注“已排除”或“待验证”，让结论建立在证据上。下面四条线索按从外到内的顺序推进，前一层排除后再进入下一层。
| 线索层 | 典型原因假设 | 验证方式 | 假设成立的表现 | 可排除的证据 |
|---|---|---|---|---|
| 入口与网络 | DNS解析异常、网关或负载均衡故障、证书过期、区域网络中断 | 从不同网络访问同一入口；检查证书有效期；查看网关与负载均衡状态 | 多区域同时无法访问，或证书已过期 | 部分区域访问正常，证书在有效期内 |
| 服务与依赖 | 应用实例异常、数据库连接耗尽、缓存或消息队列故障、第三方接口超时 | 查看实例健康状态与错误日志；检查数据库连接数与慢查询；确认第三方接口响应 | 错误集中在某一服务或某一依赖调用 | 该服务健康检查正常，依赖响应在正常范围 |
| 数据与配置 | 存储容量不足、连接数打满、权限配置变更、字典或字段配置错误 | 核对存储余量；比对配置变更记录；用管理员账号复现 | 特定操作稳定报错，且与某次配置调整时间吻合 | 配置无变更，容量与连接数均在阈值内 |
| 变更与外部依赖 | 近期发布、配置修改、账号权限调整、外部服务故障 | 拉取时间窗内的变更记录，与异常起始时间对齐 | 异常起始时间紧跟某次发布或配置修改 | 时间窗内无相关变更，外部服务状态正常 |
排查顺序上，先看入口层，因为它决定用户能否到达系统，验证成本低、结论快。入口正常后进入服务与依赖层，重点看错误日志的集中位置：如果错误集中在某个服务，继续查它的下游依赖；如果错误分散在多个服务，优先怀疑共享的数据库、缓存或网络。数据与配置层适合处理“特定操作必现”的问题，变更层则用于解释“突然发生”的异常。
每条线索都要留下排除证据，而不只是记录“看起来没问题”。例如排除证书问题时，记录证书到期时间；排除数据库问题时，记录连接数峰值与阈值。这些证据在复盘时能说明范围判断为什么成立，也能帮助发现监控盲区。
定位影响范围：从用户到工作项的逐层圈定
影响范围不能停留在“平台整体不可用”这种粗粒度描述。更实用的做法是沿四个维度逐层圈定：哪些用户受影响、哪些功能可用、哪些业务对象受影响、持续了多长时间。四个维度交叉后形成影响范围矩阵，每个格子标注“已确认”或“待核实”。
按用户维度圈定
从访问日志和错误日志中提取受影响账号清单，标注所属团队、登录方式（账号密码、企业目录对接、单点登录）和客户端类型（浏览器、移动端）。如果异常集中在某一登录方式，问题可能在认证链路；如果集中在某一团队或某一区域，问题可能与该团队常用的入口或网络有关。用户反馈是重要补充，但要与日志交叉印证，避免只凭个别反馈扩大范围。
按功能维度区分读写
逐项确认核心模块的状态：哪些完全可用、哪些降级、哪些不可用。特别要区分读操作与写操作。只读页面能打开不代表写入正常，写入延迟往往在保存后才暴露。把功能状态列成清单，例如需求查看正常、需求创建超时、附件上传失败，比笼统说“部分功能异常”更有处置价值。
按业务对象维度核对
研发平台的业务对象通常包括项目、需求、任务、缺陷、文档与评审记录。要确认影响落在哪些项目、哪些工作项、哪些文档上。在 ONES 中，可以按项目和工作项查看相关记录的状态与变更情况，结合时间窗核对哪些条目在异常期间被创建、修改或流转，从而把影响边界落到具体条目，而不是停留在模块名称。这一步的产物是受影响对象清单，供后续数据完整性核对使用。
按时间维度确认持续时长与数据完整性
记录影响开始时间、恢复时间点和持续时长。同时标记异常期间产生的数据是否完整：是否存在写入丢失、重复提交、状态错乱。时间维度与业务对象维度结合，可以回答“哪些条目在哪个时间段受到影响”，这是后续修复和对外说明的基础。
最后用监控指标、访问日志、错误日志和用户反馈四类信息交叉印证范围边界。四类信息指向一致时，范围判断可以确认；出现矛盾时，把矛盾点标为待核实，继续用同一时间窗复测，不要用单一来源下结论。
处置与恢复：按影响范围安排动作与停止点
范围明确后，处置顺序应服从影响范围：先恢复入口可用，让用户能进入系统，再处理局部功能降级。如果入口本身正常，只是某模块异常，就不要做全平台重启，避免扩大影响面。
涉及有破坏风险的操作时，前置条件和停止点要提前写清楚：
- 数据修复前先备份受影响数据，并在小范围样本上验证修复脚本，确认结果符合预期后再扩大；
- 配置回滚前记录当前配置快照，回滚后立即用同一入口复测关键功能；
- 服务重启前确认实例数量与流量切换方式，避免重启期间全部实例同时不可用；
- 每步操作设定停止点：影响面扩大、数据一致性无法确认、回滚失败时立即暂停并升级处理，不在状态不明时继续操作。
处置期间要同步受影响团队，说明当前哪些功能可用、哪些暂不可用、有无临时替代方式，例如通过其他入口提交、暂缓批量写入操作。同步信息与影响范围矩阵保持一致，范围更新时同步更新说明，减少重复询问。
验证恢复与防止复发
症状消失不等于恢复彻底。恢复后要在同一时间窗口径下、用同一入口和同类账号复测此前的异常场景，确认报错消失、响应时间回到正常范围。复测结果要记录，作为恢复完成的依据。
接着核对影响期间的数据完整性：对照受影响对象清单，确认异常期间创建、修改、流转的记录无丢失、无重复、无状态错乱。发现不一致的条目，按处置阶段约定的方式修复，并再次核对。
复盘时重点看两件事：原因判断是否准确，范围判断是否有偏差。如果实际影响范围比最初估计的大或小，说明监控覆盖或日志口径存在缺口，据此补充监控项、调整告警阈值、完善变更审批要求。把本次的排查路径整理成检查清单，包括症状记录表、四条线索的验证项、影响范围矩阵模板和处置停止点，下次遇到类似情况可以直接复用，缩短定位时间。
常见问题
只有个别用户反馈平台变慢，需要按平台级故障排查吗？
先不要直接按平台级故障处理。建议用同一入口、同类账号和不同网络环境复测：如果只有个别账号或特定客户端异常，优先按个体问题排查，例如本地网络、浏览器缓存、账号权限或客户端版本；如果多个团队、多种入口同时出现异常，再升级为群体现象排查。个别反馈可以作为线索，但需要与访问日志、错误日志交叉印证后再扩大范围。
影响范围矩阵里“待核实”的格子应该怎么处理？
“待核实”表示当前证据不足以确认该格子是否受影响。处理方式是回到同一时间窗，用另一类信息源复测：例如监控指标显示正常但用户反馈异常时，查访问日志和错误日志；日志正常但业务方反馈数据不对时，核对具体工作项的变更记录。复测后仍矛盾，就保留“待核实”并记录矛盾点，在处置和对外说明中按保守口径处理，不要用单一来源强行下结论。
处置阶段什么情况下应该暂停操作并升级？
建议提前设定三类停止点：一是操作后影响面反而扩大，例如重启后更多用户无法访问；二是数据一致性无法确认，例如修复脚本执行后无法核对哪些记录被改动；三是回滚失败或回滚后关键功能仍未恢复。出现任一情况时暂停后续操作，保留现场日志与配置快照，升级给平台负责人或原厂支持处理，避免在状态不明时继续操作扩大影响。
恢复后怎么确认影响期间的数据没有丢失或重复？
以影响范围矩阵中的业务对象清单为基准，逐项核对异常期间被创建、修改或流转的记录：检查记录数量是否与操作日志一致，状态流转是否完整，是否存在同一操作重复提交产生的重复条目。对写入延迟期间提交的内容，重点确认最终是否落库、有无部分成功。发现不一致的条目，按处置阶段约定的修复方式处理，并再次核对，直到清单内所有条目状态明确。
排查结束后，检查清单应该包含哪些可复用内容？
建议包含四部分：症状记录表模板，覆盖现象、首次出现时间、复现入口、报错信息与影响人数估计；四条线索的验证项与排除证据记录方式；影响范围矩阵模板，按用户群、功能模块、业务对象、时间段四个维度组织；处置停止点清单，写明每类操作的前置条件与暂停升级条件。清单按本次实际排查路径整理，下次遇到类似异常可以直接对照执行，减少重复摸索。
