---
url: >-
  /courses/cloud-platform-build-management/09-stage-assessment-troubleshooting/index.md
---
# 第九次课：阶段考核——故障定位与恢复

## 进入本课环境

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

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

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

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

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

## 9.1 考核要交付什么

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

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

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

## 9.2 独立排障规则

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

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

## 9.3 先建立未故障的基线

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

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

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

```bash
[ECS] docker compose config --quiet
```

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

启动基准测试环境：

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

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

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

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

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

{{guided-demo:lesson-09-evidence-loop}}

## 9.4 故障出现后先冻结现场

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

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

```bash
[ECS] docker compose ps -a
```

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

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

```bash
[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 状态与耗时能区分立即拒绝、网关错误和等待超时。不要连续刷新覆盖最早现象。

最后，查看最近日志：

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

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

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

把每条证据写进表格：

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

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

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

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

## 9.6 修复前写出变更说明

在报告中先填写：

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

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

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

```bash
[ECS] docker compose ps
```

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

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

必须重新取得 `status=ok`。

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

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

{{chat-lab:lesson-09-assessment-evidence}}

## 9.7 自动验收与人工验收

运行：

```bash
[ECS] bash verify.sh
```

自动验收检查：

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

人工验收继续核对：

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

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

## 9.8 清理和提交

完整考核环境、故障注入范围和截图清单见[实训 09：阶段故障诊断考核](./lab-09.md)。

确认报告截图齐全后：

```bash
[ECS] docker compose down
```

确认项目不再运行：

```bash
[ECS] docker compose ps -a
```

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

确认端口释放：

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

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

提交文件：

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

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

{{reflection-checkpoint:lesson-09-assessment-ready}}

## 9.9 第九次课小测

{{assessment:lesson-09-check}}

## 9.10 小结

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

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

## 9.11 资料来源

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

* [Docker Compose CLI](https://docs.docker.com/reference/cli/docker/compose/)
* [Docker Compose `stop`](https://docs.docker.com/reference/cli/docker/compose/stop/)
* [Docker Compose `start`](https://docs.docker.com/reference/cli/docker/compose/start/)
* [NGINX `ngx_http_proxy_module`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html)

{{assistant-invite:lesson-09-finish}}