Oracle云重启虚拟机：3个被忽略的坑让工程师栽了跟头

生产环境执行sudo reboot时，SSH会话冻结的那3秒，足够让资深工程师手心冒汗。Oracle云上一台跑了47天的虚拟机，上周就因为漏看一行apt升级日志，重启后容器集体失联——这种事本可以避免。

这篇指南把"应该没事"变成"确实没事"。从读懂升级输出的隐藏信号，到用真实命令测量恢复时间，所有步骤都带实际输出，拒绝复制粘贴式操作。

重启前的2分钟清单：别让你的容器睡过去

先跑docker ps，确认没有容器正在"半梦半醒"。

如果看到某个迁移容器的状态是Up 2 minutes，而平时它30秒就跑完——这说明它可能卡住了。此时重启等于直接拔电源，数据库表锁死、任务队列丢消息都是大概率事件。

接下来这行命令很多人跳过，但它是最后一道保险：

docker compose config

它的作用是把所有环境变量解析后的完整配置打印出来。上周有个团队把.env里的数据库密码从单引号改成了双引号，YAML解析直接报错——重启后所有容器原地打转，花了40分钟才定位。

关键检查点：你的restart策略设对了吗？

Docker Compose里常见的配置陷阱：后台服务写了restart: always，但一次性迁移任务也照搬。结果是迁移跑完正常退出，Docker以为它崩溃了，无限重启，日志里全是Restarting (1) 5 seconds ago的循环。

正确的分法：

- 长期服务（后端API、消息队列）：restart: always ✅

- 一次性任务（数据库迁移、数据初始化）：不写或写restart: "no" ✅

读懂apt升级的"天气预报"

执行sudo apt update && sudo apt upgrade -y时，输出里藏着系统变更的完整清单。不要按回车跳过。

典型输出长这样：

The following packages will be upgraded: containerd.io coreutils docker-ce docker-ce-cli docker-ce-rootless-extra

这里有个细节：如果docker-ce在升级列表里，意味着容器运行时本身会被更新。某些版本迭代会要求重启daemon，而daemon重启会短暂中断所有容器——这在生产环境是计划外停机。

Oracle云的Ubuntu镜像有个特性：内核更新不会自动提示重启，但/var/run/reboot-required文件会出现。检查这个文件的存在比猜"要不要重启"靠谱得多。

升级后的验证命令：

docker version --format '{{.Server.Version}}'

确认服务端版本与客户端一致。曾有人遇到过客户端升级到24.x、服务端卡在23.x的诡异状态，容器网络模式表现异常，排查了两个小时才发现是版本错位。

重启后的恢复时间：从"感觉很快"到"确实知道多少秒"

容器启动顺序是隐形杀手。假设你的架构是：Nginx → 后端API → 数据库。如果Nginx比后端先启动，它会立即开始健康检查，连不上后端就标记为unhealthy，触发负载均衡摘除——哪怕后端5秒后就能就绪。

用这条命令抓真实启动耗时：

docker events --filter event=start --since 1m --format '{{.Time}} {{.Actor.Attributes.name}}'

输出示例：

2024-01-15T09:23:17.342Z db 2024-01-15T09:23:21.891Z backend 2024-01-15T09:23:22.105Z nginx

4.5秒的间隔暴露了一个问题：后端依赖数据库就绪，但没有等数据库完全初始化就开始启动，导致第一次连接超时、重试、最终成功。这4.5秒里，Nginx已经向监控上报了两次5xx错误。

更精确的测量需要进入容器内部：

docker inspect --format='{{.State.StartedAt}}'

对比宿主机uptime的时间差，能得到从系统启动到服务就绪的完整链路。某次优化后，这个时间从127秒压到31秒——差距不在硬件，而在健康检查间隔和依赖等待策略的调整。

Oracle云特有的一个坑：虚拟网卡初始化延迟。

云实例重启后，ens3网卡获取IP的速度比物理机慢1-3秒。如果容器配置了network_mode: host，它会尝试绑定一个还不存在的IP，启动失败。改用桥接网络或添加启动延迟脚本，是更稳妥的做法。

验证网络恢复的标准动作：

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" http://localhost:8080/health

连续跑10次，记录状态码和响应时间。如果前3次是000（连接拒绝），第4次突然变成200——说明你的健康检查阈值设得太激进，负载均衡已经把你踢出去了。

最后留一个开放问题：你的重启SOP里，有没有一条命令能证明"所有服务真的好了"，而不是"看起来没报错"？