服务崩溃自动恢复的关键是配置“恢复动作”，Windows、Docker、supervisor、Kubernetes均原生支持，核心为定义失败条件、设置响应动作、验证闭环效果。
服务崩溃后能自动重启、记录日志甚至触发脚本，关键在于正确配置“恢复动作”。这不是高级功能，而是 windows、docker、kubernetes、supervisor 等主流平台都原生支持的基础能力。核心思路一致：定义失败判定条件 + 设置响应动作 + 验证闭环效果。
Windows 服务的恢复选项设置
适用于本地部署的 Windows 服务（如 SQL Server Agent、自研 .NET 服务等），无需额外工具，图形界面即可完成。
- 打开“计算机管理” → “服务和应用程序” → “服务”，右键目标服务选“属性”
- 切换到“恢复”选项卡，重点配置三项：第一次失败、第二次失败、后续失败 —— 均建议设为“重新启动此服务”
- “重置失败计数”填 1（小时），避免短时抖动被误判为持续故障
- 勾选“如果服务无法启动，运行以下程序”，可填：
C:WindowsSystem32eventcreate.exe /t ERROR /id 999 /l APPLICATION /d "MyService crashed at %date% %time%" —— 实现崩溃留痕 - 点击“应用”后，手动停止服务测试：几秒内会自动重启，状态栏显示“正在启动”
Docker 容器的健康检查与自动重启
面向容器化部署，靠 HEALTHCHECK + --restart 组合实现精准自愈，比单纯“always重启”更可靠。
- 在
Dockerfile中添加健康检查：
HEALTHCHECK --interval=20s --timeout=5s --start-period=30s --retries=2 \
CMD curl -f http://localhost:8080/health || exit 1
- 运行容器时指定重启策略：
docker run -d --restart=on-failure:3 myapp—— 表示健康检查连续失败 2 次后标记 unhealthy，再结合 on-failure 最多尝试重启 3 次 - 验证方式：
docker ps查看 STATUS 列是否变为 unhealthy；再用docker logs -f观察重启日志 - 注意：
start-period必须足够长，确保应用真正就绪后再开始探活，否则误判重启会形成死循环
supervisor 托管服务的故障自愈配置
常用于 Linux 下 Python、Node.js 等后台进程，通过配置文件直接控制重启行为与容错逻辑。
- 编辑
/etc/supervisor/conf.d/phi4-reasoning-vision-web.conf，确认含以下关键项：
autostart=true
autorestart=true
startretries=3
stopwaitsecs=10
exitcodes=0,2
-
autorestart=true是核心，表示进程退出即重启；startretries=3控制启动失败时重试次数 - 搭配自定义健康检查脚本（如调用
curl http://127.0.0.1:7860/health）可增强判断精度 - 执行
supervisorctl reread && supervisorctl update重载配置，再用supervisorctl status查看当前状态
Kubernetes 中的 Liveness 探针实战
云原生环境的标准做法，由 kubelet 主动探测 Pod 内部应用状态，失败即杀 Pod 并重建，真正实现“不可用即替换”。
- 在 Deployment YAML 的
containers下添加：
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 45
periodSeconds: 15
timeoutSeconds: 5
failureThreshold: 3
- 含义：容器启动 45 秒后开始探测，每 15 秒一次；单次超时 5 秒，连续 3 次失败则重启 Pod
- 务必配合
readinessProbe使用：它控制流量接入，避免新 Pod 还没就绪就被打满请求 - 上线后用
kubectl describe pod <name></name>查看 Events，确认是否有 Liveness probe failed 记录
