别让脚本跑两遍：用预执行校验保护你的 DevOps

谁都遇到过这种情况：部署脚本明明执行成功了，结果因为重试、点错或者 CI/CD 配置问题，又跑了一次。第二次运行本不该发生，却真的发生了。数据库迁移重复执行、云资源被创建两次、支付回调被触发多次……麻烦就来了。

这时候，预执行状态校验 就能帮你把关。

为什么“幂等”靠不住

很多开发者默认脚本是幂等的——跑两次和跑一次结果应该一样。理论上没错，实际操作中却经常翻车。

比如下面这些场景：

• 创建 AWS 资源的部署脚本
• 修改数据库结构的迁移
• 处理用户注册的 Webhook
• 同步数据的批处理任务

就算这些操作“基本”幂等，短时间内跑两次也可能出问题：时间戳重复更新、计数器多加一次、用户收到两条通知。

问题在于，你不是在用幂等性保护自己，而是在盲目相信它不会出错。

预执行校验：别靠假设，靠验证

与其赌脚本不会重复执行，不如在执行前明确问一句：“这个操作之前已经跑过吗？”

现代 DevOps 里，很多企业级方案正是这么做的。它们会维护一份执行记录（可以用时间戳、哈希值、数据库标记或分布式锁），用来回答一个简单问题：现在真的需要跑吗？

工作流程

1. 查历史：脚本启动前，先去执行状态库里查一下
2. 验上下文：确认这次和上次的参数、环境是不是完全一样
3. 加标记：把当前操作标记为“进行中”，防止并发冲突
4. 执行：真正跑业务逻辑
5. 更新状态：执行完后标记为“已完成”

这一套流程把脚本从“希望它是幂等的”变成了“已经验证过没跑过”。

为什么对域名和托管特别重要

在域名和托管场景下，重复执行的代价很高。DNS 记录不能改两次，SSL 证书不能重复申请，域名注册流程也必须严格执行一次。

预执行校验在这些地方尤其管用：

分布式系统：脚本分布在多个服务器或云区域时，需要协调机制。校验框架能防止同一操作在不同节点重复执行。

CI/CD 管道：部署失败重跑时，校验层会自动跳过已经成功的步骤，避免基础设施重复创建。

Webhook 处理：外部服务重试失败的回调时，你的系统要能识别并忽略重复请求。

数据库迁移：migrate up 本身可能安全，但自定义迁移脚本跑两次就可能破坏数据。校验能有效防止这种情况。

定时任务：Cron 任务如果执行时间超过预期，容易出现重叠。校验机制可以确保同一时刻只跑一个实例。

怎么落地

想引入预执行校验系统，需要考虑以下几点：

状态存储：用数据库、Redis 还是分布式锁服务？根据一致性要求和可用性需求来选。

唯一键设计：怎么判断两次执行是“同一个”？文件名 + 参数？Git commit + 环境？关键看你怎么定义“重复”。

TTL 和清理：记录要保留多久？太短失去保护作用，太长又浪费资源。结合你的重试窗口和业务逻辑来定。

并发问题：两个实例同时想执行怎么办？用原子操作、分布式锁或版本控制来处理。

失败策略：校验系统出故障时，是默认不执行（fail safe），还是默认执行（fail open）？取决于业务风险。

NameOcean 的做法

我们正在把 AI 辅助开发引入基础设施管理。预执行校验正好能和这套系统结合。想象一下：

• 系统能从历史部署中学习执行模式
• 提前预测可能出现的重复执行风险
• 根据实际行为自动调整校验阈值
• 直接在基础设施模板里生成校验代码

这不是单纯执行命令，而是让平台真正理解你的操作。

怎么开始

如果你管理着基础设施、部署脚本或分布式系统，建议先做个审计：

1. 列出那些绝对不能重复执行的操作
2. 检查它们是否已经有执行状态校验
3. 如果没有，就加一层
4. 故意触发重复执行来测试效果

优先从高风险操作入手：数据库迁移、支付处理、资源创建。

总结

预执行状态校验听起来不酷，但确实是基础。它能把系统从“大部分时间正常”变成“遇到问题也能稳住”。

在企业级基础设施里，“大概能跑”是不够的。脚本必须知道自己做过什么，才能做出正确的决策。

管理域名、DNS、SSL 或云资源时，重复执行的代价不只是多花时间，更是用户信任的流失。

把校验当成部署策略里的一等公民。你的未来自己（以及值班的同事）会感谢你。

NameOcean 专注于可靠性。无论是通过我们的注册服务管理域名，还是在我们的云平台上部署应用，我们都确保你的操作只执行一次——不多也不少。