测试环境检查发现服务不可用时，先别急着重启。把不可用的服务名称、报错信息、首次发现时间和影响范围记录下来，再按“检查记录→变更记录→依赖关系→资源占用”的顺序逐层缩小范围。每一步都留下原始输出，把猜测变成可验证的结论，最后用复测和回归确认恢复。
要点总览（TL;DR）
- 先固定症状：记录不可用服务名称、报错原文、首次发现时间和影响范围，区分单服务、依赖链和整环境三类情况。
- 用检查记录确定异常首次出现的时间点，再比对同一时间窗口内的变更记录，把配置、版本、部署差异作为高优先级假设。
- 按固定顺序排查依赖关系和资源占用：入口连通性、下游服务、数据库与中间件，再看CPU、内存、磁盘、连接数、线程池是否触顶。
- 每条假设标注已证实、已排除或待验证，保留原始输出作为证据，避免把最先想到的原因当成结论。
- 处置后分三层验证：服务可用性复测、关键用例回归、版本与配置一致性核对，并把有效检查项沉淀为可复用记录。
症状与范围：先确认哪些服务不可用
“服务不可用”是一个笼统的描述，直接进入排查容易在多个方向之间来回跳。第一步是把现象固定成一份可对照的记录：哪个服务、通过什么方式访问、返回什么报错、从什么时间开始、影响了谁。这份记录既是排查基线，也是后续判断“是否恢复”的依据。
记录时至少覆盖以下字段：
- 服务名称与访问入口：接口地址、页面地址、任务入口或消息队列主题，写清楚调用方是谁。
- 报错原文：HTTP 状态码、超时提示、连接拒绝、认证失败等原始信息，保留截图或日志片段，不做转述。
- 首次发现时间与发现方式：是定时检查发现，还是执行某个测试用例时暴露；此前最近一次正常的时间点同样要记。
- 影响范围：哪些测试用例无法执行、哪些角色（测试、开发、产品）受影响、涉及哪个环境实例（联调环境、预发环境、某条特性分支环境）。
范围判断决定后续排查的起点。单个服务不可用，优先看该服务自身与它直接依赖的组件；一条依赖链上的多个服务同时异常，优先看链路上游或共享的数据库、中间件；整个环境的所有服务都不可用，优先看网络入口、DNS、网关、宿主机资源或环境级配置。把这三类情况分开记录，可以避免用排查单服务的思路去处理环境级故障。
检查时的原始输出要原样保留，包括检查脚本的输出、监控告警截图、浏览器网络面板的错误信息。后续验证假设时，这些材料能直接用于对比，减少“当时看到的是什么”这类争议。
原因假设与排除证据：从检查记录到变更记录
拿到症状记录后，先列出可能的原因方向，再为每个方向指定验证证据。常见方向包括：近期变更引入的问题、版本或配置不一致、依赖组件故障、资源触顶、环境本身被误操作。假设可以多列，但每条都要标注状态——已证实、已排除、待验证，避免把最先想到的原因当成结论。
检查记录的作用是确定异常首次出现的时间点。把本次检查项结果与历史检查结果逐项对比：是某一项从正常变为异常，还是多项同时变化；异常是突发的，还是在前几次检查中已经出现渐进迹象。时间点确定后，再去比对同一时间窗口内的变更记录，因果关系的排查范围会明显收窄。
变更记录是优先级最高的证据来源之一。重点比对异常前后的配置项、服务版本、部署包、依赖组件升级、环境变量和数据库脚本。版本不一致和配置偏差建议作为独立假设验证：同一服务在不同实例上的版本号是否一致，配置文件是否被手工改动，依赖服务的接口版本是否匹配。验证方式是对比文件内容、查询版本号、检查配置中心的历史版本，而不是凭印象判断“应该没改过”。
| 原因假设 | 需要的验证证据 | 状态标注 |
|---|---|---|
| 近期配置或部署变更引入异常 | 变更记录时间线与异常首次出现时间是否吻合；变更前后的配置差异 | 待验证／已证实／已排除 |
| 服务版本不一致 | 各实例版本号、构建产物哈希、发布记录 | 待验证／已证实／已排除 |
| 配置偏差 | 配置文件与配置中心基线对比、环境变量差异 | 待验证／已证实／已排除 |
| 依赖组件故障 | 数据库、缓存、消息队列的连接状态与错误日志 | 待验证／已证实／已排除 |
| 资源触顶 | CPU、内存、磁盘、连接数、线程池的时序数据 | 待验证／已证实／已排除 |
表格中的状态要随排查推进实时更新。已经排除的方向写明排除依据，例如“变更记录显示该时间段无发布，排除部署变更”；尚未排除的方向写明下一步验证动作。这样即使排查中途交接给其他人，也能接着往下做。
按依赖关系与资源占用逐层排查
假设清单确定后，进入具体排查。依赖关系和资源占用是两个主要方向，建议固定一个顺序执行，例如先沿依赖链从入口服务向下游查，再回到各节点看资源占用；或者先确认资源层面无异常，再深入依赖链。顺序本身不重要，重要的是每次按同一顺序走，并把每步结果记下来，避免遗漏和重复。
依赖关系排查从调用入口开始：确认请求是否到达网关或负载均衡，端口是否可连通，DNS 解析是否正常，证书是否过期。再逐层向下游检查：被调用的服务是否存活，数据库连接是否可用，缓存和消息队列是否正常响应，第三方接口是否超时。每一步记录使用的命令或检查项、返回结果和判断，例如连通性测试的结果、连接池的活跃连接数、下游服务的健康检查响应。
资源占用排查关注是否触顶：CPU 使用率是否持续高位，内存是否接近上限并伴随频繁回收，磁盘空间是否不足，数据库连接数和应用线程池是否耗尽，文件句柄是否达到限制。判断时要区分瞬时峰值和持续高位，结合异常发生时间点看资源曲线，确认资源问题与不可用现象在时间上是否对应。
涉及重启、清理、回滚等有破坏风险的操作时，先确认三件事再执行：备份是否可用且经过验证，停止点在哪里（做到哪一步如果仍无改善就停止并回退），回退方案是否明确。例如回滚版本前，确认上一版本制品可获取、数据库变更是否兼容回滚；清理磁盘前，确认清理对象不包含正在使用的日志或数据文件。破坏性操作执行后立即记录操作时间和结果，便于与后续现象对应。
处置与恢复验证：确认根因并防止复发
定位到根因后，处置动作按“先恢复可用、再消除根因、最后补防复发”的顺序执行。如果根因是配置偏差，修正配置并确认生效范围；如果是版本不一致，统一版本并核对构建产物；如果是资源触顶，先缓解占用再评估容量；如果是依赖组件故障，恢复组件后确认上下游连接重建。每项处置写明执行人、执行时间和预期结果，执行后立即进入验证。
恢复验证分三层：第一层是服务可用性复测，用与发现问题时相同的访问方式确认接口或页面恢复正常；第二层是关键用例回归，覆盖受影响测试用例中优先级最高的部分，确认业务功能可用；第三层是版本与配置一致性核对，确认所有实例的版本号和配置与基线一致，避免只恢复了部分节点。三层验证的结果都要记录，作为关闭本次问题的依据。
复发预防的重点是把本次排查中有效的检查项沉淀下来：把症状记录、假设清单、逐层排查结果和处置动作整理成一份可复用的检查记录，标注哪些检查项在本次起了关键作用；把异常时间点与变更记录的关联方式固定为检查步骤；把本次涉及的依赖清单补充到环境说明中。同时明确尚未完全排除的风险和后续观察点，例如某项资源仍处于高位、某个依赖组件的稳定性待观察，指定观察周期和责任人。
在团队协作层面，这类排查记录和结论需要有稳定的承载位置，便于测试、开发和环境负责人共同查看和更新。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转。排查中确认的服务异常可以转为缺陷任务跟进，检查记录和处置结论可以随任务和测试报告留存，自动生成的测试报告与项目缺陷分布统计也有助于后续复盘同类问题。是否将环境检查记录纳入平台管理，取决于团队现有的工具分工，可以在缺陷流转和测试报告环节先行衔接。
常见问题
检查时服务还能访问，过一会儿又不可用，这种情况怎么排查？
这类间歇性不可用，重点看时间维度的证据。把每次不可用的发生时间、持续时长和恢复方式记录下来，与资源曲线、依赖组件的健康检查记录、变更发布时间对齐。常见方向是资源在峰值时段触顶、连接池被慢请求占满、依赖组件间歇超时或主备切换。排查时不要只看故障瞬间的快照，要拉取故障前后一段时间的时序数据，确认资源占用和错误率的变化趋势是否与不可用时间吻合。
怀疑是配置偏差，但没人记得改过什么，怎么确认？
以文件和环境变量的实际内容为准，不依赖记忆。把当前实例的配置文件、环境变量、启动参数与配置中心或版本库中的基线逐项对比，查配置中心的历史版本记录和发布时间。同时核对同一服务不同实例之间是否一致，不一致本身就是线索。如果配置确实与基线一致，就把这个方向标注为已排除并写明比对依据，把精力转到依赖和资源方向。
排查中需要重启服务或回滚版本，执行前要确认什么？
执行破坏性操作前确认三件事：备份可用且经过验证，停止点明确，回退方案清晰。回滚前确认上一版本制品可获取，数据库变更是否兼容回滚；重启前确认重启不会丢失正在处理的测试数据，并记录重启时间和预期恢复时间。操作执行后立即记录结果，与后续现象对应。如果做到停止点仍无改善，按预定方案回退，避免在故障状态下继续叠加操作。
恢复后怎么判断问题真的解决了，而不是暂时缓解？
分三层验证：用与发现问题时相同的访问方式复测服务可用性；回归受影响测试用例中优先级最高的部分；核对所有实例的版本号和配置与基线一致。三层都通过再关闭问题。如果根因是资源触顶，还要观察一段时间内的资源曲线，确认缓解措施能覆盖峰值时段。尚未完全排除的风险写明观察周期和责任人，例如某项资源仍处高位、某个依赖组件稳定性待观察。
排查记录放在哪里，才能让测试、开发和环境负责人一起用？
关键是让记录跟着问题走，而不是散落在个人笔记里。可以把确认的服务异常转为缺陷任务跟进，检查记录和处置结论随任务留存，测试报告汇总执行结果。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，也支持自动生成测试报告和项目缺陷分布统计，便于后续复盘同类问题。是否把环境检查记录整体纳入平台，取决于团队现有工具分工，可以先从缺陷流转和测试报告环节衔接。
