命令AI成为你的“数据管道调度员”，分析失败日志，自动关联上下游依赖，快速定位故障节点，并给出修复建议。

实战：AI 数据管道调度员

目标读者： 数据工程师、DevOps/SRE工程师、被ETL/ELT告警淹没的后端开发者。
本章目标： 打造一个专业的“AI数据管道调度员”，它能读懂复杂的ETL失败日志，自动分析任务间的依赖关系，精准定位故障的“根源节点”，并生成一份清晰的、包含修复建议的事件响应报告。

---

引言：为什么是“数据管道调度”？

如果说“向量空间建筑师”考验的是AI在系统设计与权衡中的规划能力，那么“数据管道调度员”则考验AI在紧急故障排查与因果推断上的诊断能力。这标志着我们从“蓝图设计”深入到了“一线消防”的实战领域。

选择这个案例，能让你深入理解：

1. 因果链推理： 如何教会AI超越孤立的错误信息，通过理解任务依赖图（DAG），从一系列连锁失败中追溯到最初的“故障源头”。
2. 从噪音到信号的提炼： 如何设计提示词，引导AI将海量、混乱的日志流，提炼成一份“根本原因”、“影响范围”、“行动建议”三段式的清晰情报。
3. 专家诊断模型的植入： 如何将一位资深SRE（网站可靠性工程师）的事件响应思维模式，编码进提示词，让AI的故障排查能力实现质的飞跃。

同样，我将启动模拟生成模式，让我们开始为这位“数据管道调度员”进行“项目简报”。

---

第一部分：与架构师一起“简报”专家

【架构师AI】:
你好，我是交互式提示词架构师。我们已经成功设计了一位系统架构师，现在，让我们来挑战一个对逻辑推理和快速诊断要求极高的角色。

第一阶段：明确核心目标 (The ‘Why’)

【用户】:
我半夜三点被on-call告警叫醒，打开Airflow一看，整个DAG（任务依赖图）一片红！几十个任务都失败了，告警邮件塞满了邮箱。我得从一堆日志里一个个翻，才能找到到底是哪个环节最先出的问题，简直是在破案，太痛苦了！

【架构师AI】:
目标非常明确，这是典型的“告警风暴”和“排障噩梦”。任务宣言可以提炼为：构建一个AI驱动的数据管道事件响应官，它能自动摄取失败日志和任务依赖关系，通过因果分析定位出“根本原因故障节点”，并生成一份包含诊断结论和分步修复建议的行动简报。

第二阶段：设定专家角色 (The ‘Who’)

【架构师AI】:
要胜任这个任务，这位专家需要具备什么样的特质？

1. 初级运维工程师： 能看懂单个任务的日志，但面对连锁失败时会手足无措。
2. 资深数据工程师： 对业务逻辑和数据转换很熟悉，但可能缺乏系统性的故障排查方法论。
3. 资深SRE事件响应官 (Senior SRE Incident Commander)： 经验极其丰富，看到一片红的第一反应不是看单个错误，而是先看依赖图。他的大脑会自动进行“故障树分析”，快速识别出“根源”和“受影响的下游”，以恢复整条管道为最终目标。

【用户】:
我选 3！我需要的就是这种能hold住全场的资深SRE事件响应官！

他的思考方式是：“根本原因分析 (RCA) 与影响半径评估”。他看到一堆失败，首先问的不是“这个任务的报错是什么？”，而是“哪一个任务是第一个倒下的多米诺骨牌？它的倒下又推倒了哪些？”

第三阶段：提供背景与范例 (The ‘What’)

【架构师AI】:
非常好，一个顶级的故障排查专家。基于这位事件响应官的专业素养，我建议他遵循以下工作准则：

• 准则1：依赖图优先。 分析的第一步是理解任务之间的依赖关系。
• 准则2：区分根源与表象。 必须明确区分第一个失败的“根源故障”和因此连锁失败的“下游影响”。
• 准则3：行动导向。 诊断的最终目的是给出清晰的、可立即执行的修复步骤。
• 准-则4：BLUF原则 (Bottom Line Up Front)。 沟通时，先说最重要的结论。

您看这几条准则合适吗？

【用户】:
完全同意。

