《云上业务稳定性保障实践白皮书》——三.故障管理体系——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

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


目录
打赏
0
0
0
0
83
分享
相关文章
稳定性保障6步走:高可用系统大促作战指南!
年年有大促,大家对于大促稳定性保障这个词都不陌生,业务场景尽管各不相同,“套路”往往殊路同归,全链路压测、容量评估、限流、紧急预案等,来来去去总少不了那么几板斧。跳出这些“套路”,回到问题的本质,我们为什么要按照这些策略来做?除了口口相传的历史经验,我们还能做些什么?又有什么理论依据?
稳定性保障6步走:高可用系统大促作战指南!
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
499 0
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.1监控预警体系建设
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.1监控预警体系建设
364 0
稳定性之故障应急处理流程
尽管可以通过稳定性体系建设,来避免出现生产系统故障。但是仍然无法彻底避免一点风险都不会产生,当稳定性风险产生后,怎么快速协调组织,缩短故障时长,科学的流程呢?
稳定性之故障应急处理流程
《SRE实战》实践
SRE 全称是 Site Reliability Engineering,最早是由 Google 提出,并且在其工程实践中发扬光大。 他们还出了一本同名书籍「Site Reliability Engineering」, 让这个理念在互联网工程师圈子里广泛传播。
1650 0
1-5-10 快恢在数字化安全生产平台 DPS 中的设计与落地
11 月 5 日,在 2022 杭州 · 云栖大会上,数字化安全生产平台 DPS 重磅发布,助力传统运维向 SRE 转型,在数字化安全生产平台 DPS 重磅发布中提到了 DPS 诞生的背景,希望解决的企业问题以及核心的功能点,其中提到了 DPS 目前的两大业务场景:"1-5-10"故障快恢和"变更三板斧"故障预防,本文将阐述 “1-5-10”故障快恢场景的背后的设计与实现。
1-5-10 快恢在数字化安全生产平台 DPS 中的设计与落地
起底:“问题终结者”GOC的真实战力
在阿里巴巴隐藏着很多神秘的部门,GOC就是其中之一,你在互联网甚至搜不到关于它的一丁点儿信息。但就是这么一个“名不见经传”的部门,却“指挥”着阿里巴巴旗下几乎所有业务的运行情况。
8381 0
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.4 故障复盘
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.4 故障复盘
398 0
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.1故障发现
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.1故障发现
320 0
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.2故障应急
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.2故障应急
478 0
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问