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