前言
业务和产品的线上质量是研发团队的生命线，也是支撑业务快速试错，小步快跑的前提。但是现代计算机系统已经极端复杂，除了要应对日益复杂的软件系统同时也要适配不同的硬件环境。系统是人开发的，就不可能百分之百的不产生问题。作为一名developer可以说我们每天不是在写bug，就是在写bug的路上。
那么作为一名技术Leader，如何看待稳定性？如何应对故障？如何从不断出现的线上事故中吸取足够的经验？会成为一个团队能否做好稳定性的关键。发生事故之后的事故复盘就成了关键。事故复盘的目的不是追责，查找根因、改进框架、完善应急、总结经验才是我们想要的。我们聊一聊如何从不同角度给事故定性。
线上事故千千万，但总是有章可循。
按照性质分为可用性事故和资损性事故
-
可用性事故： 可用性事故通俗的讲就是由于技术原因导致系统功能部分获取全部功能不可用，业务无法完成正常流程或者无法提供有效服务。比如无法登录、接口Bug、列表不展现或者展现不完整，闪退等。这类事故通常都是由于技术本身导致。这里包括功能实现设计、接口实现、预案不足等。
-
资损类事故：资损类事故通常都是系统功能正常，但是因为实现逻辑或者计算错误等原因使业务方产生了资金损失，例如价格错误，优惠券错发，打折错误，或者系统漏洞等。这类事故一般影响较大，影响周期长，防控成本高等。
根据事故严重程度分
- P0（致命问题）：系统完全不可用，或者产生较大资损。
- P1（严重问题）：核心功能丧失或者次要功能大部分丧失，同时产生资损。
- P2（一般问题）：次要功能丧失或者产生轻微资损。
- P3（轻微问题）：界面显示不正常，提示性问题不正常，不影响用户重要功能使用。
按照分类可以分
按照分类可以分为外部依赖类故障、运营类故障、产品需求类故障、系统质量类故障
- 外部依赖类故障： 依赖上下游功能不正常导致业务流程受阻，引起功能不正常。例如第三方sdk，客户端依赖接口不可用等。
- 运营类故障： 由于配置错误导致系统异常不可用。例如营销活动少配置字段或者配置错误等。
- 产品需求类故障： 产品方案存在缺陷，功能上无法自洽，导致的线上问题。
- 系统质量类故障： 例如系统Crash/Anr/响应超时等。
