IT运维流程库历史主题 · 只读
← 返回目录

集团和省级公司之间如何进行ITSS事件交互


20151022淡然
续上


4.13集团、省公司两级交互4.13.1紧急事件上报
省公司在紧急事件发生时，必须在第一时间上报集团公司业务支撑系统部，并在事件处理过程中的每个状态变化点将最新事件记录上传到集团公司。
ITSS考试
上报方式
触发条件
上报内容
事件信息项
附件内容
服务管理平台
事件状态进入一线处理中，并得到一线支持的确认
所有事件信息项
N/A
处理中的事件信息项发生改变
所有事件信息项
N/A
事件状态转入已解决
所有事件信息项
N/A
事件状态转入关闭
（如果影响度为重大，必须有重大事件报告作为附件）
所有事件信息项
《重大事件报告》内容包含：
包括事件的发生时间、事件现象、影响的主要系统、影响度、处理过程、解决方法、业务恢复时间等
4.13.2集团协查事件下发
在业务支撑网全网运营管理工作中，会出现一些需要集团与省公司共同协作才能有效处理的事件，为了实现此类事件在集团和省公司服务管理平台间的流转，特在BOMC两级接口规范中制定集团与省公司之间的事件交互流程及其接口定义。
需要集团与省公司协作处理的事件，目前有如下几类：
n集团的直采业务系统中出现故障时，如果此故障的处理属于省公司运维职责范围，则集团会向省公司发起事件单，由省公司处理故障并将结果反馈给集团，本次流程打通仅针对此项。
n集团在运维管理方面需要省公司进行相应处理的，则集团会向省公司发起事件单，由省公司填写并反馈给集团；
省公司在处理本省系统故障时，如果此故障需要集团参与处理，则省公司可以将对应事件单流转给集团，由集团处理后填写必要信息并转回给省公司。
集团与省公司的事件两级交互流程描述如下：

序号
名称
描述
注意事项
1
集团登记发起事件给省公司
集团的帮助台人员发现直采业务系统出现故障，并且此故障的处理属于省公司运维职责范围时，在集团端服务管理平台中登记填写事件单，并启动下发动作
l[事件ID]由集团端生成；
l[事件性质]填为“系统故障”
l[事件来源]填为“集团协查”；
l[所属系统]填为“其他系统”；
l[所属子类系统]填为“集团-直采业务系统”
l[事件状态]填为“分配到一线”
l[分配对象]填写为“直采业务支持组||省公司接口人姓名”
l对于集团规定的直采A类和B类故障，[优先级]填为“紧急”；C类故障，[优先级]填为“高”
l[实际开始时间]由集团端根据事件下发给省公司的时间自动生成
2
省公司接收事件并进行处理
省端系统通过两级接口收到文件后，自动在省端服务管理平台上登记此事件，并通知被分配的人员进行处理；
处理过程仍遵循省公司自己的事件流传；

3
省公司解决故障后反馈给集团
省公司处理解决故障后，填写必要信息，将事件状态置为已解决，并启动上报动作ITSS认证
l[事件状态]填为“已解决”
l[解决方案]需填写故障原因，故障解决方案及处理过程等信息；
l[解决人]需填写故障最终解决人的“姓名(手机号)”
l[解决人角色]需填写故障最终解决人的所属角色
l[分配对象]填写为“全国帮助台||直采业务接口人”
l除（工单修改时间，事件状态，分配对象，解决人，解决人角色，解决方案，附件）外，集团对于省上报事件记录中的其他字段值都不做入库处理(因为这些字段值以集团侧信息为准)；
4
集团审核确认处理结果
集团的帮助台人员对省公司处理情况进行审核确认；
如果确认处理结果正常，则跳到步骤5；
如果确认故障仍未解决或处理信息填写不全等，则帮助台填写审核意见，将事件重新分配给省公司，并启动下发动作；
l[事件状态]填为“分配到一线”
l[分配对象]填写为“直采业务支持组||省公司接口人姓名”
5
集团关闭事件单
集团的帮助台人员最终确认处理结果正常后，关闭此事件单，并启动下发动作；
省端系统接收到后，自动将事件信息更新到省端服务管理平台；
l[事件状态]填为“关闭”
l[实际完成时间]由集团端根据省公司最后一次将“已解决”状态的事件信息上报并在集团入库的时间来自动生成

4.14省公司上报报表
参见附录事件管理上报报表章节。

4.15实施指导4.15.1流程图、流程角色定义与映射
n各省在细化时，一二线支持可以根据实际情况合并，可以增加省公司管理层等角色以及相关的流程活动描述
n各省在进行流程角色映射时，可以根据实际情况设置多个事件经理，建议由各职能部门经理分别承担
n各省在对进行流程角色映射时，帮助台建议映射为值班组和投诉受理组
n建议业务支撑中心统一对外部门服务热线电话，并在全公司范围内宣传

4.15.2流程衡量指标和报表
n各省在细化时，可以扩充流程衡量指标
n各省在细化时，可以自定义省内使用的流程报表内容、计算方法和生成频度
4.15.3事件信息项
n各省在细化时可以增加新的信息项，但概要设计中已经定义的信息项不能修改和删除，对信息项的描述可以扩充说明，但不能违反现有描述
n集团、省公司两级交互时不传递省内新增的事件信息项
4.15.4流程相关定义
定义

章节号
细化原则
其它说明
事件性质

6.6.2
不能增加、修改或删除代码
对各代码的描述可以扩充说明，但不能违反现有描述
事件来源

6.6.3
不能增加、修改或删除代码

所属系统类型

6.6.4
注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为“其他系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。
各省在细化时，对没有覆盖到的业务系统用“其他系统”表示，子类中没有覆盖到的业务用“其他”表示
事件分类

6.6.5
各省根据自己的业务需要可以在此基础上扩充子类，但不能修改或删除已经定义的类别和子类
各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目
例如：对于小型机的条目，可以按照品牌细分或按照故障原因（配置参数、性能、硬件…）
事件优先级

6.6.6
不能增加、修改或删除优先级别代码，但每个优先级别对应的描述内容可以扩充
如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加。
优先级映射表中已经定义的级别，各省在细化时只可以扩充不能减少。
优先级映射表中为空的字段，各省在细化流程中自行定义
事件响应时限和解决时限

6.6.7
各省根据自己的业务需要可以修改优先级对应的响应时限和解决时限，但应该小于这个范围
在省公司上报报表中需按概要设计中定义的标准进行相关数据统计和上报
事件影响度

6.6.8
不能增加、修改或删除影响度代码，但每个影响度代码对应的描述内容可以扩充
对于影响度为重大的定义应严格按照集团公司的定义。
特别需要考虑的是：所有优先级为紧急而且影响度为重大的事件，在解决后需要将《重大事件报告》上报集团公司，各省在这个原则的基础上酌情考虑如何扩充和修改
事件状态

6.6.9
可以扩充ITSS培训
各省在细化时，如果增加了角色定义，可以考虑对状态进行扩充，以反映该角色的处理动作
事件结束代码

6.6.10
不能增加、修改或删除代码

处理是否超时

6.6.11
不能增加、修改或删除代码

故障厂商

6.6.12
各省根据自己的业务需要可以在此基础上修改



待续
本帖关键字：ITSS