比故障定位更重要的是：故障定界

前面发的Observability的文章，引起了不少的共鸣，在群里或私聊时很多朋友提到一个点：

故障处理时，运维的逻辑是快速恢复，所以根因是什么不重要，但是不知道根因发生的位置在哪儿，怎么做应急处置呢？

这是个非常好的问题，这里我们就要区分两个经常挂在嘴边，但是确很少有人去能理解透彻的概念：定界和定位。

我们讲故障时可以不用定位，指的是在故障时，不用去定位故障原因是什么，但是不能不做定界。

重要的事情讲三遍：

定界和定位是两回事。

定界和定位是两回事。

定界和定位是两回事。

定界不做，那接下来的恢复就无从谈起了。

举个简单的场景案例：

当一次故障发生，业务指标受影响，硬件层面、网络层面、数据库层面，分布式组件层面、存储层面、应用层面，可能都会有告警。

我们不管是通过AIOps的手段，还是Observability去观察，还是依赖运维专家的经验，总会能做出一些问题所在位置的基本判断。

有了定界，其实就可以指导后面的应急手段执行了。

针对有问题的点，能自愈最好，不行就重启、切换、降级限流或者回滚这种三板斧套路怼上去用起来。

假设当我们确认了是数据库有宕机，主备切换没成功，这时候没必要去翻数据库的日志，或者分析报告之类去分析原因。人工介入，手动切换，不行就降级，抓紧重启。

如果是应用内存出问题，也没必要去打个堆栈，然后分析下哪个对象没释放，那段代码逻辑是怎么写的，为什么会占用这么多内存。能先重启就重启，如果刚才做了发布就先回滚等等。

所以，定界的能力，其实比定位更重要，定界必须要高效，定位在绝大多数情况下是可以在事后做的。

一定一定要区分开看，不能混为一谈。