问题及故障处理流程

NGBOSS3.0系统问题及故障管理流程1、相关概念1)问题定义：问题是一个或多个不知原因的事件。2)问题与故障（或突发事件）的关系：当问题的影响符合故障（或突发事件）定义标准时，问题即形成故障（或突发事件）。3)故障处理小组：故障处理小组由各业务流的故障牵头处理人组成，共同完成故障管理相关工作。目前业务运营中心故障处理小组包括话单流陈霞、订单流张嘉琦、账务流刘华、热线支持组马立娜及值班组阴衍亮。2、故障处理一、角色及职责定义1)故障上报人根据故障上报标准判断为故障后，第一时间按要求发出报告邮件，并电话通知故障分派员。对于符合故障或突发事件定义的问题，逐层升级至本部门主管经理；未达到标准的通知主管，由主管酌情升级。对于故障或突发处理过程中未按时限回复进展情况，由故障上报人直接升级至故障分派员。对于发生的故障，统一按业务运营中心内部要求进行登记。故障上报人由业务运营中心50000号值班班长及运维组人员担当。2)故障分派员接收故障上报人的报障邮件和报障电话通知。根据故障情况，以邮件及电话方式指定故障处理牵头人。根据故障牵头人要求，协助故障牵头处理人进行故障处理，跟进处理步骤，监督执行。故障分派员由值班组人员担任。3)故障处理牵头人牵头处理故障分派员分派的故障。指派故障涉及的各部分人员协助进行故障处理，如有必要，可要求相关人员现场支持。跟踪整个故障处理过程，做好记录，评估各步骤的完成情况。组织BMCC相关人员和相关厂商人员进行故障处理方案的制定，掌控整个过程。监督故障处理各重要步骤的执行，做好资源调度，在异常问题及时升级至相关领导，协助完成资源调配。在原因明确后、方案确认后、方案实施关键点完成后及时通报故障最新进展，直至故障解决。。根据故障处理情况及时向领导汇报故障处理情况。与对外信息发布人及时沟通，协商确认对外发布口径。记录问题处理过程，登记故障问题管理列表中的相关处理信息。负责故障处理完成后，整理并填写故障分析报告，并按时提交。总结及优化类似故障的处理步骤，为后续故障处理提供依据。根据故障管理员的要求组织故障分析会、故障分享会，对故障进行总结分析。故障处理牵头人由运维组/值班组人员担任。4)对外信息发布人负责接收来自业务管理部门的统一报障。负责牵头拟定对业务部门的回复口径（重大问题报领导决策）。负责对业务管理部门发布统一回复口径。对外信息发布人由业务运营中心马立娜担任。5)故障管理人负责管理故障管理流程，更新流程文档，监督流程的执行。对所有故障进行统一管理；符合故障标准的，督促故障报告的提交。负责对故障报告/督办单进行审核，保证故障报告/督办单的质量。依据故障的影响及复杂程度，要求故障处理牵头人召开故障分享会或故障分析会。每月组织故障分析会及问题总结会以及周例会。每周按时提交故障周报。故障管理人由业务运营中心故障处理小组担任。二、故障处理流程图故障处理流程图故障上报阶段故障总结阶段故障处理阶段故障牵头处理人对外信息发布人故障上报人故障分派人故障管理人用户/系统工单系统/热线电话系统监控日常维护是否是故障发送报障邮件并电话通知故障分派人是判断故障属性及负责人将故障邮件分派至牵头处理人并电话通知联系厂商恢复业务降低影响调查故障原因故障处理与业务部门沟通故障情况相互沟通故障记录提交故障分析报告/督办单审核故障分析报告/督办单是否符合要求故障汇总是否故障分析故障分析结束是是否否三、流程描述1)故障判断符合以下标准，判断为故障，按以下故障上报流程处理：故障通用标准：高敏感业务出现问题用户自助办理业务出现问题用户存有凭证的业务出现问题具体说明：短信接收到区域中心上报突发事件，核实为支撑系统问题。品质或市场部通知系统存在问题，核实为支撑系统问题。批量下发短信的内容有误。用户充值缴费、开停机业务有问题。批量用户发票打印或内容出现问题。批量用户账详单内容有误。客服终端、营业前台无法正常登录系统。各渠道通用业务的办理出现问题。影响北京公司在集团支撑系统考核成绩、集团公司信息化考核成绩。2)故障上报发现故障后的第一时间发出报告邮件，并电话通知故障分派人。邮件基本内容包括：问题现象、报告时间、上报人、影响类型、问题来源、投诉量、投诉号码、初步定位。针对以下类型的故障，除基本内容外，还应根据实际情况增加故障邮件报障内容：短信类：品牌、短信内容、短信接收时间充值类：品牌、充值时间、问题详细情况业务办理类：系统失败界面截屏或详细的报错提示信息系统登录类系统失败界面截屏或详细的报错提示信息话单类：品牌、话单类型、影响时间段、具体错误描述账务类：品牌、影响用户范围、账期范围、具体错误描述账详单显示类品牌、错误截屏邮件发送范围：主送：值班组全体成员；抄送：章玮，BOCM，信息系统部50000号组，刘华，陈霞，张嘉琦，徐晖，曲国强，王英基，石伟，吕鹏，杨海威，姜宏岩，陈云磊，杨英苹邮件主题：报障：故障现象简述对于符合故障或突发事件定义的问题，逐层升级至本部门主管经理；未达到标准的通知主管，由主管酌情升级。对于故障或突发处理过程中未按时限回复进展情况的，由问题报告人直接升级至故障牵头处理人。对于发现问题，按故障登记表填写要求及时填写故障情况。3)故障分派收到故障上报人的邮件或电话报障后，根据故障的实际情况指定故障的牵头处理人，将邮件转发至牵头处理人并电话或当面通知牵头处理人完成故障处理。故障牵头处理人的指派依据：根据发生故障的实际情况，分配至运维组的业务负责人/值班组负责人，针对不明确的问题，分派至相应组的主管，由主管指定本组的故障牵头处理人。针对涉及多组的情况，首次分派的组为牵头处理组，牵头处理人也由此组指定。4)故障处理故障处理应以降低对外影响，减少用户不良感知为第一行动准则，故障处理全过程都应优先考虑此准则。故障发生后，组织厂商人员首先进行业务恢复或降低影响的相关操作，尽量减少用户感知。相关应急手段处理后，需组织相关人员查询和分析问题原因。故障处理牵头人需组织亚信及BMCC相关负责人（包括开发中心及维护中心人员），共同讨论故障处理方案，综合考虑可能带来的用户影响，制定细节处理步骤，核查关键点，核查方案并指定具体负责人，针对重点步骤后设置决策点及决策人，明确计划后再开始进行故障处理。故障牵头处理人需充分调配BMCC及厂商人员，在资源出现问题的情况，需升级至部门经理协助进行资源调配。故障处理过程中如果关键路径中的步骤出现问题或延迟的情况，各步骤处理人员需提前上报至故障牵头处理人，由牵头处理人统一评估后续影响，及时通报。如有必要，可重新组织相关人员进行讨论，确认最终方案。故障处理过程中需及时与服务组及对外信息发布人沟通，确认最新的影响和感知，确认故障处理方案是否需调整。故障处理过程，进行相关决策点的决策，针对影响面大的重要决策，需升级至领导的进行决策，升级时需提供决策依据及建议方案。故障处理过程中需及时向领导报告问题处理进展，针对可能出现问题或延迟的步骤需提前升级；故障处理后，请及时填写故障登记表中的信息。针对不能及时解决的问题，请填写处理进展。5)故障总结故障处理完成后，需及时更新故障登记表中的故障状态。故障处理完成后，需在三个工作日内提交故障分析报告。故障分析报告命名规则为：故障分析报告_yyyymmdd_故障名称_处理人故障分析报告格式及填写要求见附件：故障处理分析报告_yyyymmdd_故障名称_处理人.docx故障分析报告填写完成后，需由故障管理人审核通过，之后上载\\db\信息系统部\运行中心\03-维护记录\9-问题管理\故障分析报告目录下，并发送邮件至章总、BOCM、故障管理人、相关故障处理人。针对品质下发的督办单，故障牵头处理人需根据故障产生原因，并结合此故障的对外的发布口径填写督办单中的内容，填写完成后需由故障管理人审核后，提交至对外信息发布人//部门经理，由对外信息发布人统一回复至品质部门。6)故障分析故障处理完成后，由故障管理员根据故障的情况，确定各故障的后续分析方式，主要包括故障周例会，故障分析会，故障分享会。故障分析方式的确认依据：针对重复发生且处理流程简单的故障，可在故障总结后直接关闭。针对处理流程较复杂需改进的故障，在故障周例会上具体讨论分析。针对影响大且处理环节较多，流程复杂的故障，使用故障分享会的方式。针对影响大但处理方式明确，但涉及系统实现较复杂的问题，使用故障分析会的形式。以上形式可重复使用。每周需依据本周故障发生情况及故障的最新进展，整理完成当周故障周报。附故障分析会议要求：故障周例会牵头人：故障管理人参与人：BOCM，（业务需求负责人）频率：每周一下午目标：针对每周的故障情况进行总结，包括重点故障及故障管理流程的实施情况，另外针对需讨论及升级问题进行重点讨论。形式：由故障管理员牵头主持，由经理、各组主管及厂商人员参与，针对话单流、交易流、账务流的重点故障进行分别的讨论，相互了解，相互借鉴；针对故障管理情况进行通报，讨论需改进项目及后续安排。如涉及需求引发的故障，业务开发中心需求负责人也需参加进行讨论。输出物：故障周例会会议纪要故障分享会牵头人：故障牵头处理人参与人员：故障管理人、故障处理人、BOCM频率：不定时目标：通过分享会，让参会人员对故障处理的方法及处理思路有进一步的认识，旨在指导大家之后的故障处理过程，帮助以后的方案制定。形式：由故障的牵头处理人做为主持人，引导参会人员针对故障的处理过程进行分析讨论，找出不足与问题，具体参与形式不限。输出物：故障总结资料，应包含出账处理的全过程，故障处理方案，处理过程的问题及改进，处理经验总结，系统知识积累总结、故障案例库输出等内容。故障分析会牵头人：故障牵头处理人参与人员：故障管理人、故障处理人、厂商人员频率：不定时目标：通过分析会，让参会人员请楚了解故障涉及的相关系统实现方式，故障发生的根本原因，旨在加深大家对系统的了解程度，帮助以后的故障定位。形式：由故障处理牵头人自己或联系厂商人员，针对此故障涉及的系统具体实现方式进行详细讲解，并将因故障造成的系统变更明确说明。主持人与参会人员在会议过程中以可以以提问回答的形式增加对讲解内容的理解。输出物：故障分析会资料，包括系统实现及故障变更的培训资料，相关系统知识积累总结，故障案例库输出等内容。3、问题处理一、角色及职责定义1)问题上报人经判断非故障的问题，按要求发出问题报告邮件本组主管处。对于发现问题，统一按业务运营中心内部要求进行登记。问题上报人由业务运营中心50000号及运维组人员担任。2）问题处理人：针对问题进行初步判断，确认问题产生原因。协调开发中心与厂商人员共同针对问题进行处理，并定期通报问题处理进展。填写问题登记表中的相关信息。问题处理人由业业务运营中心运维组人员担任。3）问题管理人：对于问题进行统一管理，每周通报整理问题进展情况。针对问题流程进行监控，如有问题及时更新发布。问题管理人由业业务运营中心刘华/阴衍亮担任。二、流程图问题管理流程上报所属组主管问题所属组主管问题处理人问题管理人问题上报人开始是否是问题确认问题所属系统发送问题上报邮件是问题分派确认问题情况问题处理登记问题表相关内容登记问题表相关内容问题统一汇总反馈问题情况了解问题处理情况结束召开问题分析会三、流程描述:1)问题上报发现问题后的第一时间发出报告邮件至本组主管处，并电话或当面与本组主管沟通问题情况。邮件内容包括：问题现象、报告时间、上报人、影响类型、问题来源、投诉量、投诉号码、初步定位情况各组主管在接收到问题上报邮件后，确认分析问题所属组别，将邮件转发至所属组的主管处，之后电话通知。问题上报人将上报问题的相关信息填写至故障问题管理列表中，是否形成故障填写为否。2)问题处理对问题进行初步整理及分析，确认问题根据原因。联系开发中心或厂商相关人员进行问题的处理。定期更新问题最新进展至故障问题管理列表，并且邮件回复问题上报人及其相关组主管，直到问题最终