第九次课：阶段考核——故障定位与恢复

约 2367 字大约 8 分钟

阶段考核故障定位证据链Docker Compose

2026-07-30

进入本课环境

[Windows PowerShell] wsl ~：打开本机默认的 WSL2 Ubuntu；出现 用户名@主机名:~$ 后再执行标为 [WSL] 的命令。
[WSL] ssh root@你的ECS公网IP：从 WSL 连接自己的 ECS；如果登录用户不是 root，请换成控制台显示的实际用户，看到远端提示符后再执行标为 [ECS] 的命令。

前八次课已经练过 SSH、Linux 巡检、Nginx、备份恢复、Compose、数据库和负载均衡。本次课不再增加一套新工具，而是考查能否把已有方法连成一次完整的运维处理：

确认范围 -> 建立基线 -> 复现现象 -> 收集证据
        -> 提出假设 -> 最小修复 -> 回归验证 -> 清理与报告

考核环境是一套独立的 Web—API Compose 项目，项目名为 cloud-course-exam-09，入口只绑定 127.0.0.1:18009。每组会得到一种可恢复故障，不得通过询问他组答案或重建全部环境绕过定位过程。

安全边界

考核只允许操作 cloud-course-exam-09。不得停止服务器所有容器、删除未知卷、修改防火墙与安全组、开放公网端口或重置共享服务器。无法确认对象时，先停止变更并保留证据。

9.1 考核要交付什么

页面最后能打开，只说明结果恢复了；本次阶段考核还要交付 5 组可以复核的链条证据：

环境基线记录：核对登录账号、当前主机、剩余资源、项目命名、容器服务与端口映射；
原始现场证据：未经任何人工修复干预的 HTTP 状态码、容器运行态与原始错误日志；
推演判断过程：清晰说明每一条命令行证据支持或排除了哪种故障假设；
最小修复动作：仅对存在故障的对象进行精准修补，并给出明确的操作依据；
回归与撤场结果：自动化校验输出、完整用户路径访问测试、项目最终运行态与资源清理记录。

评分的核心关注点在于“推演证据链是否能够自洽地支持故障结论”。如果纯靠运气随机重置服务凑巧恢复，却无法清晰解释根本原因，将无法获得完整的分数。

9.2 独立排障规则

拿到案例后，先保存基线，再接收故障现象。故障出现后不要立即重建项目，也不要翻看答案库。可以查阅前几课的命令卡，但报告中的每个判断都要指向自己取得的状态、端口、HTTP 或日志证据。

修复动作必须限制在 cloud-course-exam-09 内。若一条命令会影响其他容器、端口、网络或目录，先停下来重新确认范围。

9.3 先建立未故障的基线

进入 ECS 上的考核工程目录，先做静态审查：

[ECS] cd ~/cloud-course/exam-09
[ECS] docker compose config --services

预期输出 api 和 web 两个服务。理解它们各自的职责分工，不要机械抄写名字。

[ECS] docker compose config --quiet

静默无报错代表 Compose 语法合规；这仅代表文件可读，服务还没跑通。

启动基准测试环境：

[ECS] docker compose up -d
[ECS] docker compose ps

在正常基线状态下，两项服务都应处于 healthy 状态，且仅有 web 服务将端口绑定在 127.0.0.1:18009。

校验完整的用户请求路径：

[ECS] curl -sS http://127.0.0.1:18009/api/status.json

若终端正确返回包含 exam-api 与 status=ok 的 JSON 响应，将该输出留存作为故障前的基线对照。基线的作用在于为你确立“系统在无故障时应当展现的标准形态”。

阶段考核环境基线的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

保存用户现象

对 /api/status.json 发送一次限时请求，记录 HTTP 状态与耗时。

观察点

修复前的原始现象无法事后补拍。
每条命令都应减少一个不确定性。
回归必须使用最初失败的用户路径。

9.4 故障出现后先冻结现场

故障注入完成后，不要立即执行 docker compose up -d、docker restart 或重建容器。先按流程保存未经修改的原始现场。

首先检查容器整体运行态：

[ECS] docker compose ps -a

带有 -a 参数能把已经异常退出的容器一并列出。记录容器名、退出码与端口映射。某个容器仍处于 Up 状态，只能说明它没有退出，业务功能是否完整还要沿用户路径验证。

紧接着，发起与用户真实访问路径一致的请求测试：

[ECS] curl --max-time 8 -sS -o /dev/null -w \
  'http=%{http_code} time=%{time_total}\n' \
  http://127.0.0.1:18009/api/status.json

HTTP 状态与耗时能区分立即拒绝、网关错误和等待超时。不要连续刷新覆盖最早现象。

最后，查看最近日志：

[ECS] docker compose logs --since 2m --tail 30 web api

