云端自动化部署的容错设计：把幂等、状态检测和轮询用在正确的地方

做云端自动化部署的同学大概都有这个体验：脚本第一次跑成功，第二次跑就报错；换台机器跑，又报另一个错；跑一半网络抖动，重跑直接卡死。

问题往往不在业务逻辑，而在容错设计。这篇文章把云端自动化里最容易踩的六个坑和对应原则整理出来，都是可以立刻套用的模式。

一、原则一：幂等——任何脚本都必须能安全地重跑

云上操作最常见的失败模式不是"执行失败"，而是"不知道执行到哪一步了"。超时、断连、进程被杀，都会让你面对一个中间状态：资源可能已经创建了一半。

所以每个步骤都应该设计成幂等：无论执行一次还是十次，结果一致。

具体做法：
创建类操作，先查后建。比如创建安全组规则，先列出已有规则做去重判断，存在则跳过。
删除类操作，容忍"已经不存在"。删除时若返回 404，视为成功而非失败。
写入类操作，用确定性键。配置文件、标签、元数据用固定 key 覆盖写，而不是追加。

反例很常见：脚本里直接 create，重跑时资源名冲突报错，然后人工去控制台删干净再来一遍——这就把自动化的价值全丢了。

二、原则二：状态检测优先于盲目重试

判断一个操作要不要重试，不能只看"失败了"，要看"为什么失败"。

把错误分成三类处理：
第一类，资源不存在。通常意味着前置步骤没完成，应该补前置而不是重试当前步骤。
第二类，资源已存在或已在运行。说明这个步骤其实已经成功过，跳过即可，不应报错。
第三类，资源紧张、限流、节点池不足。这才是真正需要等待重试的。

把这三类混在一起无脑重试，结果就是：该跳过的反复失败，该等待的很快耗尽重试次数。

实战里非常典型的一个例子是：沙箱环境处于运行中时，再次调用"启动"接口返回"环境未关闭，无法启动"。这不是故障，是状态冲突。如果代码把它当故障处理并反复重试，永远好不了；正确做法是先查状态，运行中则直接复用。

三、原则三：轮询代替固定 sleep

固定 sleep 是自动化脚本里最贵的坏习惯：sleep 短了资源没就绪，sleep 长了浪费大量时间。

正确姿势是状态机加轮询：
第一步，发起异步操作，拿到任务 ID 或资源 ID。
第二步，以固定间隔查询状态，直到进入终态（成功或失败），或达到超时上限。
第三步，超时分两种：可以继续等待的，加大间隔继续一轮；不可恢复的，明确失败并给出当前状态快照。

伪代码结构大概是：
提交任务 → 循环查询状态 → 状态为成功则跳出 → 状态为失败则中止 → 达到上限则超时报错

轮询间隔建议 5 到 15 秒起步，长任务用指数退避。关键是每次轮询都要判断"失败终态"，不能只等成功——否则资源创建失败时会白白等到超时。

四、原则四：局部失败不能中断全局

一个巡检或部署脚本往往要处理多个独立对象：三台机器、四个资源类型、五个区域。

如果第一个对象失败就整体退出，你会失去后面所有对象的信息，排查时还要再跑一遍。

更好的设计是容错聚合：每个对象独立执行，失败记入错误列表，继续处理下一个；最后统一汇报"成功 N 个，失败 M 个，失败明细如下"。这样一次运行就能拿到全量诊断信息。

这个原则在批量操作里尤其重要：十个资源的批量操作，要求要么全成功要么全失败，在云上是几乎不可能实现的奢侈要求。

五、原则五：所有环境假设都要可重建

云上的开发环境、临时容器、沙箱空间都有一个共同特点：随时可能被回收重建。今天好好的配置目录，明天可能就空了。

所以脚本里任何"依赖环境里已有某个东西"的假设都是脆弱的。正确做法是：每一步都先检测前置条件，缺失则自动补齐。

具体实践：
入口处检查命令行工具是否可用、版本是否满足、凭证是否有效，缺失就安装或提示；
配置文件丢失时用默认值重建，而不是直接报错；
中间产物写到可丢弃的临时位置，重要状态写到明确的持久位置。

一句话原则：把环境当成一次性的，任何需要的东西都能从零构建。

六、原则六：不可逆操作必须有人工闸门

自动化最大的价值是效率，最大的风险也是效率——删错了，数量级也放大。

所以要把操作按可逆性分级：
可逆且低风险的操作（查询、创建、修改配置），自动执行；
不可逆或高成本的操作（删除实例、释放公网 IP、清空存储桶、删除磁盘），一律输出明确的执行计划，等待人工确认后再执行。

注意"看起来可逆"的陷阱：实例可以重建，但实例上的数据不一定能重建。判断标准应该是"数据能不能恢复"，不是"资源能不能再创建"。

七、一个完整的检查清单

写云端自动化脚本前，对照这六条过一遍：

1. 每个步骤重跑是否安全？创建前查过重吗？删除容忍不存在吗？
2. 错误分类了吗？哪些该跳过、哪些该等待、哪些该中止？
3. 异步操作是轮询还是固定 sleep？超时有处理吗？失败终态判断了吗？
4. 批量处理是否单点失败即全量退出？
5. 依赖的环境状态是检测出来还是假设出来的？能自动重建吗？
6. 不可逆操作有没有人工确认环节？

八、写在最后

云端自动化的本质，是把人的操作经验固化成可重复执行的确定性流程。

确定性不来自"写了很多重试"，而来自：状态可查、操作幂等、失败可分类、危险有闸门。把这四条做扎实，脚本的健壮性会有一个质的变化——从"第一次能跑"到"任何时候都能跑"。

这比多写多少行代码重要得多。