故障定义
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、改进措施任务类型：预防、流程、缓解、降级、演习、原因排查等
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。