为什么说可观测性Observability对运维没用？

本篇文章是跟浙江移动信息技术部总经理，中国移动首席专家的王晓征总交流探讨后形成。

首先，再复述下本文标题，Observabilty对运维没用，如果硬要说的精确点，exactly，对绝大多数的运维没用。

为啥呢？

Observability的三个环节是什么？

Detect发现—Trouble Shoot定位—Root Cause找到根因

而真正在出现问题的时候，对于运维也好，还是对于处理故障的人也好，最需要做的是什么？

是快速恢复，快速止损，这个时候定位和找根因很重要，但不是最重要的。

真正发生故障时，对于运维来说，真正重要的是：

Detect发现—Recover&Mitigate恢复和止损

这个角度，我们常用的“三板斧”、“一指禅”这样的预案和套路会更重要。

所以，Observability产品的逻辑跟运维的逻辑是不一样的。

拿业界现在经常提到的故障处理标准1-5-10，也就是1分钟发现，5分钟定位，10分钟恢复来讲，经过大量实践验证，其实把要求换成1-15，也就是1分钟发现，15分钟恢复会更合理。

而且已经有很多企业不再提故障时精准定位，有问题能快速恢复反而更实际一些。

这里再往深里分析下的话，快速恢复和止损，也就是Recover和Mitigate换成我们常用的稳定性和词汇又是什么呢？

一个是切换，切换之后可以Recover，这是完美的故障应急效果。但如果切换不行，咱就限流、降级、熔断等各种预案都执行起来，降低故障影响程度，这就是Mitigate。

而Recover和Mitigate的能力，其实根本上取决于产品的架构设计和实现，也就是产品的反脆弱性是不是足够强，单纯的Observability是解决不了这些问题的。

如果要是这么讲，Observability是不是就没存在的价值和意义了呢？

当然不是，

如果让我来定义系统稳定性或运维能力层级的话，我会分为四层：

第一层，产品运维自动化的达成，自动化的扩缩容，CI/CD等。

第二层，产品反脆弱能力的达成，快速切换、限流、降级、熔断等。

第三层，AIOps能力的达成，这一部分我17年专门写文章分享过《AI时代，我们离AIOps还有多远？》，单纯AIOps能力的存在是没有意义的，它必然是建立在第一、二层基础之上，与之相辅相成才有意义。

第四层，混沌工程Chaos Engineering 和 可观测性Observability能力的达成，同样的，它们必然要依托于前面的几层能力才有意义。

因为试想，当我们的系统内部服务都无法做到自动切换，无法通过AIOps能力识别服务过载，需要自动化降级或者执行扩缩容的时候，混沌工程的破坏性测试又有什么意义呢？

而我们的Observability，能够发挥的最大价值就是，帮助我们在这些日常的各种异常、全站大容量压测、以及混沌破坏性测试时，很好的给到我们指导，帮我们找出薄弱点在那里，指导SRE和产品在架构和逻辑层面做出优化。

所以，Observability的价值和作用一定是在平时，而不是紧要时刻。

而我们讨论Observability，一定要全局地看，系统性地看，而不是单一维度的看。

不然，Observability真的就是空中楼阁，景象很美好，但是没法落地。