job设计

 

1  背景及目的

随着业务的增长，平安的数据库中的数据量不断增大，数据库对象间的关系日趋复杂，数据库中的JOB执行的时间也不断增长，规则也更加复杂。各系统中原有的随意设置JOB，对JOB异常不监控，处理不及时状况已经不能满足现有业务的要求。目前系统中JOB异常影响到生产系统可用性的问题日益严重，针对这些问题罗总提出希望做到JOB的运行监控可以由基础架构的TIER1人员来做，另外也希望开发、运营、DBA三方一起制定出JOB的开发规范、管理规范和监控规范，通过规范管理和加强监控减少JOB对生产的影响。

由于LBS的JOB数量最多，关系最复杂，所以选取LBS作为试点系统，目前LBS已经对JOB开发和监控建立了规范，并且已经在生产环境运行。

本文档的JOB规范是根据LBS试点形成的开发规范、监控规范和运营规范。规范中的开发过程管理操作细则由CMM参与设计制作，运营过程管理操作细则由SQA参与设计制作。

2  制定JOB规范的原则

2.1  资源控制

1、  确定JOB用户，将同一数据库中同一个系统的所有的JOB都放到同一用户下执行。

2、  对JOB运行时间进行估计，根据业务逻辑指定JOB先后顺序，分批串/并行。需要重新整理job，将有先后执行顺序、相互可能会有锁等影响的job合并成一个job；将没有关联关系、同时执行没有影响的job单独出来，可以和其他job并发执行。

3、  将最早开始运行时间，最晚开始运行时间，最大运行时间，运行频度（天、周、月）等写入配置表。

4、  JOB代码通过读取配置表判断是否可以运行JOB，凡是在配置表时间段之外启动的JOB都不能执行。如果特殊情况需要在配置表时间段之外执行JOB，采用手工执行方式。

5、  超时JOB将被KILL。运营开发需要根据DB的具体情况确认是否要在工作时间开始前对DB中还在运行的JOB进行Kill，对于需要Kill的DB，由DBA根据需求在后台增加Cron进行Kill。

6、  运营和开发需要对维护期间（冷备，主机数据库维护、版本下发期间DB受限等）停库影响JOB执行的情况进行评估，确定在这些时段受到影响的JOB的执行策略和后续处理措施，原则上配置表中JOB配置最好避开常规的冷备时间段内。

 

2.2  异常控制

1、  JOB的所有异常都要有记录，要进行处理；

2、  必须在JOB执行日志表中记录下该JOB执行的开始时间，结束时间，成功标志，失败原因；

3、  必须对JOB执行超时情况（结束时间超过配置表的配置）的异常进行记录；

4、  JOB必须分过程记录异常，保证异常能跟踪到JOB调用的哪个过程(procedure)出错；

5、  DBA或运营人员手工KILL JOB也需要作为异常，记录在错误信息表中；

6、  JOB的异常要划分级别，目前警告级别定为warning/minor/major/critical.运营可以根据JOB的具体情况给每个JOB规定不同的级别。

7、  所有的异常都要抛出给OpenView，由Tier-1根据运营提供的处理手册来判断是否要上报到问题管理系统。

8、  JOB问题要通过指定问题管理通道上报，运营、开发要定期对JOB问题进行分析，并根据分析结果对JOB的运行时间等参数进行调整。

9、  异常的抛出流程为：JOB异常->DB TABLE LOG->OPENVIVW->OVSD->TIER1->问题管理系统->运营->开发。

 

2.3  批处理。

1、 批处理是指批次对数据进行操作的过程。

2、  批处理可以手工调用，也可以通过JOB调用，一般情况下，批处理被设定为JOB，在特定的时间执行（例如：LBS的批处理大部分都在凌晨执行）。

3、  批处理开发规范应该明确规定：每个批处理过程执行结束后，在日志表中记录下该批处理执行的开始时间，结束时间，成功标志，失败原因，处理结果（如：记录数，金额等）

