在故障处理中，定界比定位更重要。定界是指确定问题所在位置，而定位是找出故障原因。在面对故障时，即使不立即知道原因，也要迅速定界以采取应急措施。例如，当数据库宕机导致故障，应立即进行主备切换或重启，而不是深入分析原因。同样，应用内存问题可直接重启或回滚。高效定界能力对于快速恢复至关重要，而定位可在事后进行。
前面发的Observability的文章，引起了不少的共鸣，在群里或私聊时很多朋友提到一个点：
故障处理时，运维的逻辑是快速恢复，所以根因是什么不重要，但是不知道根因发生的位置在哪儿，怎么做应急处置呢？
这是个非常好的问题，这里我们就要区分两个经常挂在嘴边，但是确很少有人去能理解透彻的概念：定界和定位。
我们讲故障时可以不用定位，指的是在故障时，不用去定位故障原因是什么，但是不能不做定界。
重要的事情讲三遍：
定界和定位是两回事。
定界和定位是两回事。
定界和定位是两回事。
定界不做，那接下来的恢复就无从谈起了。
举个简单的场景案例：
当一次故障发生，业务指标受影响，硬件层面、网络层面、数据库层面，分布式组件层面、存储层面、应用层面，可能都会有告警。
我们不管是通过AIOps的手段，还是Observability去观察，还是依赖运维专家的经验，总会能做出一些问题所在位置的基本判断。
有了定界，其实就可以指导后面的应急手段执行了。
针对有问题的点，能自愈最好，不行就重启、切换、降级限流或者回滚这种三板斧套路怼上去用起来。
假设当我们确认了是数据库有宕机，主备切换没成功，这时候没必要去翻数据库的日志，或者分析报告之类去分析原因。人工介入，手动切换，不行就降级，抓紧重启。
如果是应用内存出问题，也没必要去
最低0.47元/天 解锁文章
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
