凌晨 02:40，我站在将军澳机房的冷通道里，手心贴着前面板的蜂窝罩，能感觉到 NVMe 的微热顺着风道往上爬。刚才一次计划外停电把整排混合业务服务器都“冻”了一遍——恢复电力后，业务栈从内核起来到 API 可用足足拖了 3 分 10 秒。在低延迟跨境访问的场景里，这 190 秒就像一条小裂缝，会让等候在上游的网关打满重试队列。

我第一反应不是去怼数据库配置，而是掏出口袋里的小本本，写下四个字母：s-y-s-t-e-m-d。

接下来这篇文章，就是我在香港机房 + Debian 生产环境里，如何用 systemd 把“冷启动时间”从 190 秒压到 58 秒的完整过程。没有玄学，只有工具、日志、依赖图和一点点“临场修补”。

香港机房和服务器环境画像（硬件/系统/业务栈）

表 1：硬件与系统参数

业务冷启动完成的定义：

从上电 → SSH 可登 + /healthz 返回 200 + 入站 Nginx 能转发到 API + API 能访问 PG/Redis。

1. 先量化：把“慢”拆成具体的秒

1.1 baseline（优化前）

$ systemd-analyze time
Startup finished in 3.214s (kernel) + 187.341s (userspace) = 190.555s
graphical.target reached after 185.201s in userspace

$ systemd-analyze blame | head -n 15
90.322s systemd-networkd-wait-online.service
31.487s docker.service
18.663s postgresql.service
12.014s mnt-data.mount
8.477s  consul.service
6.921s  nginx.service
...

$ systemd-analyze critical-chain
multi-user.target @1min 55.201s
└─docker.service @1min 34.999s +31.487s
  └─network-online.target @1min 34.998s
    └─systemd-networkd-wait-online.service @4.676s +90.322s
      └─systemd-networkd.service @3.998s +676ms
...

快速解读：

• network-online.target 被 wait-online 卡了 90s；根因是某条上行在 IPv6 上挥发，systemd-networkd-wait-online 默认“等到所有设备完全联机”——我们根本不需要。
• docker.service 在冷启动自动 pull 了 2 个侧车镜像（慢），并且被错误地放在关键链路里。
• /mnt/data 是软阵列 + ext4，fsck 与 mdadm sync 在启动时叠加，Requires= 连锁导致 PG 等它。

表 2：冷启动基线（优化前）

2. 优化思路（先原则，后手术刀）

把“必须同步完成”的少数服务留在关键路径（比如：本地盘、最小网络、健康检查链路），其余全部延迟/按需/懒加载。

缩短阻塞点：用 wait-online --any --timeout=...，让“有一个可用”即可进入。

依赖图“去钢化”：少用 Requires=，多用 Wants=；把 After= 只用于真正需要顺序的地方。

socket 激活：能用 socket 激活的服务（自研 API、内网 RPC 网关）就别在引导阶段提前起。

mount 按需：把非根业务卷改成 x-systemd.automount，去掉引导链阻塞。

把“重资源”的事移出冷启动：Docker 拉镜像、应用预热、apt 升级等，全部丢到 *.timer。

