关键服务应选restart=on-failure而非always，因其仅在退出码非0、信号终止、启动或看门狗超时时重启；须配restartsec和startlimit防雪崩，并确保type匹配实际启动行为。
关键服务需要的不是“能重启”，而是“重启得合理、停得及时、查得清楚”。systemd原生就支持这套闭环机制，核心是三件事：精准触发重启、主动限制频率、明确暴露异常。不需要额外脚本，也不依赖外部监控。
重启策略选 on-failure，不是 always
对数据库、消息队列、API网关等有状态或资源敏感的关键服务，Restart=on-failure 是更安全的默认选择。它只在以下情况触发重启：
- 进程退出码非 0（如程序报错退出）
- 被信号强制终止（如 SIGSEGV 段错误、SIGKILL 被 OOM killer 杀掉）
- 启动超时（由 TimeoutStartSec 控制）
- 看门狗超时（若启用 WatchdogSec）
避免用 Restart=always，否则正常 reload 或运维主动 stop 都会立刻拉起，干扰操作节奏，也掩盖了本该人工介入的计划性停机。
必须配 RestartSec 和 StartLimit 防雪崩
光设 Restart 不够，连续崩溃可能拖垮系统。要在同一 [Service] 块中同步配置：
- RestartSec=10：每次重启前强制等待 10 秒，给依赖服务（如数据库、缓存）恢复时间，也避免 CPU 空转
- StartLimitIntervalSec=60：以 60 秒为一个统计窗口
-
StartLimitBurst=3：该窗口内最多重启 3 次；超过即标记为 start-limit-hit，systemd 停止自动拉起，必须人工
systemctl reset-failed 服务名后才能继续
这个组合相当于给服务加了一道“熔断器”——既保可用，又防失控。
Type 匹配真实启动行为，否则 Restart 失效
systemd 能否检测到崩溃，取决于它是否真正在追踪主进程。确认 Type= 设置与服务实际行为一致：
- Type=simple（默认）：适合前台运行的 Go/Python 服务，systemd 启动后即认为就绪，崩溃可捕获
- Type=forking：适用于传统 daemon（如 nginx、redis），必须配合 PIDFile= 指向正确路径，否则 systemd 无法识别主进程是否存活
-
Type=notify：推荐用于需初始化完成才对外提供服务的场景（如 Spring Boot、FastAPI），服务启动后调用
sd_notify("READY=1")主动通知就绪，systemd 才开始计时和监控
如果 Type 错配，比如把 notify 型服务写成 simple，systemd 可能在服务真正就绪前就判定“启动成功”，后续崩溃也无法准确感知。
验证与日常可观测性不能少
配置完别只信 status 显示“active”，要主动验证闭环是否真实有效：
- 模拟崩溃：
sudo systemctl kill --signal=SIGSEGV 服务名，观察是否在 RestartSec 秒后拉起 - 查重启记录：
systemctl show 服务名 | grep -E "(Restarts|StartLimit)"，确认 Restarts 计数递增且未触发 limit-hit - 盯日志流：
journalctl -u 服务名 -n 30 -f，重点看 Started / Starting / Failed with result 的交替节奏 - 设环境变量或日志重定向（如
StandardError=file:/var/log/服务名-error.log），确保错误上下文不丢失
真正的自愈能力，是故障发生时你还没收到告警，服务已恢复；而故障持续时，你又能第一时间从日志和计数里定位根因。
