上一期可觀測性文章《可觀測性（一）》里面聊了可觀測性的定義、價值和三大支柱。
其中值得再次提及的是，可觀測性的核心目的是以量化的方式管理企業的基礎設施（包括中間件等）、平臺和應用程序。
正所謂 “如果你無法量化它，你就無法管理它” -- 彼得·德魯克。
同時還有一個要點，就是可觀測性要完成閉環，終究需要告警管理平臺來做連接--將問題指標即時反映給相關維護人員，以解決系統無法自修復的問題，同時提高系統自修復能力。
接著這個話題，這期我整理了構建一個優秀的可觀測系統需要哪些核心能力。
由于這個話題近乎實操，太過深入，本人暫時力不能及，但學習完之后又覺得很有價值，想分享給大家，同時留作日后回顧。因此以引用的方式將精髓呈現出來。
原文來自公眾號《成哥的世界》，作者：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，這兩天如此火熱，我覺得還是技術應用發展到一定程度的結果，大家前幾年都在分頭搞監控、鏈路跟蹤和日志系統，這兩年搞差不多了，自然就會有更高的應用訴求。
所以，從技術上講，并無新鮮的東西，關鍵還是得有更清晰的判斷和思考。
