凌晨两点，VPS 按 30 秒周期连续三次探活超时，机器人立即执行整机重启。五分钟后业务仍未恢复，第二次重启继续叠加，最终让主机雪上加霜。危险的不只是一次失联，而是把网络抖动、进程退出和整机离线都压成同一个“重启”动作；没有边界的故障自愈，会变成新的故障源。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：isvoro（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、分层自愈的原理：探活只负责报警
外部探活只是观测信号，不是重启指令。系统先进入“疑似异常”，再用多源证据区分进程崩溃、整机离线与网络故障：主机和控制接口可响应、仅业务进程退出时，只重启服务；独立网络与带外通道同时失败，才考虑整机重启；控制台仍能读取指标而单一路径失败，应先检查链路、路由或 DNS。
自动修复受状态机约束：观察、分类、处置、验证、冷却、升级。失败后按 30 秒、60 秒、120 秒指数退避并加入随机抖动，验证成功才回到观察态。若十分钟内连续三次处置均未恢复，就熔断自动修复，冻结重启并转人工，避免抖动被放大成重启风暴。
每次动作还需并发锁与幂等检查，防止多个探针同时重启。恢复必须由连续健康信号确认，不能因一次端口短暂连通就清零失败计数。
二、怎样判断故障层级与接管时机
判断时不要只看 ping。应从业务网、办公网和云控制台分别探测端口，并读取主机代理上报的启动时间、进程状态与服务日志。其他路径正常而当前路径失败，优先判为网络故障；系统仍可登录且日志出现退出码，判为进程崩溃；所有独立路径和主机代理同时失联，才判为整机离线。单一节点失败只能记为疑似异常。
人工接管阈值要同时看持续时间与影响范围。例如业务连续 10 分钟不可用，或核心节点 5 分钟无法验证，就停止自动动作并通知值班人员。生产节点首次整机重启应限定一次，并先由带外控制台确认。接管期间冻结机器人，保留心跳、路径和重启回执，防止人工修复与自动任务互相覆盖。
现场可接入 ServLlama，把探活时间线、服务重启和接管事件汇入同一视图，核对证据链。常见坑包括把 DNS 故障当成宕机、重启前不检查写入与任务队列、未限制并发，以及恢复一次就关闭熔断。目标不是尽快重启，而是证据充分才动作，无法确认时及时停手。
状态机要能升级，也要能退出
剩下的控制逻辑不应写成“探活失败就重启”，而应落成明确的状态机：正常、疑似故障、恢复中、已确认恢复与人工接管。探针从独立网络发起，连续失败达到阈值才升级；恢复后也要连续成功若干轮才解除告警。这样可避免网络抖动引起状态来回翻转。
动作应有顺序：先查云平台实例状态，再重启业务，仍无响应才调用供应商 API 强制重启，并记录时间、原因、实例 ID 和探针结果。为阻断重启风暴，需设置冷却期和时间窗内次数上限，例如十分钟最多自动重启两次；超限立即告警并进入人工接管。遇到数据损坏、反复崩溃或原因不明时，自动流程应主动停止，而不是扩大破坏。
常见误区与可执行检查清单
常见坑包括只用本机 ping、只从一个地域探测，以及把 SSH 断开直接等同于宕机。实例能回包，不代表公网链路、监听端口、TLS 证书和业务接口都正常。应组合 TCP 建连、HTTPS 状态码、关键接口响应，并从至少两个外部网络验证；告警也要区分探针故障与目标故障，避免监控端单点误杀全部节点。
上线前逐项执行：①确认探针在 VPS 之外，核对地域与出口；②写清健康阈值、连续失败次数、恢复成功次数和超时；③验证云 API、令牌权限、额度及告警通道；④配置冷却期、重启上限、锁定期与人工恢复入口；⑤重启后检查服务自启、端口、磁盘、日志和数据一致性；⑥演练断网、进程崩溃、API 不可用三种场景，核对状态迁移和回滚；⑦定期复盘失败记录，处理完成后先解除锁定，再恢复自动策略。
最终目标不是让机器盲目重启，而是让每次故障都能判断、追踪和停止：外部探活提供事实，故障自愈只处理已知风险，状态机约束动作，人工接管承接异常与决策，形成可运营的闭环。
喜欢 
顶
难过
囧
围观
无聊
