《生产系统故障及问题》由会员分享，可在线阅读，更多相关《生产系统故障及问题（8页珍藏版）》请在金锄头文库上搜索。
1、生产系统故障及问题处理流程文件编号受控编号版次1.0密级内部公开总页数10附录无作者： 杨波 日期： 2011-6-28批准： 日期： 审核： 日期： （版权所有，翻版必究）文件修改记录修改日期修改状态修改页码及条款修改人审核人批准人目 录1目的42适用范围43职责44故障及问题处理流程54.1流程图54.2故障/问题类型64.3故障/问题优先级64.4故障/问题提交74.5故障/问题的响应和解决74.6故障/问题关闭94.7故障/问题数据统计分析91 目的该流程的目的是为了保证运维、客服及各省业务团队反馈的产品故障及问题能够得到研发及时响应、受理及解决，从而提高客户对公司产品及服务的满意度。
2、2 适用范围适用于以现网问题跟踪表、邮件以及电话形式提交的故障及问题信息，人员包括项目经理、研发人员、QA。3 职责项目经理：负责故障及问题的受理及安排研发人员进行解决。开发人员：负责故障及问题的受理及信息反馈和解决。QA：负责对故障及问题的解决状态进行监控； 4 故障及问题处理流程4.1 流程图4.2 故障/问题类型Ø 故障：计算机程序中不正确的步骤、过程和数据定义导致的产品功能不能正常使用，分为5个等级（重大故障、一级故障、二级故障、三级故障和四级故障）；Ø 程序缺陷：软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，其结果是软件运行于某一特定条
3、件时将出现软件故障；Ø 页面问题：由于浏览器兼容性、页面源文件不完整性、脚本bug、页面结构或标签错误等导致的页面显示不完整或点击失效等问题，也包括页面内容错误和连接地址错误等问题；4.3 故障/问题优先级Ø 紧急：需要立即给予响应并解决的故障或问题；Ø 高：需要研发人员在规定的响应时间内给予响应并优先安排解决的故障或问题；Ø 一般：需要研发人员在规定的响应时间内给予响应，并及时安排解决的故障或问题。Ø 优先级的判定标准如下表： 优先级判定因素紧急高一般投诉/报障对象移动运营商或局方领导；第三方拨测公司拨测人员；最终个人用户；运维维护和拨测人员
4、；最终个人用户；运维维护和拨测人员；最终个人用户；运维维护和拨测人员；故障类型故障故障程序缺陷故障程序缺陷页面错误故障等级二级及以上级别故障三级故障四级及以下级别故障潜在的安全隐患存在导致系统崩溃或引发二级以上级别故障的安全隐患存在引发三级故障的安全隐患存在引发四级及以上级别故障的安全隐患故障/问题优先级的判定，首要确定投诉和报障的对象，如果是移动运营商、局方领导或第三方拨测公司拨测人员，则故障的优先级直接判定为紧急；如果是其他保障人，则继续进行故障类型、故障等级以及潜在的安全隐患等因素的判断。4.4 故障/问题提交本流程中故障/问题的提交过程主要指故障/问题从运维部提交到研发部的过程。
5、16; 提交方式：故障/问题的提交主要包括工单、邮件和电话，根据故障/问题的紧急程度可选择不同的方式提交，一般非紧急情况下都选择用工单的形式提交，全球通驻点发现故障和问题一般都用邮件提交，一些紧急的故障/问题的提交可根据具体情况选择电话或者同时采用几种方式并行提交；Ø 提交的内容要求：要求提交的内容要将故障/问题现象发现的路径、手机号码、时间点、邮件主题等描述清楚，以及出现的问题页面具体的内容信息，最好能够提供页面截图；还要给出希望研发作出回复的时限要求；Ø 提交人：运维部技术支持组运维值班工程师；根据发现的故障/问题的具体信息，对照研发的应用模块负责人列表（该列表由QA每
6、月定期更新，然后发送给运维相关人员），除了发送故障/问题直接责任人之外，还要抄送相关的研发室经理、QA，以便对于问题的跟进及统计分析。如果根据故障/问题的具体信息不能准确的判断是研发哪个部门，哪个负责人的情况，可以请QA工程师协助进行判断，然后再进行发送。 4.5 故障/问题的响应和解决 Ø 对于不同优先级别的故障/问题，受理人要在规定的时限内作出响应和给予解决，对于比较棘手、技术复杂度较高的故障/问题，受理人难以在规定的时限内解决的，可以组织室内部和其他室的技术骨干公共参与解决方案的讨论和制定；Ø 故障/问题的受理、响应和解决的时限以及相应的解决方式如下表：优先级受理人受
7、理时间响应时限解决时限解决方式紧急室经理项目经理或直接责任人7X24小时电话立即响应重大故障：1小时内一级故障：2小时内二级故障：4小时内紧急故障修复或开发环境解决经测试环境测试后上线更新高项目经理或直接责任人工作日4小时内12小时内开发环境解决经测试环境测试后上线更新一般项目经理或直接责任人工作日8小时内24小时内开发环境解决经测试环境测试后上线更新上表中的“解决时限”指的是研发解决问题的时间，不包括问题解决后到上线的时间。Ø 故障接收人在接到报障后，首先要判断是否是自己负责的产品的问题，然后判断是否需要其他研发室配合解决；Ø 如果是自己负责的产品的问题，而且不需要其他研
8、发室配合，则根据工单的优先级及时的给出回复；如果需要其他研发室配合解决，则要及时的与其对应的模块负责人沟通，共同确定具体的解决方案和计划，并由接收人在工单或邮件中给予回复。回复信息内容包括：产生故障/问题的原因分析以及解决的时间计划等；Ø 如果不是自己负责的产品的问题，则有责任和义务在工单或邮件中给出回复，如能确定是谁负责的产品问题，则立即将工单或邮件转给其负责人；如不能确定，则立即通过口头、邮件或者即时通讯工具等方式通知QA或文档工程师，由其负责协调相关部门确定责任人及时的给出回复；Ø 故障/问题责任人依据拟定解决的方案和计划进行故障的解决；Ø 如涉及到多方配合
9、解决的故障/问题，则成立一个临时的故障/问题解决小组，由故障受理人负责协调解决故障/问题；Ø 故障/问题解决后，受理人在工单或邮件中回复问题当前已解决的状态，并分派给报障人进行验证；Ø 如果是紧急故障的修复/问题的解决而导致没有经过版本基线和测试组的测试，直接由研发人员将发布包发给运维上线执行人员的情况，则要根据生产环境的配置变更同步更新到测试环境，同时要将修改后的程序包及其源代码和相关更新部署文档交由配置工程师进行基线化处理； Ø 如果被分派的故障/问题处理责任人因公或因私不在公司办公，则其所属的室经理要代其处理或者安排其他人进行处理。4.6 故障/问题关闭&#
10、216; 验证通过后，由工单发起人将工单进行关闭；Ø 对于移动运营商、局方领导或运维系统维护组人员提出的，要求公司/研发部对于此次故障/问题出具故障报告的情况，由运维系统维护组人员在故障修复后，发邮件给故障/问题的责任部门室经理，由其安排相关的故障/问题处理人员填写故障报告，对此次故障/问题的产生原因、解决办法进行描述，然后交由其室经理审核后，由其室经理反馈给研发总监、运维总监、QA及运维系统维护组相关人员；Ø 研发人员出具故障报告的时间，要求在收到运维系统维护组相关人员要求出具故障报告的邮件后，依据邮件里面的时间要求提交故障报告，如果邮件没有要求时限，则在收到邮件后的24小时内提交（节假日除外）。 4.7 故障/问题数据统计分析Ø 由QA负责对分派给研发一部的工单以及研发故障/问题信息进行数据统计和分析；Ø 工单统计数据包括：所属产品、所属部门、负责人、工单处理情况、工单数量、及时处理的数量、未及时处理的数量以及分派错误的数量等；Ø 故障/问题的统计数据包括：故障的现象描述、原因分析、解决方案、故障等级、故障类型、是否重复发生、责任部门、责任人、是否漏测等。该数据的统计同时为研发每月的绩效考核提供数据依据；Ø QA每个月月末至下个月月初对本月内出现的故障/问题数据进行历史趋势的分析；