4、  JOB异常和批处理异常的关系

由于JOB是调用批处理过程进行业务处理，JOB本身并不处理任何业务。所以，JOB正常运行并不表示业务处理已经正确完成。故而，是否抛异常不仅要看JOB是否正常完成，还要看该JOB调用的批处理是否正确完成。

JOB是否正常完成、JOB中调用的批处理是否正确完成、是否要抛异常三者之间关系如下：

JOB本身是否正常完成	JOB调用的批处理过程是否正确完成	是否抛出异常
Y	Y	N
Y	N	Y
Y(但超时)	Y/N	Y
N	Y/N	Y

5、  JOB调用的批处理程序对于大批量的数据修改（执行时间超过1小时或操作数据数量超过2000条）操作，要实施分段提交和断点续做，以保证job的批处理占用较少的回滚段等资源，最终提高job执行成功的几率。

 

3  JOB开发规范

JOB的开发规范总体来讲有两个方面，一是用后台的配置表来控制JOB的执行，二是要将JOB运行的状况记录到表中，并将异常发送到OpenView，再由基础架构管理部Tier1组（基础架构管理部Tier1组是一个24小时值班的系统监控组）录入到问题管理系统中。然后由运营按照正常问题处理流程进行处理跟进。具体流程参看下页的流程图。

 

 

3.1  JOB用户

各系统要指定一个用户为系统的JOB专用用户（例如，LIFEJOB为LBS的JOB专用用户，LBS中所有业务相关JOB都放在这个用户下），JOB专用的表，JOB要调用的PACKAGE(JOB_PACKAGE)都放在这个用户下，如果其他的包或过程需要被JOB_PACKAGE调用，则需要授执行权给此用户。

    JOB 用户的命名规则为 <系统名>＋JOB, 对于一个库中有多个系统的情况，如果功能彼此独立，可以按照系统名＋JOB的规则给每个系统建立一个JOB用户；如果是一个大系统下的多个子系统，请开发酌情申请建立一<大系统名>＋JOB 的JOB用户。

3.2  开发规范

1、 每新增一个JOB都必须插入记录到JOB执行配置表，凡没有在JOB配置表中登记的JOB，均视为无效JOB。

2、 对每个JOB过程必须加以注释说明（执行时间/执行频次/主要功能/创建人/创建时间/修改人/修改时间），此注释说明必须和数据库中的执行时间和执行频次一致，如有调整必须修改此注释，并重新提交下发！

3、 对每个JOB调用的批处理过程，必须说明其功能/维护模块

4、 对每个JOB，启动后如果确定要执行其中的批处理过程，必须往JOB_RUNNING_LOG插入记录，并且在批处理过程执行完成后更新JOB_RUNNING_LOG中的结束时间。

5、 对每个JOB必须加上错误控制，错误必须明确是JOB中的哪个过程引起的异常。

将所有发生的错误记录到JOB_ERROR_LOG表中.

6、 对于新增JOB过程或JOB过程调整，必须同现有的JOB负责人进行沟通协调，以防止冲突

7、 JOB要调用的package(JOB_PACKAGE)过程由专人负责编写，JOB下发说明由负责编写package的同事编写后放到CC上，由各个项目组打标签下发，JOB下发说明文件的命名格式为：JOB下发说明+需求名.TXT

8、  提供各个JOB批处理过程中所有用到的表，形成文档

 

3.3  下发规范

系统下发的JOB中不能直接调用各个功能过程，必须是调用JOB专用PACKAGE中的过程，否则不得下发。

 

4  JOB开发管理规范

4.1  开发JOB负责人

各开发部门设立一名JOB负责人（原则上由各开发部门核心组负责数据库设计的同事承担），统筹管理该部门各系统的JOB开发。

开发JOB负责人工作职责如下：

1、负责本部门JOB规范的推广实施，

2、负责和JOB管理相关的JOB Package和表结构的开发、维护、管理工作。

