《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.1 故障等级定义

简介: 《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.1 故障等级定义

3.1 故障等级定义


一个完整的故障等级定义一般由业务场景(功能模块)+影响面+对应等级组成。从功能受损后对用户实际受影响的程度可以简单将模块分为核心功能、次核心功能和非核心功能等模块,核心功能模块主要是直接影响用户使用服务的,非核心模块影响到用户体验,但是对主路径功能没有重大影响的。例如,交易创建和支付类的毫无疑问是核心模块,其他查询类,展示类的功能为非核心功能模块。次核心功能模块,比如说退款、提现、绑卡等功能,会间接影响用户使用核心功能,但用户可接受一定时间的不可用的,介于核心和非核心之间的一种分类。


影响面主要是用来描述某个功能模块受损后的现象和结果,最常使用的指标是成功量、成功率、耗时、影响用户数、失败量、影响时长等指标,其中使用成功量比较常见且直观。


最后,根据业务层面对影响面的判断,对不同级别的影响面匹配不同的故障等级(P1-P4)。


标准化故障等级定义制定的思路:

依据业务属性先将业务划分为大的子类(业务整体技术架构层面)。

将每个子类业务里的核心模块和次核心、非核心模块区分开来(功能层面)。

根据各功能模块的业务量级去适配不同的影响面及故障等级定义模板。


其中根据业务量级适配不同的影响面及其对应的故障等级定义模板是这个思路的重点。下面来举例解释(仅作参考,业务可根据自身实际情况酌情使用部分推荐值):


对于核心功能:

•大体量的情况下(例如:高峰期分钟级超过1000TPS,日均100W以上),建议分钟级成功量下跌30%及以上定义为P1。

中体量的情况下(例如:高峰期分钟级100-1000TPS,日均10-100W),建议10分钟内总体成功量下跌45%及以上定义为P1。

•小体量的情况下(例如高峰期分钟级10-100TPS,日均1-10W),15/30分钟内总体成功量下跌45%及以上定义为P1。

•更小体量的业务(日均小于1WTPS),可使用60分钟内总体成功量下跌45%及以上定义为P2。

在最高故障等级P1确定的情况下,依次降低影响面,形成P2-P4的标准(大体

量业务的主路径失败可以考虑P3起,不设置P4级别故障),如30%-20%,

45%-30%等影响面对应剩余等级。


对于次核心功能(如营销类,注册类等业务),可以在核心功能的基础上统一降低一个级别;

对于非核心功能(如查询类,后台使用等业务),可以在核心功能的基础上统一降低两个级别;


由此生成一个故障等级定义的模板可以如下所示(实际使用中可适当精简,避免过于冗余)


image.png

故障等级定义制定好以后,需要得到技术负责人的审批,以及后续面向技术团队和上下游团队的公示,必要时需要进行宣讲。


相关文章
Bug级别判定法则
Bug级别判定法则
1117 0
|
9月前
|
运维 自然语言处理 算法
云栖实录 | 大模型在大数据智能运维的应用实践
云栖实录 | 大模型在大数据智能运维的应用实践
1053 3
|
自然语言处理 运维 Cloud Native
运维大模型探索之 Text2PromQL 问答机器人
本文主要介绍将AIGC技术运用到可观测领域的探索。
1666 96
|
存储 运维 Prometheus
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.1监控预警体系建设
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.1监控预警体系建设
425 0
|
算法 BI
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
606 0
十年磨一剑:蚂蚁集团可观测性平台 AntMonitor 揭秘
蚂蚁集团的业务种类繁多,兼具金融级的“稳” 和互联网的 “快”,支撑又快又稳的业务发展需要完善的稳定性保障体系, 这个体系的基石就是可观测性平台-AntMonitor 。 早在2011年前,监控平台就已经完成初代建设,在2012到2017年这五年间,蚂蚁监控技术团队抽象出了业务视角监控牵引的模式,大大提升了核心业务的故障发现能力,同期研发了可视化引擎与易用的配置系统。为了支撑双11等大规模海量计算场景,在底层数据技术上做到了实时稳定的大规模日志和指标处理能力。随着这些能力的完成,可观测平台的产品也逐渐成熟。
|
移动开发 监控 前端开发
从0-1的建设云上稳定性
本文将从前后端的视角整体看下我们在云上稳定性治理的一些路径和经验。首先从平台的系统架构模型出发,站在全局视角看下整个平台的风险。
根因分析(Root Cause Analysis)
根因分析(Root Cause Analysis)
964 1
|
运维 监控 双11
起底:“问题终结者”GOC的真实战力
在阿里巴巴隐藏着很多神秘的部门,GOC就是其中之一,你在互联网甚至搜不到关于它的一丁点儿信息。但就是这么一个“名不见经传”的部门,却“指挥”着阿里巴巴旗下几乎所有业务的运行情况。
9245 0