Dry‑run 干跑一个容易被忽略却价值巨大的 CLI 设计模式前言做开发这么久接触过大量命令行工具修改配置、操作数据库、维护目录服务。很长一段时间我并没有听过dry‑run干跑这个概念。在接到海外客户的项目需求之前我甚至会觉得工具把活干完就行为什么还要模拟一遍、只打印结果而不真正执行当时内心是有些不解甚至略带一丝不屑这是不是洋鬼子过度谨慎多此一举的需求直到实际接触 OpenLDAP、PowerShell再研究大量成熟开源工具之后才恍然大悟。Dry‑run 不是锦上添花的花哨功能而是面向生产环境、面向风险控制的工程思想。它值得每一个做运维工具、命令行程序的开发者好好理解。什么是 Dry‑run 干跑Dry‑run中文常译作干跑、试运行、模拟执行底层也叫 No‑opNo‑operation无操作模式。它的核心逻辑一句话概括完整执行全部业务逻辑做全部校验输出将要执行的操作但是跳过最终写入、修改、删除等产生副作用的动作不对真实数据做任何改动。简单说彩排一遍但是不上台演出。它和单元测试、测试环境还不一样单元测试用造好的模拟数据跑逻辑测试环境复制一套完整环境做真实变更Dry‑run直接基于真实生产数据上下文推演只是不落地修改。很多工具会用特殊标记区分模拟输出例如 OpenLDAPldapmodify -n模拟输出行前面带上感叹号!告诉使用者这是将要发生的变更并未真正写入 LDAP 数据库。PowerShell 里不叫 dry‑run而是叫公共参数-WhatIf本质就是干跑模式。脚本会完整走完流程告诉你 “如果继续执行这里会做什么”但是不会改动系统状态。业界工具的 Dry‑run 大盘点很多我们天天在用的工具都内置该模式只是很多人平时很少留意1.OpenLDAP ldapmodify-nNo‑op手册描述show what would be done, but dont actually modify entries。模拟增删改 LDAP 条目输出带!标记不写入 MDB 后端库。在批量导入、批量修改用户时先‑n 跑一遍确认输出没有错误再去掉‑n 正式执行防止批量写错身份数据。2.PowerShell-WhatIfPowerShell 框架原生公共参数。所有兼容 Cmdlet 均可开启模拟脚本执行预览每一步变更不改动文件、注册表、AD 对象。同系列还有‑Confirm交互式确认参数二者共同构成风险防护体系。3.rsync-n / --dry‑run文件同步神器最重要的安全参数之一尤其搭配--delete删除旧文件时必须先干跑一遍。它会完整扫描源目录与目标目录列出哪些文件新增、更新、删除但不会传输、删除任何文件DigitalOce...。生产做镜像备份不做 dry‑run 直接跑一旦路径写错会直接大量删文件。4.Gitgit clean -ngit clean -n预览将要删除哪些未跟踪文件不会真正删除磁盘文件。确认输出无误再执行不带‑n 的命令清理工作区避免误删重要本地文件。5.Ansible-C / --check检查模式Ansible 叫 check mode就是 dry‑run。在大量服务器批量执行 playbook 前先‑C 干跑预览每台机器会发生的变更不修改远端主机提前发现权限错误、路径错误、变量异常Ansible。6.Kubernetes kubectl--dry‑runK8s 操作资源前模拟创建、更新、删除 Pod、Deployment输出 yaml 变更不向 apiserver 提交真实请求防止误删业务负载Kubernetes。7.Debian aptapt‑get install --dry‑run模拟软件包安装计算依赖、输出将要安装、升级、卸载哪些包不会改动系统包管理状态。做大规模版本升级前先预览依赖冲突与卸载列表避免把系统搞崩。8.Azure ARM/Bicep What‑If云基础设施即代码What‑if 就是云平台层面的 dry‑run。对比现有云上资源和模板输出哪些资源会新建、修改、删除不实际部署防止模板写错把云资源销毁。可以看到LDAP、文件同步、版本管理、配置自动化、容器编排、包管理、云资源部署凡是会修改数据、删除资源、具备破坏性操作的工具成熟方案几乎全部实现 Dry‑run。一开始我为什么会觉得它多余站在开发者角度很容易产生一种思维我的代码逻辑写对了输入校验做好了直接运行就完事为什么还要多写一套模拟逻辑过去我也是这样想。我们习惯写完程序自己在测试环境测几遍就交付使用。我们默认 “代码逻辑正确结果就正确”。但现实生产环境变量远比本地测试复杂真实数据、脏数据、特殊条目、权限边界、批量输入、人为复制粘贴错误。你以为只改 100 条用户实际匹配了 2000 条正则写错会批量删除大量条目路径参数写错会触发大规模删除脚本变量异常会引发不可回退的数据变更。很多操作一旦执行损失已经发生回滚成本极高。测试环境可以复现一部分场景但无法 100% 复刻生产真实数据。Dry‑run 解决的不是 “代码有没有 Bug”而是“本次输入在当前真实环境下会产生什么后果”。它相当于给操作者一次 “反悔机会”在破坏性动作提交之前把全部影响摊开到控制台面前。海外工程文化里非常看重这一点先看后果再执行动作把风险暴露在执行之前而不是出事之后再救火。这不是胆小而是工程稳健性。当我理解这点之后我才意识到这套模式确实值得学习。Dry‑run 模式的设计要点可直接用于自研工具例如 ldapctl如果我们自己开发 CLI 运维工具做 dry‑run参考业界最佳实践参数约定短参数统一用-n长参数--dry‑run对齐 rsync、OpenLDAP 用户习惯。输出标记模拟产生的操作行首增加特殊标记如!区分真实输出与模拟输出运维人员一眼识别。逻辑完整性dry‑run 模式下完整执行语法校验、权限检查、条件判断仅仅跳过最终提交 / 写入数据库 / 删除文件的步骤校验错误照常抛出不能因为是模拟就跳过报错。配合 verbose和‑‑verbose配合使用dry‑run 下输出更详细变更内容。只跳过副作用读取、查询、计算全部正常执行只拦截写操作。注意Dry‑run 不是万能保险箱复杂业务下无法 100% 复现运行时全部副作用但它是成本极低、收益极高的一道安全防线。总结Dry‑run 干跑表面看只是一个简单命令行开关背后是一套工程哲学执行破坏性操作前先推演全部影响把风险可视化。过去我以为它是一个可有可无的附加功能见识大量工业级工具之后才明白凡是面向生产、面向批量、面向数据变更的工具dry‑run 应该作为标配能力去设计。它保护使用者减少事故降低线上故障修复成本。对于自研运维命令行工具不要再把它当成 “洋人的多余需求”它是稳健工具不可或缺的一环。需求邮件主题【功能需求】为自研 ldapctl 工具增加 Dry‑run (--dry‑run /-n) 模拟执行功能收件人项目组、产品、客户对接人各位同事在本项目开发过程中客户提出需要增加 Dry‑run干跑 / 模拟执行功能。在刚收到该需求时我个人最初是有些疑惑的主观上觉得现有逻辑校验已经完备该功能属于额外开发的附加项甚至一度认为是过度谨慎的非必要需求。经过调研 OpenLDAP ldapmodify-n、PowerShell-WhatIf、rsync、Ansible、kubectl 等大量主流运维工具实现之后我重新理解该功能的工程价值现正式提出该功能需求。1、需求描述为 ldapctl 命令行工具实现 Dry‑run 模拟执行模式增加短选项-n长选项--dry‑run开启该参数时完整执行全部输入解析、语法校验、条件过滤、权限预检查在控制台输出本次将要执行的 LDAP 变更新增、修改、删除条目模拟输出行首以!作为标记不向 LDAP 服务端提交真实修改不改动后端数据校验、匹配过程中的报错信息正常输出不因模拟模式屏蔽错误可与‑‑verbose组合使用输出更详细变更详情。2、业务价值与场景批量 LDAP 用户变更场景运维人员执行批量导入、属性修改、删除操作前先使用 dry‑run 模式预览将要改动的全部条目确认匹配范围、变更内容符合预期再关闭 dry‑run 正式执行规避人为输入错误、正则表达式错误、参数错误引发大规模误改误删对齐业界 OpenLDAP、rsync 等工具使用习惯降低海外用户上手成本将风险前置在真实写操作发生前暴露问题减少线上故障与回滚成本。3、实现思路简述命令行参数层解析-n / --dry‑run全局开关业务逻辑层完整执行查询、过滤、解析、校验逻辑输出层对每一条待执行操作打印带!标记的模拟变更提交层dry‑run 开启状态下跳过 LDAP 提交操作直接返回错误处理校验失败、参数错误、权限预校验失败正常返回错误码。4、补充说明Dry‑run 无法 100% 复现所有运行时边界场景但属于成本很低、收益很高的安全防护机制。调研大量成熟工具后我意识到这套设计思路值得借鉴不应当作为可选项建议纳入本次版本迭代。如有疑问欢迎沟通。此致 ALTRANCE Byron Bai白胜
