OI-IT-12 运维故障处理与报告流程.docVIP

CCC信息技术有限公司深圳分公司 运维故障处理与报告流程 编号： OI-IT-12 页码/页数： PAGE 7/7 工作文件 版本 A 修订次数 00 修订人 修订日期 2018-9-1 第 PAGE7 页，总 NUMPAGES7 页 运维故障处理与报告流程 2018年9月1日起发布实施 PAGE 文档修订历史 修订版本 修订日期 作者 审核人 批准人 说明 目录 TOC \o 1-3 \h \u 1. 简介 4 1.1适用范围 4 1.2服务介绍 4 2. 故障处理基本流程 5 3. 故障处理规范 6 3.1故障级别 6 3.2故障发现途径 6 3.3故障表现 6 3.4应对措施 6 3.5故障影响与损失估计 7 3.6故障原因分析与改进措施 7 4. 事故通告及报告汇总 7 简介 1.1适用范围 本文档为运维故障处理流程与规范，用于运维工作人员在日常工作中对紧急故障的处理指导说明。 1.2服务介绍 运维作为网络与服务的运营岗位，一直以来都高度关注和重视数据安全。为保护业务正常运营、数据安全等，我们从技术、服务规范流程等各个方面进行了细致而周密的规范，并严格执行。 故障处理基本流程 故障处理规范 3.1故障级别 关于事故级别的定义，我们采取两个指标： 订单损失量、宕机时间来做衡量标准。两者任一达到定义的标准即可认定达到该事故级别。 事故等级 订单损失量(个) 宕机时间 (小时) 轻微 500 0.5 一般 500 ～ 1000 0.5 ～ 2 严重 1000 ～ 2000 2 ～ 8 灾难 2000 8 3.2故障发现途径 监控平台告警信息 Zabbix/Pingdom 根据定义的监控点的故障问题发送邮件或短信至相关责任人 例行检查 内部工作人员反馈 客户反馈 其他 3.3故障表现 在事故发生初期，需对故障表现在技术、业务流等各个层面进行详细汇总记录，方便快速定位事故原因，界定受影响的业务系统，及影响严重级别等。 3.4应对措施 故障处理应以首先快速规避损失/影响，使业务正常运转；再分析根本原因进行彻底改正为原则。详细的应对措施应该分为四个过程： 对事故表现进行初步分析，通知相关的受影响的系统责任人 详细的对故障处理的操作 解决问题的关键因素、操作 相关责任人对故障恢复后的系统功能进行验证与确认 3.5故障影响与损失估计 故障处理完成之后，需对该次故障造成的影响以及损失进行记录。 在处理故障时应给出大概的影响/损失估计，后续给出详细精确的数据，并可能需要对初次估计进行修正。 3.6故障原因分析与改进措施 故障原因分为两个方面： 工作失误 相关人员对该系统的日常维护、升级等操作过程中，存在操作失误、对业务流程不熟悉、系统关联关系考虑不完善、应用Bug、验证不及时等等问题，造成故障发生； 其他不可抗因素 网站及其他业务系统是实际运行中可能遭遇网络攻击、硬件故障、网络故障等不可控因素造成的业务运行缓慢甚至中断等情况。 实际故障问题中，可对以上两个故障原因进行深度分析，详细分析定位问题的故障发生原因，制定相应改正措施，并跟进改正结果。 事故通告及报告汇总 故障发生后30分钟内，需邮件通知到受影响的各业务部门相关负责人； 对于持续宕机时间在30分钟以上的事故，在故障处理完毕后30分钟内，需邮件发送故障概要给公司相关负责人以及受影响的业务相关负责人。24小时内更新事故报告并发送全体IT及相关人员； 每月需对事故报告进行汇总分析，给出统计指标，作为工作反馈方式及改进指标。