嵌套执行的排查之苦用 OOS系统运维管理跑过批量运维任务的同学大概都经历过这样的场景模板执行失败了打开控制台查看执行详情StatusMessage 写着 failures exceeded MaxErrors——这句话告诉你有东西失败了但没告诉你到底是什么东西、为什么失败。OOS 支持嵌套执行。一次顶层的 CICD 流水线执行内部可能调用部署阶段的子执行子执行里又可能调用 ACS::ROS::CreateStack 这样的叶子任务。真正的报错信息往往藏在第二层甚至第三层子执行的 StatusMessage 里。要定位它你得在控制台手动展开子执行列表找到 StatusFailed 的那一条点进去再看——如果还是通用报错继续往下一层翻。三层嵌套就是三轮翻找最后看到的往往是一个需要再去查文档的 API 错误码。这个过程没有技术难度但足够枯燥嵌套层级一多还容易看漏。我们把这套流程写成了一个技能交给 OOS 控制台内置的 ChatOps Agent 去跑。ChatOps Agent控制台里的对话式运维入口ChatOps Agent 是 OOS 控制台内置的对话式运维能力。使用方式很直接在控制台进入 ChatOps 入口选择一个技能然后用自然语言和 Agent 对话Agent 就会按照技能定义的流程去完成对应的运维动作。这里的技能是一份结构化的 SOP 文档规定了 Agent 该收集什么信息、调用哪些 API、按什么逻辑判断、以什么格式输出结果。不同技能对应不同运维场景——本文聚焦的「OOS 执行诊断」就是其中之一专门解决执行失败了帮我看看为什么这个问题。和手动翻控制台相比区别不只是少点几下鼠标。Agent 的价值在于它把排查逻辑固化了什么时候该下钻、什么时候当前信息已经够用、报告怎么写才能直接指导下一步动作——这些判断不再依赖排查人当时的经验和耐心。实操丢一个执行 ID 过去使用只需要两步在 ChatOps 对话窗口选择「OOS 执行诊断」技能然后告诉 Agent 你要排查的执行 ID。Region 可以指定不指定默认查 cn-hangzhou。一段典型的对话长这样你帮我诊断执行 exec-xxxxxx地域 cn-wulanchabuAgent查询顶层执行发现 StatusMessage 是通用的 “failures exceeded MaxErrors”判断无法直接定位开始下钻子执行Agent逐层递归最终在叶子级执行拿到具体的资源栈创建报错Agent输出诊断报告——报错原因执行失败是因为创建资源栈时传入的参数不符合约束条件具体为 InstanceType 指定了当前可用区不支持的规格……建议方案将 InstanceType 更换为目标可用区支持的规格可通过 DescribeAvailableResource 查询修改模板参数后重新发起执行用户侧的体感就是给一个执行 ID拿回一份为什么失败 怎么修的结构化报告。至于中间翻了几层子执行、调了几次 API那是 Agent 的事。当然如果顶层执行的 StatusMessage 本身就足够具体——比如直接写了 InstanceNotFound 或者某个权限错误码——Agent 不会画蛇添足去下钻直接基于当前信息出报告。原理查询、下钻、出报告技能的核心依赖是一个 OOS OpenAPIListExecutionsAgent 通过阿里云 CLI 调用它。整个诊断分三个阶段。第一阶段收集信息。 确认执行 ID 和地域。只需要终态执行Success / Failed / Cancelled才能完整诊断还在 Running 的执行会直接告知用户稍后再查。第二阶段查询与下钻。 先查顶层执行的状态和 StatusMessage然后做一个关键判断——当前信息够不够定位根因。如果 StatusMessage 里已经包含具体的错误码、资源 ID 或异常描述就地诊断只有当错误信息是failures exceeded MaxErrors、child execution failed这类通用描述时才启动递归下钻用 --ParentExecutionId 查出所有直接子执行找到 Failed 分支看它的 StatusMessage 是否足够具体不够就继续往下钻直到叶子节点。典型的三层下钻路径exec-topCICD 流水线failures exceeded MaxErrors └─ exec-child部署阶段仍是 failures exceeded MaxErrors └─ exec-leafACS::ROS::CreateStack具体 ROS 报错← 根因在这里第三阶段分析与报告。 拿到根因后Agent 结合常见失败模式权限不足、资源不存在、参数无效、依赖超时等进行分析输出固定两段式报告「报错原因」从用户视角直接说明为什么失败「建议方案」给出编号的可操作步骤。报告语言跟随用户提问语言——中文问就是中文报告英文问就是英文报告。权限方面技能只依赖一个 RAM Actionoos:ListExecutions配置门槛很低。边界与说明说几个诚实的边界。其一只有到达终态的执行才能完整诊断。还在 Running 或 Waiting 的执行Agent 只会告诉你尚未结束稍后再查不会硬猜。其二诊断质量取决于 StatusMessage 的质量。如果叶子执行的报错信息本身就含糊Agent 能做的就是帮你缩小到是这一步出了问题再精确的结论需要结合日志进一步排查。其三当前支持单条执行 ID 的诊断。把今天的失败执行全部排查一遍这种批量场景暂未覆盖。如果你曾经被嵌套执行的排查折磨过下次不妨直接把执行 ID 丢给 ChatOps Agent 试试。
一句话定位 OOS 执行失败：ChatOps Agent 执行诊断技能实践
嵌套执行的排查之苦用 OOS系统运维管理跑过批量运维任务的同学大概都经历过这样的场景模板执行失败了打开控制台查看执行详情StatusMessage 写着 failures exceeded MaxErrors——这句话告诉你有东西失败了但没告诉你到底是什么东西、为什么失败。OOS 支持嵌套执行。一次顶层的 CICD 流水线执行内部可能调用部署阶段的子执行子执行里又可能调用 ACS::ROS::CreateStack 这样的叶子任务。真正的报错信息往往藏在第二层甚至第三层子执行的 StatusMessage 里。要定位它你得在控制台手动展开子执行列表找到 StatusFailed 的那一条点进去再看——如果还是通用报错继续往下一层翻。三层嵌套就是三轮翻找最后看到的往往是一个需要再去查文档的 API 错误码。这个过程没有技术难度但足够枯燥嵌套层级一多还容易看漏。我们把这套流程写成了一个技能交给 OOS 控制台内置的 ChatOps Agent 去跑。ChatOps Agent控制台里的对话式运维入口ChatOps Agent 是 OOS 控制台内置的对话式运维能力。使用方式很直接在控制台进入 ChatOps 入口选择一个技能然后用自然语言和 Agent 对话Agent 就会按照技能定义的流程去完成对应的运维动作。这里的技能是一份结构化的 SOP 文档规定了 Agent 该收集什么信息、调用哪些 API、按什么逻辑判断、以什么格式输出结果。不同技能对应不同运维场景——本文聚焦的「OOS 执行诊断」就是其中之一专门解决执行失败了帮我看看为什么这个问题。和手动翻控制台相比区别不只是少点几下鼠标。Agent 的价值在于它把排查逻辑固化了什么时候该下钻、什么时候当前信息已经够用、报告怎么写才能直接指导下一步动作——这些判断不再依赖排查人当时的经验和耐心。实操丢一个执行 ID 过去使用只需要两步在 ChatOps 对话窗口选择「OOS 执行诊断」技能然后告诉 Agent 你要排查的执行 ID。Region 可以指定不指定默认查 cn-hangzhou。一段典型的对话长这样你帮我诊断执行 exec-xxxxxx地域 cn-wulanchabuAgent查询顶层执行发现 StatusMessage 是通用的 “failures exceeded MaxErrors”判断无法直接定位开始下钻子执行Agent逐层递归最终在叶子级执行拿到具体的资源栈创建报错Agent输出诊断报告——报错原因执行失败是因为创建资源栈时传入的参数不符合约束条件具体为 InstanceType 指定了当前可用区不支持的规格……建议方案将 InstanceType 更换为目标可用区支持的规格可通过 DescribeAvailableResource 查询修改模板参数后重新发起执行用户侧的体感就是给一个执行 ID拿回一份为什么失败 怎么修的结构化报告。至于中间翻了几层子执行、调了几次 API那是 Agent 的事。当然如果顶层执行的 StatusMessage 本身就足够具体——比如直接写了 InstanceNotFound 或者某个权限错误码——Agent 不会画蛇添足去下钻直接基于当前信息出报告。原理查询、下钻、出报告技能的核心依赖是一个 OOS OpenAPIListExecutionsAgent 通过阿里云 CLI 调用它。整个诊断分三个阶段。第一阶段收集信息。 确认执行 ID 和地域。只需要终态执行Success / Failed / Cancelled才能完整诊断还在 Running 的执行会直接告知用户稍后再查。第二阶段查询与下钻。 先查顶层执行的状态和 StatusMessage然后做一个关键判断——当前信息够不够定位根因。如果 StatusMessage 里已经包含具体的错误码、资源 ID 或异常描述就地诊断只有当错误信息是failures exceeded MaxErrors、child execution failed这类通用描述时才启动递归下钻用 --ParentExecutionId 查出所有直接子执行找到 Failed 分支看它的 StatusMessage 是否足够具体不够就继续往下钻直到叶子节点。典型的三层下钻路径exec-topCICD 流水线failures exceeded MaxErrors └─ exec-child部署阶段仍是 failures exceeded MaxErrors └─ exec-leafACS::ROS::CreateStack具体 ROS 报错← 根因在这里第三阶段分析与报告。 拿到根因后Agent 结合常见失败模式权限不足、资源不存在、参数无效、依赖超时等进行分析输出固定两段式报告「报错原因」从用户视角直接说明为什么失败「建议方案」给出编号的可操作步骤。报告语言跟随用户提问语言——中文问就是中文报告英文问就是英文报告。权限方面技能只依赖一个 RAM Actionoos:ListExecutions配置门槛很低。边界与说明说几个诚实的边界。其一只有到达终态的执行才能完整诊断。还在 Running 或 Waiting 的执行Agent 只会告诉你尚未结束稍后再查不会硬猜。其二诊断质量取决于 StatusMessage 的质量。如果叶子执行的报错信息本身就含糊Agent 能做的就是帮你缩小到是这一步出了问题再精确的结论需要结合日志进一步排查。其三当前支持单条执行 ID 的诊断。把今天的失败执行全部排查一遍这种批量场景暂未覆盖。如果你曾经被嵌套执行的排查折磨过下次不妨直接把执行 ID 丢给 ChatOps Agent 试试。
