故障定义

1、影响功能正常使用的现象（服务中断、服务质量下降），服务不能执行规定功能的状态

2、用户反馈的大面积线上体验问题上述定义是理论层面的，实际工作中，会根据故障评分定级模型对线上问题进行分值定级考量，从五大维度进行评估：受影响业务功能、影响范围、影响量级、影响时长和受影响业务个数，根据维度对应的权重比例进行评分加权求和，分值大于40分的线上问题则定义为故障，线上问题一般通过以下方式获取：各类监控系统、全国运营POC反馈渠道、SSC对接群。

连锁故障：由于正反馈循环（positive feedback)导致的不断扩大规模的故障。例如；某个服务的一个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例向多米诺骨牌一样一个一个出现故障

故障级别

1.紧急故障A

网络、应用服务器、数据库服务器宕机，造成EBS无法作业超过20分钟。

系统崩溃，用户无法读取数据超过20分钟

2.严重故障B

EBS口传递数据错误或者缓慢，导致EBS业务无法使用超过1小时；

与结算相关接口错误引起的重复付款，与账务相关程序创建错误，账务错乱

3.一般故障C、D

由于数据或者设置原因引起的会计科目创建不成功

日记账无法过账

请求运行缓慢，导致账务延迟生产超过2小时

4.轻微故障E

操作错误，职责应用不正确导致报表无法提取

请求参数异常，提取数据正确

报表错误或格式修改​

故障报告字段故障报告内容包含5个方面：故障描述、故障影响、故障原因、事件过程、改进措施；涉及的主要字段如下：故障现象故障发生时的业务表现故障时间

1、 发现时长（分）=故障报警（内外部用户报障）-故障发生时间（大部分是上线/变更时间）原则上：如报警发现，则几乎为零。如果是用户投诉，时间较长。针对超过5分钟则单独备注。

2、 故障组响应时长（分）=故障组响应时间-故障发现时间

3、 业务响应时长（分）=业务响应时间-故障发现时间

4、 根因定位时长（分）=根因定位时间-业务响应时间

5、 故障处理时长（分）=故障止损时间-业务响应时间

6、 故障持续时长（分）=服务影响时长（分）=故障止损时间-故障发生时间7、 故障上报时长（分）=故障上报时间-发现时间（注：持续时长未超过5分钟的线上问题不记为故障)

发现方式

1、人工上报-用户反馈，

2、人工上报-内部反馈，

3、监控报警-故障组报障，

4、监控报警- RD发现

故障归类故障原因从三个角度进行描述

1、根本原因：导致故障发生的最本质原因，对故障起到关键作用、决定作用的原因

2、触发原因：导致故障发生的导火线，直接诱发故障发生原因，或是什么动作造成故障的产生

3、延长原因：故障处理时长超过30min的原因

根据故障原因的不同，对根本原因和触发原因进行归类，类别如下：6大类：变更类、容量/性能类、安全类、第三方、代码类、设计类18小类：有变更与无变更两类

1、角色变更类---运维变更（SRE）、网络变更、数据库变更（DBA）、配置变更、数据变更（业务）、上线/下线发布、上云变更（容器）、代码变更设计类---非变更类—容量/性能类、安全类、第三方、代码类、设计类

2、过程变更：方案阶段、测试阶段、上线阶段、验收阶段无过程

3、细类变更-方案阶段-系统设计不合理变更-方案阶段-应急预案不足变更-方案阶段-服务混部不合理变更-方案阶段-方案评审不足变更-方案阶段-方案缺失变更-方案阶段-方案评审缺失

根本原因大类-小类

变更类-运维变更-线上误操作

1、变更类-运维变更：因为运维变更（无论任何形式的变更）触发的故障

2、变更类-线上误操作：对线上环境进行误删除、kill之类的操作导致的故障

3、变更类-变更流程不规范：变更的流程存在隐患，有导致故障发生的风险；或变更本身流程无问题，进行变更时未按照流程进行

4、变更类-数据变更：业务方由于数据修改或者数据导入引发的故障，不包括运维的数据变更

5、变更类-配置变更：业务方由于修改配置（界面配置非配置文件）而导致的故障，除去运维类的配置变更类

6、容量/性能-非资源类：性能问题，可通过参数调整、逻辑优化等措施避免

7、容量/性能-资源类：需资源扩容才可根治，或资源提供方使用不当导致的故障

8、代码类-代码逻辑类：代码逻辑问题、代码bug引发的故障

9、代码类-代码性能类：代码不健壮

10、安全类-网络爬虫：爬虫导致的

11、安全类-Ddos攻击：恶意攻击系统

12、第三方-硬件故障：任何硬件非人为原因损坏 导致的故障

13、第三方-配置问题：第三方配置修改导致的

14、第三方-软件故障：技术架构中用到的任何OS，软件在特殊场景下，BUG被触发导致故障；第三方提供的服务故障

15、第三方-局方故障：ISP，根域服务，IP被封等外部单位故障导致的问题（局方：运营商）

16、设计类-系统设计不合理：代码不健壮，可以通过参数调整，逻辑优化等措施避免

14、设计类-版本不兼容：系统底层架构不统一，在升级过程中或新版本与老版本不兼容导致问题出现

15、设计类-配置不当：配置有隐患，后期因其他因素触发导致故障

16、设计类-应急预案不足：系统底层架构不统一，在升级过程中或新版本与老版本不兼容导致问题出现

17、设计类-服务混部不合理：服务混合部署不合理

18、设计类-技术方案评审不足：方案执行前，评审不到位

触发原因常见归类：变更类、流量类或其他故障级别

故障根据不同的分值划分为A、B、C、D、E五个等级，其中

1、重大故障：故障级别为A级的故障，分值>85分

2、严重故障：故障级别为B级的故障，75分<分值≤85分

3、一般故障：故障级别为C、D级的故障，40分<分值≤75分

4、E级（<40分）不记为故障，只做一般问题记录

责任部门

原则

1、依据根本原因和触发原因划分，

a、若因流量增加触发故障，流量增加超过3倍（原来x，现在3x），追责触发原因部门

2、责任部门尽量唯一，最多不超过2个

3、非qa直接导致的故障（如上线流程、上线工具等），不建议列入qa。对qa考核时，可参看其所负责的模块故障情况

分类

根据根本原因分类，责任部门定义如下：

1、机器宕机、操作系统类故障——机器所在部门；

2、代码bug类故障——代码服务所在部门；

服务：WEB服务、数据库服务、给应用系统提供的基础服务等

3、应用系统类bug、系统使用第三方、开源软件类bug——系统所在部门

4、变更类故障——变更方所在部门

5、第三方故障——追责引入第三方付费服务的部门，强依赖第三方服务部门无有效止损措施控制故障影响面的扩大，同样追责

改进措施

在故障报告整理好后，我们会组织复盘会针对故障中出现的问题分析讨论，从预防和治理的角度提出优化方案

1、所提改进措施要对应到具体人，并明确完成时间

2、如果所提改进措施耗时较长，超过1个月则需进行拆分，按照时间阶段记录

3、改进措施任务类型：预防、流程、缓解、降级、演习、原因排查等

应广大粉丝要求，我们建立了一个【PMO前沿交流群】，小伙伴们热情踊跃，目前人数已经上万人了，不能直接进群啦，想要进群的添加小编微信，拉你进群。两个添加其一即可！

欢迎加入中国最大的PMO&PM社群