★ FEATURED ARTICLE 1. 从一个调度脚本的崩溃说起凌晨两点某数据平台的运维群里弹出一条告警核心报表任务卡在某个环节超过四十分钟下游十几个依赖任务全部挂起。值班的同事第一反应是去看那台跑任务的机器CPU、内存、磁盘都正常日志里也没有明显的报错任务就是不动。折腾了半小时才定位到问题——上游一个数据同步任务因为源端表结构变更失败了但调度系统没有把这个失败状态正确传递给下游导致下游任务一直在等一个永远不会到来的信号。这件事让我重新审视了调度系统里一个平时不太被重视的东西Workflow。很多人对它的理解停留在“把几个任务串起来按顺序跑”但真正在生产环境里跑过一段时间就会发现Workflow 的设计质量直接决定了整个数据链路的稳定性和可维护性。TDHTranswarp Data Hub作为一套完整的大数据平台它的 Workflow 组件承担着把散落在各处的计算任务、数据同步任务、脚本任务编排成一条可靠流水线的职责。这篇文章不打算复述官方文档而是想从一个实际使用者的角度把 TDH Workflow 的核心机制、设计思路、实操要点和踩过的坑讲清楚让正在用或者准备用这套东西的人少走点弯路。如果你手上有几十上百个任务需要按依赖关系调度如果你被“任务失败了但没人知道”“改了上游忘了改下游”“重跑一次要手动点十几个按钮”这类问题折磨过那这篇内容应该对你有用。我会从 Workflow 到底解决什么问题讲起然后拆解它的核心概念、依赖模型、参数传递、失败处理最后给出一套我在实际项目里验证过的编排规范。2. TDH Workflow 到底在解决什么问题2.1 裸写 crontab 的三种死法在没有 Workflow 之前大部分团队调度任务的方式就是 crontab 加一堆 shell 脚本。这种方式在任务数量少、依赖关系简单的时候确实够用但一旦规模上去就会以各种姿势出问题。第一种死法是时间依赖代替数据依赖。比如 A 任务每天凌晨一点跑B 任务两点跑因为“A 一般一小时能跑完”。结果某天 A 的数据量翻了三倍跑到两点半才结束B 在两点准时启动读到的是一份不完整的数据。这种问题最恶心的地方在于它不会报错只会静默地产生错误结果等你发现的时候可能已经错了好几天。第二种死法是失败无人知晓。crontab 跑一个脚本脚本里某一步失败了如果没有显式地检查退出码并做处理后面的步骤可能继续执行或者整个脚本静默退出而 crontab 本身不会告诉你任何东西。等到业务方来问“今天的报表怎么还没出”你才知道出事了。第三种死法是重跑成本极高。一个任务链有十几个环节中间某个环节失败了要重跑就得手动判断从哪一步开始、哪些需要清理、哪些可以复用。全靠人脑记迟早出错。TDH Workflow 的价值就在于把这三种死法都堵上了。它用依赖关系代替时间约定用状态管理代替人工盯守用可重跑的设计代替手工操作。2.2 Workflow 在 TDH 体系里的位置TDH 是一套覆盖数据存储、计算、分析全链路的平台里面有负责存储的、负责批处理的、负责流处理的、负责查询的各个组件。Workflow 不属于任何一个计算引擎它是横跨在这些组件之上的一层编排层。打个比方各个计算组件像是厨房里不同的厨具——有的负责切菜有的负责炒菜有的负责蒸煮。Workflow 就是那个统筹整个出菜流程的厨师长它不亲自切菜炒菜但它知道哪道菜要先做、哪道菜依赖哪道菜的半成品、哪道菜失败了要重新做。这个定位决定了 Workflow 的几个特点它要能调用各种类型的任务SQL 任务、脚本任务、数据同步任务等它要能感知每个任务的状态它要能根据状态决定下一步做什么。理解这一点后面很多设计上的取舍就都能想通了。2.3 什么样的场景该用 Workflow不是所有任务都需要 Workflow。我见过有人把两个简单的、没有依赖关系的定时脚本也塞进 Workflow 里结果配置的复杂度比脚本本身还高这就属于过度设计。我的判断标准是这样的如果任务之间存在数据依赖下游要用上游的输出或者存在数量上的规模超过十个任务需要统一管理或者存在失败重试的诉求不希望失败后从头再来那就值得用 Workflow。反过来如果只是几个互不相干的定时任务crontab 反而更轻便。还有一类场景特别适合 Workflow就是跨组件的流水线。比如从消息队列消费数据落到存储层然后在存储层做清洗清洗完再导入分析引擎做聚合最后把结果导出到目标库。这条链路跨越了多个组件用 Workflow 串起来之后任何一个环节出问题都能被捕获和重试整个链路的可观测性也上了一个台阶。3. 拆开 Workflow 的骨架核心概念逐个说透3.1 任务节点最小执行单元Workflow 里的基本单位是任务节点Node。一个节点代表一次具体的执行动作可以是一条 SQL、一个 shell 脚本、一次数据同步、一个存储过程调用等等。节点是调度的最小粒度Workflow 的状态管理、重试、日志都是围绕节点展开的。每个节点有几个关键属性需要关注。任务类型决定了这个节点用什么方式执行不同类型的节点在参数配置、资源申请、超时控制上都有差异。执行命令或脚本内容是节点的实际逻辑。超时时间是我特别想强调的一个属性很多人配置节点的时候不设超时结果一个卡死的任务能把整条链路拖到天荒地老。我的经验是超时时间应该设置为该任务正常执行时间的 2 到 3 倍既能容忍正常的波动又能在真正卡死时及时止损。节点还有一个容易被忽略的属性是重试策略。不是所有失败都值得重试。网络抖动导致的失败重试一下大概率能成功但如果是 SQL 语法错误重试一百次也没用只会浪费资源。所以重试次数和重试间隔要根据任务的性质来定后面我会专门讲这块。3.2 依赖关系Workflow 的灵魂如果说节点是 Workflow 的骨架那依赖关系就是让骨架动起来的关节。TDH Workflow 支持多种依赖类型理解它们的区别是正确编排的前提。最基础的是上游依赖也就是“我这个节点要等哪些节点成功之后才能跑”。这是最常用的依赖类型构建出来的是一张有向无环图。这里有个关键点依赖的是上游节点的成功状态而不是上游节点“跑完了”。上游失败或者被跳过下游默认是不会执行的这正是它比 crontab 时间依赖更可靠的地方。除了节点之间的依赖还有时间依赖比如“每天凌晨两点之后才能跑”。这种依赖通常用在链路的起点或者用在需要等待某个外部系统就绪的场景。时间依赖和上游依赖可以叠加使用表示“既要在两点之后又要等上游成功”。还有一种是跨 Workflow 的依赖。当业务复杂到一定程度一个 Workflow 装不下所有逻辑就会拆成多个 Workflow这时候就需要跨 Workflow 的依赖来串联。这种依赖配置起来要小心因为两个 Workflow 的调度周期如果不一致很容易出现死等的情况。3.3 调度周期与实例时间维度上的展开Workflow 定义好之后它本身只是一个模板。真正跑起来的是实例Instance。每个调度周期会产生一个实例比如一个每天调度一次的 Workflow每天都会生成一个当天的实例。这里有个概念叫业务日期是理解调度系统时间逻辑的关键。业务日期指的是这个实例“逻辑上属于哪一天”它和实例实际运行的时间是两回事。比如一个统计昨天销售额的任务它在今天凌晨运行但它的业务日期是昨天。很多新手会混淆这两个概念导致在 SQL 里用错时间条件统计出来的数据对不上。业务日期还影响依赖的匹配。当 A 节点依赖 B 节点时默认是“同一个业务日期的 B 节点”。如果两个节点的调度周期不同比如 A 是每天调度B 是每小时调度那依赖关系就需要特别配置指定 A 依赖 B 的哪个小时实例。这块是配置中最容易出错的地方之一我后面会专门展开。3.4 参数与变量让 Workflow 活起来如果 Workflow 里的每个节点都是写死的那它的复用价值就很有限。参数和变量机制让同一个 Workflow 模板可以适应不同的场景。TDH Workflow 里常见的变量有系统内置的比如业务日期、实例 ID 等也有用户自定义的。内置变量在写 SQL 的时候特别有用比如WHERE dt ${bizdate}这样的写法让同一条 SQL 在不同日期运行时自动处理对应日期的数据不需要每天改代码。自定义变量则用于传递一些业务相关的配置比如目标表名、阈值参数等。变量可以在 Workflow 级别定义也可以在节点级别覆盖还可以通过上游节点的输出动态生成。这个动态传递的能力很重要它让节点之间不仅能传递“成功/失败”的信号还能传递实际的数据实现更灵活的编排。4. 依赖编排的实战细节那些文档不会告诉你的坑4.1 同周期依赖与跨周期依赖的区别前面提到业务日期这里展开讲一个实际配置中绕不开的问题同周期依赖和跨周期依赖。假设你有一个每天调度一次的 Workflow里面有节点 A 和节点 BB 依赖 A。默认情况下今天这个实例的 B 依赖今天这个实例的 A这就是同周期依赖符合直觉。但现实往往更复杂。比如节点 A 是每小时跑一次的数据同步节点 B 是每天跑一次的汇总B 需要用到 A 当天所有小时的数据。这时候 B 依赖的就不是 A 的某一个小时实例而是 A 当天全部小时实例都成功。这种依赖在配置时需要指定依赖的周期范围和聚合方式配置错了就会出现“B 在 A 只跑了一部分小时的时候就启动了”这种问题算出来的汇总是残缺的。我的经验是凡是涉及不同调度周期的依赖一定要在配置完之后做一次依赖关系的可视化检查确认依赖的实例范围符合预期。TDH Workflow 提供了依赖视图能看到每个节点实际依赖了哪些上游实例这个功能在排查“任务为什么没跑”或者“任务为什么提前跑了”的时候特别有用。4.2 依赖成环一个必须提前避免的坑有向无环图这个名字里的“无环”不是随便说说的。一旦依赖关系里出现了环比如 A 依赖 BB 依赖 CC 又依赖 A整个调度就会陷入死锁所有节点都在等别人谁也不会启动。成环这个问题在小型 Workflow 里不容易出现但在几十个节点、依赖关系错综复杂的大型 Workflow 里稍不注意就可能绕出一个环。更麻烦的是成环有时候不是直接的而是间接的——你新加了一条依赖看起来只是 A 依赖 D但 D 通过一系列中间节点最终又依赖回了 A。我的做法是在 Workflow 设计阶段就画一张依赖图用纸笔或者工具都行把所有依赖关系可视化出来。每次新增依赖之前先在这张图上确认不会成环。TDH Workflow 在保存 Workflow 定义的时候也会做环检测但等到保存时才报错返工成本已经产生了不如提前规避。4.3 依赖失败时的传播行为上游节点失败之后下游节点会怎样这个问题看似简单但实际行为有好几种可能取决于配置。默认行为是下游节点不执行状态标记为“等待上游”或者类似的阻塞状态。这是最安全的做法避免了用错误的数据继续往下算。但有些场景下我们希望上游失败不影响下游比如上游是一个“尽力而为”的清理任务失败了也无所谓下游该跑还得跑。这时候就需要把依赖配置成“弱依赖”或者“忽略失败”。这个配置要慎用因为它打破了依赖的可靠性保证用之前一定要想清楚上游失败是否真的对下游没有影响。还有一种情况是上游被跳过比如因为条件判断不满足而没执行这时候下游的行为也需要明确。是当作成功继续跑还是当作失败阻塞这取决于业务逻辑。我的建议是对于关键数据链路宁可保守一点上游状态不明确时就让下游等着人工介入确认后再放行也不要让下游带着不确定性往下跑。4.4 依赖配置的检查清单每次配置完一个 Workflow 的依赖关系我都会过一遍下面这个清单能挡掉大部分低级错误检查项检查内容常见问题依赖方向上游是否真的是下游的数据来源依赖配反下游先于上游执行周期匹配上下游调度周期是否一致跨周期依赖未指定范围汇总数据残缺成环检测依赖图是否存在环间接依赖成环调度死锁失败传播上游失败时下游的预期行为弱依赖滥用错误数据向下游扩散时间依赖时间条件是否与业务日期匹配用错时间变量处理了错误日期的数据跨 Workflow跨 Workflow 依赖的周期是否对齐周期不一致导致死等这张表看起来简单但每一条背后都是真实踩过的坑。尤其是“周期匹配”和“时间依赖”这两条在涉及多周期、多业务日期的复杂场景里出问题的概率非常高。5. 参数传递与动态编排让流水线真正灵活起来5.1 内置变量的正确打开方式TDH Workflow 提供了一批内置变量用好了能省很多事。最常用的几个包括业务日期、实例时间、Workflow 名称等。这些变量在节点配置里用${变量名}的形式引用运行时会被替换成实际值。业务日期变量是使用频率最高的。写 SQL 的时候WHERE dt ${bizdate}这种写法几乎是标配。但这里有个细节要注意业务日期的格式。不同组件的日期格式要求可能不一样有的要yyyyMMdd有的要yyyy-MM-dd。如果格式不对SQL 不会报错但会查不到数据这种静默失败最难排查。我的习惯是在 Workflow 级别统一定义日期格式变量各个节点引用这个变量避免格式不一致。还有一个容易踩的坑是时区。业务日期的计算依赖于时区设置如果平台时区和业务预期不一致算出来的业务日期可能差一天。这个问题在跨时区协作的团队里尤其常见配置之前一定要确认清楚平台的时区设置。5.2 节点间传递动态参数内置变量解决的是“预定义”的参数但有些参数是运行时才能确定的。比如上游节点执行完一条查询得到一个最大值下游节点需要用这个最大值作为过滤条件。这种场景就需要节点间动态传参。实现方式通常是上游节点把结果写入一个约定的位置比如一张临时表、一个文件、或者调度系统的变量存储下游节点从那里读取。TDH Workflow 支持把节点的输出定义为变量供下游引用。这里的关键是约定要清晰。上游写出的格式、下游读取的格式必须严格一致否则解析会失败。我一般会在上游节点里加一段校验逻辑确保输出的格式符合预期如果不符合就主动让节点失败而不是把脏数据传给下游。宁可在这里失败也不要让错误的数据流下去因为下游可能已经基于错误数据做了很多计算追溯起来成本更高。5.3 条件分支与循环不是所有 Workflow 都是线性的。有些场景需要根据条件走不同的分支比如“如果今天的数据量超过阈值就走告警流程否则走正常处理流程”。TDH Workflow 支持条件分支节点根据上游节点的输出或者变量的值决定走哪条路径。条件分支配置的核心是条件表达式的正确性。表达式写错了可能永远走不到预期的分支。我的做法是条件分支的每个分支都加上明确的日志输出记录“因为什么条件走了这个分支”这样出问题的时候一眼就能看出判断逻辑是否符合预期。循环则用于处理“对一批数据逐个处理”的场景。比如有一个列表需要对列表里的每一项执行相同的操作。循环节点会遍历列表每次迭代执行一次子流程。循环要注意的是迭代次数和超时如果列表很大或者单次迭代很慢整个循环可能跑很久需要合理设置超时和并发度。5.4 参数传递的调试技巧参数传递出问题的时候排查起来往往比较麻烦因为参数是在运行时才确定的静态看配置看不出问题。我总结了几个调试技巧。第一在关键节点里加参数打印。把节点实际收到的参数值打印到日志里对比预期值很快就能定位是哪个环节传错了。第二用最小化复现。如果整个 Workflow 跑起来参数不对就单独抽出涉及参数传递的那几个节点构造一个最小的测试 Workflow逐步排查。第三注意变量的作用域。Workflow 级别的变量和节点级别的变量如果重名节点级别的会覆盖 Workflow 级别的。这个覆盖规则如果不清楚很容易出现“明明在 Workflow 级别改了变量怎么节点里还是旧值”的困惑。6. 失败处理与重跑生产环境最考验人的部分6.1 失败重试的策略设计任务失败是常态关键是怎么处理。TDH Workflow 支持节点级别的重试配置包括重试次数和重试间隔。但重试不是无脑配的要根据失败的类型来设计。我把失败分成三类。第一类是瞬时故障比如网络抖动、目标库短暂不可用。这类失败重试大概率能成功重试间隔可以短一点比如 1 到 5 分钟重试次数 2 到 3 次。第二类是资源竞争比如同时跑的任务太多导致资源不足。这类失败重试也可能成功但间隔要长一点给资源释放留出时间比如 10 到 30 分钟。第三类是逻辑错误比如 SQL 写错了、数据格式不对。这类失败重试多少次都没用应该快速失败并告警让人来修。如果给这类任务配了重试只会浪费时间和资源还延迟了告警的触发。所以我的做法是对每个节点评估它最可能出现的失败类型据此配置重试策略。对于不确定的宁可少重试、快告警也不要让一个逻辑错误的任务在后台默默重试几十次。6.2 重跑的正确姿势重跑是数据开发的家常便饭。但重跑不是简单地“再跑一次”里面有不少讲究。首先要明确重跑的范围。是只重跑失败的那个节点还是从失败节点开始往下全部重跑还是整个 Workflow 从头重跑这取决于失败的影响范围。如果失败节点的输出没有被下游消费那重跑这一个节点就够了。如果下游已经基于错误数据跑了那下游也得重跑。其次是数据的清理。重跑之前通常需要把上次跑产生的部分数据清理掉否则可能出现数据重复。清理的方式有几种按分区删除、按批次标记删除、或者用幂等写入覆盖。我倾向于让任务本身具备幂等性也就是同一个任务跑多次结果是一样的。实现幂等的方式包括用INSERT OVERWRITE代替INSERT INTO、用MERGE语句处理更新、或者在写入前先删除目标分区。幂等的任务重跑起来最省心不用担心数据重复。最后是重跑的触发方式。TDH Workflow 支持手动重跑和自动重跑。手动重跑适合需要人工确认的场景自动重跑适合明确的、可自动恢复的失败。我的建议是对于生产环境的核心链路默认用手动重跑让人确认一下再跑避免自动重跑把问题放大。6.3 补数据的场景与注意事项补数据是重跑的一个特殊场景不是重跑今天的数据而是补跑过去某几天的数据。比如发现过去一周的某个指标算错了需要重新计算这一周的数据。补数据比普通重跑复杂的地方在于依赖的处理。补跑历史数据时上游数据可能已经不存在了或者上游数据的保留周期已经过了。这时候要么先补上游要么确认上游数据还在。我遇到过好几次“补下游的时候发现上游数据已经被清理了”的情况只能从头补起工作量翻了好几倍。另一个注意点是补数据对下游的影响。补跑历史数据可能会覆盖下游已经产出的结果如果下游有对外提供的报表补数据期间报表数据会波动。所以补数据最好安排在业务低峰期并且提前通知相关方。6.4 告警配置的经验失败处理离不开告警。告警配得好问题能第一时间被发现配得不好要么漏报要么骚扰。我的告警配置原则是分级。核心链路的失败立即告警通过多种渠道比如即时通讯工具加短信。非核心链路的失败汇总后定时告警避免半夜被吵醒。可重试的瞬时故障如果重试成功了就不告警只有重试耗尽还失败才告警。告警内容也很重要。一条好的告警应该包含哪个 Workflow、哪个节点、什么时间失败、失败原因是什么、影响的下游有哪些。信息齐全的告警能让值班的人不用登录系统就能判断严重程度决定是否需要立即处理。还有一个技巧是告警收敛。如果一条链路上游失败导致下游十几个节点全部阻塞不要发十几条告警而是发一条汇总告警说明根因节点是哪个。否则告警风暴会淹没真正重要的信息。7. 一套可复用的 Workflow 编排规范7.1 命名规范让 Workflow 自解释命名看起来是小事但在几十上百个 Workflow 的环境里好的命名能省下大量沟通成本。我的命名规范是这样的Workflow 名称采用“业务域_数据层级_处理内容_调度周期”的结构比如“销售域_明细层_订单清洗_日”。这样一看名字就知道这个 Workflow 属于哪个业务、处理哪一层数据、做什么、多久跑一次。节点名称则采用“动作_对象”的结构比如“同步_订单表”“清洗_订单明细”“汇总_日销售额”。动作在前对象在后符合阅读习惯。变量命名统一用下划线分隔的小写字母避免大小写混用带来的困惑。日期相关的变量统一加_date后缀明确它的含义。7.2 分层设计把复杂链路拆开一个复杂的处理链路如果全部塞进一个 Workflow会变得难以维护。我的做法是分层把链路拆成几个职责清晰的 Workflow。通常分为三层接入层负责从源系统同步数据处理层负责清洗、转换、聚合输出层负责把结果导出到目标系统。层与层之间通过跨 Workflow 依赖串联。这样拆的好处是每一层可以独立调度、独立重跑。接入层出问题只需要重跑接入层处理层和输出层等接入层恢复后再跑。如果全在一个 Workflow 里重跑的时候很难只跑一部分。分层的另一个好处是复用。处理层的 Workflow 往往可以复用于多个数据源只要接入层把数据准备好了处理层的逻辑是一样的。7.3 幂等性设计重跑的底气前面提到过幂等性这里再展开说一下因为它是重跑可靠性的基础。实现幂等性的常见手段有几种。对于写入操作用INSERT OVERWRITE或者先DELETE再INSERT保证同一个分区不会被写两次。对于更新操作用MERGE语句根据主键判断是插入还是更新重复执行结果一致。对于有状态的操作比如累加要特别小心因为重复执行会导致重复累加。这种场景要么改成基于全量重算要么在累加前先减去上次的贡献。我在设计每个节点的时候都会问自己一个问题这个节点如果跑两遍结果和跑一遍一样吗如果答案是否定的就要想办法改造直到答案是肯定的。这个习惯让我在重跑的时候特别有底气不用担心数据被搞乱。7.4 监控与可观测性Workflow 跑起来之后你需要知道它跑得好不好。除了失败告警还应该关注一些运行指标。关键指标包括每个节点的执行时长对比历史发现异常变慢、Workflow 的整体耗时、失败率和重试率、资源使用情况。这些指标能帮你发现一些还没导致失败但已经不正常的情况比如某个任务越来越慢可能是数据量增长导致的需要提前优化。TDH Workflow 提供了运行历史的查看功能我习惯定期回顾一下最近一周的运行情况看看有没有异常的耗时波动。这种主动的监控比被动等告警更能发现问题。8. 几个真实场景的编排思路8.1 场景一跨组件的数据同步链路有一个典型的链路是从消息队列消费数据落到存储层然后在存储层做清洗清洗完导入分析引擎做聚合最后导出到目标库。这条链路跨越了消息队列、存储、分析引擎、目标库四个组件。编排思路是接入层一个 Workflow 负责从消息队列消费并落到存储层处理层一个 Workflow 负责清洗和聚合输出层一个 Workflow 负责导出。三层之间用跨 Workflow 依赖串联。这里的关键点是消费的幂等性。消息队列的消费如果重跑可能重复消费同一条消息。解决办法是在落存储层的时候做去重比如根据消息 ID 判断是否已经处理过。这样即使重跑也不会产生重复数据。8.2 场景二多周期依赖的汇总任务有一个日汇总任务依赖当天所有小时级的数据同步任务。小时级任务从零点到二十三点每小时跑一次。日汇总需要等所有小时任务都成功之后才能跑。编排思路是日汇总节点依赖小时任务的当天全部实例依赖配置里指定周期范围和聚合方式为“全部成功”。这样只要有一个小时任务没成功日汇总就会等待。这里要注意的是跨天的问题。二十三点的小时任务可能在第二天零点之后才跑完日汇总的调度时间要考虑到这一点不能设得太早。我一般把日汇总设在凌晨两点之后给小时任务留足缓冲。8.3 场景三带条件分支的告警流程有一个数据质量检查任务检查结果如果超过阈值就触发告警流程否则走正常处理流程。这是一个典型的需要条件分支的场景。编排思路是数据质量检查节点输出检查结果条件分支节点根据结果判断走哪条路径。告警路径触发告警通知正常路径继续后续处理。这里的关键是条件表达式的严谨性。阈值判断要考虑边界情况比如刚好等于阈值算不算超标。我的做法是在条件表达式里把边界情况写清楚并且在两个分支里都加日志记录判断的依据方便事后核对。9. 我在实际使用中总结的几条经验用了几年 TDH Workflow踩过的坑不少总结几条我觉得最有价值的经验。第一条依赖关系宁多勿少。不确定两个节点有没有依赖的时候先加上依赖。多加一条依赖最多是让任务多等一会儿少加一条依赖可能导致数据错误。数据错误的排查成本远高于等待的成本。第二条重试策略要区分对待。不要给所有节点配一样的重试策略要根据失败类型来定。逻辑错误快速失败瞬时故障适度重试这样既能提高成功率又不会掩盖真正的问题。第三条幂等性是重跑的底气。花时间把节点改造成幂等的重跑的时候就不用提心吊胆。这个投入是值得的尤其是在需要频繁补数据的场景下。第四条告警要分级收敛。核心链路立即告警非核心链路汇总告警根因告警优先于症状告警。好的告警配置能让值班的人快速定位问题而不是被一堆告警淹没。第五条定期回顾运行历史。不要只在出问题的时候才看 Workflow平时也要定期看看运行指标发现潜在的隐患。很多大问题都是从小异常积累起来的早发现早处理。最后分享一个小技巧给每个 Workflow 写一段简短的说明记录它的业务含义、依赖关系、重跑注意事项。这段说明在交接或者自己隔一段时间再看的时候特别有用能省下大量回忆的时间。Workflow 的配置本身是给机器看的这段说明是给人看的两者同样重要。
阅读完成 · 觉得有帮助？