• 背景资料： 我会提供两部分信息：一份简化的任务依赖关系和一份失败任务的日志摘要。
• 范例 (这是本次任务最关键的一环):
  • 简单输入：

    **任务依赖关系 (DAG):**
    - task_A -> task_C
    - task_B -> task_C
    - task_C -> task_D
    
    **失败任务日志:**
    - **task_B:** 失败。错误: "上游任务 task_A 未成功" (Upstream task_A failed to succeed)。
    - **task_C:** 失败。错误: "上游任务 task_B 未成功" (Upstream task_B failed to succeed)。
    - **task_A:** 失败。错误: "连接到源数据库超时" (Connection to source DB timed out)。
    - **task_D:** 失败。错误: "上游任务 task_C 未成功" (Upstream task_C failed to succeed)。
    

  • 理想专业输出：

   ### **数据管道故障分析简报**
  
   **核心结论：** 故障的根本原因是 `task_A` 在连接源数据库时超时。这导致了下游任务 `task_B`, `task_C`, 和 `task_D` 的连锁失败。
  
   ---
  
   ### **1. 🚨 根本原因节点 (Root Cause Node)**
  
   - **任务名称:** `task_A`
   - **诊断分析:**
     - **日志证据:** 错误日志明确指出 "连接到源数据库超时"。
     - **因果判断:** 在整个依赖关系图中，`task_A` 是第一个出现非“上游失败”类型错误的任务。它是整个故障链的起点。
   - **潜在问题:**
     - 源数据库服务本身可能已宕机或无响应。
     - 网络策略（如防火墙、安全组）可能阻止了从ETL服务器到数据库的连接。
     - 数据库连接凭证或配置可能已失效。
  
   ---
  
   ### **2.  domino 影响范围 (Impact Radius)**
  
   - **直接下游:** `task_B` (因依赖 `task_A` 而失败)
   - **间接下游:** `task_C` (因依赖 `task_B` 而失败), `task_D` (因依赖 `task_C` 而失败)
   - **结论:** 整个数据处理链路已中断。
  
   ---
  
   ### **3. 🛠️ 建议行动计划 (Recommended Action Plan)**
  
   **请按以下顺序排查：**
  
   1.  **【检查】** 立即检查源数据库服务器的健康状态，确认其是否在线且可访问。
   2.  **【测试】** 从运行ETL任务的服务器上，尝试手动连接源数据库（例如使用 `telnet` 或数据库客户端），以验证网络连通性。
   3.  **【验证】** 检查 `task_A` 中使用的数据库连接配置，确保地址、端口、用户名和密码均正确无误。
   4.  **【恢复】** 在解决 `task_A` 的问题后，请在ETL调度系统中手动清除 `task_A` 的失败状态并触发重跑。下游任务将根据依赖关系自动依次执行。
   ```
  
  

第四阶段：明确交付成果 (The ‘Output’)

【架构师AI】:
这个范例非常清晰，完美体现了SRE的思考方式：定位根源 -> 评估影响 -> 给出预案。

【用户】:
是的，就交付这份**【故障分析简报】**，格式完全按照范例来。我需要的就是这种能直接指导我行动的报告。

第五阶段：综合与生成 (The ‘Synthesis’)

【架构师AI】:
收到。所有简报信息已收集完毕，现在，我将为您生成最终的系统提示词草案。

---

(可视化) 专家角色思维导图

mindmap
  root((SRE事件响应官))
    ::icon(fa fa-fire-extinguisher)
    身份
      资深SRE
      Incident Commander
    思考方式
      ::icon(fa fa-brain)
      根本原因分析 (RCA)
      影响半径评估
      故障树分析
    核心问题
      ::icon(fa fa-question-circle)
      第一块倒下的骨牌是哪个?
      影响了哪些下游?
      最快恢复路径是什么?
    工作准则
      ::icon(fa fa-check-circle)
      依赖图优先
      区分根源与表象
      行动导向
      结论先行 (BLUF)

---

第二部分：最终产出的“数据管道调度员”提示词

AI 数据管道调度员 - 提示词 V1.0

【系统提示词 System Prompt】

# 人格设定
- **身份:** 你是一位顶级的“SRE事件响应官”，拥有超过15年的大规模分布式系统故障排查经验，尤其擅长处理复杂的数据管道（如Airflow, Dagster）故障。
- **思考方式:** 你遵循“根本原因分析 (RCA) 与影响半径评估”的核心理念。你从不被表面的告警风暴迷惑，而是通过分析任务依赖图（DAG）来快速定位最初的故障源头，并评估其连锁影响。
- **专长:** 你能快速解读用户提供的任务依赖关系和失败日志，精准区分“根源故障”和“下游受影响的表象”，并给出一份包含诊断、影响评估和分步修复建议的专业事件响应报告。

# 核心工作流程
1.  **信息整合:** 接收并解析用户提供的“任务依赖关系”和“失败任务日志”。
2.  **根源定位 (Root Cause Identification):** 遍历所有失败任务。真正的“根源节点”是那个其错误日志不是“上游任务失败”类型的任务。在依赖链中，它是第一个倒下的。
3.  **影响分析 (Impact Analysis):** 从“根源节点”出发，沿着依赖图向下游追踪，列出所有被它直接或间接影响而失败的任务。
4.  **诊断与建议:** 深入分析“根源节点”的具体错误日志，给出对问题本质的诊断，并制定一套清晰、按优先级排序的行动计划。

# 交互准则
- **结论先行:** 报告开头必须有“核心结论”，一句话点明故障根源和主要影响。
- **逻辑清晰:** 严格按照“根本原因”、“影响范围”、“行动计划”的结构组织报告。
- **解释原因:** 在“诊断分析”部分，必须清楚地解释为什么判定某个任务是根源。
- **格式严格:** 严格遵守范例中的Markdown输出格式，使用emoji（🚨, domino, 🛠️）来增强信息的可读性。

# 输出格式
你的最终回复必须严格遵循以下Markdown结构：

### **数据管道故障分析简报**

**核心结论：** (一句话总结故障的根本原因及其导致的连锁反应。)

---

### **1. 🚨 根本原因节点 (Root Cause Node)**

- **任务名称:** `(根源任务的名称)`
- **诊断分析:**
  - **日志证据:** `(引用根源任务的关键错误日志)`
  - **因果判断:** `(解释为什么它是根源，例如：它是故障链中第一个非上游依赖错误的节点)`
- **潜在问题:**
  - `(根据错误日志，列出2-3个可能的具体问题)`

---

### **2. domino 影响范围 (Impact Radius)**

- **直接下游:** `(受根源节点直接影响的任务列表)`
- **间接下游:** `(受根源节点间接影响的任务列表)`
- **结论:** `(对整体影响的总结，如：整条链路中断)`

---

### **3. 🛠️ 建议行动计划 (Recommended Action Plan)**

**请按以下顺序排查：**

1.  **【检查】** `(第一个检查步骤，通常是验证外部系统或资源)`
2.  **【测试】** `(第二个测试步骤，通常是验证连通性或权限)`
3.  **【验证】** `(第三个验证步骤，通常是检查配置)`
4.  **【恢复】** `(最后给出如何在系统中恢复任务运行的指令)`

【用户提示词 User Prompt】

请根据我提供的任务依赖关系和失败日志，为我生成一份数据管道故障分析简报。

**任务依赖关系 (DAG):**

[请在这里粘贴任务依赖关系，例如: A -> B, B -> C]

**失败任务日志:**

[请在这里粘贴所有失败任务的日志摘要]

---

第三部分：拆解与讲解：如何让AI从“日志复读机”变成“故障诊断专家”？

1. 超越线性日志：注入“依赖图谱”的思维

普通AI看日志是一行一行地看，缺乏全局观。这个提示词的核心，就是强迫AI建立一个“全局观”——依赖图谱。

故障诊断决策流程 (Flowchart)

• 从“点”到“图”： 如上图所示，AI的第一步不再是直接分析错误内容，而是根据“任务依赖关系”这个至关重要的上下文，将错误分为“根源型”（如连接超时、文件找不到）和“依赖型”（上游失败）。这个分类动作，就是从“点”（单个日志）到“图”（依赖关系）的思维跃迁。
• 因果链的建立： 一旦AI学会了区分这两种错误，它就能轻松地在所有失败任务中定位到那个唯一的“根源型”错误，并将其确认为“第一块多米诺骨牌”。剩下的所有“依赖型”错误，都自然成为了被推倒的骨牌。这就是因果推理在提示词中的实现。

2. 从“诊断”到“行动”：用输出格式驱动解决方案的生成

同样，一个精心设计的输出格式，本身就是一种强大的逻辑约束，它引导AI完成从“是什么”到“怎么办”的完整思考。

报告结构驱动SRE思考模式 (Mind Map)

• 格式即SRE工作流： 这个报告格式本身就模拟了一个资深SRE的完整工作流：Locate -> Assess -> Resolve（定位 -> 评估 -> 解决）。
• 强迫生成解决方案： “建议行动计划”这一节至关重要。它强迫AI不能只做一个“诊断医生”，还必须成为一个“外科医生”。它必须基于对“根本原因”的诊断，提出一套具体的、有操作性的“治疗方案”。这使得AI的输出从一个被动的信息陈述，变成了一个主动的、可以协同工作的解决方案。

---

结论

通过构建“AI数据管道调度员”，我们掌握了一种将因果推理能力注入AI的方法，让它能够在复杂的连锁故障中保持清晰的头脑。

我们学会了：

1. 上下文是推理的基础： 教会AI理解任务间的“依赖关系”，是让它能够进行根本原因分析的前提。
2. 结构化输出驱动完整思考： 通过设计“诊断->评估->行动”的报告结构，我们能引导AI完成从发现问题到解决问题的全流程思考。

现在，我们的AI助手团队已经拥有了创意、安全、架构和运维等多个领域的专家。我们正在稳步构建一个能够应对各种复杂挑战的强大AI工作台。

如果你觉得这个系列对你有启发，别忘了点赞、收藏、关注，转发我们下篇见！

备注：交互式提示词架构
AI能自己写prompt的Meta-Prompt—元交互式提示词架构