上一期可观测性文章《可观测性（一）》里面聊了可观测性的定义、价值和三大支柱。
其中值得再次提及的是，可观测性的核心目的是以量化的方式管理企业的基础设施（包括中间件等）、平台和应用程序。
正所谓 “如果你无法量化它，你就无法管理它” -- 彼得·德鲁克。
同时还有一个要点，就是可观测性要完成闭环，终究需要告警管理平台来做连接--将问题指标即时反映给相关维护人员，以解决系统无法自修复的问题，同时提高系统自修复能力。
接着这个话题，这期我整理了构建一个优秀的可观测系统需要哪些核心能力。
由于这个话题近乎实操，太过深入，本人暂时力不能及，但学习完之后又觉得很有价值，想分享给大家，同时留作日后回顾。因此以引用的方式将精髓呈现出来。
原文来自公众号《成哥的世界》，作者：Cheng哥。有删改。
通常我们在IT领域看到的关于可观测性概念的介绍，都会提到它是Metrics, Traces以及Logs的结合，通常会以下图来呈现。
这里我找了一个Splunk的Demo，我们可以直观的感受一下，可观测性的实际效果是怎样的。
大家看完这个示意，对可观测性就有更直观的理解了，不做赘述。
但是这个Demo就只能作为Demo看一下，现实情况远比这个要复杂的多，原因我们后面会讲到。
不过，这里就有问题了，监控做了这么多年，Metric都是全的，日志系统也上了，Log一条都没拉下，调用链工具也引入了，Trace拓扑也能画出来，那上面这个效果是不是将三者结合一下就有了呢？
答案显而易见，是否定的。相反，现实情况下上述的效果并不容易达成，这里不仅仅是Metric、Trace和Log三者的技术结合在一起就OK，这只是外在的形，要想达成这个效果，其实更关键的是背后的神。
那这个神到底是什么，接下来我就换一个方式描述一下这个过程，把背后更为核心的内容呈现出来。
可观测性Observability的剖析
一图胜千言，我直接用一张图来描述，如下所示：
其实有了这张图，对Observability有一定理解的同学，应该就看的差不多了。
如果说Observability的内在的神是什么，总结下来就是3部分内容：
1.SRE方法论
2.AIOps算法能力
3.业务架构的理解，这里暗含着对领域知识的掌握
我们可以看到，这三部分的核心能力的掌握就不单纯是技术能力的体现了，这里要有非常深厚经验积累和时间，以及长时间对业务架构摸索和理解。
也只有在这三部分核心能力的指导下，像Metric、Trace和Log这样的技术手段才能发挥最大价值。
接下来我们再谈谈为什么这三个核心能力非常重要：
可观测性之SRE方法论
这里面要用到SLO的方法，帮助我们识别关键Metrics，快速感知问题发生，主要是在Detect阶段。
我们知道复杂系统下，会包含网络、应用、分布式中间件、容器、主机、存储、数据库等等多层设备和部件，每个部件都会有自己的各类指标。
但是指标这么多，出问题同时告警，那就告警风暴了，一个是会造成关键信息淹没，再就是信息多了，告警就变成了“狼来了”，接收告警的人就麻木了。
这个时候就要设定SLO，而且SLO得是要分层设定，业务层面，要关注业务SLO，比如GMV、订单量、支付成功率等等。
系统层面就要关注系统SLO，比如订单接口成功率、时延和TPS等等，应用就要关注应用的SLO，缓存、消息、存储、数据库，以及底层的网络、容器、虚拟机、硬件主机要也要有自己的SLO。
SLO怎么设计，我不详述了，之前讲了很多，大家自行了解SRE的SLO机制就好了。
不过，即使做分层设定，出问题告警依然很多，我可以通过选定最上层的业务SLO来感知出问题了，提升响应速度，但是问题出在哪儿依然未知，这个时候在这种复杂系统中，就必须依赖AIOps的能力了。
可观测性之AIOps
AIOps领域，针对Metric、Trace和Log，都有专门的算法来应对支持，对应三类，比如针对Metric，就是KPI Anomaly Detection，针对Trace就是Tracing Anomaly Detection，针对Log就是Log Anomaly Detecion。
所以，AIOps是会始终贯穿整个Observability过程的，关于AIOps推荐看一下清华裴丹教授的文章和课程，会有更详细的分享。
可观测性之业务架构的理解
如果SRE方法论和AIOps是落地Observability的两个核心，那对业务架构的理解，我对它的定位就是核心中的核心。
我们在架构领域经常听到的一句话就是，“脱离业务谈架构就是耍流氓”，其实也适用于Observability，适用于SRE和AIOps，脱离业务架构谈Observability就是耍流氓。
那对业务架构的理解为什么这么重要呢？我们看两个场景：
第一个，还是回到SLO设定上，当我们设定业务SLO时，我们是要根据业务类型和特点来的，或者换种说法，用户对我们业务的感知，是通过哪些指标来体现的？
首先，我们得能定义出来，比如电商可以是可以订单和支付维度来判定，对应会有下单成功率、下单量，支付成功率，支付笔数等等。
再进一步，正常这些指标都一个平滑的驼峰式曲线，等但是在做活动时，它可能就是一个个的尖峰和突刺，在节假日它的同环比会下降，遇到热点商品，可能会出现一段时间的波动，但是这些场景并不意味着系统出问题了，这种就要在AIOps的算法里识别出来。
那类似微信的IM又是什么指标和特点？社交软件微博又有什么不同？跨行业的电信运营商，以及银行、证券、保险等金融行业又各是什么特点。
这些都取决于对业务场景的深刻理解。
如果说第一个场景只要我懂业务就可以设定SLO，那如果我往深里看，那就不仅仅是对业务场景的理解了。
第二个，我们往业务架构深里看，我们都知道复杂分布式系统里，调用关系是异常复杂的，会呈现密布的网状调用关系。
当然现在有各类Trace工具能帮我们把调用拓扑呈现出来，也可以根据TraceID或业务ID单独看某次的调用链，确实方便了很多。
但是这么复杂的调用关系全部呈现出来，我到底应该怎么看？
答案是基本没法看！
所以这个时候就必须得事先规划出一条核心的业务链路，也就是我们常说的业务关键路径Critical Path，再进一步，关键路径上就会有核心应用，只有对照着这个路径去看，Observability才会有针对性和指导意义。
所以上面的那个Splunk的Demo，我们为什么说就是个Demo，因为现实中的调用关系要比Demo复杂N多倍，但是它想呈现的效果，就是针对Critical Path关键路径路来的。
关于Critical Path，核心应用，强弱依赖关系等等，在我的课程和之前的文章中都有，可以自行查阅。
所以讲到这里，我们可以看到，Observability从业务来讲，其实是需要事先定义出如下一条业务分析链路的：
业务SLO—Critical Path—核心应用SLO—核心分布式组件SLO—容器SLO—IAAS SLO
只有这个链路清晰了，AIOps才会发挥最大的优势，Observability的效果才会呈现出来。
一开始可以冗余，不那么清晰，但是必须得有，就像杭州到深圳，大家得知道杭州打车去机场，飞机去深圳机场，到了深圳再打车或地铁去目的地，这就是一条主线，这个都没有，基本就没法出门了。
所以，要做到这个程度，你就得懂业务、懂业务架构、懂技术架构、还要有一定的经验积累和沉淀，不然没法做判断。
上面讲了那么多，我放个示例，就不多讲了。
当然，可能会有人挑战我说，AIOps可以做到无监督学习，自行分析关键路径，不用这么麻烦还要人工分析。
当然，我相信未来有一天或许会做到，但是到目前为止，我觉得这还不现实，即使能分析出链路来，但是已然离不开架构师的梳理和确认。
这个状态，我觉得就跟现在的无人驾驶一样，绝大多数情况下，他可以自动巡航，但是关键时刻还是离不开人的判断和控制。而人的判断又是来自于驾驶经验、交通法规、伦理道德以及当时的精神面貌等很多因素。
从这个角度，自动巡航能力只是人的决策依据的一部分而已，只能做辅助，永远离不开也取代不了人的判断。
最后，总结一下：
当前看到的Observability的产品只有Metric、Trace和Log的技术描述，额外再加上部分AIOps的加持，但是这些只是形，没有神。
要想有神，最关键不能离开业务和场景，所以SRE方法论、领域知识（业务和架构）以及AIOps才是Observability的落地的关键所在。
而这三者之中，对业务场景及业务架构的理解程度，决定了SRE和AIOps可以发挥的效果如何，也最终决定了落地的效果。
再就是，为什么之前很少有人提Observability，这两天如此火热，我觉得还是技术应用发展到一定程度的结果，大家前几年都在分头搞监控、链路跟踪和日志系统，这两年搞差不多了，自然就会有更高的应用诉求。
所以，从技术上讲，并无新鲜的东西，关键还是得有更清晰的判断和思考。
