【方法论】如何及时发现故障（脑图展示）

随着项目系统的上线发布，如何在系统的日常运行之中及时地发现其存在的故障是一项很关键的工作。

试想一下，用户来电反馈订单无法支付、App 无法登录，研发发现下单 QPS 曲线同比下跌，这些都是事故发生时的现象，虽然现象不完全等于故障点，但通常最早出现异常现象的地方和故障根因关联最大，所以第一时间发现异常对于锁定问题至关重要。

故障发现就是系统异常反馈到研发的过程，这里猫哥画了一个简单的脑图，分类说明故障发现的几种常见方式：

负责开发的同学往往更关注技术类指标，比如 QPS、CPU LOAD，而管理者则应该更多地从业务场景出发，结合需求来看系统的业务监控覆盖是否完全。业务监控往往更加敏锐，但是要想用好，就需要对业务和系统有较长链路的理解和掌握。

比如用户进入餐厅后会添加菜品到购物车，并跳转到结算页完成下单。菜品服务会提供一个查询接口，根据餐厅 ID 返回菜品信息。假设这个查询接口最近做了变更，在库存逻辑的处理中埋下了一个 Bug，导致实际库存小于 50 时，库存的返回值被默认为 0，而其他数据则一切正常。

那么此时类似 CPU、内存、I/O 等技术指标可能都不会异常。而因为是部分实际库存小于 50 的菜品被影响，用户依然可以添加其他菜品到购物车，但因为部分菜品库存为 0，用户想吃却没办法下单，那么这个时候订单成交量的环比、同比曲线就有可能下跌，而这个现象会让我们感知到异常，进而排查问题处理。

总的来说，人工的被动反馈在时间和速度上有较强的不确定性，很容易出现“小故障 * 长时间 = 大事故”的情形。而纯粹的技术指标监控又会忽略掉接口正常响应，但是业务异常的场景，只有两者结合，通过监控告警，最大程度上缩短故障感知的时间，才能早发现早解决，减少业务影响。