| | |
|---|
| | | 测试库是哪两个库、什么版本**、3 项已知基线失败，以及一类会随测试库累积而出现的环境相关失败；不要为 |
|---|
| | | 证明它们是"既有的"而重复造 worktree）。 |
|---|
| | | |
|---|
| | | ### 攀枝花政务云服务器：操作纪律（务必遵守） |
|---|
| | | |
|---|
| | | 这台机器**没有公网自服务控制台**——console/VNC 只在「云管理方」手里，进去只有一条路：堡垒机 |
|---|
| | | （`172.18.105.9`）。**一旦把这条路弄断，你和用户谁都进不去，只能求服务商。** 2026-09-21 已经发生过 |
|---|
| | | 一次（docker 网桥占用 `172.18.0.0/16`，与堡垒机网段冲突，回程路由被劫走）。以下每条都是那次事故立的： |
|---|
| | | |
|---|
| | | - **只在用户明确授权后动手。** 用户说"先别干活"、或语义模糊（例如只说"我们继续吧"）时，**只给方案和 |
|---|
| | | 命令，不执行**。事故当天就是凭一句模糊的"继续吧"动了手。 |
|---|
| | | - **改网络/路由/防火墙/端口/SSH 之前，先确认带外通道可用。** 没有 console/VNC 兜底，这类改动一律不做。 |
|---|
| | | - **改之前先枚举已知网段**，不要只看"自己那一段"： |
|---|
| | | |
|---|
| | | | 网段 | 是谁 | |
|---|
| | | |---|---| |
|---|
| | | | `172.192.19.0/24` | 服务器自己，网关 `172.192.19.254` | |
|---|
| | | | **`172.18.0.0/16`** | **堡垒机所在网段**（堡垒机连服务器的来源是 `172.18.140.254`） | |
|---|
| | | | `192.169.1.10` | 办公侧（VPN 客户端来源） | |
|---|
| | | | `192.168.110.0/24` | 办公室开发库 `192.168.110.13` | |
|---|
| | | |
|---|
| | | - **不要在这台机器上引入 docker（2026-09-21 已卸载，别再装回去）。** 两个原因：一是它的网桥默认 |
|---|
| | | 地址池会依次分到 `172.17`、`172.18`、`172.19`…，正好撞上堡垒机网段 `172.18.0.0/16`，回程路由被劫走 |
|---|
| | | 就直接失联；二是这台机器的虚拟 CPU 缺 SSE4.2/POPCNT，以 x86-64-v2 为基线的镜像根本跑不起来（见下）。 |
|---|
| | | **MySQL/Redis 一律原生装。** 万一将来确实要重新引入，**必须在建任何网络之前先钉死地址池**： |
|---|
| | | `"default-address-pools": [ { "base": "10.201.0.0/16", "size": 24 } ]`（同时把 `data-root` 指向 |
|---|
| | | `/data`——40G 系统盘装不下镜像）。 |
|---|
| | | - **一次只改一件事，每步之后先复检堡垒机通道还在**，再走下一步。 |
|---|
| | | - **高危改动挂自动回滚**：`systemd-run --on-active=5min /bin/bash -c '<撤销命令>'`，确认通道正常后再 |
|---|
| | | 取消它。最坏情况 5 分钟后自己恢复，不必求人。 |
|---|
| | | - **给服务商的命令要一次说准、可直接复制、并写出期望输出。** 消息要经**两跳**（对接人 → 云管理方）， |
|---|
| | | 每次返工就是几十分钟。事故当天给的 `docker compose down` 缺了 `-f`（本仓的 compose 叫 |
|---|
| | | `docker-compose.prod.yml`，不是 compose 的默认文件名），白费一跳。 |
|---|
| | | - **不要把凭据写进聊天。** 必须提供给执行人时，事后立刻轮换。 |
|---|
| | | |
|---|
| | | **这台机器的硬约束（改环境前先看）：** |
|---|
| | | |
|---|
| | | - **虚拟 CPU 缺 SSE4.2/POPCNT/AVX**（KVM 上是老的 QEMU 型号，物理 CPU 其实够用）→ **任何以 |
|---|
| | | x86-64-v2 为基线的镜像都跑不起来**：官方 `mysql:8.4` 会 `Fatal glibc error: CPU does not support |
|---|
| | | x86-64-v2` 循环退出（exit 127）。Redis 官方镜像正常，Ubuntu 自己的包都正常。要跑这类镜像，得请服务商 |
|---|
| | | 把虚拟机的 CPU 型号改成 `host-passthrough`。 |
|---|
| | | - **出网**已开通，是**任意公网地址**（不是域名白名单）。但 **Docker Hub 直连不通**（`registry-1.docker.io` |
|---|
| | | 连接被重置），拉镜像走 `public.ecr.aws/docker/library/<name>`。 |
|---|
| | | - **入向**只有 `8081`/`8082` 开放（公网地址 `117.172.73.106`）；`80`/`443`/`8080` 要备案号才能开。 |
|---|
| | | - **办公网到 `172.192.19.0/24` 没有路由**，所以只能走堡垒机，不能直连。 |
|---|
| | | |
|---|
| | | ### Git 提交 |
|---|
| | | |
|---|
| | | 提交信息一律用中文，沿用仓库既有风格：`type(scope): 中文摘要`，type 保留英文 |
|---|
