★ FEATURED ARTICLE 简介Control-M简称CTM作业定义指南面向初次接触CTM的运维与调度人员也适合有经验的管理员作为参考覆盖从概念到上手的完整路径。内容先说明CONTROL-M/EM与SERVER如何协同工作再系统讲解作业生命周期、作业组与作业流组织方式、基于时间或前置作业完成的依赖设置、SMART TABLE与SUB TABLE定义、一次性/周期/事件触发调度、监控告警和高级工作流设计并配有多个定义实例和最佳实践能帮助读者理解作业运行方式掌握作业配置中的关键考虑因素。压缩包内含1个doc文档整体约3.05MB目录按概述、CONTROL-M概览、作业概览、作业定义工具、表与作业定义、实例等模块组织章节明确便于按需查阅和反复研读。已有74529人浏览学习是CTM作业配置学习与日常排错时值得收藏的参考资料。若需快速定位作业定义难点、核对调度配置可将其作为常用工具书。1. 把 Control-M 作业配置讲透一份让新手少走弯路的实战手册第一次接触 Control-M简称 CTM的人多半是被企业里那些动不动几百个批处理作业的调度环境逼着上手的。你可能会先翻官方文档然后被 EM、Server、Agent、AJF、SMART Table 这一串名词砸晕——文档把概念讲得很严谨但没人告诉你第一步该在哪点鼠标。这份《Control-M 作业配置手册》刚好补上了这个空档。它不是官方文档的翻译而是从实际项目里沉淀出来的操作指南。我读完的感受是它把“定义一张表、定义一个作业、把作业放进当天调度环境”这条主链路讲得很完整对刚接手 CTM 运维或第一次做作业定义的人来说照着点就能跑通对已经写过作业的老手里面的实例部分也能当参考手册用。本文会按这份手册的主线把这套企业级批处理调度系统从头拆到尾。2. CTM 架构拆解EM、Server、Agent 和 AJF 是如何协作的2.1 三个核心组件各自的职责Control-M 不是单机软件它是一个典型的三层架构。手册里对 EM、Server、Agent 的分工讲得很清楚我用一句话概括EM 是管界面和配置的Server 是算调度计划的Agent 是真正去干活儿的。Control-M/EMEnterprise Manager集中管理入口。你定义作业、监控作业、管理整个 CTM 环境都是通过 EM 完成的。一个 EM 可以挂多个 Server相当于一个控制台管多个执行引擎。Control-M/Server调度核心。Server 里有一个排程引擎它负责读取作业定义、计算调度时间、触发作业执行、维护作业状态。你可以理解为一个“强化版 crond”但它能处理的依赖关系和条件逻辑比 crond 复杂得多。Control-M/Agent安装在目标业务机上的执行器。Server 发出指令后由 Agent 在目标机上拉起具体的命令或脚本。文档里特别提到 Agent 需要超级用户权限这一点在实际部署时经常被忽略权限不够的话作业会直接失败。2.2 作业定义库和 AJF一个容易绕晕的概念手册第二章花了不小篇幅讲 AJFActive Jobs File这是理解 CTM 调度机制的关键也是很多新手最容易绕晕的地方。我换个方式解释CTM 里存在两套“作业存放地”。第一套是定义库存在数据库里里面是静态的作业定义包括运行什么命令、在哪个机器上跑、什么时间跑、依赖什么条件。第二套是 AJF它是一个活动作业文件里面是“今天”实际要跑的作业清单。作业从定义库进到 AJF 这个过程叫做Order或Force。这个设计的意义在于你可以把几百个作业定义都存在库里但只有被 Order 进 AJF 的作业才会在当天被 Server 真正调度。每天零点前后Server 执行一次 New Day 处理把前一天的作业清出去把今天按周期该跑的作业放进 AJF然后同步到 EM 的数据库里。如果当天作业运行状态有变化或者有人工干预操作也会实时更新 AJF。提示Order 和 Force 的区别在于Order 是按作业定义里的调度日历正常放行Force 是忽略调度日历强制执行。排查作业为什么没跑时先看它有没有被 Order 进 AJF。2.3 一张图看懂 Write、Upload、Load、Download 的关系手册里有张图我没法原样搬过来但它描述了 Write、Upload、Load、Download 四种操作的关系。实际使用中你只需要记住写作业定义Write→ 上传到 ServerUpload→ Server 载入调度环境Load→ 下发到 Agent 执行Download。在 Desktop 里保存作业定义时默认会走完上传和载入流程但命令行工具可以分别执行这些步骤用于排查问题。我把这四步简化成一张表方便对照操作作用对象实际效果Write数据库保存作业定义的草稿或正式版本UploadServer将作业定义从 EM 传到 ServerLoadAJF将作业载入活动作业环境等待调度DownloadAgentServer 将执行指令下发到目标机 Agent3. 作业定义实操从登录 Desktop 到建出第一个 Job3.1 登录 EM/Desktop 的完整步骤作业定义的主战场是 Control-M/Desktop。手册里强调了一个容易被忽略的点Desktop 不是独立软件它通过 EM 连接到 Server所以登录时要填的不只是用户名密码还要指定连接哪个 Server。我补一个常见的登录坑如果你在客户端机器上启动 Desktop但网络不通或 EM 服务没起程序会卡在登录界面不动这时候先检查网络端口通不通不要反复重试。登录后你会看到 Desktop 的主界面左边是服务器树右边是作业定义区域。第一次进来可能有点懵但别急着点先建立一张表。3.2 定义 SMART Table排程的入口SMART TableScheduling Table是 CTM 里作业的“容器”你可以理解为一张表代表一套批处理流程。新建 SMART Table 后要依次填写几个关键 TabGeneral TabCONTROL-M选择执行这张表的 ServerTable表名通常和业务或应用名对应Application应用名用于逻辑分组Group组名建议与表名保持一致Author定义者用户名Scheduling TabRBC Name运行日历名称。这里有个实际项目中常犯的错——把 RBC Name 和表名设为一致没错但如果多个表共用同一个 RBC修改了这一个日历会影响所有引用它的表。所以新建表时一般会同步新建一个专属 RBC。Days每周哪几天执行Months每年哪几个月执行Execution TabSubmit开始执行时间。如果是凌晨批处理一般填一个相对早的时间比如00:05。手册里提到表示无限延长这个符号在 CTM 里代表“继续等待所有条件满足”。Condition TabIN/OUT Condition这是 CTM 最核心的调度逻辑。IN Condition 是这张表开始执行前必须满足的前置条件OUT Condition 是表执行完后产生的后置条件。比如你有一张表 A 需要在表 B 之后运行那 B 的 OUT Condition 就叫B_DONEA 的 IN Condition 就填B_DONE。这就像给作业发信号——上一棒跑完下一棒接棒。PostProc Tab表执行完之后的处理动作。最常见的用法是表执行成功后把它的 IN Condition 删掉释放信号同时生成 OUT Condition通知下游。这样第二天重跑时不会因为前一天残留的条件状态而误判。3.3 定义 Sub TableSMART Table 里的分组单元Sub Table 是挂在 SMART Table 下的子表作用是把一批相关的作业划到一个分组里便于管理。新建 Sub Table 的方式是在 SMART Table 上右键选择 Add Sub-table。它也有自己的 General、Scheduling、Execution、Condition 这些 Tab但有几个点要注意Sub Table 的 Application 和 Group 要跟所属 SMART Table 保持一致否则作业归属会乱Scheduling Tab 一般选默认 All 即可它继承父表的调度日历Execution 里的 Submit 可以为空这样 Sub Table 的执行时机完全由作业级条件和依赖控制我的习惯是在 SMART Table 层只配通用的运行日历和条件Sub Table 层尽量少配条件把具体的 IN/OUT Condition 留给 Job 级去设置。这样修改依赖关系时不用一层层去翻。3.4 定义 Job命令类型作业的关键参数Job 是真正干活的单元。手册介绍了四种 Job 类型Command、Job、Detached、Dummy。最常用的是 Command它在目标机上执行一条命令或一个脚本本质就是 crontab 的升级版。定义 Command Job 时除了常规的服务器、应用名、组名之外最关键的几个参数是Command要执行的命令行。如果是执行脚本建议写绝对路径并慎重对待环境变量——CTM 的 Agent 进程环境变量往往和手动登录终端时不一样这是脚本在被 CTM 拉起时报错的第一大原因。Run On目标机器或机器组。可以指定具体主机名也可以指定 Agent 组Pool让 Server 在组内选一台空闲机执行。Start Condition作业开始的条件。可以填 IN Condition依赖其他作业的信号也可以填时间窗口比如15:00之前必须启动。Execution Frequency执行频率。比如每天跑、工作日跑、每月某天跑。这里要小心时区问题New Day 是按 Server 所在时区算的。Post Processing作业执行完后的动作比如成功/失败后生成条件、是否重试。这个跟 SMART Table 的 PostProc 类似但作用范围是作业级。下面模拟一份 Command Job 的配置代码按 Desktop 界面字段整理Job Name: APP_DB_BACKUP Job Type: Command [General] CONTROL-M Server: PROD_SERVER_01 Application: PAYMENT_CORE Group: NIGHT_BATCH Owner: sched_user Priority: 200 [Execution] Command: /home/pay/scripts/db_backup.sh --full --dbpayment Run On: srv-db-01 Submit Time: 01:00 Days: MON,TUE,WED,THU,FRI,SUN Months: ALL [Conditions] IN Condition: ETL_DONE (PAYMENT_CORE) OUT Condition: BACKUP_DONE (PAYMENT_CORE) [Post Processing] Success: DELETE CONDITION ETL_DONE; ADD CONDITION BACKUP_DONE Failure: ADD CONDITION BACKUP_FAILED Retry: 2 times, interval 5 minutes这段配置的逻辑是每个工作日及周日的凌晨 1 点等ETL_DONE信号到位后在数据库服务器上执行备份脚本。成功了就把ETL_DONE删掉、生成BACKUP_DONE信号通知下游失败了重试两次每次隔 5 分钟同时生成一个BACKUP_FAILED告警信号。参数说明Priority200作业在队列中的优先级数字越大越先执行。如果多个作业同时准备就绪Server 按优先级排序调度。这个参数在实际生产里很有用比如凌晨数据库备份和报表计算撞在同一时间你肯定希望备份先跑完再跑报表。Run On 指定srv-db-01如果这里填的是主机名Agent 必须在该主机上安装并正常注册。如果 Agent 没起来作业会一直挂在 Queued 状态而不是直接失败——这是排查时容易误判的点。IN Condition 里的(PAYMENT_CORE)括号里是 Application 名。CTM 的条件名不是全局唯一的同一名字在不同 Application 下互不干扰。这一点比 crontab 先进但也意味着你管理条件时要严格规范命名否则很难排查“为什么信号到了作业还是没触发”——多半是这个条件名不是在同一个 Application 下。4. 实例拆解六个典型作业定义场景的配置逻辑4.1 例一到例三从单作业到多作业依赖手册第六章给了六个完整实例这是整份手册含金量最高的部分。虽然原文的界面截图和参数我没法逐字还原但其配置逻辑可以完整讲清楚。例一是最基础的场景定义一个每日自动执行的作业。它覆盖了新建 SMART Table、设置调度日历每天的02:00、新建 Command Job 执行一个脚本。这里值得注意的知识点是SMART Table 的执行时间Submit不等于作业的执行时间它只是表开始“检查”的时间起点。如果表里有作业依赖前置条件表会在Submit时间之后持续等待直到所有条件满足。例二引入了依赖关系。场景是作业 B 必须等作业 A 的脚本执行成功后才能启动。实现方式是作业 A 定义 OUT ConditionJOB_A_DONE作业 B 定义 IN ConditionJOB_A_DONE这样就形成了一条简单的作业链。例三的典型场景是并发控制两个作业互斥比如一个写入临时表一个读取该表做计算不能同时跑。解法不是去抢资源锁而是共用同一个 IN/OUT Condition 机制——作业 C 执行前必须拿到LOCK_DB_TEMP信号作业 D 也一样。谁先拿到谁先跑后到者等待。4.2 例四和例五周期表和日历的高级用法例四讲的是多日历场景。假设有一个报表系统工作日周一到周五跑日批每月最后一个工作日跑月批。实现方案有两种定义两个 SMART Table一个挂“工作日日历”一个挂“自定义月结日历”定义一张 SMART Table在 Scheduling Tab 里用两个 RBC 规则来区分实际项目里我推荐第一种原因很直接分开定义排查问题简单。你监控界面里看到一个作业状态异常直接锁定它所在的表去排查不用去猜当前生效的是哪个日历规则。例五的关键词是量化条件和到期日Until。在这个例子里作业 E 在每天03:00执行但它有一个强制截止时间06:00超过这个时间即使前置条件满足也不会再启动。这个参数在数据批处理里特别实用——凌晨计算如果拖到资金系统对外营业还没跑完结果数据会把生产数据覆盖掉宁可今天不跑也不能晚跑。4.3 例六作业失败自动重试的最佳实践例六是定义 Dummy Job 并配合 On Failure 动作实现失败重试。Dummy Job 不执行实际命令只作为逻辑节点存在用于控制流管理。它的典型用途是作为一组并发作业的汇合点。比如三个作业并行走全部完成后才触发下游作业最简单的方式就是定义三个作业的 OUT Condition 指向同一个 Dummy Job 的 IN Condition。重试配置方面我把几个关键参数总结一下参数说明实际建议Max Retries最大重试次数依据脚本类型稳定脚本建议 1-2 次外部接口调用建议 3 次Retry Interval重试间隔分钟数据库类作业至少 5 分钟以上避免锁没释放就重试Retry Condition仅当某些退出码才重试只对可重试错误重试比如脚本退出码 8不要什么错误都重试否则会掩盖真正的 bug提示重试不是万能的。如果作业是依赖外部系统比如对账平台的结果重试间隔应该拉长到对方系统的处理周期否则前一次请求还没落库后一次重试又发过去反而把数据搞重了。这六个例子拼在一起就是一条完整的批处理链路定义单作业 → 串起依赖 → 控制并发 → 挂日历 → 设截止时间 → 补重试策略。这是 CTM 实际交付项目里最常见的六块拼图。5. 避坑指南作业定义阶段最容易踩的五个坑5.1 作业一直停留在 Queued 状态不执行也不报错现象作业状态是 Queued/Running但 Agent 侧完全没有进程拉起。原因可能有两个一是 Agent 服务没启动或网络不通Server 无法下发指令二是作业的 IN Condition 没满足它虽然在 AJF 里但调度条件被卡住了。解决先看 Agent 是否在线Desktop 左侧服务器树里有 Agent 状态灯再看条件依赖。我遇到最多的是第二种——上游作业失败后没人清理条件下游作业卡了一整晚。处理方式是在 PostProc 里加超时删除条件的逻辑或者让值班运维在 New Day 前检查条件列表。5.2 脚本在终端手动执行正常被 CTM 拉起后报错现象同样的脚本登录服务器手动跑一遍成功CTM 调度执行时却报command not found或环境变量为空。原因Agent 启动的进程环境是精简环境没有加载用户登录时的.bash_profile。解决脚本开头显式声明环境比如#!/bin/sh后加. /home/user/.profile或者将需要的PATH硬编码在脚本里。还有一个思路是在作业定义里设置环境变量CTM 的 Job 属性中可以直接配 Environment Variables比在脚本里改动更优雅。5.3 New Day 后作业没有进入当天的调度计划现象早上看 Monitor 界面今天某些作业没有出现在列表里。原因作业定义里FORCE/ORDER标志没有设置正确或者作业未关联到有效的 RBC运行日历。解决确认作业的 Scheduling 里 Days/Months 是否覆盖今天然后检查 SMART Table 是否被手动设置成了 Do Not Order。我第一次遇到这种情况时以为是作业丢了后来发现是表被人改了状态。建议在 New Day 后养成检查 Order List 的习惯。5.4 条件名冲突导致作业被错误触发现象一个新定义的作业只要前置条件满足就会启动但条件其实是别人留下的旧信号。原因CTM 条件名在 Application 范围内生效不同 Application 可以用同名条件。如果两个作业在不同 Application 下复用了同一个条件名就会发生串扰。解决条件命名规范建议带上应用前缀比如PAYMENT_DAILY_DONE、REPORT_MONTH_DONE避免裸名。已有体系里如果已经乱了就要靠 PostProc 在成功和失败的路径上都清理条件确保每次执行后信号是干净的。5.5 Run On 指定的主机不在 Server 的 Agent 池中现象作业状态变 Red在输出日志里看到Agent not reachable。原因Run On 填的机器名和 Agent 注册时的主机名不一致或者目标机 Agent 没加入当前 Server。解决在 CCM组件管理工具里确认目标主机 Agent 的注册状态和 Agent Name作业里填的 Run On 值要和 Agent 注册名完全一致包括大小写。另一个坑是目标机装了 Agent 但配到了另一个 Server 上这种情况再怎么重装 Agent 也没用。6. 二次开发思路把 Excel 作业清单批量导入 CTM 定义的方法这份手册主要讲图形化操作但实际生产环境里第一次批量上线几百个作业时一个窗口一个窗口点效率太低了。这一章讲一种可行的批量导入方案——基于文档里的命令行工具思路适合需要做作业批量迁移的读者。实现的思路很直接Excel 保存作业定义清单作业名、应用名、组名、命令、调度日期、条件、目标主机再写一个 Python 脚本读 Excel 后调用 CTM 命令行工具完成导入。命令行工具的核心是ctm系列命令常见做法是先导出模板再按格式填充或者使用 Rest API 接口方式。一个简化版的批量导入脚本流程概念示意import subprocess import openpyxl wb openpyxl.load_workbook(jobs.xlsx) sheet wb.active for row in sheet.iter_rows(min_row2, values_onlyTrue): job_name, app_name, group_name, command, run_on, days, condition row # 生成完整命令行 cmd ( fctm create job --server PROD_SERVER_01 f--name {job_name} --app {app_name} --group {group_name} f--command \{command}\ --run-on {run_on} f--days {days} --condition {condition} ) result subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue) print(f{job_name}: {result.returncode}) if result.returncode ! 0: print(result.stderr)参数说明--days直接传MON,WED,FRI这样的简写可读性好--condition里要包含 Application 前缀比如PAYMENT_ETL_DONE(PAYMENT_CORE)避免条件串扰跑了第一条成功了务必在 Desktop 里打开确认参数无误再跑全量。全量跑完后再抽查几份作业的运行日历和依赖关系导入只是第一步。验证批处理定义是否正确我习惯的做法是新建一张临时测试表把要验证的作业挂上去用 Force 的方式强制 Order 到 AJF 里然后盯着执行日志看状态流转。确认无误后再改正式表的日历让作业在下一个调度日起自动跑。这份手册的例子从最简单的单作业一直铺到条件依赖和重试策略基本覆盖了各种常见的批处理配置场景。唯一可惜的是用文字描述界面操作有天然的信息损耗——截图的直观感没法完全还原但表格、参数和实例串起来的知识链路自己跟着做一遍也足够打通主流程了。希望这份手记能帮你在处理企业级批处理作业调度时少走一些弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