3、对本部门各开发组提交的JOB变更（新增、修改、删除、配置表数据调整等）和JOB程序进行审核，确保其符合JOB规范

4、根据JOB运行的历史数据和业务逻辑，业务需求，提供JOB配置表的数据，对JOB的运行时间、运行顺序统筹安排。确定超时JOB的处理方案（如是否需要在上班前杀掉仍在运行的JOB）。

5、配合运营定期分析JOB异常，并负责转报给开发的JOB问题的处理跟进。

6、负责推动JOB调用的相关程序（如批处理过程）的优化。

 

4.2  JOB开发管理过程

4.2.1流程图

图2  JOB开发管理流程图

4.2.2要点说明

1、  系统分析人员分析需求后，如果确认需要新增JOB和调整JOB则填写“JOB变更申请表”，并按照正常开发过程对JOB调用的过程进行开发。

2、开发完之后将JOB调用的过程和功能过程的效率以及同现有的JOB过程的功能及数据之间的冲突关系评估结果提交开发JOB负责人和受影响关联项目组进行审核，复审时开发JOB负责人需提供修改后的JOB_PACKAGE。（如部门内系统过多，开发JOB负责人不能一一了解，可让各系统JOB开发人员进行修改，但开发JOB负责人要对JOB_PACKAGE的质量负责）

3、审核结果需记录到JOB复审记录中

4、审核通过后提交EOA流程确认，具体说明如下：

1)        编写JOB程序人员需在EOA中申请复审，同时在签报中须附上《JOB变更申请表》，《JOB复审记录》、代码、配置表和脚本

2)        部门JOB负责人在EOA中确认资料内容的完备性和正确性，确定JOB运行的时间，同时提供JOB_PACKAGE

3)        如部门系统过多，可增加系统JOB负责人审核环节。并由系统JOB负责人提供JOB_PACKAGE（可选）

4)        部门长/开发JOB负责人直属领导确认

5)        运营组长确认/运营分管领导确认

 

表1JOB复审流程（EOA）

处理环节序号	审批类型	审批角色	说明	附件
0	申请提交	编写JOB业务程序人员	填写签报正文，启动该流程	签报中须附上JOB变更申请表、JOB复审报告、代码、配置表和脚本
1	内部批示	开发JOB负责人	确认资料内容的完备性和正确性，确定JOB运行的时间，提供最终JOB_PACKAGE并更新到CC中	附上最终的JOB_PACKAGE
2	内部批示	系统JOB负责人	本环节为可选环节，如开发部门内系统过多，开发JOB负责人不能一一了解，在处理环节一可转发给系统JOB负责人进行审核处理。由系统JOB负责人提供最终JOB_PACKAGE	附上最终的JOB_PACKAGE
3	内部批示	部门长/开发JOB负责人直属领导	审核申请的合理性
4	内部批示	运营负责人/运营分管领导	确认申请的合理性
说明： 审核流程详见EOA中“集团信息管理中心 – IT各部门工作流程”中各开发部门下面的“数据库JOB复审”

 

5、EOA审批通过后，如EOA审批中有新的问题产生，需由流程申请人员把问题更新到《JOB复审报告》中，并提交给部门开发JOB负责人。

6、开发JOB负责人将确认的JOB_PACKAGE和JOB复审记录更新到Clearcase中，并通知项目组及关联组

1)        在CC中“公共服务\src”下建立存放JOB_PACKAGE的文件目录

2)        在JOB_PACKAGE存放的目录下建立“JOB审核及申请”目录，在该目录下按照JOB系统名建立子目录，在该目录下存放JOB审核和变更申请的文档，文件命名方式遵循开发中心规范“配置管理指南”要求

7、项目组对JOB_PACKAGE打标签并进行下发

5  JOB运营管理规范

5.1  运营JOB负责人

各运营部门运营组设立一名JOB负责人（由运营应用服务组成员担任），运营JOB负责人工作职责如下：

-        在JOB新程序测试和上线期间向监控组提出监控申请

