临时 VM 重建后服务自己恢复：一次自愈脚本实战
【摘要】 背景：重建一次，服务就丢了一半服务跑在一台临时 VM 上，机器随时可能被回收重建。一次重建后，隧道服务起不来，站点报 530 约 35 分钟。查下来不是应用本身坏了，而是重建把不持久目录里的东西清掉了，隧道二进制没了，服务一直在崩溃循环。第一个坑：只看“在运行”是不够的原来的自愈检查只看服务是不是 active，结果服务卡在 activating 也被当成正常，漏检了。改成看子状态必须等于 ...
- 背景：重建一次，服务就丢了一半
服务跑在一台临时 VM 上，机器随时可能被回收重建。一次重建后，隧道服务起不来，站点报 530 约 35 分钟。查下来不是应用本身坏了，而是重建把不持久目录里的东西清掉了，隧道二进制没了，服务一直在崩溃循环。 - 第一个坑：只看“在运行”是不够的
原来的自愈检查只看服务是不是 active，结果服务卡在 activating 也被当成正常，漏检了。改成看子状态必须等于 running，才算健康。这个改动很小，但正是它让漏检变成了能发现问题。 - 第二个坑：恢复要用的东西，必须放在持久区
隧道二进制原来只放在系统目录，重建就丢。改成在工作目录里留一份备份，缺失就自动恢复再重启。依赖也一样：包管理器在重建后会丢，基础运行环境还在基座镜像里，自愈脚本里就要加上包管理器缺失自动重装，否则服务代码在、工具不在，还是起不来。 - 第三个坑：权限
有一次备份文件只给了所有者可执行权限，服务用户根本执行不了。改成 755 后才正常。这类问题报错往往不直观，排查时先看权限和执行用户，别只看服务日志。 - 验证：模拟丢失，实测自愈通过
改完后模拟一次二进制丢失：自愈脚本先从备份恢复，再重启隧道服务，最后本地端口和公网域名都恢复正常响应。自愈有没有用，不能只看脚本跑没跑，要看服务是不是真的恢复了。
结尾
自愈脚本的关键不是写得多复杂，而是两点：恢复所需的东西都要放在重建后还在的地方；健康判断要用真实状态，不要用“进程在”代替“服务可用”。临时环境尤其如此，先把恢复路径做实，再谈别的优化。
【版权声明】本文为华为云社区用户原创内容，未经允许不得转载，如需转载请自行联系原作者进行授权。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）