• SRE方法论；

   

我们可以看到，这三部分的核心能力的掌握就不单纯是技术能力的体现了，这里要有非常深厚经验积累和时间，以及长时间对业务架构摸索和理解。

也只有在这三部分核心能力的指导下，像Metric、Trace和Log这样的技术手段才能发挥最大价值。

接下来我们再谈谈为什么这三个核心能力非常重要。

这里面要用到SLO的方法，帮助我们识别关键Metrics，快速感知问题发生，主要是在Detect阶段。

我们知道复杂系统下，会包含网络、应用、分布式中间件、容器、主机、存储、数据库等等多层设备和部件，每个部件都会有自己的各类指标。

但是指标这么多，出问题同时告警，那就告警风暴了，一个是会造成关键信息淹没，再就是信息多了，告警就变成了“狼来了”，接收告警的人就麻木了。

这个时候就要设定SLO，而且SLO得是要分层设定，业务层面，要关注业务SLO，比如GMV、订单量、支付成功率等等。

系统层面就要关注系统SLO，比如订单接口成功率、时延和TPS等等，应用就要关注应用的SLO，缓存、消息、存储、数据库，以及底层的网络、容器、虚拟机、硬件主机要也要有自己的SLO。

SLO怎么设计，我不详述了，之前讲了很多，大家自行了解SRE的SLO机制就好了。

不过，即使做分层设定，出问题告警依然很多，我可以通过选定最上层的业务SLO来感知出问题了，提升响应速度，但是问题出在哪儿依然未知，这个时候在这种复杂系统中，就必须依赖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，这两天如此火热，我觉得还是技术应用发展到一定程度的结果，大家前几年都在分头搞监控、链路跟踪和日志系统，这两年搞差不多了，自然就会有更高的应用诉求。

所以，从技术上讲，并无新鲜的东西，关键还是得有更清晰的判断和思考。