注意：说明：
注意：预计用时 90 分钟。学习目标：以一条生产数据管道的运维场景为例，端到端跑通 平台准备→ 告警与重试配置 → 实时监控 → 失败重跑与历史补数 → 根因排查 → 用量与容量管理 的完整运维链路。
一、场景介绍
·为新入职同事开通空间权限；
·在生产工作流上一次配置好告警、自动重试策略，避免漏报；
·凌晨任务失败时能第一时间收到告警，5 分钟内定位失败任务、决定重跑或补数；
·通过日志、智能诊断快速定位根因，并形成可分享给上下游的复盘；
本教程把这套工作完整跑一遍，所有路径都对齐工作空间内 平台管理、工作流、工作流运行 模块。
二、前提条件
在开始本教程前，请确保满足以下条件：
·已开通 DataBuddy 服务并完成空间初始化。
·当前账号在目标工作空间中拥有 空间成员 角色。
·已有至少一条 已发布且按天调度 的工作流（可使用 数据工程师快速上手 中产出的 quickstart_orders_etl）。该工作流应当在工作流运行中已有 ≥ 7 天的执行记录，便于演示历史趋势与补数。
·已准备好用于接收测试告警的邮箱、企业微信群机器人（或 Slack / Teams Incoming Webhook URL）。
三、教程贯穿场景
教程中的运维主线场景：
| 场景 | 说明 |
| 工作流 | quickstart_orders_etl，每天 00:00 跑，含 sync_mysql2dlc、pyspark_transform 两个任务。 |
| 接收告警的渠道 | 团队邮件 data-ops@example.com + 企业微信群机器人。 |
| 测试故障 | 故意把上游 MySQL 实例临时停机，让 sync_mysql2dlc 失败；故障恢复后练习重跑 + 补数。 |
四、步骤 1：开通成员并分配空间角色
新同事到岗，第一件事是把人加入到工作空间，并按职责给到对应权限。
五、1.1 把 CAM 子账号引入控制台
1. 登录 DataBuddy 控制台，在左侧导航选择 用户管理 > 用户 。
2. 单击 添加用户 ，选择需要添加的子账号。
3. 控制台角色 ：均选择 控制台成员 （仅可访问自己被加入的工作空间，不能创建新空间）。
4. 单击 添加 完成添加。
注意：仅 CAM 子账号可以被加入 DataBuddy。如下拉中找不到目标账号，请先到 CAM 控制台 创建。详见 成员与权限管理 。
六、1.2 邀请进入目标工作空间并分配角色
1. 进入目标工作空间，在左侧导航选择 工作空间 > 用户管理 > 用户 。
2. 单击添加用户 ，添加上一个步骤用户到工作空间，赋予空间成员角色（具备除空间管理之外的全部读写删权限）。
3. 单击添加，完成添加。
七、步骤 2：配置告警通知渠道
通知渠道是工作空间级的告警出口，所有支持告警的实体（工作流、任务、数据质量规则等）都共用这套渠道。
1. 进入 工作空间 > 通知管理 。
2. 单击 添加通知渠道 ，依次配置以下两个渠道：
八、2.1 配置邮件渠道
| 参数 | 取值 |
| 类型 | |
| 名称 | email_data_ops |
| 地址 | data-ops@example.com（多个邮箱用半角逗号分隔，不支持换行） |
单击 添加 保存。
九、2.2 配置企业 IM 渠道（Webhook / Slack / Teams 任选一种）
以企业微信群机器人为例，使用 Webhook 类型：
| 参数 | 取值 |
| 类型 | Webhook |
| 名称 | webhook_wechat_ops |
| URL | 群机器人在企业微信侧生成的 Incoming Webhook URL |
| 用户名 / 密码 | 一般留空，按机器人侧规则配置 |
如团队使用 Slack / Teams，请在对应平台先创建 Incoming Webhook，再在 DataBuddy 中选择对应类型填入 URL。详见 设置通知渠道 。
注意：通知渠道是 工作空间级配置，不跨空间共享 。如需在多个空间使用同一渠道，需在每个空间分别配置。删除渠道前请确认未被任何告警规则引用，删除后引用该渠道的告警将无法发送。
邮件渠道在工作空间配置后，告警时并不能直接引用，需要在告警渠道中手动输入。
十、步骤 3：为工作流配置告警与重试
将上一步配置的通知渠道挂到工作流上，再为关键任务加一道自动重试。
十一、3.1 配置工作流级告警
1. 在左侧导航选择 工作流 ，单击 quickstart_orders_etl 进入工作流详情页。
2. 在 监控指标 区域单击 添加 监控指标：
·指标 ：运行时长。
·警告阈值 ：01h00m00s（教程工作流正常 10 分钟内跑完，超过 1 小时即视为异常）。
·超时阈值 ：02h00m00s（超过 2 小时触发失败重试或置失败）。
3. 在 告警配置 中 配置告警：
·接收渠道 ：点击添加渠道，勾选个人邮箱，在输入框中输入email_data_ops的邮箱地址；勾选 Webhook 选择 webhook_wechat_ops。
·告警条件 ：勾选 失败 （默认必选）+ 监控指标 （用于超时告警）。
·免打扰 ：勾选 手动终止 （手动 Terminate 时不发告警，避免值班误报）。
4. 单击 确定 保存。
十二、3.2 为关键任务配置自动重试
1. 进入工作流，选择“任务编排”页签进入“工作流编辑器画布”，画布中单击 sync_mysql2dlc 任务节点。
2. 在任务配置面板找到 失败与超时策略 ：
| 参数 | 推荐值 | 说明 |
| 执行失败后重试 | 开 | 网络抖动 / 上游短暂不可达时自动恢复 |
| 超时后行为 | 触发重试 | – |
| 最大重试次数 | 3 | 重试 3 次仍失败再置失败 |
| 重试间隔 | 5 分钟 | 给上游足够恢复时间 |
3. 单击 确定 。
注意：说明：
注意：任务级告警与工作流级告警互不干扰 ：建议在工作流级配置「整体失败、整体超时」，在关键任务级别叠加「任务运行时长、等待时长、完成时间」告警，做到分层报警。详见 工作流与任务的告警 与 任务通用配置 的「失败与超时策略」。
十三、3.3 触发一次告警验证
为验证告警链路通畅，可手动构造一次失败：
1. 在工作流编辑器中临时把 sync_mysql2dlc 的数据源切到一个不存在的 MySQL 实例。
2. 单击工作流顶部 运行 。
3. 在 email_data_ops 邮箱与企业微信群中应在 1–2 分钟内收到告警通知。
4. 验证完成后回到任务配置，还原原数据源 并保存。
十四、步骤 4：在工作流运行中跟踪执行状态
工作流上线后，日常运维主要在 工作流运行 模块完成。
十五、4.1 查看运行列表，快速定位异常
1. 在左侧导航选择 工作流 > 工作流运行 。
2. 在顶部筛选条中：
·工作流名称 ：输入 quickstart_orders_etl。
·开始时间 ：默认近 3 天（可调到近 60 天）。
·运行账号 ：支持根据运行账号筛选。
3. 列表顶部图表区会展示：
·运行数量变化趋势图 ：按时间分组展示各状态运行数。
·错误码 ：单击错误码可一键筛选该错误码的运行实例。
十六、4.2 状态生命周期（重点对照）
工作流与任务有两套独立的状态机，建议熟悉以下高频状态：
工作流运行状态 ：
| 状态 | 含义 | 可执行操作 |
| 等待中 | 工作流排队中 | 终止 |
| 运行中 | 至少一个任务在运行 | 终止 |
| 成功 | 全部任务到达终态且无失败 | 重跑、删除 |
| 失败 | 全部任务到达终态且至少一个失败 | 重跑、删除 |
| 终止中 | 正在终止 | – |
任务运行状态 （含 12 种，常见 6 种）：
| 状态 | 含义 | 排障提示 |
| 等待上游 | 上游任务未到终态 | 先看上游状态 |
| 等待资源 | 等待调度 / 引擎资源 | 检查计算资源负载与 CU 配额 |
| 运行中 | 任务执行中 | – |
| 失败重试 | 失败后等待自动重试 | 看 步骤3.2 中设置的间隔 |
| 失败 | 终态，任务失败 | 进入根因排查（步骤6） |
| 上游失败 | 上游失败导致下游被跳过 | 先修复上游，再决定下游重跑范围 |
完整状态映射详见 工作流与任务的运行监控 。
十七、4.3 在三种视图间切换查看运行详情
单击任意 运行流 ID 进入运行详情页，可在左上角页签切换：
| 视图 | 适用场景 |
| 图模式（DAG） | 直观查看每个任务节点的状态颜色：绿/红/蓝/灰/黄。 |
| 列表模式 | 表格化展示所有任务的运行 ID、类型、时长、计算资源、源文件路径，支持按列排序。 |
| 甘特图 | 横向时间轴排列所有任务的开始-结束区间，最适合发现长尾任务与并发瓶颈 。 |
用甘特图找瓶颈 的三类典型现象：
·单一任务条过宽：长尾任务，看是否能拆分或加并发。
·多个任务首尾相接但本可并行：依赖关系冗余，回到工作流编辑器调整。
·任务间出现大段空白：等待资源或上游导致，关注 等待时长 指标。
十八、步骤 5：失败任务重跑与历史补数
排障的核心动作：把失败的实例修复并补齐数据。
十九、5.1 重跑当次失败的工作流运行
1. 在工作流运行详情页或运行列表行末单击 重跑 。
2. 弹窗中：
·DAG 图默认勾选所有失败节点 ，按住 Shift 单击节点可调整范围。
·参数 ：默认填入当次运行使用的参数值，可调整。
3. 单击 运行 触发重跑。
| 场景 | 推荐操作 |
| 上游修复后下游补跑 | 在 DAG 中勾选「失败任务 + 其下游」 |
| 单任务代码修复后局部跑 | 在任务运行详情页直接单击 重跑 ，仅勾选当前任务 |
| 配置错误想从头重跑 | 在工作流运行列表单击 重跑 ，DAG 中全选所有任务 |
注意：重跑使用 任务最新代码、最新配置 。依赖关系发生变更 时按钮会置灰，hover 提示「工作流中任务依赖关系发生变更，不支持重跑操作」——这种情况下需要新建一次工作流运行而非重跑历史实例。详见 工作流与任务的运维操作 。
20、5.2 历史日期补数（高级运行）
当历史数据缺失（例如调度新上线、近 3 天数据需重做），用 高级运行 按日期分别触发：
1. 在工作流详情页操作栏单击 高级运行 。
2. 弹窗中：
·左侧 DAG 图 ：默认全选；如仅需补特定任务，单击节点取消勾选。
·右侧 参数配置 ：把工作流参数中的 业务日期 （如 dp_data_dt）改为目标历史日期 2025-01-13。
·也可单击 + 添加参数 增加临时参数，仅对本次运行生效。
3. 单击 运行 提交一次。
4. 重复上面步骤，依次提交 2025-01-14、2025-01-15 等需要补的日期。
注意：说明：
注意：DataBuddy 的工作流调度按 工作流运行级别 触发；补数本质上就是「按指定参数手动触发 N 次运行」。如调度频率为每天一次，3 天补数提交 3 次即可；如为小时级，则按小时粒度补。详见 工作流与任务的运维操作 与 系统内置参数 。
21、5.3 终止异常运行
| 操作 | 入口 | 行为 |
| 终止单次运行 | 运行列表行末 终止 | 仅终止该次运行（运行中 / 等待中 / 失败重试可操作） |
| 全部终止 | 工作流详情页操作栏 | 终止当前工作流所有运行（含运行中和等待中），二次确认 |
| 终止全部等待中运行 | 工作流详情页操作栏 | 仅终止等待状态的运行，保护正在运行的实例 |
22、步骤 6：根因排查（识别原因）
收到告警后，定位根因建议遵循以下流程。本节以 pyspark_transform 任务失败为例。
23、6.1 进入任务运行详情页
1. 在 工作流 > 工作流运行 中找到失败实例，单击 运行流 ID 进入运行详情。
2. 在 图模式 中单击红色节点 pyspark_transform，跳转到任务运行详情页。
任务运行详情页提供 3个 Tab 和1个按钮：
| Tab/按钮 | 适用场景 |
| Tab-运行结果 | 任务代码与产出 |
| Tab-运行日志 | 错误码、错误信息、完整日志（最重要 ） |
| Tab-任务洞察 | 累计 CPU 时、扫描数据量、Shuffle、输出行数等性能指标 |
| 按钮-Spark UI | 跳转 Spark 原生 UI 排查算子级细节 |
24、6.2 三段式读日志
切换到 运行日志 Tab，按顺序检查三类信息：
| 阶段 | 找什么 |
| 等待上游 | 上游任务的依赖与状态 |
| 等待运行 | 资源排队情况、调度日志 |
| 任务运行 | 错误码 （如 RESOURCE_* / PERMISSION_* / DATA_* / CONFIG_* / TIMEOUT_*）+ 完整错误堆栈 + 提交的任务代码 |
操作技巧：
·搜索 框定位关键字（Error / Exception / 错误码）。
·自动换行 开关让长堆栈一屏看完。
·下载日志 把完整日志带离平台，配合内部知识库或工单提交。
25、6.3 用智能诊断快速判定故障类型
将鼠标 hover DAG 节点上或者在任务运行详情页单击 AI 诊断。详见 任务的智能诊断 。
26、6.4 故障分类的应急处置对照
| 错误码前缀 | 典型场景 | 应急处置 |
| RESOURCE_* | 资源不足、CU 排队、Driver OOM | 临时扩容计算资源；优化 Spark executor.memory、shuffle.partitions |
| PERMISSION_* | 数据源 / Catalog 权限缺失 | 在 数据源管理 或 数据目录 中确认 ACL，必要时申请权限 |
| DATA_* | 上游数据缺失 / 格式错误 | 先看上游数据源，确认补数链路 |
| CONFIG_* | 参数 / SQL 语法错误 | 在任务详情页 运行结果 中查看提交的代码与参数；与开发同学协同修改 |
| TIMEOUT_* | 任务超时 | 看「监控指标」中超时阈值是否合理，必要时优化代码或调高阈值 |
27、6.5 用血缘做影响分析
如失败任务的下游还有其他工作流，进入失败任务所属表的详情页（DataLakeCatalog.wedata_demo_db.quickstart_amazon_orders）切到 血缘 Tab：
·列表模式 ：快速列出当前表的一层上下游。
·图模式 ：从拓扑视角看清整条链路上还有谁会受影响。
详见 数据血缘 。
28、验证结果
完成全部步骤后，你应当能确认：
1. 成员与角色 ：analyst_alice 为空间成员、ops_bob 为空间管理员；用户组 data-ops-team 可批量管理。
2. 通知渠道 ：email_data_ops 与 webhook_wechat_ops 均出现在 通知管理 列表，且至少收到过一次测试告警。
3. 告警与重试 ：工作流级失败、监控指标告警均已挂渠道；sync_mysql2dlc 任务的失败重试策略为 3 次 × 5 分钟。
4. 失败重跑、补数 ：能用 重跑 修复单次失败；能用 高级运行 按日期补数 3 天。
5. 根因排查 ：能在任务运行详情页 5 分钟内定位错误码、读取关键堆栈、识别故障分类。
29、总结
在本教程中，你完成了：
·在 工作空间 中按 空间角色 + ACL 双层模型 接入新成员并完成权限分配。
·在 通知管理 中接入邮件与 IM 渠道，做到统一出口、跨场景复用。
·在工作流与任务上分层配置 告警、自动重试、监控指标阈值 。
·在 工作流运行 中熟练使用 DAG / 列表、甘特图 三种视图，理解 12 种任务状态。
·用 重跑、高级运行 完成失败修复与历史补数。
·用 运行日志、智能诊断、数据血缘 三件套定位根因并形成复盘文档。
本条端到端运维链路覆盖了运维 / SRE 岗位日常 80% 以上的高频操作。后续可继续探索：实时接入任务运维、数据质量阻塞链路、CI/CD 流水线、计量计费控制等进阶能力。