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