生产故障划分
1.故障等级定义
故障等级定义，不同的业务形态，不同的公司团队，有不一样的划分标准，下表列举了一般常见的维度和标准
| 线上故障等级 | 标准 | 回滚 |
|---|---|---|
| 【P0】 致命问题 | 安全：影响线上生产核心数据安全【1】核心数据定义(丢失、泄漏）；功能：造成系统崩溃、死机，主要功能或重要功能完全不能正常使用；资损：造成资损超过>5W；体验：（1）有效客诉超过>30人或客诉>50人；（2）由于系统问题导致、不能开展业务的核心企业，超过3家 影响范围：针对P0/P1/P2/P3系统[【2】系统级别定义] 影响范围与故障等级，见下表：【3】影响范围与故障等级 | 是 |
| 【P1】 严重问题 | 安全：影响线上生产部分数据安全（丢失、泄露）；功能：主要功能部分丧失或次要功能大部分丧失，或严重误导的提示信息；资损：造成资损超过>1W 体验：（1）有效客诉>5人；（2）由于系统问题导致、不能正常开展业务的核心企业，超过1家。 影响范围：针对P0/P1/P2/P3系统[【2】系统级别定义] 影响范围与故障等级，见下表：【3】影响范围与故障等级 | 是 |
| 【P2】 一般问题 | 功能：次要功能丧失、边界校验不全等； 体验：用户界面交互差或操作等待时间长；资损：造成资损超过>1K 影响范围：针对P0/P1/P2/P3系统[【2】系统级别定义] 影响范围与故障等级，见下表：【3】影响范围与故障等级 | 否 |
| 【P3】 轻微问题 | 功能：界面提示描述错别字、排版问题等用户提示性问题，但不影响执行工作功能或重要功能 | 否 |
| 线上故障分类 | 说明 |
|---|---|
| 外部依赖类 | 是由所依赖的上下游系统的缺陷或不稳定直接导致业务流程受阻，用户体验客诉类事故 |
| 运营质量类 | 由运营或业务人员在进行营销活动创建或线上策略配置错误等导致的一些问题 |
| 需求质量类 | 由于产品方案设计存在逻辑或流程上缺陷直接导致的线上问题 |
| 系统质量类 | 系统存在逻辑或流程缺陷直接导致线上问题，同时还包括性能、稳定性引发的问题 |
【1】核心数据定义
| 核心数据定义 | 描述 |
|---|---|
| 个人敏感信息 | 姓名、出生日期、身份证件号码、个人生物识别信息、住址、通信通讯联系方式、通信记录和内容、账号密码、财产信息、征信信息、行踪轨迹、住宿信息、健康生理信息、交易信息等。 |
| 用户画像 | 职业、经济、健康、教育、个人喜好、信用、行为等。 |
【2】系统级别定义
| 系统级别定义 | 描述 |
|---|---|
| 零级系统(P0) | 为公司核心业务服务的核心系统，一旦发生不可用会直接影响公司核心业务的业务连续性，对所有系统用户造成影响。 |
| 一级系统(P1) | 重点的业务系统，一旦发生不可用，影响核心业务的连续型，并造成大部分内部用户或外部用户不可使用此系统。 |
| 二级系统(P2) | 重要的业务系统，一旦发生不可用存在一定的业务可用性问题，但不会影响核心业务的业务连续性。 |
| 三级系统(P3) | 非核心的支撑系统，一旦发生故障不直接产生业务影响，但会影响少部分内部用户使用此系统。 |
【3】影响范围与故障等级
| 系统分级 | 故障时长\受影响用户 | 全部用户 | 大部分用户（超过 20%****） | 少量用户 |
|---|---|---|---|---|
| 零级系统 （P0） | 超过60分钟 | P0 | P0 | P1 |
| 超过30分钟 | P0 | P1 | P2 | |
| 超过10分钟 | P1 | P1 | P2 | |
| 10分钟以内 | P2 | P2 | P2 | |
| 一级系统 （P1） | 超过60分钟 | P0 | P1 | P1 |
| 超过30分钟 | P1 | P1 | P2 | |
| 超过10分钟 | P1 | P2 | P2 | |
| 10分钟以内 | P2 | P2 | N/A | |
| 二级系统 （P2） | 超过60分钟 | P1 | P1 | P2 |
| 超过30分钟 | P2 | P2 | P2 | |
| 超过10分钟 | P2 | P2 | P2 | |
| 10分钟以内 | N/A | N/A | N/A | |
| 三级系统 （P3） | 超过60分钟 | P1 | P2 | P2 |
| 超过30分钟 | P2 | P2 | N/A | |
| 超过10分钟 | N/A | N/A | N/A | |
| 10分钟以内 | N/A | N/A | N/A |
2.故障报告模板示例
2.1模板参考
| 故障分析报告 | |||
|---|---|---|---|
| 故障编号 | 服务不可用时间 | ||
| 故障开始时间 | 故障结束时间 | ||
| 故障类型 | 责任组（造成该故障的主要责任团队 ） | ||
| 一，问题回顾 | |||
| 故障概况 | 概要描述 | 对事故进行概要描述，写清楚何时？何系统？因何原因？发生什么故障，总体影响是什么（影响用户，服务拒绝还是功能错误？） | |
| 问题经过 | 补充故障的完整时间线，方便回溯内容，以时间顺序详细描述故障 发生（诱发）、 发 展（扩散、隔离）、 发现（测试、监控、内部反馈、用户反馈和客诉）、 处理（止损）过程及其间系统的表现， 重点关注诱发原因、扩散条件、止损动作、止损效果等关键要素， 每句以时间开头，每个关键节点单独写一行。 | ||
| 问题原因 | 描述故障根本原因，以及此原因导致故障发生的逻辑。 | ||
| 故障影响和损失 | 详细描述故障对业务造成的影响以及具体的损失数据，格式： 1，故障影响范围及程度说明 2，损失量情况 损失数据包括：流量损失、收入损失、流水损失、损失占当天的比例。 | ||
| 二，后续改进措施 | |||
| 序号 | 管理措施+技术措施+产品功能 | 负责人 | 期望完成时间 |
| 1 | |||
| 2 | |||
| 3 |
2.2故障响应处理机制
一般生产故障的处理机制故障发现：
- 客户投诉或者业务反馈，研发自我发现
- 监控报警：技术监控，业务监控
2.3思考
- 怎样防止类似的事情发现？
- 为什么会发生这个问题？
- 为什么测试阶段没有发现？
- 为什么系统不能容错？
- 能不能更早发现问- 题？
- 解决过程能不能更快？
- 怎样防止类似的事情发现？
3 .生产故障原因和分类
3.1 故障分类
-
突发流量：热点或突发事件，引发的瞬时流量超过日常峰值或成倍增长，造成性能下降或功能不可用问题
-
-资源使用不均：整体产品线利用率不达标，但有些业务冗余度不足，导致资源不能正确合理使用容量
-
预估不足：对个别业务核心池预估不足
-
网络类：公网拥堵、丢包、专线、网络设备故障、ip被攻击（包括DNS被攻击）、IP被封、域名被封、网络软件BUG、业务部门使用不当、未及时扩容等
-
安全类：被攻击，漏洞被利用等问题，均归为此类
-
局方故障：ISP，根域名服务，电力，空调，光缆等外部单位故障导致的问题。
-
硬件故障：任何硬件非人为原因损坏导致的故障均归为此类。
-
第三方合作公司或接口故障：项目依赖的第三方公司或接口故障
3.2故障分类占比
实际生产中，遇见的故障所占比例(参考)
| 故障分类 | 比例 （%） | 示例 |
|---|---|---|
| 配置不当，操作不当 | 30 | 数据库新加字段，线上忘记添加；配置文件更改位同步，操作不当（设计本身也可能不合理） |
| 代码bug | 50 | 业务考虑不周全，未覆盖所有场景，测试不到位；代码质量或设计问题，各种异常等，包括异常处理； |
| 突发流量+资源问题(包括使用不当，也包括软件特性原理不够深入理解) | 10 | 跟场景有很大关系；电商等领域的促销流量；内容网站的突发流量等；依赖的存储，网络，等自身波动异常等；慢sql，各种主从不一致等； |
| 第三方合作公司或接口故障 | 8 | 依赖的接口有故障；微信认证失败等等 |
| 其他 | 2 | 硬件故障等 |
4.故障处理
- 回滚到稳定版本/紧急修补上线。
- 在日志和代码中搜索错误和异常。
- 添加log日志，创建新的修补程序版本。
- 提交测试，等待测试和发布（数天）。
- 部署预发，获取详细日志，验证问题。
- 发布新版本到线上。