1. 别被“调度”两个字唬住：先搞清楚 Flink 作业的一生
做 Flink 开发的，几乎都遇到过这种场面：集群资源看着还有一大堆，结果提交作业就是起不来；或者作业跑得好好的，某天夜里突然挂了，重启之后状态怼不上，数据对不齐，领导在群里连环问。这种时候，SR 一般第一反应是查日志、看监控，但真正追根溯源的时候，往往都会落到一个绕不开的底层话题——Flink Jobs and Scheduling。说白了，就是作业从提交到运行再到失败恢复，资源是怎么分配的、任务是怎么被调度起来的、挂了以后又是怎么被捞回来的。
这篇文章不打算给你搬教科书上的概念，也不堆术语。我想从实际排查问题的角度，把 Flink 资源调度和失败恢复这条线完整捋一遍，说清楚作业从提交到挂掉再到恢复的完整链路。不管是刚开始学 Flink 的菜鸟，还是已经写了几年 SQL 但没仔细抠过底层的老手，这篇文章的思路都适用。看完之后你能知道：为什么作业卡在 SUBMITTED 起不来，为什么 Slot 明明有剩余但作业就是跑不满，为什么 Checkpoint 频繁失败，以及作业挂了以后 Flink 是怎么决定要不要重启、从哪儿恢复的。
我尽量用大白话拆解，但涉及的机制会比较深。建议你按顺序读，别跳，因为调度和恢复这两件事是强关联的——调度层面决定了任务怎么摆，恢复层面决定了任务摆错了之后怎么办。
2. 一张完整的调度路径图：从提交到运行的每一步
2.1 作业提交后到底发生了什么
先直接给结论：一个 Flink 作业从你点击提交或者执行 flink run 开始，背后会经历这么一条链路：用户代码 -> StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行。这条链路你只要记住，后面所有调度相关的问题都从这里面展开。
详细拆一下。用户写的 DataStream 或者 Table/SQL 代码，经过编译后会先形成一个 StreamGraph，这玩意儿本质上是逻辑层面的算子拓扑，里面的节点叫 StreamNode，边叫 StreamEdge。它描述的是“计算逻辑长什么样”，跟并行度、资源还没完全挂钩。
接着 Flink 会做一个关键操作：把 StreamGraph 转成 JobGraph。这个转换过程做的事情很多，最核心的是算子链优化（Operator Chaining）。两个相邻的算子如果能满足条件——比如分区方式相同、并行度相同、没有 keyBy 之类的重分区操作——就会被合并到一个 OperatorChain 里，形成 JobVertex。这一步直接影响后续的资源分配：合并得越多，需要的 Slot 就越少，网络传输开销也越低。实际生产中，经常遇到“并行度调高了反而变慢”的怪现象，很多时候就是算子链被拆散，导致任务被调度到不同 TaskManager 后走了一遍序列化和反序列化。
JobGraph 会被提交给 JobManager。到了这里，真正的调度才开始。JobGraph 里的节点会继续被展开成 ExecutionGraph，这是调度层面的核心数据结构。一个 JobVertex 展开成多个 ExecutionVertex，每个 ExecutionVertex 对应一个并行子任务，ExecutionVertex 之间通过 ExecutionEdge 相连，代表数据流转关系。
2.2 调度器的工作方式：两种模式的取舍逻辑
ExecutionGraph 生成之后，接下来问题就变成了：这些 ExecutionVertex 怎么分配到 TaskManager 的 Slot 上，以及什么时候分配。
在 Flink 1.5 之前，调度逻辑写死在 JobManager 里，调整起来非常费劲。从 1.5 开始引入了 Scheduler 接口，并且默认实现了两种调度模式：Eager Scheduling 和 Lazy From Sources Scheduling。
Eager 模式下，作业一提交到 JobManager，调度器就会把整个 ExecutionGraph 里的所有 ExecutionVertex 一次性申请资源，全部拿到 Slot 之后才开始部署任务。好处是作业启动之后不容易因为资源不足而中途失败，适合对实时性要求高、作业规模不大的场景。坏处也很明显：如果集群资源不够，整个作业就完全起不来，哪怕你的作业逻辑上可以先跑一部分任务。
Lazy 模式正好相反，它从 Source 节点开始，先申请部分资源部署上游任务，然后随着数据往下游推进，逐步申请更多资源调度下游任务。这种模式适合大规模作业，资源不够时至少源端能先跑起来，但代价是作业启动慢，且某个下游任务调度失败时，恢复逻辑会更复杂。
选哪种模式其实不用我们改配置，但理解这一点对排查问题非常有帮助：如果作业一直处于 CREATED 状态不执行，先判断它卡在哪个环节——是资源申请阶段还是任务部署阶段——再对症下药。另外补充一句，生产环境大多数 Streaming 作业默认用 Eager 模式，因为流作业要求所有任务都在线。
3. 资源调度的核心机制：Slot 到底在调度什么
3.1 先搞懂 Slot、TaskManager、资源粒度之间的关系
很多人对 Flink 资源调度最大的误解是——以为 Slot 就是 CPU 核数。真不是。一个 TaskManager 是一个 JVM 进程，它内部被划分成若干个 Slot，每个 Slot 本质上是 TaskManager 内存资源的一个固定分片。两个 Slot 共用进程里的堆内存和 CPU，只是通过线程来隔离任务执行，这种隔离非常弱。
默认情况下，一个 TaskManager 的 Slot 数量等于它的 CPU 核数（可以通过 taskmanager.numberOfTaskSlots 配置）。这里的逻辑是：每个 Slot 能跑一个线程，一个 CPU 核在同一时刻大致能跑一个线程，所以核数定 Slot 数。但这不代表 Slot 跟 CPU 做了绑定，实际上一个 Slot 里的任务在运行时会用到整个 TaskManager 的所有 CPU 资源，没有做硬隔离。所以如果一个 TaskManager 上有 8 个 Slot，而其中 6 个 Slot 的任务都是 CPU 密集型的，另外 2 个 Slot 的任务就会被拖慢。
内存方面是分 Slot 计算的。每个 Slot 分到的内存主要是托管内存（Managed Memory）的一部分，这部分用于 RocksDB 状态后端、排序缓冲等操作。调整 taskmanager.memory.process.size 或 taskmanager.memory.task.off-heap.size 会影响每个 Slot 可用的内存配额，进而影响作业稳定性。
明确一点：Slot 是 Flink 做资源调度的最小单元，但不是资源隔离的最小单元。容器化部署的时候，真正的隔离是靠底层 YARN 或者 Kubernetes 的 Pod 来实现的。这个区别非常重要，很多分布式系统里“调度单元”和“隔离单元”的职业病如果混在一起，排查问题时会走很多弯路。
3.2 从资源申请到 Slot 分配的内幕
一个作业请求资源的过程是这样的：JobManager 中的调度器发现某个 ExecutionVertex 需要执行，会根据它所属的 JobVertex 所需要的资源（默认每个 Slot 的资源规格由 TaskManager 的 Slot 数、内存大小推算而来）向 ResourceManager 发起 Slot 请求。
ResourceManager 是 Flink 跟底层资源管理系统（YARN、K8s、Standalone）打交道的中介。它拿到请求以后，先看已注册的 TaskManager 列表里有没有可用的 Slot。有就直接分配；没有的话，它会向底层资源平台申请启动新的 TaskManager。
这个“申请新 TaskManager”的过程是异步的、需要时间的。YARN 模式下要经过 ResourceManager -> NodeManager -> 启动容器 -> 注册到 JobManager 一系列流程，K8s 模式要经历创建 Pod、拉镜像、启动进程。我见过很多次生产故障，就是作业在高峰期追加并行度，资源不足，然后 TaskManager 扩容需要几分钟，期间作业一直处于等待资源的状态。所以如果你发现作业运行得慢，不要只盯 CPU，先看监控里的 Slot 申请耗时。
Slot 分配成功之后，TaskManager 会向 JobManager 确认，然后 JobManager 把具体的 Task（也就是 ExecutionVertex 的执行体）部署上去。这里有一个细节：Task 的部署是以 Task 为单位，但资源占用是以 Slot 为单位。一个 Slot 里可以先后运行多个 Task，因为一个 Task 执行完了，Slot 就会被释放，然后重新分配给新的 Task。Flink 通过 SlotSharingGroup（槽位共享组）机制允许来自不同 JobVertex 的 Task 共享同一个 Slot。默认情况下所有节点都属于同一个默认组，这样整个作业最小只需要一个 Slot 就能跑完——当然前提是并行度也要适配。
3.3 资源调优时最容易踩的坑
围绕 Slot 这块，踩坑经验堪称丰富。先说最常见的：Slot 数量设置等于并行度总和。很多新手直接把所有算子并行度加起来设 Slot 数，这是错的。因为默认所有算子都在同一个 SlotSharingGroup 里，一个 Slot 里可以串行执行多个不同算子的 Task。正确的做法是——Slot 数只需要大于所有 Task 中并行度最大的那个算子的并行度就行，通常是大于等于 max(parallelism)。
第二个坑是内存配置。Slot 数调大以后，如果没同步调大 TaskManager 内存，每个 Slot 分到的内存反而会变小，RocksDB 状态后端很快就给你抛内存溢出。节奏应该是：先确定每个 Slot 需要多少内存，再确定 TaskManager 总内存，最后反推 Slot 数。顺序反了，作业就等着 OOM。
第三个坑是 Standalone 模式的资源隔离。Standalone 集群里的 TaskManager 是提前启动好的，JobManager 只是在已有的 Slot 里做分配。这种模式下就算作业资源需求很高，集群资源不够，作业也只会卡在等待资源状态，不会自动扩容。很多公司在测试环境用 Standalone 模式跑作业，遇到资源不足时第一反应是“加并行度”，结果越加越起不来，就是因为忘了 Standalone 不自动扩容。
4. 从调度到执行：ExecutionGraph 展开背后那些事
4.1 ExecutionGraph 到底长什么样
前面提到了 JobGraph 转 ExecutionGraph，这里展开讲透。JobGraph 中的 JobVertex 是逻辑节点，它包含了并行度信息和算子链信息，但并不知道自己会被拆成几个并行实例。到了 ExecutionGraph 这一层，每个 JobVertex 会根据并行度展开为若干个 ExecutionVertex。
举个例子：一个 JobVertex 并行度是 4，展开后得到 4 个 ExecutionVertex，编号从 0 到 3。每个 ExecutionVertex 在执行时会创建一个 Execution 对象，这个对象记录了任务的当前状态（RUNNING、FINISHED、FAILED 等）和尝试次数。
ExecutionVertex 之间通过 ExecutionEdge 相连。这些边是逻辑连接，指向数据应该从哪里来、到哪里去。真正决定数据怎么传输的，是中间结果（IntermediateResult）和分区（ResultPartition）的概念：每个 ExecutionVertex 产生的输出数据会写入到 ResultPartition 中，下游的 ExecutionVertex 从上游的 ResultPartition 消费数据。
调度器在分配 ExecutionVertex 时，会考虑数据本地性。如果你的作业上游和下游都分配到同一个 TaskManager 上，那么数据可以直接走内存管道（Pipelined）传输，不需要落盘和网络序列化。如果被分配到不同的 TaskManager，那数据就要通过网络传输。所以你会发现，并行度调整之后作业变慢，往往不是 CPU 不够，而是数据本地性变差了、网络开销增加了。
4.2 调度策略的源码级逻辑与选择标准
刚才提到 Eager 和 Lazy 两种调度器，这里再往深挖一层。在 Flink 源码里，调度器实现的接口是 SchedulerNG，真正干活的有几个核心类：SchedulerBase 负责状态管理，DefaultScheduler 是 Eager 模式的实现，LazyFromSourcesScheduler 是 Lazy 模式的实现，而 AdaptiveScheduler 是 1.15 之后主推的适应型调度器。
AdaptiveScheduler 的逻辑值得多说一句：它允许作业声明一个并行度范围（比如 1 到 10），调度器根据当前集群可用资源量自动决定并行度。这个东西的爽点是，作业不会因为并行度固定而导致资源不足失败，资源多时自动加并行度，资源紧张时自动降并行度。代价是作业运行途中的并行度可能变化，导致需要重新分发 Key 或者状态恢复。
实际选型建议：流式作业稳定性优先，生产环境不怕资源浪费，选 Eager 模式最可靠；批式作业（用 Flink Batch）或者源端吞吐波动大的作业，Lazy 模式更合适；如果你用的是 Flink 1.15+，自适应调度器也可以试试，但做好监控和告警，因为并行度动态调整带来的状态迁移问题在低版本里有可能触发 bug。
4.3 数据本地性优化，它的实际意义
数据本地性（Data Locality）在调度里是个容易被忽略但影响巨大的因素。调度器在给 ExecutionVertex 分配 Slot 时，会尝试把它放到已经有上游数据缓存的 TaskManager 上。比如上游任务在 TM1 上产生了数据，下游任务如果能分到 TM1，那就能直接从本机内存读取，避免网络传输。这在计算和存储分离的架构里尤其重要。
但要注意：Flink 的数据本地性不是绝对的“计算跟数据放一起”，而是“计算跟上一条 Task 放一起”。对于流式作业，上游算子的输出数据已经分不到哪儿去了，下游算子分配在同一个 TM 能大大减少网络 I/O。所以并行度调整、Slot 分配策略都会直接反映到“本地执行占比”这个监控指标上。我排查作业性能问题时，最先看的就是这个指标，一旦本地执行占比掉到 60% 以下，优先怀疑 Slot 分配和数据倾斜。
5. 失败恢复：作业挂了以后 Flink 都做了哪些事
5.1 失败类型和重启策略的完整决策流程
作业挂掉的原因千奇百怪：网络抖动、第三方系统超时、OOM、JDBC 连接池被耗尽、K8s 把 Pod 杀了等等。Flink 面对失败不是一刀切重启，它有一套完整的决策流程。
首先要区分失败发生在哪个层面。如果发生在 JobManager 层面，整个作业都玩完了，需要 JobManager 重启，这个过程依赖外部系统（YARN/K8s）的故障转移能力。如果发生在 Task 层面，也就是某个 Execution 挂了，JobManager 会尝试对这个 Task 进行重启。如果同一时间多个 Task 失败了，或者一个 Task 连续失败次数超过阈值，那就触发整个作业级别的重启。
重启策略有三个选项：固定延迟重启（fixed-delay）、失败率重启（failure-rate）、无重启（none）。固定延迟就是失败后等 N 秒再重启，最多重启 M 次。失败率策略是在一个时间窗口内，如果失败次数超过阈值就停止重启。默认情况下 Flink 用的是固定延迟重启，Integer.MAX_VALUE 次，延迟 1 秒——这意味着如果代码有 bug，作业会一直重启循环。
实际操作里我最常用的是失败率重启，原因很简单：如果一份代码有静态 bug，那固定延迟重启多少次也没用，反而会让 Namenode 一类的下游系统频繁闪断。失败率策略在窗口内超过阈值就自动放弃，让告警发出来，人工介入处理，而不是集群里像个傻子一样反复重启。这个细节，建议每个 Flink 项目的默认配置都改掉。
5.2 Checkpoint 与 Exactly-Once 恢复链路
Task 挂了之后，重启只是第一步，恢复状态才是关键。Flink 靠 Checkpoint 机制实现状态恢复。Checkpoint 会把算子状态 + Source 位点打包存入远端存储（HDFS、S3、RocksDB 增量），一旦失败，就从最近一次成功的 Checkpoint 恢复。
整个恢复流程是这样的：作业进入 FAILED 状态后，调度器重新申请 Slot，重新调度 ExecutionGraph，然后让每个算子从 Checkpoint 里加载状态。Source 任务从这个 Checkpoint 里记录的位点重新消费数据，内部任务恢复自己的状态，整个作业继续跑。
这期间有几个非常重要但容易被忽略的细节。第一个是恢复粒度：默认是“全量恢复”，也就是说只要有一个 Task 挂了，所有 Task 全部重启并从同一个 Checkpoint 恢复。这在作业规模大的时候非常慢。Flink 1.14 开始支持局部恢复（Local Recovery），只有受影响的任务和它的上游任务会重启，其他任务不受影响，前提是你用了增量 Checkpoint 和可重缩放的状态分发策略。
第二个是 Checkpoint 对齐问题。如果你的作业里有一个算子处理速度特别慢，会导致整个 Checkpoint 的 barrier 流转变慢，Checkpoint 超时，然后频繁失败，最后作业挂掉。这也是生产环境最常见的失败恢复触发原因。排查思路就是看 Checkpoint 监控里的 Alignment 耗时和 Skew 指标。
第三个是状态 TTL。如果 Checkpoint 里的状态数据很大，恢复时间会非常长，极端情况下作业重启后长时间处于 INITIALIZING 状态。建议对非核心状态设置 TTL，能省去大量恢复时间。
5.3 重启策略、Slot 分配与恢复失败的联动问题
有一个场景值得单独拿出来讲，因为它综合了调度和恢复两个主题。假设某个 TaskManager 所在节点宕机了，上面有 4 个 Slot，各跑着不同作业的 Task。这时候 ResourceManager 会把坏掉的 TaskManager 从列表中移除，JobManager 感知到 Slot 失去后，会让受影响的任务进入重启流程，并重新申请 Slot——新的 Slot 大概率落在另一台 TaskManager 上。
但这里有个坑：如果新的 Slot 资源规格跟旧 Slot 不一致（比如内存变小了），根据 Task 的内存需求重新计算后，有可能会导致 Slot 数量不够，作业就一直处于 WAITING_FOR_RESOURCES 状态，看起来像“卡死”，其实是在等资源。这种情况下如果你看日志，会看到类似 “Not enough free slots available” 的警告。对应的解法就是保证 TaskManager 规格统一，或者开启自适应调度。
还有一个坑是 Zookeeper 或者 HA 模式下，JobManager 本身挂了之后，新的 JobManager 恢复作业时需要重新获取所有 TaskManager 的注册信息。如果 TaskManager 数量多、注册慢，作业恢复时间会很长。有时候你看到作业已经从 SUCCEEDED 变成 FAILED 了，其实不是代码问题，而是 JobManager 在恢复过程中给了个保守的失败判定。
6. 实战排查指南：从现象定位到根因
6.1 作业一直 PENDING/SUBMITTED 不动，怎么查
这是群里问的最多的问题之一。作业提交后一直停在 SUBMITTED 或者 PENDING，不进入 RUNNING。按我排查的顺序来。
第一步，打开 Flink Web UI，看 Job 的“Task Manager”数量和“Slots”指标。如果 Slot 数为 0，说明 ResourceManager 还没有可用的 TaskManager，要么是资源平台层面没分配下来，要么是 TaskManager 挂了。
第二步，看 JobManager 日志，重点找 “Requesting new TaskManager” 和 “Slot request” 相关关键字。如果一直循环请求但没结果，大概率是底层资源不够或者资源平台拒绝分配（YARN 队列满了，K8s 的 ResourceQuota 超限）。
第三步，如果 Slot 有剩余但作业就是调度不上去，那就要检查 ExecutionGraph 的调度进度。看哪些 ExecutionVertex 处在 SCHEDULED 状态但没变 RUNNING，可能是它等待的上游中间结果没就绪（批作业常见），或者是 SlotSharingGroup 配置有问题，导致调度器没法匹配。我在 K8s 环境里踩过一次，因为某个 Pod 的资源请求（requests）设置太高，超过了节点可分配量，导致 Slot 永远申请不下来。
6.2 任务反复失败重启，如何看日志快速定段
如果任务总是失败 -> 重启 -> 再失败 -> 再重启，无外乎几种原因：代码里有不可恢复的异常、上下游系统连接问题、资源被打爆。
先说代码异常：看 TaskManager 日志里 Exception 类型，如果是 NullPointerException、IllegalArgumentException 这类，基本是业务逻辑写错了，重启多少次都没用。这时候你的重启策略如果还是固定延迟无限次，那就是灾难，建议马上改成 failure-rate 并设置较低的阈值。
再说连接问题：热词里提到 flink 的 jdbc 连接器异常，这是典型的例子。JDBC 连接器在连接池耗尽、数据库重启、驱动版本不匹配时都会抛异常。这类问题的特点是——重试一段时间后可能自己恢复。遇到这种情况，重启策略配 fixed-delay，但重试次数不要太高，延迟时间（比如 30 秒）要足够给下游恢复时间，同时要同步排查连接池配置：max connections、validation timeout 都要调。
最后是资源问题：如果 TaskManager 日志里有 OutOfMemoryError，或者 GC 日志显示频繁 Full GC，那要立即看内存配置。注意区分堆内和堆外内存：堆外内存不足会直接抛 “Direct buffer memory”，堆内不足会抛 “Java heap space”。两者的解法不同，前者调 taskmanager.memory.task.off-heap.size，后者调 taskmanager.memory.process.size 和 JVM 堆大小。
6.3 从热词“openmetadata 获取 flink 血缘关系”说开去
最近 openmetadata 获取 flink 血缘关系这个话题挺火，这里顺便说一句。数据血缘本质上就是从 Flink 作业解析出数据来源、处理链路、输出目标之间的关系。OpenMetadata 这类工具通常有两种接入方式：一种是从 Flink Catalog 和 SQL 的解析结果中抽取血缘；另一种是靠 Flink 内置的 Lineage 机制（开源生态里目前在演进中）或者外部解析器读取 Plan。
这个场景跟调度和恢复有什么关系？关系在于：Flink 作业恢复之后，血缘关系能不能继续保持准确，取决于你的作业拓扑是否稳定。如果用了自适应调度，作业运行过程中的并行度会变，但血缘是逻辑层面的，跟并行度无关，所以血缘关系本身不会断。真正会让血缘出错的情况是：同一个作业代码被多个环境共用，或者通过 Java/Scala API 动态拼接算子——这个时候 OpenMetadata 抓到的血缘可能对不上实际的执行 Plan。
建议是：不管用不用 OpenMetadata，都要在作业开发规范里强调“用 SQL 或 Table API 写逻辑，避免动态生成算子链”。这不止是血缘的问题，更关系到调度稳定性和恢复后的状态兼容性。动态生成算子链在极端情况下会导致 JobGraph 结构不稳定，一旦任务失败恢复时执行图不一致，状态恢复就会出现二次故障。
6.4 面试里调度与恢复最常被问的几个题
既然热词里有“flink 面试题”，我顺手把调度和恢复这块高频问题整理一遍。这些问题不是死记硬背能过关的，全都需要你理解机制。
第一问：Flink 的 Slot 是如何分配的？答案里必须包含：Slot 是 TaskManager 内部分配的最小资源单元；SlotSharingGroup 决定哪些 Task 可以共享 Slot；调度器根据 ExecutionVertex 的状态分阶段申请和分配 Slot；这个分配又分 Eager 和 Lazy 两种模式。
第二问：一次 Task 失败后，Flink 如何恢复？这个问题的完整回答要覆盖：失败检测（TaskManager 心跳/异常回调）-> 调度器感知失败 -> 重启策略决策（固定延迟/失败率）-> 从 Checkpoint 加载状态 -> 重新调度和执行。同时要说明如果是不可恢复异常（比如 JobManager 挂了），那就要靠外部 Failover 机制。
第三问：并行度怎么调才能让作业跑得快？这个问题高频考的就是“Slot 数不是越多越好”。并行度高，任务之间数据传输和协调开销也高。而且并行度增加会带来状态重新分组，代价很大。合理的做法是根据数据量、单并行度处理能力和资源规格来定，不要拍脑袋。
第四问：Checkpoint 失败会导致作业停止吗？答案是不一定。如果 Checkpoint 持续失败，最终会触发作业失败，但在失败之前，作业可能还在正常处理数据。你可以配置 decline 的容忍次数，或者打开 unaligned checkpoint 来避免 barrier 对齐造成反压。核心理解是：Checkpoint 失败是症状，不是根因，排查时得找它为什么失败。
第五问：状态恢复时 RocksDB 和 Heap 状态后端有什么不同？这个问题看似磕碜，但实际踩过的人才知道关键区别——RocksDB 的恢复是先加载本地增量文件再异步补全远端 Checkpoint 数据，恢复启动快但瞬时 CPU 和磁盘 I/O 很高；Heap 状态直接把数据加载到堆内存，启动快但容易 OOM。选型时要结合状态大小和恢复时间要求。
7. 关于 Flink 调度和恢复，我的最终建议
坦白说，Flink 的调度和恢复机制这篇文章只能算剥了一层皮，真要搞到源码级理解，还得自己动手去跟踪一条 JobGraph 的完整生命周期。但作为一线使用的人，你不需要把每个类名都背下来，你需要的是建立完整的因果链路意识：作业提交流程讲的是资源申请；资源申请挂在调度器上；调度器执行依赖 Slot；Slot 不够就等资源或扩容；任务跑起来以后监控数据流向；数据积压导致 Checkpoint 慢；Checkpoint 慢导致恢复失败；恢复失败触发重启策略；重启策略选错了就反复重启拖垮集群。链条上的每一环都有对应的配置、指标和日志可以观察。
我自己在实际排查中最大的体会是——大多数调度问题都不是调度器本身的锅，而是配置和设计的失衡。比如资源规格不统一、并行度设置不合理、重启策略选错、状态后端没配置好。Flink 很灵活，但这种灵活是把双刃剑，它把很多选择权交到你手里，同时也把所有出错的代价交到你手里。
最后分享一个我自己的小习惯：每次新建一个 Flink 作业，我都会在提交之前把一张检查表过一遍。检查表包含：作业并行度是多少、每个 Slot 内存多大、状态后端用的是什么、Checkpoint 间隔和超时时间是否合理、重启策略是不是失败率模式、最大重启次数是不是超过 3 次、本地恢复开没开。这套流程跑下来，作业上线之后调度和恢复层面踩雷的概率会小很多，也希望你拿去就能用。