线上故障定级标准

1. 前言：

 **线上故障**是指提供给客户使用的平台服务全部或部分不可用，包括服务性能的降低，如：服务延迟导致用户体验变差。在创业前期，为了抢占市场先机，产品新功能的发布速度追求往往优先于其质量，埋下了很多技术债务，部分技术债务的爆发会引起线上故障，造成客户的体验下降或经济损失。

 故障管理的目标是“尽快恢复服务到正常运行，并且最小化对业务运营的不利影响，从而尽可能地保证服务质量和可用性的水平”。在故障发生后，故障紧急处理小组会定位、分析和恢复故障，并在故障恢复后对故障进行Review和总结，制定出可执行的Actions，以提高故障处理效率和避免类似故障再次发生

2. 故障处理流程介绍

 我们使用禅道 或 公共bug池：  ****  作为跨部门协作工具，线上故障管理也借助于禅道。我们制定了下面的故障处理流程，故障禅道工单遵循该工作流，故障会被建立在 禅道-紧急修复版 执行迭代中。

3. 确认故障与通知协调人

当收到客户、内部员工或监控上报的潜在故障时，报告人会尽快确认故障的有效性。当确定是个故障后，会在禅道提交一个故障工单或者直接群里反馈，并通知故障协调人。协调人确保公司内业务部门、技术和产品部门被通知到位，同时将故障上报到对应群里，故障原因排查和讨论会在该群里或拉单独的故障处理群进行。

故障录入的2种方式，2选1即可

1. 禅道对应录入地址：

2. 对应线上bug池录入地址：

4. 定位/处理故障

  为避免无关消息干扰，故障处理人组建故障紧急处理小组，以提高故障处理效率。故障处理人在定位到问题后需将故障原因和预计多久修复同步给协调人。对于处理时间比较长的故障，紧急处理小组会每隔半小时对相关业务部门同步一次故障处理进展。

5. 故障恢复

  如确定是发布引起的故障，需将代码回滚到故障前的某个稳定版本。故障恢复后，故障处理人需跟业务影响方确认是否有数据需要修复。如有，需将影响情况反馈给协调人，并配合业务方尽快修复数据。

6. 组织故障Review

   故障Review针对的是P1、P2级别，全员邮件通知，一般安排在故障处理结束后24小时内，包括故障标题、故障回顾、事件回顾、故障原因、故障总结、改进计划等，其产出物为：故障分析报告。

故障分析报告模板见其它文章

7. 线上故障定级标准

故障定级分为P1、P2、P3和P4四个等级（依次降低）

7.1 符合下列条件之一的，为P1级事故：

安全：影响线上生产核心数据安全（丢失和泄漏）
功能：主要功能完全不能使用，主业务接口阻塞，系统崩溃、死机、瘫痪
资损：造成资损损失超过 >5k
影响范围：
有效客诉超过 >3
由于系统问题导致、不能开展核心业务的核心企业超过1家

7.2 符合下列条件之一的，为P2级事故：

功能：线上主要功能部分丧失或次要功能大部分丧失报错，或严重误导的提示信息
资损：1k< 造成资损损失 <5K
影响范围：
1< 有效客诉 <=3人

7.3 符合下列条件之一的，为P3级事故：

功能：线上次要功能异常，但通过其它方式仍然能正常使用，边界校验不全导致的报错但是不影响正常功能使用
体验：用户界面交互差或操作等待时间长
资损：造成资损损失超过 <1k
有效客诉 =1

7.4 符合下列条件之一的，为P4级事故：

界面提示描述错别字、设计排版等用户提示性问题，但是不影响业务功能并且没有收到客诉

8. 线上故障的处理措施及时效

等级	处理措施及负责人	处理时效
P1	所有系统关联方进行问题排查, 找到问题后第一时间修复	Bug确认1小时内必须有解决方案（包含临时方案和远期完整方案），Bug确认3小时内必须至少有临时方案解除当前业务影响。Bug确认24小时内，必须有完整解决方案彻底杜绝该问题。
P2	整个系统研发组进行问题排查, 找到问题后第一时间修复	当天发现当天修复，测试上线
P3	分配研发人员进行问题排查, 排期进行修复	视改动大小和紧急程度决定上线时间，一般跟着周二、周四正常迭代上线
P4	分配研发人员进行问题排查, 排期进行修复	视改动大小决定上线时间，一般跟着周二、周四正常迭代上线
需求类	产品提交新需求	视研发团队任务排期而定

9. 故障参考指标说明：

9.1 核心数据包括：

   企业信息
   企业业务线价格
   数据泄漏
   等结合业务

9.2主要功能包括：

  根据业务写

9.3. 有效客诉

  客户出现负面或者敏感词汇比如：投诉，强烈要求退款等，就直接上升为 P1和P0 事件
  其他情况，需要定性为客诉，需要公司层面出面统一定性

9.4. 资损

   需要公司层面出面统一定性

9.5. P1 和 P2 故障定级

   一般故障可以根据定性标准定级P0、P1
   对于存在异议的定级可直接上升到公司层面来定性