-        提供本组的TIer1 JOB异常处理操作手册，并定期维护手册，确保手册的及时更新，并对Tier1进行必要的培训，使其能满足运营JOB异常处理要求

-        设置MOSS的JOB异常邮件发送策略，确保JOB异常邮件能及时发送给正确的收件人

-        负责审批运营组内的JOB变更请求（新建、修改、删除、配置表数据调整等）,对本运营组提交的JOB程序进行审核，确保其符合JOB规范

-        负责运营自己写的JOB相关的JOB Package和表结构的开发、维护、管理工作

-        定期主动分析JOB异常，并跟进JOB问题的处理进度（运营、开发）

5.2  JOB异常的响应与处理

-        Job异常事件的处理遵循运营事件管理流程中的规定

-        JOB异常事件上报通道统一规定为：在ItsmPortal系统中“IT系统监控－应用系统监控“下，服务目录的建立遵循”IT应用系统问题“下所有的服务目录设计

ü   通道命名规则为：

IT系统监控-----应用系统监控-------应用系统名称（即服务目录第一层）

-        各应用服务组应该在Tier1指引中明确上报通道和上报主题,在上报界面选择

        a. 上报主题-------JOB运行异常

b.上报方式-------人工上报

c.上报来源-----Openview

   -

-        运营事件响应人员处理TIRE1上报的job运行异常的事件，并遵循事件管理流程中的定义

 ü          应用系统监控通道收到的事件，在处理界面选择事件类型为“JOB类监控”.

ü          判断是否可以解决该事件，可以则自己处理，不能解决则升级至PIR事件处理；同时确定该事件是否需要更改程序，如果需要则上报PIR需求

ü   解决时判断是否需要补执行，需要补执行的则由事件响应人员使用实名用户执行。补执行时，要预估补执行的过程运行的资源占用情况，对其他操作的影响，需要选择合适的运行时间，避免JOB过程补执行对生产系统的影响。

5.3 告警级别的定义

可以根据job重要性的不同，定义不同的告警级别，Tier1工作人员会根据不同的告警级别采用不同的处理方案，告警级别及Tier1处理方案如下：

-        低(warning)  ：不需要处理，直接终止；原则上此级别不使用

-        一般(minor) ：上报问题管理系统；原则上所有JOB最低设置级别是minor

-        中(major)：上报问题管理系统，8：00--23：00电话通知运营负责人员，若公司电话无人接听，拨打运营负责人员的手机

-        高(critical) ：上报问题管理系统，立即电话通知运营负责人员，若公司电话无人接听，拨打运营负责人员的手机

5.4  告警级别的修改

告警级别原则上不能修改，如果特殊情况需要修改（如因为job相关的业务重要性发生变化时，可以根据业务的重要性升高或降低告警级别），需要走JOB下发流程（按照4.2中要求进行申请和审核），由开发提交版本给运营进行修改。

 

5.5  程序测试与版本发布

程序测试与版本发布由运营测试组和运营应用部署组负责，流程与工作要求与其他程序的测试和版本发布相同。

新版本流程上线之前，JOB规范的执行由各开发部门核心组JOB负责人和运营JOB负责人一起把关，在EOA审批流中运营JOB负责人参与复审。

5.6  运营新增、修改及删除JOB的申请流程

新增JOB需提交统一申请表（参看job变更申请表.doc），待审批后进行开发

1业务类监控JOB的新建/修改/删除，运营提出需求,由对应开发部门开发新建。

2 数据库性能监控类JOB的新建/修改/删除，由运营提出需求并开发，通过DBA审核后发布到生产环境。

建议邮件与DBA组组长沟通确认可行后,运营开发人员遵照JOB开发规范进行开发，完成后了附上相应文档与脚本，进行如下EOA签报。

详细申请操作请参见4.2.2要点说明 

1.     编写JOB程序人员需在EOA中申请复审，同时在签报中须附上《JOB变更申请表》，《JOB复审记录》、代码、配置表和脚本

2.     各组JO