故障定级和定责
一、背景
往往在故障复盘的时候故障怎么定级、定责我们没有抓手容易扯皮推诿，这篇文章从什么是故障、故障分类分级、业务重要级别结合业界互联网公司经验来帮你在企业中怎么做故障定级和定责，希望对你所帮助。
互联网产品提供7*24小时服务，而因配置变更、程序Bug等原因导致服务不可用是影响服务持续运行的重要原因，为了提高各业务产品的稳定性，规范各业务线的变更、故障响应，对故障"分级和定责"是有一定的必要性的。
故障定级和责任分配的目的并非是为了追究个人责任，而是为了更有效地解决问题、提高系统稳定性，并确保业务连续性。通过对故障进行分类和分级，团队能够更有序地响应不同类型和严重程度的问题，优先处理对业务影响较大的故障，从而降低潜在的损失。责任分配则有助于团队更好地协同合作，确保每个成员能够专注于其擅长的领域，共同追求问题的迅速解决。在这个过程中，强调的是整个团队的合作和学习，以推动持续改进和提高整体服务水平。
故障怎么定级和定责，下面先来看看什么是故障。
二、什么是故障？
百度百科：不能执行某要求功能的一种特征状态。它不包括在预防性维护和其他有计划的行动期间，以及因缺乏外部资源条件下不能执行要求的功能。
ITIL中的定义 : ①非计划性的IT服务中断，或者IT服务性能的下降。②配置项的失效，即便没有影响到服务。
阿里云产品-运维事件中心定义：在日常运营中，无论什么原因导致业务服务中断、服务品质下降或用户服务体验下降的现象，称为故障，但不包括用户侧环境或用户自身操作引起的问题。比如：
1. “用户体验下降”说明故障的核心要关注用户感受，可通过客服渠道获知用户投诉，也可通过监控渠道推知用户端的使用情况；
2. “服务中断、服务品质下降”说明即使用户没有投诉（甚至没有用户使用），但是如企业提供的服务出了问题，也是故障；
3. “无论什么原因”指无论是企业自身原因，还是第三方如供应商、运营商的原因，只要影响到了用户，就都是故障。
在日常运营中，无论什么原因导致业务服务中断、服务品质下降或用户服务体验下降的现象，称为故障，但不包括用户侧环境或用户自身操作引起的问题。
三、故障定级
3.1 业务分级
要给业务故障定级，得先知道业务的重要性，不同的业务相同的场景定义的故障级别也是不一样的
| 业务 | 说明 |
| 核心业务(L1) | 公司的核心业务，发生故障影响公司业务连续性、造成资损、影响公司形象 |
| 重点业务(L2) | 重点业务不可用影响核心服务的稳定性，并造成部分用户不能使重点业务 |
| 重要业务(L3) | 重要业务不可用会对重点业务稳定性有一定影响，不影响核心服务的稳定性 |
| 非核心业务(L4) | 非核心业务不可用不直接影响线上服务的可用性，比如技术运营平台或者公司内部系统 |
3.2 故障分类
故障分类一般是围绕可用性的角度上进行一些分类，大体上可以分为5类。
| 类别 | 说明 |
| 配置变更类 | 70%的故障是由配置变更带来的，比如代码上线、数据库、服务器、网络、脚本等配置变更 |
| 安全类 | 业务漏洞导致数据泄露、服务被DDOS攻击、业务被挂马等 系统被入侵，数据被篡改，被勒索等 |
| 网络类 | 运营商网络故障、域名劫持、网络设备故障、带宽不足等 |
| 三方类 | 业务以来的三方服务比如CDN、消息、推送、支付、云服务商故障等 |
| 突发流量类 | 突发事件、社会热点、活动流量预估不足导致的业务故障等 |
3.3 故障定级维度
故障定级的维度是要根据自己公司的业务特性来做选择，下面是一些互联网公司故障定级维度供你参考。
| 公司 | 维度 |
| 阿里云 | 重要性、影响面、持续时间 |
| 钉钉开放平台 | 业务模块的“重要性”，“影响面大小” “处理时长” |
| 蘑菇街 | 根据错误预算消耗的比例来指定故障的级别 |
| 美图 | 重要性、影响面、持续时间、发生时间段 |
3.4 故障级别
| 级别 | 等级 | 说明 |
| P1 | 重大故障 | 可用性：核心功能或重点业务完全不能使用 安全：核心数据损坏、丢失、泄露，比核心数据如个人信息 资损：资损超过5万 用户体验：用户反馈超过10人，付费用户反馈超过3家 |
| P2 | 严重故障 | 可用性：部分主要功能不能使用或次要功能大部分不能使用 安全：部分核心数据损坏、丢失、泄露 资损：资损超过1万 用户体验：用户反馈超过5人，付费用户反馈超过1家 |
| P3 | 一般故障 | 可用性：次要功能不能使用，用户体验变差 资损：资损超过2千 |
| P4 | 轻微故障 | 可用性：非核心业务部分不能使用 用户体验：产品文案排版、错别字 |
3.5 故障定级
这里给予业务系统级别、故障时长、影响用户量级制定的故障等级，大家可以根据自己公司的业务情况参考
| 业务系统 | 故障时长 | 影响全量用户 | 影响部分用户（超过30%） | 影响少量用户 |
| L1 | 超过60分钟 | P1 | P1 | p2 |
| L1 | 超过30分钟 | P1 | P2 | p3 |
| L1 | 超过10分钟 | p2 | P2 | p3 |
| L1 | 10分钟以内 | p3 | P3 | p3 |
| L2 | 超过60分钟 | P1 | P2 | p2 |
| L2 | 超过30分钟 | P2 | P2 | p3 |
| L2 | 超过10分钟 | p2 | P3 | p3 |
| L2 | 10分钟以内 | p3 | P3 | NULL |
| L3 | 超过60分钟 | P2 | P2 | p3 |
| L3 | 超过30分钟 | P3 | P3 | p3 |
| L3 | 超过10分钟 | p3 | P3 | p3 |
| L3 | 10分钟以内 | NULL | NULL | NULL |
| L4 | 超过60分钟 | P2 | P3 | p3 |
| L4 | 超过30分钟 | P3 | P3 | NULL |
| L4 | 超过10分钟 | NULL | NULL | NULL |
| L4 | 10分钟以内 | NULL | NULL | NULL |
3.6 业绩互联网公司故障定级定义
3.6.1 钉钉开放平台
参考 钉钉开放平台应用故障定级标准
3.6.2 蘑菇街
参考 运维-运维体系标准化之故障管理
下面是两个定级参考范例。首先是交易系统，主要以钱为衡量指标。
另一个是IM即时通信App的故障定级标准。
3.6.3 美图
参考：围绕故障管理谈SRE体系建设
四、故障定责
故障定责可以参考以下维度
高压线原则
未经发布系统，私自变更线上代码和配置
未经授权、严格的方案准备和评审，私自在业务高峰期（9点19点）进行硬件和网络设备变更
未经授权、严格的方案准备和评审，私自在业务高峰期（9点19点）进行组件变更
未经授权，私自在生产环境进行调测性质的操作
未经授权，私自变更生产环境数据
变更执行
比如变更方没有及时通知到受影响方，或者事先没有进行充分的评估，出现问题，责任在变更方；
如果通知到位，受影响方没有做好准备措施导致出现问题，责任在受影响方；
变更操作的实际影响程度大大超出预期，导致受影响方准备不足出现故障，责任在变更方。
服务依赖
比如私自调用接口，或者调用方式不符合约定规则，责任在调用方；
如果是服务方没有明确示例或说明，导致调用方出现问题，责任在服务方等等
健壮性原则
根据服务的健壮性定责。例如服务A挂掉导致服务B出问题，这时候责任不能完全划分到服务A上，还要考虑到服务B本身的健壮性；（缓存redis挂了，依赖方业务挂了）
其他
出现core或oom导致的问题，不管触发的原因，谁写的代码谁的团队承担；
演习时，操作者不承担责任，哪个系统挂掉，对应的团队承担；
一个小的触发因素导致一个超大的故障时，恶化的模块承担责任，而不是触发者；
每个模块有责任保护自己声称容量以内的流量和用户，超出流量可以限流但不是不能超时，谁超时谁的责任；
第三方服务故障，比如机房故障。
五、故障处罚
等级处罚P1责任人xxx元 Leader xxx元，公司级通报P2责任人xxx元 Leader xxx元，公司级通报P3责任人xxx元 Leader xxx元，产品线通报P4小组内通报金额大家可以视情况而定，处罚金额P1到P3级别逐级减少。处罚金额可以用于团队团建、购买书籍、团队内部激励等。
在面对故障时，我们要明确，我们的目标并不是通过处罚来追求责任，而是通过解决问题和共同学习，提高我们的团队整体素养。故障处罚并非目的，而是帮助我们更好地理解、预防和应对未来可能出现的问题。
每一次故障都是一个学习的机会，是我们不断提升的契机。我们相信，通过共同努力，我们能够更好地理解系统运作的复杂性，改进我们的流程，从而提高我们的整体稳定性。
团队的力量在于我们共同努力、相互支持的精神。让我们一起积极面对问题，不断改进，不仅仅是为了解决眼前的故障，更是为了构建一个学习型、攻克难题、能打胜仗的团队文化。