前言
业务系统提供7*24小时服务,而因人为操作、程序BUG等原因导致服务不可用是影响服务持续运行的重要原因,为了提高各业务系统的运行稳定性和服务水平,需要规范各业务系统的服务、故障响应、升级流程。
故障分级标准
系统运行中,对非不可抗力所造成的故障归类为“故障”。故障分级如下表,由于故障可能在多方面体现影响,所以故障的综合等级评定原则,取各个方面中严重等级最高者为该故障综合严重等级。
业务可用类
等级 | 故障描述 |
---|---|
一级故障 | 业务非计划中断8小时一上 |
二级故障 | 业务非计划中断2-8小时 |
三级故障 | 业务非计划中断1-2小时,业务核心功能无法使用 |
四级故障 | 业务非计划中断1小时一下,业务核心功能受到影响 |
五级故障 | 业务非计划中断1小时一下,业务次要功能无法使用 |
业务安全类
等级 | 故障描述 |
---|---|
一级故障 | 系统入侵:核心业务受到入侵,核心用户数据等受到入侵,或者系统文件给恶意窜改,容易引发入侵扩散; |
二级故障 | 系统入侵:核心业务受到入侵,未危及重要数据,仅造成扩散隐患但是并未发现有以外的机器系统受入侵的; |
三级故障 | 系统入侵:核心业务存在高危端口或者系统漏洞; |
四级故障 | 系统入侵:非核心业务存在高危端口或者系统漏洞; |
五级故障 | 隐患:自身有漏洞,但无重大后果; |
故障响应升降级标准
故障升降级的处理是根据相关责任对故障响应、处理、完成结果等因素来对故障处理情况进行综合评定。该评定只适用于运维部门内部进行故障响应、处理、升降级。和公司层面的故障定责奖惩无关。
评定项 | 降级标准 | 升级标准 |
---|---|---|
响应时间 | 第一时间响应,包括故障的痛追,处理,善后事宜 | 相关人员一再催促下,责任人仍没有及时对故障进行处理 |
准备度 | 对故障的发生原因已有充分的预防机制 | 对已有发生的问题,或避免低价错误没有进行干预或规避 |
处理态度 | 在最快时间内处理故障,并积极配合其他相关人员的故障处理工作 | 对故障不重视,态度怠慢、敷衍 |
处理能力 | 遇到技术问题积极寻求解决办法和资源支持 | 没有足够技能进行故障处理 |
处理结果 | 系统在最短时间内完全恢复,故障影响降到了最低 | 故障没有完全解决;由于处理过程不及时或不完善导致故障影响(范围、金额、投诉量、恶性舆论等)有所扩大 |
后续措施 | 对故障发生的原因进行总结,制定同类故障预防规避措施 | 拒绝对故障原因(除不可抗力因素以外)进行总结和制定预防/规避措施 |
运维响应级别
运维响应级别是规范运维日常工作,故障应急响应方面的标准流程。针对业务部门的请求进行分类,并对运维相关人员作出相关约束。所有运维工作尽量在计划内处理,尽量避免计划外操作情况发生。
运维级别 | 内容 | 计划内 | 计划外 |
---|---|---|---|
一级运维 | 常规工作:正常的业务系统升级,备份,监控状态查看,值班巡检,查看及简单修改等不影响业务系统运行的操作。 | 提前三天申请排期 | 工作时间响应处理 |
二级运维 | 非紧急情况:发现常规bug,不修复不影响数据和结果。并且短期内不会造成严重问题。 | 提前一天申请排期 | 工作时间响应处理 |
三级运维 | 紧急情况:严重bug,设备故障。不操作会造成严重后果之类的情况。 | 提前一小时申请 | 24小时响应处理 |
四级运维 | 非常规操作,重装系统,硬件升级。网络割接等,必须暂停业务的情况。 | 提前一周偶申请 | 尽量避免计划外实施,出现后根据事情缓急程度由领导制定。 |
运维应急响应流程
以外情况应尽量避免但无法完全避免,规范应急响应流程是有必要的。流程如下所示。
评论 (1)