上一期可觀測性文章《可觀測性（一）》里面聊了可觀測性的定義直撤、價值和三大支柱非竿。
其中值得再次提及的是，可觀測性的核心目的是以量化的方式管理企業(yè)的基礎(chǔ)設(shè)施（包括中間件等）谋竖、平臺和應(yīng)用程序红柱。
正所謂 “如果你無法量化它，你就無法管理它” -- 彼得·德魯克蓖乘。
同時還有一個要點(diǎn)锤悄，就是可觀測性要完成閉環(huán)，終究需要告警管理平臺來做連接--將問題指標(biāo)即時反映給相關(guān)維護(hù)人員嘉抒，以解決系統(tǒng)無法自修復(fù)的問題零聚，同時提高系統(tǒng)自修復(fù)能力。
接著這個話題些侍，這期我整理了構(gòu)建一個優(yōu)秀的可觀測系統(tǒng)需要哪些核心能力隶症。
由于這個話題近乎實(shí)操，太過深入岗宣，本人暫時力不能及蚂会，但學(xué)習(xí)完之后又覺得很有價值，想分享給大家狈定，同時留作日后回顧颂龙。因此以引用的方式將精髓呈現(xiàn)出來挡篓。
原文來自公眾號《成哥的世界》防楷，作者：Cheng哥蜂厅。有刪改蛙酪。
通常我們在IT領(lǐng)域看到的關(guān)于可觀測性概念的介紹奏纪，都會提到它是Metrics, Traces以及Logs的結(jié)合棠赛，通常會以下圖來呈現(xiàn)榔袋。
這里我找了一個Splunk的Demo丑念，我們可以直觀的感受一下让蕾，可觀測性的實(shí)際效果是怎樣的浪规。
大家看完這個示意，對可觀測性就有更直觀的理解了探孝，不做贅述笋婿。
但是這個Demo就只能作為Demo看一下，現(xiàn)實(shí)情況遠(yuǎn)比這個要復(fù)雜的多顿颅，原因我們后面會講到缸濒。
不過，這里就有問題了粱腻，監(jiān)控做了這么多年庇配，Metric都是全的，日志系統(tǒng)也上了绍些，Log一條都沒拉下捞慌，調(diào)用鏈工具也引入了，Trace拓?fù)湟材墚嫵鰜砑砼巧厦孢@個效果是不是將三者結(jié)合一下就有了呢啸澡？
答案顯而易見，是否定的氮帐。相反锻霎，現(xiàn)實(shí)情況下上述的效果并不容易達(dá)成，這里不僅僅是Metric揪漩、Trace和Log三者的技術(shù)結(jié)合在一起就OK旋恼，這只是外在的形，要想達(dá)成這個效果奄容，其實(shí)更關(guān)鍵的是背后的神冰更。
那這個神到底是什么，接下來我就換一個方式描述一下這個過程昂勒，把背后更為核心的內(nèi)容呈現(xiàn)出來蜀细。
可觀測性O(shè)bservability的剖析
一圖勝千言，我直接用一張圖來描述戈盈，如下所示：
其實(shí)有了這張圖奠衔，對Observability有一定理解的同學(xué)谆刨，應(yīng)該就看的差不多了。
如果說Observability的內(nèi)在的神是什么归斤，總結(jié)下來就是3部分內(nèi)容：
1.SRE方法論
2.AIOps算法能力
3.業(yè)務(wù)架構(gòu)的理解痊夭，這里暗含著對領(lǐng)域知識的掌握
我們可以看到，這三部分的核心能力的掌握就不單純是技術(shù)能力的體現(xiàn)了脏里，這里要有非常深厚經(jīng)驗積累和時間她我，以及長時間對業(yè)務(wù)架構(gòu)摸索和理解。
也只有在這三部分核心能力的指導(dǎo)下迫横，像Metric番舆、Trace和Log這樣的技術(shù)手段才能發(fā)揮最大價值。
接下來我們再談?wù)劄槭裁催@三個核心能力非常重要：
可觀測性之SRE方法論
這里面要用到SLO的方法矾踱，幫助我們識別關(guān)鍵Metrics恨狈，快速感知問題發(fā)生，主要是在Detect階段呛讲。
我們知道復(fù)雜系統(tǒng)下拴事，會包含網(wǎng)絡(luò)、應(yīng)用圣蝎、分布式中間件刃宵、容器、主機(jī)徘公、存儲牲证、數(shù)據(jù)庫等等多層設(shè)備和部件，每個部件都會有自己的各類指標(biāo)关面。
但是指標(biāo)這么多坦袍，出問題同時告警，那就告警風(fēng)暴了等太，一個是會造成關(guān)鍵信息淹沒捂齐，再就是信息多了，告警就變成了“狼來了”缩抡，接收告警的人就麻木了奠宜。
這個時候就要設(shè)定SLO，而且SLO得是要分層設(shè)定瞻想，業(yè)務(wù)層面压真，要關(guān)注業(yè)務(wù)SLO，比如GMV蘑险、訂單量滴肿、支付成功率等等。
系統(tǒng)層面就要關(guān)注系統(tǒng)SLO佃迄，比如訂單接口成功率泼差、時延和TPS等等贵少，應(yīng)用就要關(guān)注應(yīng)用的SLO，緩存堆缘、消息滔灶、存儲、數(shù)據(jù)庫套啤，以及底層的網(wǎng)絡(luò)、容器随常、虛擬機(jī)潜沦、硬件主機(jī)要也要有自己的SLO。
SLO怎么設(shè)計绪氛，我不詳述了唆鸡，之前講了很多，大家自行了解SRE的SLO機(jī)制就好了枣察。
不過争占，即使做分層設(shè)定，出問題告警依然很多序目，我可以通過選定最上層的業(yè)務(wù)SLO來感知出問題了臂痕，提升響應(yīng)速度，但是問題出在哪兒依然未知猿涨，這個時候在這種復(fù)雜系統(tǒng)中握童，就必須依賴AIOps的能力了。
可觀測性之AIOps
AIOps領(lǐng)域叛赚，針對Metric澡绩、Trace和Log，都有專門的算法來應(yīng)對支持俺附，對應(yīng)三類肥卡，比如針對Metric，就是KPI Anomaly Detection事镣，針對Trace就是Tracing Anomaly Detection步鉴，針對Log就是Log Anomaly Detecion。
所以璃哟，AIOps是會始終貫穿整個Observability過程的唠叛，關(guān)于AIOps推薦看一下清華裴丹教授的文章和課程，會有更詳細(xì)的分享沮稚。
可觀測性之業(yè)務(wù)架構(gòu)的理解
如果SRE方法論和AIOps是落地Observability的兩個核心艺沼，那對業(yè)務(wù)架構(gòu)的理解，我對它的定位就是核心中的核心蕴掏。
我們在架構(gòu)領(lǐng)域經(jīng)常聽到的一句話就是障般，“脫離業(yè)務(wù)談架構(gòu)就是耍流氓”调鲸，其實(shí)也適用于Observability，適用于SRE和AIOps挽荡，脫離業(yè)務(wù)架構(gòu)談Observability就是耍流氓藐石。
那對業(yè)務(wù)架構(gòu)的理解為什么這么重要呢？我們看兩個場景：
第一個定拟，還是回到SLO設(shè)定上于微，當(dāng)我們設(shè)定業(yè)務(wù)SLO時，我們是要根據(jù)業(yè)務(wù)類型和特點(diǎn)來的青自，或者換種說法株依，用戶對我們業(yè)務(wù)的感知，是通過哪些指標(biāo)來體現(xiàn)的延窜？
首先恋腕，我們得能定義出來，比如電商可以是可以訂單和支付維度來判定逆瑞，對應(yīng)會有下單成功率荠藤、下單量，支付成功率获高，支付筆數(shù)等等哈肖。
再進(jìn)一步，正常這些指標(biāo)都一個平滑的駝峰式曲線念秧，等但是在做活動時牡彻，它可能就是一個個的尖峰和突刺，在節(jié)假日它的同環(huán)比會下降出爹，遇到熱點(diǎn)商品庄吼，可能會出現(xiàn)一段時間的波動，但是這些場景并不意味著系統(tǒng)出問題了严就，這種就要在AIOps的算法里識別出來总寻。
那類似微信的IM又是什么指標(biāo)和特點(diǎn)？社交軟件微博又有什么不同梢为？跨行業(yè)的電信運(yùn)營商渐行，以及銀行、證券铸董、保險等金融行業(yè)又各是什么特點(diǎn)祟印。
這些都取決于對業(yè)務(wù)場景的深刻理解。
如果說第一個場景只要我懂業(yè)務(wù)就可以設(shè)定SLO粟害，那如果我往深里看蕴忆，那就不僅僅是對業(yè)務(wù)場景的理解了。
第二個悲幅，我們往業(yè)務(wù)架構(gòu)深里看套鹅，我們都知道復(fù)雜分布式系統(tǒng)里站蝠，調(diào)用關(guān)系是異常復(fù)雜的，會呈現(xiàn)密布的網(wǎng)狀調(diào)用關(guān)系卓鹿。
當(dāng)然現(xiàn)在有各類Trace工具能幫我們把調(diào)用拓?fù)涑尸F(xiàn)出來菱魔，也可以根據(jù)TraceID或業(yè)務(wù)ID單獨(dú)看某次的調(diào)用鏈，確實(shí)方便了很多吟孙。
但是這么復(fù)雜的調(diào)用關(guān)系全部呈現(xiàn)出來澜倦，我到底應(yīng)該怎么看？
答案是基本沒法看杰妓！
所以這個時候就必須得事先規(guī)劃出一條核心的業(yè)務(wù)鏈路藻治，也就是我們常說的業(yè)務(wù)關(guān)鍵路徑Critical Path，再進(jìn)一步稚失，關(guān)鍵路徑上就會有核心應(yīng)用栋艳，只有對照著這個路徑去看恰聘，Observability才會有針對性和指導(dǎo)意義句各。
所以上面的那個Splunk的Demo，我們?yōu)槭裁凑f就是個Demo晴叨，因為現(xiàn)實(shí)中的調(diào)用關(guān)系要比Demo復(fù)雜N多倍凿宾，但是它想呈現(xiàn)的效果，就是針對Critical Path關(guān)鍵路徑路來的兼蕊。
關(guān)于Critical Path初厚，核心應(yīng)用，強(qiáng)弱依賴關(guān)系等等孙技，在我的課程和之前的文章中都有产禾，可以自行查閱。
所以講到這里牵啦，我們可以看到亚情，Observability從業(yè)務(wù)來講，其實(shí)是需要事先定義出如下一條業(yè)務(wù)分析鏈路的：
業(yè)務(wù)SLO—Critical Path—核心應(yīng)用SLO—核心分布式組件SLO—容器SLO—IAAS SLO
只有這個鏈路清晰了哈雏，AIOps才會發(fā)揮最大的優(yōu)勢楞件，Observability的效果才會呈現(xiàn)出來。
一開始可以冗余裳瘪，不那么清晰土浸，但是必須得有，就像杭州到深圳彭羹，大家得知道杭州打車去機(jī)場黄伊，飛機(jī)去深圳機(jī)場，到了深圳再打車或地鐵去目的地派殷，這就是一條主線毅舆，這個都沒有西篓，基本就沒法出門了。
所以憋活，要做到這個程度岂津，你就得懂業(yè)務(wù)、懂業(yè)務(wù)架構(gòu)悦即、懂技術(shù)架構(gòu)吮成、還要有一定的經(jīng)驗積累和沉淀，不然沒法做判斷辜梳。
上面講了那么多粱甫，我放個示例，就不多講了作瞄。
當(dāng)然茶宵，可能會有人挑戰(zhàn)我說，AIOps可以做到無監(jiān)督學(xué)習(xí)宗挥，自行分析關(guān)鍵路徑乌庶，不用這么麻煩還要人工分析。
當(dāng)然契耿，我相信未來有一天或許會做到瞒大，但是到目前為止，我覺得這還不現(xiàn)實(shí)搪桂，即使能分析出鏈路來透敌，但是已然離不開架構(gòu)師的梳理和確認(rèn)。
這個狀態(tài)踢械，我覺得就跟現(xiàn)在的無人駕駛一樣酗电，絕大多數(shù)情況下，他可以自動巡航内列，但是關(guān)鍵時刻還是離不開人的判斷和控制撵术。而人的判斷又是來自于駕駛經(jīng)驗、交通法規(guī)德绿、倫理道德以及當(dāng)時的精神面貌等很多因素荷荤。
從這個角度，自動巡航能力只是人的決策依據(jù)的一部分而已移稳，只能做輔助蕴纳，永遠(yuǎn)離不開也取代不了人的判斷。
最后个粱，總結(jié)一下：
當(dāng)前看到的Observability的產(chǎn)品只有Metric古毛、Trace和Log的技術(shù)描述，額外再加上部分AIOps的加持，但是這些只是形稻薇，沒有神嫂冻。
要想有神，最關(guān)鍵不能離開業(yè)務(wù)和場景塞椎，所以SRE方法論桨仿、領(lǐng)域知識（業(yè)務(wù)和架構(gòu)）以及AIOps才是Observability的落地的關(guān)鍵所在。
而這三者之中案狠，對業(yè)務(wù)場景及業(yè)務(wù)架構(gòu)的理解程度服傍，決定了SRE和AIOps可以發(fā)揮的效果如何，也最終決定了落地的效果骂铁。
再就是吹零，為什么之前很少有人提Observability，這兩天如此火熱拉庵，我覺得還是技術(shù)應(yīng)用發(fā)展到一定程度的結(jié)果灿椅，大家前幾年都在分頭搞監(jiān)控、鏈路跟蹤和日志系統(tǒng)钞支，這兩年搞差不多了茫蛹，自然就會有更高的應(yīng)用訴求。
所以伸辟，從技術(shù)上講麻惶，并無新鮮的東西馍刮，關(guān)鍵還是得有更清晰的判斷和思考信夫。