只截取与本次请求接近的行。日志中的内部地址需要脱敏，无关历史日志不进入报告。

匿名化故障现象与原始证据的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

9.5 用“现象—证据—假设”缩小范围

把每条证据写进表格：

证据	已经证明	还不能证明
`compose ps -a`	各容器当前生命周期状态	完整 HTTP 是否成功
HTTP 状态与耗时	用户路径的实际结果	具体是哪项配置或进程导致
Web 日志	请求是否进入网关、上游发生了什么	上游内部业务一定正确
API 日志	API 是否启动、是否处理请求	浏览器到 Web 的外部路径正常

当前假设必须能被下一条检查证伪。例如：

假设：故障位于 Web 到 API 的内部链路。
依据：Web 入口仍能接收请求，但 /api 返回网关错误。
下一条检查：查看 API 容器状态和 Web 的上游错误。
若结果不支持：转向 Web 配置或内部名称解析。

不能写“Docker 坏了”“网络不行”这类无法验证的宽泛结论。

9.6 修复前写出变更说明

在报告中先填写：

目标对象：
准备执行的命令：
这条命令会改变什么：
为什么它比重建全部环境更小：
失败时如何停止或恢复：

确认对象属于 cloud-course-exam-09 后，才执行选定修复。考核允许使用已经学过的项目级生命周期命令和配置检查；不允许用删除整个项目、删除卷或重装系统代替定位。

修复后不要立刻宣布完成。按原路径重新检查：

[ECS] docker compose ps

确认需要运行的服务状态。

[ECS] curl -sS http://127.0.0.1:18009/api/status.json

必须重新取得 status=ok。

[ECS] docker compose logs --since 1m --tail 20 web api

确认修复后的请求产生了新的成功记录，并说明旧错误为何仍可能保留在历史日志中。

修复后的同路回归与自动验收的原始整页终端截图 — 数据来源：host-B，捕获于 2026-07-28。页面只负责选择和排版，命令与输出保存在独立数据文件中。

观察点

助教是否避免直接泄露修复答案？
是否区分状态、HTTP 与日志的证明范围？
是否要求假设可以被下一条检查否定？

不知道问什么时，可以先选一句：

正在加载对话组件…

本实验的原始聊天仅保存在当前标签页，不会写入全局课程助教上下文。

9.7 自动验收与人工验收

运行：

[ECS] bash verify.sh

自动验收检查：

项目文件是否齐全；
Compose 配置能否解析；
API 与 Web 是否运行；
18009 是否只绑定回环地址；
完整请求是否返回 status=ok。

人工验收继续核对：

原始故障是否在修复前保存；
假设是否引用证据；
修复是否限定项目与对象；
修复后是否重新发送真实请求；
报告是否脱敏；
清理后是否无课程残留。

自动脚本验收通过，也不能弥补缺失的原始故障证据。

磁盘、CPU 过高故障排查建议观看：6:48

在 Bilibili 打开

观看时留意：案例怎样从一个宽泛现象逐步找到能缩小范围的指标和进程证据？

与本课的关系：完成本课考核和验收后再展开，对照自己的现象、证据、假设和回归记录。

接口 502 的排障过程建议观看：1:43

在 Bilibili 打开

观看时留意：看到 502 后，案例先检查了什么，为什么没有直接重启 Nginx？

与本课的关系：短视频只提供一个排障样例。完成考核后，再判断它与本课故障是否属于同一层。

9.8 清理和提交

完整考核环境、故障注入范围和截图清单见实训 09：阶段故障诊断考核。

确认报告截图齐全后：

[ECS] docker compose down

确认项目不再运行：

[ECS] docker compose ps -a

空列表表示本课容器已清理。

确认端口释放：

[ECS] ss -lnt 'sport = :18009'

无输出表示考核入口端口已释放。

提交文件：

班级_学号_姓名_第09次课_阶段故障考核报告.docx

只上传一个 Word 到智慧职教“第09次课”。截图中不出现公网地址、账号、SSH 配置、内部地址、其他项目名或无关日志。

9.9 第九次课小测

9.10 小结

基线让故障前后可以比较，不是可有可无的截图。
原始现象应在任何修复前保存。
状态、HTTP 和日志分别描述组件、用户路径和内部处理。
假设要能被下一条证据支持或否定。
修复应限定到已确认的项目与对象。
回归必须沿原请求路径执行，最后还要验收、清理和提交。

下一次课进入 OpenStack 架构，用服务职责和实例创建流程理解私有云控制面。

9.11 资料来源

以下资料在 2026-07-28 核对：

课程 AI 助教

现在，试着让助教陪你复盘

助教会读取当前课程页面和结构化学习记录，但不会读取正文实验框里的原始聊天。