简介Control-M作业配置手册是一套聚焦BMC Control-M工作流自动化平台的作业定义指南主要面向刚接触CTM的运维、调度人员也可供有经验的管理员作为日常查漏补缺的参考资料。这份手册系统讲解了CONTROL-M/EM企业经理与SERVER执行引擎的协同工作方式明晰作业定义库与AJF自动作业流的作用并重点拆解SMART TABLE、SUB TABLE、JOB的定义流程覆盖时间依赖与作业依赖规则、一次性与周期性调度、基于事件的触发等核心配置。内容结合作者实际项目经验梳理了作业生命周期管理、复杂工作流设计、监控告警、版本控制及备份恢复等最佳实践帮助读者减少试错成本保障批处理流程稳定运行。资源包为单份DOC格式文档大小3.05MB目录结构完整附有多个配置实例既适合按章节系统学习也可作为团队内部培训材料。该手册已吸引超过7.4万人浏览学习从基础概念到高级应用均有涉及能为不同层级的用户提供实用指导。1. Control-M作业配置手册调度链路、条件依赖与坑都在这里Control-M简称CTM是批处理调度领域绕不开的工具很多人第一次接触它是因为生产环境里几十个作业依赖关系理不清、脚本调起时间总冲突。这本《Control-M作业配置手册》正好解决这类问题它不讲空泛概念而是把作业定义从表到Job的完整路径拆开告诉你EM、Server、AJF各自干什么SMART Table和Sub Table怎么配IN/OUT Condition怎么用。适合刚接手CTM的新手也适合已经配过作业但经常在调度条件上翻车的人。我拆完这份手册最大的感受是CTM的难点不在工具操作而在把业务依赖翻译成调度条件这份手册把这条翻译路径讲得很实在。2. 先拆调度骨架EM、Server、Agent与AJF分别管什么很多新手上来就打开Desktop定义作业配完发现作业不跑回头查才发现是没搞清组件分工。CTM的核心角色有四个EM、Server、Agent和AJF它们各管一段漏掉任何一个环节的理解都容易踩坑。2.1 EM和Server的分工逻辑Control-M/EMEnterprise Manager是集中控制和定义的门面。用户通过EM定义作业、监控作业、管理整个CTM架构环境。一个EM可以连接并管理多个Control-M/Server所以EM更像是一个管理入口不是实际执行的地方。日常打开Desktop、配置表、查看作业状态操作的都是EM。Control-M/Server才是真正的排程引擎。它负责排程作业、调起作业、管理作业流、更新作业状态。一句话概括EM负责定义和看Server负责排和调。理解这个分工很重要因为实际生产环境中同一个EM底下往往挂了多个Server作业定义在哪张表、提交到哪个Server执行直接决定了调度行为。Control-M/Agent则是安装在目标机上的执行代理接受Server的命令拉起具体脚本或命令。Agent需要安装在批处理作业实际运行的机器上而且要求具有超级用户权限。这点常被忽略Agent权限不够会导致作业调起失败但报错信息往往藏在日志深处排查起来很费劲。2.2 AJF与Order/Force作业是怎么活起来的AJFActive Jobs File是活动作业环境维护一个工作日内所有准备运行的作业。这里有个理解上的分水岭作业定义存在定义库里不动它永远不会自动执行只有把作业放入AJF它才开始进入当天的调度轨道。这个放入的动作叫Order或者Force。为什么会有两个词Order是常规调起按照作业定义的调度日历自然进入AJFForce则是手动强制调起不依赖日历条件直接干预把作业塞进当天AJF。日常排障时Force是高频操作但要注意Force进去的作业同样受前置条件约束如果IN Condition没满足Force之后作业仍然是等待状态不会立即执行。另一个关键机制是New Day。CTM Server每天执行New Day流程把前一天完成的作业清出AJF放入当天根据调度周期算出的新作业清理日志数据最后把更新后的AJF同步到EM。这意味着作业生命周期是从Order/Force进入AJF开始到完成后处理ENDED-OK到post-process结束New Day时没干完的作业会被特殊处理不会无限滞留。2.3 作业的组织方式数据结构和逻辑结构是两套CTM里作业的组织方式有两套很容易混淆。数据组织方式物理存储形式是Server下挂Scheduling Table表里放作业即Server→Tables→Jobs的结构。Scheduling Table分为普通表和有排程计划功能的Group Scheduling Table日常定义作业用的是前者。逻辑组织方式展现和管理方式是三层Server→Application→Group→Jobs。同一个作业在物理上属于某张表在逻辑上属于某个应用组。两者共同决定作业在监控界面里的归属路径。如果定义作业时Application和Group填的不规范后期监控和查找作业会非常痛苦这也是很多团队在作业规范里强调Application命名必须统一的原因。提示物理表决定了作业存哪里逻辑分组决定了作业在EM监控里怎么展示。两者不冲突但要建立统一映射规则避免同一个逻辑分组的作业散落在多张表里。3. 定义SMART Table到Job从建表到作业上线的参数全流程图形化定义作业的入口是Control-M/Desktop登录后所有定义动作都围绕表展开。配置路径是SMART Table→Sub Table→Job三级。这一章按实际操作顺序梳理参数含义和配置要点参数细节全部来自手册的Tab页拆解。3.1 SMART Table调度周期的容器定义SMART Table是第一步。通用配置在General页签下核心字段包括CONTROL-M执行该表的Server、Table表名、User Daily用于每日Order批量作业与Application保持一致即可、Application应用名、Group组名一般与表名保持一致、Author定义用户名。SMART Table真正核心的是Scheduling页签。RBC Name是调度规则名称一般与表名一致Days定义表执行的日期列表Months定义执行的月份列表。这三个字段组合决定了表在什么时间被Order。很多调度不生效的问题都出在RBC配置错误比如只在周一跑的任务Days里没排除其他日期。Execution页签里的Submit定义SMART Table开始执行的时间当值为时表示无限延长即不设定具体提交时刻让表内作业各自按自己的调度条件触发。这种写法在作业级调度更灵活的场合很常用。Condition页签则定义表的IN Condition和OUT Condition分别表示执行前置条件和执行完成后对外释放的条件。SMART Table本身也可以配PostProc后处理最典型的场景是表执行成功后删除自己的IN Condition并生成OUT Condition供下游表或作业消费。这个机制是跨表依赖的唯一正确解法比在作业级别硬编码依赖要清晰得多。3.2 Sub Table作业分组的中间层Sub Table必须挂在SMART Table或另一个Sub Table下不能独立存在。新建方式是右键父表选择Add Sub-table。General页签参数和SMART Table类似Name是子表名Parent自动带出父表Application、Group与所属SMART Table保持一致即可。Scheduling页签选默认All即可不必像SMART Table那样配置RBC。Execution页签的Submit可留空或设取决于是否需要子表整体延迟提交。Condition页签的IN/OUT Condition配置规则与SMART Table相同。引入Sub Table的实际价值在于把大表拆成逻辑分组。比如一个业务域的所有作业放在同一张SMART Table下按处理阶段拆成抽取转换加载三个Sub Table每个Sub Table里的作业共享同一组调度条件后期维护和单独Force都方便很多。3.3 Job定义Command类型最常用条件依赖是重点在Sub Table里右键Add Job即可定义作业。作业类型有四种Command、Job、Detached、Dummy。常用的是Command类型在目标机执行指定命令行或脚本可以理解为带调度计划的crontab。Job类型指调用CTM内置的作业模块Detached和Dummy用途相对小众。作业定义的关键页签包括页签核心参数配置要点General作业名称、Application、Group作业名全局唯一逻辑归属与表保持一致RunCommand、Host、User指定执行的命令行、目标机、运行用户Scheduling调度周期、时间窗口决定作业何时被Order、何时可以开始执行ConditionIN Condition、OUT Condition前置条件写IN成功释放写OUTPostProc完成后置动作成功后删除条件或生成新条件的常见位置作业级Condition是CTM依赖管理的核心机制。IN Condition表示执行前必须满足的前置条件比如PROD_LOAD_OK作业开始时会检查该条件是否存在不存在则等待。OUT Condition表示作业执行成功后产生的条件下游作业的IN Condition引用它就能形成A完成触发B的链路。这里有个容易忽略的细节Condition通常由PostProc来删除和生成而不是作业执行完自动处理。手册强调最常用的情况是当该SMART表执行完成后将删除前置条件或者生成后置条件一旦漏配PostProc可能出现条件永远存在、下游作业提前被错误触发的问题。提示把条件生成放在PostProc而不是依赖作业自身是为了让条件生命周期可控。建议所有跨作业依赖都走Condition机制不要在命令行里写sleep去硬等。4. 作业定义避坑五个高频翻车现场与排查路径图形化定义作业的流程本身不难但生产环境里翻车的点很集中。这一章写的是日常排障中最常见的五类问题每条按现象、原因、解决展开对标手册中的机制说明和实际操作经验。4.1 现象SMART表Order后作业一直不出现有时候表已经Order了EM监控里却看不到任何作业。排查时先看是不是Order到了错误的Server。定义SMART Table时CONTROL-M字段指定了执行服务器如果EM连接了多个ServerOrder动作也发生在当前连接的Server上两边不一致就会表头存在但作业不生成。更隐蔽的原因是Days和Months配置不匹配。比如RBC里Days配了今天但Months里没有当前月作业日历根本命中不了。解决方法是把Order模拟到目标日期看预测结果CTM的日历模拟功能可以提前验证。经验是表刚Order完没有作业优先查Server指向和RBC日历而不是怀疑作业本身配置。4.2 现象作业执行成功但下游没被触发这是典型的Condition链路断裂。作业配了OUT Condition但下游作业的IN Condition引用了不同条件名或者条件名的书写格式不一致。CTM条件名区分大小写LOAD_OK和load_ok是两回事。另一个原因是OUT Condition在作业成功时没有生成因为生成动作写在了PostProc里而PostProc没配置成功。解决方法是打开作业的属性确认OUT Condition挂在Condition页签同时检查PostProc页签是否真的有生成该条件的动作两个位置缺一个都会断链。4.3 现象作业在错误的时间被调起表现为作业明明设置了下午运行结果凌晨就被拉起。常见原因是误用了Submit字段和作业Scheduling的关系。SMART Table的Submit表示不限制作业本身的Scheduling里还有时间窗口两边是叠加关系而不是替代关系。真正该检查的是作业级Scheduling页签里的允许执行时间窗口以及Order时间两个字段前者管开始时间后者管提交时间。差一个Level的坑是时区。如果Server和目标Agent不在同一时区作业显示时间会跟着Server走但实际执行在Agent时区发生。解决方式是统一以Server时区为准配置调度时间并在文档里标注每个Agent所在的时区。4.4 现象New Day之后作业丢失或重复执行New Day机制清理掉已经完成的作业把新一天需要运行的作业放进来。如果作业没配调度周期只是一次性Force进入的New Day后它就会从AJF消失这是正常的。但有时候业务同学以为作业失踪了实际上是它本来就不在该天的调度日历内。重复执行则是另一种极端作业的调度周期没限定日期每天都命中加上业务上原意是只在月末跑结果每天被调起。排查路径是看Scheduling页签里Days和Months的组合Days定义了具体的执行日格式Months定义了月份范围两者共同约束时尤其要检查边界——月初、年末这类临界日期最容易踩。注意Force进入AJF的作业在New Day后不会被自动保留需要重新Force或依赖日历规则Order。习惯把所有手动干预动作记录在变更备注里否则第二天复盘时黑匣子一堆。4.5 现象登录Desktop后看不到任何Server登录Control-M/Desktop时Server字段需要填写连接服务器机器名很多人在这步填了EM的地址进去后发现Server列表为空或连接报错。原因是EM和Server是两套服务Desktop通过EM访问Server信息但Server字段填的应该是EM能够管理到的服务器地址。解决方法是确认该Server确实纳管在当前EM下且在EM/CCM界面里能看到Server状态正常。如果CCM里能看到Server但Desktop里列表为空多半是登录用户对该Server没有定义权限需要找管理员开通相应的角色权限。5. 六个实例推演批处理作业定义里的共同套路手册里给了六个完整实例我把它们归类后发现无论实例形态怎么变核心都在解决四类问题怎么把业务触发条件翻译成CTM条件、怎么控制表级和作业级的调度节奏、怎么用PostProc收尾、以及怎么处理跨天场景。这一章提取六例背后的共同设计套路。5.1 实例归类从单作业到条件链六实例大概覆盖三个层次。第一层是单表单作业完成从建表到定义作业的完整动作适合熟悉界面和参数路径第二层是表内多作业加条件依赖通过IN/OUT Condition连接同一表内上下游作业第三层是跨表跨Server依赖通过SMART Table的OUT Condition联动另一张表的IN Condition。实际生产里大部分场景落在第二层和第三层。理解这个分层后再去看实例就不容易迷路先定位这个实例在哪个层次然后只关注该层次相关的页签配置其他参数按默认即可。5.2 把业务依赖翻译成IN/OUT Condition实例里最常用的模式是作业A成功后生成条件A_DONE作业B的IN Condition设置为A_DONE。这个翻译过程有几个常见映射规则业务场景CTM实现方式关键配置位置A完成后才能跑BA配OUT ConditionB配IN Condition两个作业的Condition页签表T1整体完成后才能跑T2T1配OUT ConditionT2配IN Condition两个表的Condition页签A失败则B不跑A不生成OUT ConditionB的IN Condition等待超时加上时间窗口限制C需要在A、B都完成后跑C的IN Condition填A_DONE AND B_DONEC作业的Condition页签AND组合条件是条件依赖的进阶用法手册实例里也覆盖了这种多前置场景。配置时注意每个条件单独一行逻辑关系用AND连接还是OR连接要在表达式里写清楚不同版本界面的表达方式略有差异以实际下拉选项为准。5.3 调起时间与日历配置的取舍实例里反复出现一个边界判断调度条件到底配在SMART Table上还是作业级别上。经验判断标准很简单——如果一张表内所有作业的调度节奏一致就配在表级同一张表里不同作业执行时机差异明显表级只保留Submit把精确时间放到作业级Scheduling。混用两级调度配置是实例里最需要注意的边界配错会出现时间条件叠加导致作业迟迟不被允许执行。日历配置里另一个典型取舍是固定日期列表和相对日期计算。比如每月最后一个工作日这类需求直接列日期不现实要用CTM的条件选项里相对日表达方式。生产环境里这类需求很常见建议先把日历规则写在表设计文档里再映射到RBC配置避免直接在界面里边想边配。跨天场景是第六个实例的重点作业链从当天23:50开始最后一步在次日凌晨完成。这种场景下New Day发生时尚未完成的作业如何处理、OUT Condition是否跨天有效都需要提前设计。实例给出的常见方案是把跨天作业挂在独立的Sub Table下减少整表New Day的锁粒度这个设计在真实生产里能显著减少午夜作业互相等待的问题。6. 上线前最后一遍自查六个动作让作业定义少返工作业定义完到真正上线之间建议强制走一遍自查清单。这套动作是从多次生产排障教训里沉淀出来的每一条都对应一类真实发生过的故障。第一检查Application、Group、Author三个字段是否和团队规范一致。不一致不会导致作业跑不了但会直接影响EM监控里的查找效率。生产环境出问题时按Application过滤是最高频的排查入口归属乱了的作业往往找不到人认领。第二核对作业级Scheduling的时间窗口与表级Submit字段的关系。表级是限制还是放开、作业级是否被表级约束覆盖这两层的交互逻辑要能口头讲清楚。讲不清楚的配置建议统一改为表级Submit、时间全部放作业级减少层级叠加的复杂度。第三Condition链路完整走查从首个作业的OUT Condition开始逐层检查确保每个上游作业的OUT都能匹配到一个下游作业的IN不存在悬空条件也不存在引用了从未生成的条件。建议画一张条件流转表列上条件名、生成方、消费方、清理时机四列。第四PostProc动作确认。配了删除IN Condition或生成OUT Condition后批量验证一下条件是否真的在正确时机被创建和删除。很多条件残留问题都是PostProc漏配或配错对象造成的这个动作能提前暴露大半条件链路的坑。第五用日历模拟把未来三天的Order结果跑一遍重点看月末、月初、周一这类边界日期。模拟结果里作业对比预期多跑或少跑的情况能在上线前发现。第六把实例场景转化成自己的业务场景做一次端到端演练不要只复现手册案例用自己业务的真实脚本、真实主机、真实用户跑通一次。以前我上线新表时只在Desktop里看着定义没问题就直接Order了后来踩过一次条件悬空的翻车现场后才意识到CTM作业配置的返工成本不在定义本身而在条件依赖的完整性验证上。从那以后每次定义完作业都强制走一遍这六个动作条件流转表更是每次必画。这套自查习惯帮我省下过多次半夜起来紧急Force作业的麻烦希望帮到你。本文还有配套的精品资源点击获取