做运维自动化这一行绕不开一个高频问题同样一串操作要对着几十台机器重复执行你是老老实实把节点复制几十遍还是让流程自己循环我最早做批量重启的时候就是前者画布上拖了一排一模一样的节点跑一次改一次维护到怀疑人生。后来在标准运维里真正把“循环流程”用起来才觉得之前的工作方式有多原始。这篇就聊聊标准运维里怎么创建循环流程。我会从循环节点的定位讲起到边界参数和失败预案怎么设计再到完整实操、嵌套循环、以及我在生产环境里踩过的几个坑。适合两类人看一是刚接触标准运维、只会做线性流程的新手二是已经能用标准运维编排任务、但还没把循环节点用明白的同学。1. 标准运维的循环节点它解决的其实是“重复”带来的不稳定1.1 什么样的任务才配得上循环流程先别急着拖节点。我在标准运维里判断一个任务要不要写成循环基本就看四条动作是否完全一致比如“重启服务”“下发配置文件”“执行巡检脚本”动作本身不会变变的只是目标机器或者入参。输入是否批量变化每台机器的 IP、端口、模块名不同但这些不同可以抽象成一个参数列表。操作是否可重复执行执行失败了可以重来不会因为跑第二次就把系统搞坏。是否希望保留每轮独立结果比如每台机器的执行日志、状态码后续要汇总分析。典型场景我列一下基本都是标准运维里高频出现的场景循环的动作每轮变化参数失败处理批量重启服务执行作业平台的重启脚本主机IP、服务名失败跳过或重试批量下发配置推送文件并校验目标机器、文件内容失败记录不中断批量巡检执行巡检命令回传结果主机IP、巡检项全量执行结束汇总批量清理日志清理过期日志文件主机IP、保留天数单台失败不影响其他灰度发布调用发布接口实例ID、批次号健康检查失败即停止如果一次任务只是对固定一台机器做固定操作那压根没必要循环。循环流程最大的价值不是省画布空间而是把“同一套动作在不同输入下重复执行”这件事固化成模板减少人工介入。1.2 循环节点和普通节点到底差在哪标准运维的流程本质是节点的有向串联。普通节点是一个动作执行一次就完了循环节点则是一个容器它把一组节点包在“循环体”里然后按设定的次数反复执行这一段子流程。你可以把普通节点理解成“做一道菜”把循环节点理解成“中央厨房的流水线”——流水线本身不动配菜参数一份份送进来做完一份接着做下一份直到送完或收到停止指令。在界面上循环节点通常会要求你设置几个关键信息循环的最大次数可以是固定数字也可以引用一个全局变量。循环体里面放的子节点每轮循环都会执行一遍。循环变量每轮执行到第几轮、当前轮次的输入数据是哪一份这些会作为变量暴露给循环体内的节点。以我用的版本为例循环体内可以通过一个内置变量拿到“当前是第几次循环”比如${loop.count}或者界面上显示的“当前循环次数”。具体变量名不同版本有差异但机制都一样循环体里的节点每轮都能感知到“这次轮到我处理哪台机器了”。1.3 循环不是万能的它解决不了并发调度这里要说清楚一个容易误解的点标准运维的循环节点默认是串行执行的。也就是说第 1 轮跑完才会跑第 2 轮不是一次性把 100 台机器都并发执行。这个特性和很多人以为的“循环批量并跑”不一样。如果你要处理的是几百台机器单靠循环节点串行跑时间会非常长。我的做法通常是把机器列表拆成若干批每批当成一轮循环或者配合平台里的并行节点、子流程调用来分摊。循环解决的是“重复编排”的问题并发问题得靠外层调度设计来解决两件事别混在一起。2. 动手前把三件事问清楚边界、注入、失败预案2.1 先画一张“循环边界”清单每次创建循环流程之前我先不打开平台而是先在文档里把下面几个问题写清楚。别嫌这个步骤啰嗦我见过太多循环流程建到一半发现自己根本说不清“循环到什么时候算结束”最后只能写一个巨大的数字跑完为止。循环的输入列表是什么是一个 IP 列表一批实例 ID还是一组配置文件路径每轮循环处理一个元素还是处理一个子集合循环什么时候正常停止遍历完列表满足某个条件某一轮失败时是继续、退出还是重试要不要保留每轮结果后续统一汇总拿“批量重启数据库”举例我的清单是这样输入是数据库实例 IP 列表每轮处理一个 IP遇到底层机器下线的 IP跳过并记录执行重启后做一次端口探测连续失败 2 次则该轮标记失败最终输出一份成功/失败清单。这个文档不花多少时间但它决定了你在标准运维界面上怎么配置循环次数、怎么设计失败分支以及怎么传参。2.2 参数注入的两种常见方式在标准运维里循环体内节点要拿到“当前轮的参数”基本靠变量引用和参数解析。流程模板里先定义好全局变量循环体内再通过引用/解析把它们取出来用。我常用的方式有两种在流程模板里定义全局变量比如server_ip_list类型是字符串值是 IP 列表。循环节点的次数引用这个变量的长度或者直接引用这个变量作为遍历对象。用解析参数的方式把上一节点的输出解析成当前循环体内可用的变量。比如作业平台返回了 JSON里面包含目标机器的 IP我把它解析出来循环体内的下一个节点直接用。下面是一个典型的配置片段展示参数如何在循环里流动流程全局变量 server_list: 10.0.0.11,10.0.0.12,10.0.0.13 循环节点 循环次数/遍历对象${server_list} 循环体 - 节点A执行作业“重启服务” 主机IP${loop.current_item} 端口探测${loop.count} - 节点B结果记录 状态${node_A.output.status}注意不同版本的变量名写法不完全一样有的是${loop.current}有的是${loop.item}还有的是${current}。别背死记硬背以你平台里“变量说明”为准。关键是理解这个机制外层列表被拆开每一轮把其中一个元素暴露给循环体。2.3 失败预案继续、停止、忽略三个都得提前定循环流程比普通流程难排查就是因为一条线要跑很多轮中间某一轮出问题后面是继续还是停直接影响整个任务结果。我的习惯是提前把失败模式定成下面三类失败模式适用场景标准运维里的实现思路失败即停止灰度发布、配置变更不允许带病继续循环体里加条件判断满足失败条件则退出循环失败跳过批量巡检、日志清理单台失败不影响大局节点上配置“失败继续”把失败当成一轮正常结束失败重试网络抖动、服务重启瞬间不稳定节点上设置重试次数和重试间隔我在生产里最常用的是“失败跳过后续汇总”。比如批量清理日志一台机器清理失败不影响其他机器继续清最后看汇总里哪几台失败单独人工处理就行。但如果操作的是核心配置变更我反而希望失败即停止防止一批机器配置不一致后面更难收拾。3. 完整实操创建一个“批量重启指定机器”的循环流程3.1 搭建流程骨架打开标准运维新建一个流程模板。先把流程的骨架建起来我通常会放这样的结构开始节点循环节点循环体内的执行作业节点循环体内的结果判断节点结束节点注意循环节点作为容器在画布上和其他节点连起来但循环体内还包含它自己的子节点。不要把它当成普通节点那样直接配一个命令就完了你要进到循环节点内部把子节点拖到容器里面。3.2 配置最大循环次数与遍历对象循环次数这个参数我强烈建议不要写死。写死一个“10”意味着这台机器列表只能是 10 台下次变 12 台还得改模板。我都是把机器列表定义成全局变量循环次数引用变量的元素个数或者直接把列表变量作为循环的遍历对象。在界面里大致是这样在循环节点配置里把“循环次数”或“遍历的对象”指向server_list然后设置一个合理的最大上限作为保护。这样列表有 5 个 IP 就循环 5 轮有 20 个 IP 就循环 20 轮模板不用动。3.3 在循环体里放任务节点并注入变量循环体里放一个“执行作业平台”的节点或者干脆放一个“命令行执行”原子。我这里以作业平台为例选择作业预先在作业平台里创建好的“restart_service”脚本。主机参数选择“变量引用”填入${loop.current_item}表示本轮要处理的机器 IP。其他参数比如服务名、端口可以用流程全局变量传入也可以让每轮从解析参数中获取。这里有个比较重要的点循环体的节点不要在每次循环时重复请求一次全局变量而是优先使用循环暴露出来的“当前项”。如果你还是引用整列表那每轮都会把全部机器处理一遍循环就失去意义了。3.4 保存、执行、验证循环是否按预期跑流程模板配置完成后保存并创建一个任务执行。执行过程中我一般会盯几个点任务详情里循环节点是否显示“循环执行中”当前执行到第几轮。每一轮的执行事件里传入的 IP 是不是按顺序变化的。有没有某一轮出现参数为空、变量解析失败的情况。标准运维的任务详情里通常可以看到每个节点的执行记录。循环节点的记录会带轮次信息比如“第 1 轮”“第 2 轮”点开某一轮能看到该轮循环体内所有节点的执行情况。我第一次跑循环的时候就是靠这个确认参数确实被正确拆开了第 1 轮 IP 是 10.0.0.11第 2 轮变成 10.0.0.12说明遍历逻辑没问题。4. 如何让循环“停下来”终止条件、跳过失败、重试设置4.1 用条件判断实现“处理完即止”或者“异常即停”循环次数到了循环自然会结束。但更多时候我们希望在满足某个条件的时候提前终止循环这时候就得靠条件判断节点。举个例子做灰度发布时每轮发布一台机器发布完做健康检查。只要健康检查失败就该停止后续发布而不是把所有机器都发布完再汇报。标准运维里通常可以在循环体内加一个“条件判断”节点判断健康检查结果不通过时触发退出循环的动作或者把循环次数直接改成当前轮次。这个“提前退出”的语义不同版本实现方式不太一样。有的版本通过条件分支控制循环次数有的版本在循环节点上配置“结束条件”。我的建议是先确认你所在版本支持哪种方式然后小范围验证一次确认退出逻辑真的会触发再拿去生产用。4.2 单轮失败不中断配置“失败继续”循环里只要有一个节点失败默认可能会把整个循环流程中断掉。但在批量巡检、日志清理这类场景里我们不希望单台机器的失败阻断整体任务。做法是在循环体内的节点上把错误处理方式从“失败终止”改成“失败忽略/跳过”或者设置该节点的失败分支不连接到流程结束而是连接到循环内的下一节点或直接结束本轮。我在批量清理日志的场景里就是这种配置循环体内执行清理命令如果目标机器连不上这个节点会失败但我要的是继续循环下一台。这时我会把失败分支接到一个“记录失败机器”的节点上既不中断循环也能把失败信息保留下来。4.3 重试次数和间隔怎么给才合理重试是个好东西但别滥用。每台机器失败后重试 3 次每次间隔 2 分钟如果 100 台机器里半数都失败循环时长会被重试拖死。我一般这样设置网络类操作重试 2 次间隔 60 秒。网络抖动往往几十秒就恢复等 60 秒再试一次比较合理。服务重启类操作重试 1 次间隔 120 秒。重启后的服务需要时间完成初始化120 秒后再探测往往就能过。纯命令下发类操作重试 1 次间隔 30 秒。这类失败大多是目标机器负载高或者认证临时失败短间隔重试即可。重试是在节点级配置的不是在循环级。标准运维的节点属性里一般有重试次数和重试间隔设置好之后失败会自动重试重试仍失败才走失败分支。5. 嵌套循环外层管集群内层管机器5.1 什么时候真的需要两层循环我最早觉得嵌套循环是个花哨功能直到遇到“多个集群每个集群里有多台机器要执行同一套操作”才老实去研究。场景是这样的外层循环遍历集群列表每个集群项进入内层时内层循环遍历该集群下的机器列表。比如外层当前轮是“集群 A”内层就对集群 A 的 10 台机器逐台执行。标准的单层循环处理不了这种场景因为机器列表是跟集群绑定的不能简单拍平成一个全局列表。5.2 嵌套循环的变量作用域嵌套循环最麻烦的是变量引用。内层循环能不能引用外层的“当前集群名”绝大多数场景需要能引用。你把外层当前值当成一个上下文变量传给内层循环去筛选机器列表。具体到标准运维做法通常是这样的外层循环提供一个变量比如${outer.current_cluster}。内层循环的“机器列表”参数通过解析得到“当前集群对应的机器列表”怎么解析就看数据来源。如果你的机器列表是全局变量里按集群分组的 JSON那就可以通过解析参数方式提取。内层循环体内的节点既可以使用内层变量${inner.current_item}也可以引用外层的${outer.current_cluster}作为附加参数。这里给一个简化的 JSON 数据结构示例方便理解{ clusters: [ { name: cluster-a, hosts: [10.0.0.11, 10.0.0.12] }, { name: cluster-b, hosts: [10.0.0.21, 10.0.0.22] } ] }外层循环遍历clusters内层循环的机器列表取自current_cluster.hosts。这样外层转到 cluster-b 时内层自然就把 IP 列表切换到 10.0.0.21、10.0.0.22。5.3 嵌套循环的时长控制与防呆设计嵌套循环的执行轮数是外层次数乘以内层次数。外层层数是 5内层每层平均 20那就是 100 轮。每轮操作 3 分钟整个流程得跑 300 分钟。所以嵌套之前一定要算好时长必要时把内层操作做成批量执行减少循环轮数。防死循环也重要。如果外层变量解析失败内层拿不到机器列表可能直接退出或者变成 0 次循环更怕的是解析异常导致循环次数变成一个超大整数。我的习惯是给循环次数设置一个最大上限比如单层不超过 200同时在执行前先小规模验证一遍确认数据结构和变量引用正确再全量跑。6. 我在生产环境里被循环流程坑过的四个细节6.1 特殊字符在循环变量中被“吞掉”有次批量下发配置循环体执行到第 7 台机器时突然失败。排查事件记录发现传入的命令多了一个换行符VIM 里看不出来日志里却让脚本解析出错。这类问题绝大多数出在源数据上不是循环逻辑本身。现在我对进入循环的列表参数都会先做清洗去掉空格、去掉空行、统一分隔符。尤其 IP 列表经常有人在复制的时候带上一个看不见的空格结果执行平台把主机识别成非法 IP那轮直接就失败。6.2 循环次数和任务数量对不上先查“一轮处理了几个”我遇到过循环 5 次但实际执行了 5 组、每组 20 台机器的情况。原因是我在循环体内调用的作业节点一次就处理了一个 IP 列表而不是单独一个 IP。也就是说循环每轮处理的是一个“批次”不是一台机器。这里没有对错只有是否符合预期。如果你想让循环逐台处理那循环体里的节点入参必须是单个 IP如果你想按批执行那循环体里传入的就是一个 IP 列表。别混着来不然你看“循环次数”永远猜不到实际覆盖了多少机器。6.3 出错后怎么快速定位到“第几轮”循环流程跑挂之后直接在任务详情里点“事件”展开循环节点按轮次刷选。我一般先看失败的轮次再点进那一轮的循环体子节点看具体是哪一步报错。有些版本支持按轮次筛选执行记录能省很多时间。定位到失败轮次之后不要急着在原任务上改参数重跑。先把失败原因搞清楚是数据源的问题还是脚本本身的问题。我之前犯过错误在同一个任务上用“重试失败的节点”硬跑结果因为脚本里有个变量拼写错重试多少次都一样失败。改完流程模板再重新创建一个任务执行才是正确姿势。6.4 调试循环的小技巧先放“空操作”节点验证变量循环体里变量引用写没写对不用拿真实作业去试错。我习惯在循环体开头放一个“日志输出”或“空操作”节点先把当前轮的变量值打印出来比如当前 IP、当前集群名、当前轮次跑一轮看输出对不对确认没问题再换成真实操作节点。这个小技巧看起来笨但非常管用。尤其是嵌套循环里内层变量引用容易出错靠日志输出能一眼看出内层拿到的 IP 到底是什么不用靠猜。另外循环体内可以加一个“本轮结果汇总”节点把每轮的成功/失败状态写入一个公共变量流程结束后统一查看。这样就不用翻几十个事件记录一份汇总列表就能看出哪些机器成功、哪些失败。循环流程创建本身不复杂复杂的是把边界想清楚、把变量传对、把失败策略定明白。我建议所有刚接触标准运维循环的同学都用“批量重启两台机器”这种极小规模的任务练一次手完整走一遍创建、执行、查看轮次事件、处理失败的过程。跑通一次之后你对循环节点的理解会完全不一样。