用 drop-in 管理：只改 /etc/systemd/system/*.d/override.conf，支持快速回滚。

3. 实操：我在机房里做了什么

3.1 修剪不必要服务与计时器

# 关闭/屏蔽用不上的守护进程（示例，按需取舍）
systemctl disable --now avahi-daemon.service ModemManager.service
systemctl mask apt-daily.service apt-daily-upgrade.service

# 用自己的维护窗口替代系统的 apt 计时器（03:30 执行）
cat >/etc/systemd/system/apt-maintenance.service <<'EOF'
[Unit]
Description=Nightly apt maintenance
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/apt-maint.sh
EOF

cat >/etc/systemd/system/apt-maintenance.timer <<'EOF'
[Unit]
Description=Nightly apt maintenance timer
[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=15m
Persistent=true
[Install]
WantedBy=timers.target
EOF

systemctl enable --now apt-maintenance.timer

这里“删而不毁”，任何时候都能 systemctl unmask 恢复默认。

3.2 network-online：从“等所有”改为“有一个就上”

情景问题：我们两张 25G 口分别走不同上联，IPv6 其中一条偶尔 flap；wait-online 默认 --timeout=120s 且等所有设备 ready。

解决（systemd-networkd 场景）：

systemctl edit systemd-networkd-wait-online.service

写入：

[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --any --timeout=12

如果你用的是 NetworkManager：

systemctl edit NetworkManager-wait-online.service

写入：

[Service]
ExecStart=
ExecStart=/usr/bin/nm-online -s -x -q --timeout=12

顺带：把 不参与冷启动判定 的网卡标注出来（networkd）

# /etc/systemd/network/10-lan1.network
[Network]
RequiredForOnline=no

这一步，单枪匹马救回了 ~78 秒。

3.3 把数据卷改成按需自动挂载

原先 /etc/fstab：

/dev/md1  /mnt/data  ext4  defaults  0 2

改为：

/dev/md1  /mnt/data  ext4  noatime,x-systemd.automount,x-systemd.device-timeout=5s,nofail  0 2

执行：

systemctl daemon-reload
systemctl restart mnt-data.automount

效果：PG/应用如果没访问 mnt-data 就不会阻塞引导；第一次访问再自动 mount。

3.4 PostgreSQL：明确依赖“卷”而不是“全网”

创建 drop-in：

systemctl edit postgresql.service

写入：

[Unit]
# 不再盲等 network-online，明确只依赖数据盘
After=mnt-data.mount
Wants=mnt-data.mount
# 若你分离了 WAL 卷
RequiresMountsFor=/mnt/data/pgdata /mnt/data/pgwal

[Service]
# 冷启动时更快的 OOM 报警/恢复
Restart=on-failure
StartLimitIntervalSec=30
StartLimitBurst=5

3.5 自研 API：从“提前起”变“socket 激活”

api.service（Type=notify，支持 sd_notify）：

# /etc/systemd/system/api.service
[Unit]
Description=My API
After=postgresql.service redis.service
Wants=postgresql.service redis.service

[Service]
Type=notify
User=api
WorkingDirectory=/srv/api
Environment=ENV=prod
ExecStart=/srv/api/bin/api
WatchdogSec=30
Restart=always
RestartSec=1
# 如果需要对 PG 等待更精细：
ExecStartPre=/usr/local/bin/wait-port 127.0.0.1:5432 -t 10

[Install]
WantedBy=multi-user.target

api.socket：

# /etc/systemd/system/api.socket
[Unit]
Description=My API (socket activation)

[Socket]
ListenStream=0.0.0.0:8080
NoDelay=true
Backlog=1024

[Install]
WantedBy=sockets.target

启用：

systemctl enable --now api.socket
systemctl disable api.service    # 让 socket 去拉起 service

效果：Nginx/上游第一次有流量打到 8080 时才拉起 API，不再把它放在冷启动关键路径里。

3.6 Nginx：依赖“可用路由”而不是“全网”

systemctl edit nginx.service

写入：

[Unit]
# 不要 After=network-online.target，避免被 wait-online 拖累
After=network-pre.target
Wants=network-pre.target
# 如果你绑定的是特定地址:
# BindsTo=sys-subsystem-net-devices-<ifname>.device

只要本机能 bind 端口，Nginx 就能先起来；后续上游的 readiness 由 API/后端自管。

3.7 Docker：把“拉镜像”移出引导，改用定时预拉

问题：docker.service 在我们的 unit 里被“误伤”成关键路径，还顺手 pull 了两个侧车。

做法：

• 还原 docker 到非关键路径（多数情况下不需要 After=network-online.target）
• 单独做预拉计时器

# 1) 恢复 docker 依赖
systemctl revert docker.service  # 移除历史 drop-in（若有）

# 2) 预拉
cat >/etc/systemd/system/docker-prefetch.service <<'EOF'
[Unit]
Description=Prefetch docker images

[Service]
Type=oneshot
ExecStart=/usr/bin/bash -lc 'for i in ghcr.io/acme/sidecar1:1.4 ghcr.io/acme/sidecar2:2.1; do docker pull $i || true; done'
EOF

cat >/etc/systemd/system/docker-prefetch.timer <<'EOF'
[Unit]
Description=Prefetch docker images nightly
[Timer]
OnBootSec=5min
OnUnitActiveSec=24h
RandomizedDelaySec=10m
[Install]
WantedBy=timers.target
EOF

systemctl enable --now docker-prefetch.timer

3.8 目标聚合：做一个“应用栈 target”

把业务的“可对外服务”定义为一个 target，便于排障与一次性起停。

# /etc/systemd/system/app-stack.target
[Unit]
Description=My App Stack (externally ready)
Wants=nginx.service api.socket redis.service postgresql.service consul.service
After=nginx.service postgresql.service redis.service consul.service

以后可以 systemctl isolate app-stack.target，或在恢复演练里专盯它的 critical-chain。

3.9 小而有效的“预热”与“调度”

页缓存轻预热（只在业务允许时启用）：

# /etc/systemd/system/warm-cache.service
[Unit]
Description=Warm FS cache
After=local-fs.target
[Service]
Type=oneshot
ExecStart=/usr/bin/bash -lc 'find /mnt/data/hotset -type f -size -32M -print0 | xargs -0 -n32 -P4 cat >/dev/null || true'
[Install]
WantedBy=multi-user.target

I/O/CPU 礼貌值（避免冷启动阶段的争抢）：

在重资源 oneshot 里加：

IOSchedulingClass=idle
Nice=10

4. 验证与对比：数字会说话

4.1 重新量化（优化后）

$ systemd-analyze time
Startup finished in 3.166s (kernel) + 55.104s (userspace) = 58.270s
multi-user.target reached after 53.092s in userspace

$ systemd-analyze blame | head -n 15
12.441s mnt-data.automount
8.921s  postgresql.service
6.102s  consul.service
4.331s  nginx.service
3.551s  docker.service
2.775s  redis.service
...

$ systemd-analyze critical-chain
multi-user.target @53.092s
└─postgresql.service @44.132s +8.921s
  └─mnt-data.mount @31.588s +1.221s
...

表 3：关键指标对比

5. 依赖矩阵（我们到底改了谁依谁）

表 4：服务依赖矩阵（节选）

6. 线上“坑”与现场解法

IPv6 上游波动把 wait-online 拖死

现象：systemd-networkd-wait-online 等到超时（120s）

解法：--any --timeout=12，并对“非关键”链路 RequiredForOnline=no。

Docker 在 boot 时偷偷拉镜像

现象：docker.service blame 排名靠前

解法：把 pull 移到 *.timer，引导只起守护进程；业务容器改为按需。

远端/大卷挂载阻塞

现象：mnt-data.mount 卡在 mdadm 或 fsck

解法：x-systemd.automount + nofail + device-timeout，并把 PG 改为明确 RequiresMountsFor。

Nginx/Consul 过度依赖 network-online

现象：关键链（critical-chain）被 online target 拖长

解法：下沉依赖到 network-pre.target 或直接去掉 After=，容错交给上层重试。

Type=simple 的自研服务假“就绪”

现象：WantedBy=multi-user.target 早就到了，但 /healthz 还在连接 PG

解法：改 Type=notify，程序里增加 sd_notify(READY=1)；或至少在 unit 里加 ExecStartPre=wait-port。

回滚与变更审计

做法：所有变更都在 *.service.d/override.conf；可用 systemctl cat 审计，systemctl revert 快速回滚。

7. 我常用的“快速体检”命令清单

systemd-analyze time
systemd-analyze blame | head -n 50
systemd-analyze critical-chain
systemd-analyze plot > /root/boot.svg

journalctl -b -p warning
journalctl -b -u <unit> -e

systemctl list-dependencies multi-user.target
systemctl list-units --failed

# 检查自定义 unit 是否有语法/依赖问题
systemd-analyze verify /etc/systemd/system/*.service /etc/systemd/system/*.socket

8. 可复制的落地“配方”（最小可行改造）

1. 让 online 更宽容：wait-online --any --timeout=12
2. mount 按需：x-systemd.automount,nofail 给业务卷
3. 去关键路径：移除 Nginx/docker/Consul 对 network-online.target 的强依赖
4. API socket 激活：为自研 API 增加 .socket，服务 Type=notify
5. 定时拉镜像：docker-prefetch.timer 夜间运行
6. target 聚合：定义 app-stack.target，观察它的 critical-chain 与状态
7. 全程 drop-in：一律放 /etc/systemd/system/*.d/override.conf，便于回退

9. 尾声：从 190 秒到 58 秒

机房空调的风声一阵一阵，像在给耳朵“降噪”。我把最后一次 systemd-analyze time 的结果贴进群里，大家都松了口气。

第二天上午，业务部门发来一条短短的消息：“凌晨恢复很稳，延迟曲线漂亮。”

这一趟，让我再次确认：解决冷启动时间过长，80% 的收益往往来自 20% 的 systemd 依赖治理。
当我们把“必须同步完成”的东西收敛到最小、把“可以懒加载”的都交给 socket/automount/timer，剩下的时间自然会还给你。

如果你也在香港或其他边缘/跨境场景里被“冷启动时间”折磨，不妨按这份清单做一遍。

别忘了：先量化，再下刀；先 drop-in，再上线；随时可回滚。

下一次停电演练，你会感谢今天在冷通道里做过的这些小而确定的改动。