前面发的Observability的文章,引起了不少的共鸣,在群里或私聊时很多朋友提到一个点:
故障处理时,运维的逻辑是快速恢复,所以根因是什么不重要,但是不知道根因发生的位置在哪儿,怎么做应急处置呢?
这是个非常好的问题,这里我们就要区分两个经常挂在嘴边,但是确很少有人去能理解透彻的概念:定界和定位。
我们讲故障时可以不用定位,指的是在故障时,不用去定位故障原因是什么,但是不能不做定界。
重要的事情讲三遍:
定界和定位是两回事。
定界和定位是两回事。
定界和定位是两回事。
定界不做,那接下来的恢复就无从谈起了。
举个简单的场景案例:
当一次故障发生,业务指标受影响,硬件层面、网络层面、数据库层面,分布式组件层面、存储层面、应用层面,可能都会有告警。
我们不管是通过AIOps的手段,还是Observability去观察,还是依赖运维专家的经验,总会能做出一些问题所在位置的基本判断。
有了定界,其实就可以指导后面的应急手段执行了。
针对有问题的点,能自愈最好,不行就重启、切换、降级限流或者回滚这种三板斧套路怼上去用起来。
假设当我们确认了是数据库有宕机,主备切换没成功,这时候没必要去翻数据库的日志,或者分析报告之类去分析原因。人工介入,手动切换,不行就降级,抓紧重启。
如果是应用内存出问题,也没必要去打个堆栈,然后分析下哪个对象没释放,那段代码逻辑是怎么写的,为什么会占用这么多内存。能先重启就重启,如果刚才做了发布就先回滚等等。
所以,定界的能力,其实比定位更重要,定界必须要高效,定位在绝大多数情况下是可以在事后做的。
一定一定要区分开看,不能混为一谈。