备注说明：相关总结属于个人学习笔记，请勿商用，感兴趣的可在极客时间订阅该《乔新亮的CTO成长复盘》专栏学习，谢谢~
在企业的监控体系建设完成前，异常设计一般就可以独立发挥作用，达到快速见效的目的。
异常管理可以提升 IT 团队快速定位问题的能力、降低生产系统异常出现的频次和数量，更重要的是，它是让 IT 团队从面向技术，转为面向产品、面向用户的关键步骤，所以我们这里独立出来讲。
异常的一般定义 ：导致系统不能正常工作的问题就是异常
但是忽略了：可能当下未必会对生产环境产生影响，但不代表未来也不会；有些异常，可能在流量压力小时未必会出问题，但不代表流量压力大时也不会。
平时大家打印了log warning error 等 大家习惯忽略了这些信息，最终导致了严重故障的出现。
那些被忽视掉的异常
例子1：
一家电商平台缺货的概率可能只有 2%，配货成功率高达 98%，
但当平台用户数量达到一百万时，就会有多达两万人受到缺货问题的困扰。
这两万人中，可能只有 30% 的用户有在社交平台发帖的习惯。
也会有 6000 人出现在各大社交平台上，发帖吐槽该电商平台的缺货、质量问题。 影响企业形象
许多你不太关注的异常，最终会在产品层面对用户体验产生恶性影响。那些用户经历的坏体验，对于开发人员来说，可能只是一个简单的错误提示而已。
例子2:
C++ 服务器开发的同学，讲过他们企业发生的趣事。他们经常会处理许多到不同 CDN 节点的高频下载请求，但会有一部分下载超时或耗时增加的异常出现。 他们当时的做法是，当下载耗时超过 200ms 时，在 Log 中打印 Warning ；当下载因超时而失败时，设置定时重试，并在 Log 中打印 Error 。
然后呢？
重试一般都能成功。
如果一直不成功呢？
那可能就会导致业务出问题了，研发就得起床查 Log 了。
如果重试可以成功，但当并发压力增大时，来不及多次重试呢？
上面的“异常设计”时，并没有实现给用户的契约。对于电商平台而言，没有实现“成功下单 = 成功配送”的契约；
对于那位做 C++ 服务器开发的同学来说，没有实现给其他系统模块的“准时下载”的契约。
对于异常设计的认知、方案和治理
对于异常设计，五点认知
- 异常一定要消灭：有异常，基本就意味着系统存在风险，一定要消灭异常
- 异常一定要管理：消灭异常是个长期工程，短期要通过管理行为来进行控制
- 对异常的处理水平，会极大影响产品的用户体验
- 用户规模越大，异常的影响往往越大； 每个异常都要有具体的负责人
- 没有和具体的负责人一一对应，往往就意味着管理流于形式； 与终端用户相关的异常，要以最高优先级处理：即便是 IT 研发，也要以用户为中心
“交易体系”和“协同体系”的设计差别。
交易体系负责处理相对稳定的业务流程，协同体系则是当异常出现时，需要接入的流程。
比如客户要订 500 斤白菜，由交易体系来完成，库存满足、正常履行；库存不足时，则需要协同体系完成剩余流程。
异常设计一般包含异常注册、异常事件触发、异常协作流程以及异常统计。
异常注册信息：
- 异常的 ID 和名字
- 对异常的描述
- 异常出现的代码位置
- 负责此异常的研发、测试和产品人员
- 异常发生时的代码版本
- 当时使用的异常处理程序
企业要建设异常中心，各个系统都要在异常中心注册异常，一旦运行阶段出现异常，就要抛出异常事件，触发异常处理的协同流程。
也可以通过 收集日志中的异常，继而进行归类处理，再通过异常治理完成异常的注册，这样就间接达到了目标。
管理层也要关注异常的处理情况
- 异常的数量
- 异常的发生频次
- 系统内异常数量的增速或降速
在季度末、年末，我们会对管理层进行绩效考核，并将异常管理情况纳入考核体系，以此实现异常治理的闭环。
总结：
实现用户体验驱动内部经营完善的经营逻辑。
只要仔细观察一家企业是如何对待异常的，就可以判断这家企业的精细化运营和管理水平。
对于直接影响用户体验的问题，要有契约精神，快速迭代；对于企业宏观角度的异常治理，要坚持长期主义，不断优化。
企业的一个核心竞争力就是持续进化的能力。因此，在保持进化的过程中，企业发生的任何问题，都要纳入到异常管理流程中，将异常管理数据化、产品化、系统化，通过持续的治理和数据分析，让企业不断进化，最终建立竞争优势。
