隨著各個企業(yè)在數(shù)字化轉型的浪潮中不斷翻涌前進，IT業(yè)務復雜程度與規(guī)模體積爆發(fā)式增長，可觀測性工具成為發(fā)展剛需。在Gatner發(fā)布的2023年需要探索的十大戰(zhàn)略技術趨勢中，“可觀測性”被列為其中之一。

那么，為什么可觀測性如此重要？有哪些值得關注的演進趨勢？如何設計落地方案？本文將圍繞可觀測性為大家一一解答。

Q1、什么是可觀測性？

在IT和云計算中，可觀測性是基于系統(tǒng)生成的數(shù)據(jù)（如指標、調(diào)用鏈、日志）來測量系統(tǒng)內(nèi)部狀態(tài)的能力。

可觀測性依賴于源自多云計算環(huán)境中端點和服務的儀器的遙測。在這些現(xiàn)代環(huán)境中，每個硬件、軟件和云基礎設施組件以及每個容器、開源工具和微服務都會生成每個活動的記錄?？捎^測性的目標是了解所有這些環(huán)境和技術之間發(fā)生了什么，從而檢測并解決問題，以保持系統(tǒng)高效可靠的運行。

可觀測性解決方案可以幫助企業(yè)檢測和分析事件對其運營、軟件開發(fā)生命周期、應用程序安全和最終用戶體驗的重要性。

近年來，隨著云本地環(huán)境變得更加復雜，故障或異常的潛在根本原因變得更加難以查明，收集和處理可觀測性數(shù)據(jù)對業(yè)務的好處更加顯而易見。

由于云服務依賴于一個獨特的分布式動態(tài)體系結構，可觀測性有時也可能指企業(yè)用來解釋云性能數(shù)據(jù)的特定軟件工具和實踐。

Q2、可觀測性的三要素是什么？

可觀測性三要素即：Metrics、Trace、Log (指標、調(diào)用鏈、日志)。這三種要素在監(jiān)控體系中單獨去看也是有自身價值的。但如果只通過一種數(shù)據(jù)的模型，那就很難構建出尋找問題核心的能力。所以說，需要把這三種類型的數(shù)據(jù)有機的貫穿在一起，形成一個立體化的架構，使它們互相去發(fā)揮各自的專長，做到能夠使用遙測數(shù)據(jù)來實現(xiàn)改善最終用戶體驗和業(yè)務成果的最終目標。

Q3：為什么可觀測性很重要？

在企業(yè)環(huán)境中，可觀測性有助于跨職能團隊理解并回答有關高度分布式系統(tǒng)中發(fā)生的事情，能夠了解什么是慢的或壞的，以及需要做什么來提高性能。有了可觀測性解決方案，企業(yè)可以收到有關問題的警報，并在問題影響用戶之前主動解決問題。

由于現(xiàn)代云環(huán)境是動態(tài)的，規(guī)模和復雜性不斷變化，大多數(shù)問題既不已知也不受監(jiān)控?？捎^測性解決了“未知的未知”這一常見問題，幫助企業(yè)在出現(xiàn)新問題時能夠持續(xù)自動地理解它們。

可觀測性也是AIOps的一項關鍵能力。隨著越來越多的組織采用云本機架構，他們也在尋找實現(xiàn)AIOps的方法，利用AI在整個DevSecOps生命周期中自動化更多流程。通過將人工智能應用于一切——從收集遙測數(shù)據(jù)到分析整個技術堆棧中發(fā)生的事情——企業(yè)獲得可靠的答案，這對于自動化應用程序監(jiān)控、測試、連續(xù)交付、應用程序安全和事件響應至關重要。

可觀測性的價值并不局限于IT案例。一旦開始收集和分析可觀測性數(shù)據(jù)，企業(yè)就有了一個了解數(shù)字服務業(yè)務影響的寶貴窗口。這種可視性能夠優(yōu)化轉換，驗證軟件版本是否滿足業(yè)務目標，衡量用戶體驗SLO的結果，并根據(jù)最重要的內(nèi)容確定業(yè)務決策的優(yōu)先級。

當可觀測性解決方案還使用合成和真實用戶監(jiān)控分析用戶體驗數(shù)據(jù)時，企業(yè)可以在用戶之前發(fā)現(xiàn)問題，并基于真實、即時的反饋設計更好的用戶體驗。

Q4：可觀測性的優(yōu)勢體現(xiàn)在哪些方面？

可觀測性為IT團隊、企業(yè)和最終用戶帶來了巨大的好處。舉例來說：

1.應用程序性能監(jiān)控：完全的端到端可觀測性使企業(yè)能夠更快地了解應用程序性能問題的根源，包括云本機和微服務環(huán)境中出現(xiàn)的問題。先進的可觀測性解決方案還可用于更多自動化流程，提高運營和應用團隊的效率和創(chuàng)新。

2.DevSecOps和SRE：可觀測性是應用程序及其支持基礎設施的一個基本屬性。創(chuàng)建軟件的架構師和開發(fā)人員必須將其設計為可觀測的。同時DevSecOps和SRE團隊可以在軟件交付生命周期中利用和解釋可觀測到的數(shù)據(jù)，以構建更好、更安全、 更具彈性的應用程序。

3.基礎設施、云和Kubernetes監(jiān)控：基礎設施和運營（I&O）團隊可以利用可觀測性解決方案提供的增強環(huán)境來提高應用程序的正常運行時間和性能，減少查明和解決問題所需的時間，檢測云延遲問題，優(yōu)化云資源利用率，并改善對Kubernetes環(huán)境和現(xiàn)代云架構的管理。

4.最終用戶體驗：良好的用戶體驗可以提高企業(yè)聲譽，在競爭中取得優(yōu)勢。通過在最終用戶注意到問題之前發(fā)現(xiàn)并解決問題，并在用戶提出要求之前進行改進，企業(yè)可以提高用戶滿意度和保留率。還可以通過實時播放來優(yōu)化用戶體驗，直接獲得一個窗口，讓最終用戶的體驗與他們看到的相同，從而很快在改進方面達成一致。

5.業(yè)務分析：企業(yè)可以將業(yè)務上下文與全堆棧應用程序分析和性能結合起來，以了解實時業(yè)務影響，改進轉換優(yōu)化，確保軟件發(fā)布滿足預期業(yè)務目標，并確認企業(yè)遵守內(nèi)部和外部SLA。DevSecOps團隊可以利用可觀測性來獲得對他們開發(fā)的應用程序的更多見解，并自動化測試和CI/CD過程，以便更快地發(fā)布質(zhì)量更好的代碼。

從生產(chǎn)力的角度來看，可觀測性提高了企業(yè)的效率，加強了對有效合作至關重要的積極工作關系，進一步為企業(yè)創(chuàng)新和數(shù)字化轉型打開了大門。更重要的是，最終用戶將以高質(zhì)量的用戶體驗的形式受益。

Q5：可觀測性和監(jiān)控之間有什么區(qū)別？

雖然可觀測性和監(jiān)控是相關的，并且可以相互補充，但它們實際上是不同的概念。

在監(jiān)控場景中，通常會預先配置儀表盤，以提醒以后可能會看到的性能問題。然而，這些儀表盤依賴于一個關鍵假設，即能夠在問題發(fā)生之前預測將遇到什么類型的問題。

云原生環(huán)境不適合這種類型的監(jiān)控，因為它們是動態(tài)的、復雜的，這意味著無法提前知道可能會出現(xiàn)什么樣的問題。

在可觀測性場景中，環(huán)境已被完全檢測以提供完整的可觀測性數(shù)據(jù)，可以靈活地探索正在發(fā)生的事情，并快速找出可能無法預料的問題的根本原因。

Q6：可觀測性所涉及到的環(huán)節(jié)有哪些？

可觀測性涉及到的環(huán)節(jié)較多：

1.可觀測性需要數(shù)據(jù)作為支撐，并且對于數(shù)據(jù)的質(zhì)量有一定要求。數(shù)據(jù)需要經(jīng)過標準化的處理過程，才能真正作為基座來使用。

2.可觀測性需要海量的數(shù)據(jù)，并且涉及到不同的類型。要追求每一筆交易、每一個動作都能有完整的鏈條，所要面對的數(shù)據(jù)規(guī)模是十分龐大的。同時，可觀測性技術本身就是一個大數(shù)據(jù)匯總的平臺，因此需要高技術引擎和關系圖譜引擎的支撐，來將數(shù)據(jù)有機的結合到一起。

3.若要真正發(fā)揮可觀測性帶來的價值，不能僅僅只把數(shù)據(jù)做一個簡單的羅列，我們需要剖析數(shù)據(jù)，做關聯(lián)分析。而這一過程需要 AI 的加持，這樣才能讓效率真正提升上來，這其中涉及到一整套的系統(tǒng)工程。

做好以上這些，才能體會到數(shù)據(jù)作為大腦引擎的驅動力，讓企業(yè)的運維管理更智能、更便捷、更高效。

Q7：如何使系統(tǒng)具備可觀測性？

前面我們提到了可觀測性三要素：指標、調(diào)用鏈、日志。然而，僅從后端應用程序觀測原始遙測數(shù)據(jù)并不能全面了解系統(tǒng)的運行情況。

忽略前端透視圖可能會扭曲甚至歪曲應用程序和基礎設施在現(xiàn)實世界中對真實用戶的表現(xiàn)。為了擴展“三要素”方法，IT團隊必須利用用戶體驗數(shù)據(jù)增強遙測收集，以消除盲點：

1.日志：這些是特定時間發(fā)生的離散事件的結構化或非結構化文本記錄。

2.指標：這些值表示為計數(shù)或度量，通常在一段時間內(nèi)計算或匯總。指標可以來自各種來源，包括基礎設施、主機、服務、云平臺和外部來源。

3.調(diào)用鏈：當事務或請求流經(jīng)應用程序時，它顯示事務或請求的活動，并顯示服務如何連接，包括代碼級別的詳細信息。

4.用戶體驗：這擴展了傳統(tǒng)的可觀測性遙測，通過在應用程序上添加特定數(shù)字體驗的由外而內(nèi)的用戶視角，即使在預生產(chǎn)環(huán)境中也是如此。

Q8：國內(nèi)市場對于可觀測性的認知與需求是怎樣的？

從整個行業(yè)的使用客戶中可以看出，不同行業(yè)對于可觀測性的訴求也是不同的。比如金融行業(yè)，他們已經(jīng)針對可觀測性做了很多方面的嘗試，不論是在數(shù)量亦或是質(zhì)量方面都是比較可觀的。這并不是說可觀測性技術的滲透率有多高，而是說很多企業(yè)已經(jīng)對此產(chǎn)生了共鳴。

可能很多企業(yè)依舊處于初實驗階段或者技術考察階段，但在未來幾年里，可觀測性的發(fā)展速度可能會有指數(shù)級的變化，因為故障的產(chǎn)生是無可避免的，而可觀測性技術可以覆蓋到軟件的整個的生命周期之中，形成完整的鏈條。同時可觀測性技術還可以與自動化體系結合在一起，使企業(yè)的效率得到數(shù)倍的提升。

從目前的市場情況來看，可觀測性已經(jīng)有了一些落地的實踐，之后也會有一個慢慢成長的過程。疫情過后，很多人對于數(shù)字化轉型可能有了全新的認知，在新的系統(tǒng)架構和開發(fā)模型下，企業(yè)需要一種能力來規(guī)避問題的發(fā)生，降低問題的影響，所以可觀測性恰好適應了現(xiàn)在整合技術的發(fā)展路徑。

Q9：可觀測性面臨哪些挑戰(zhàn)？

1.數(shù)據(jù)孤島：多個代理、不同的數(shù)據(jù)源和孤島式的監(jiān)控工具使得很難理解應用程序、多個云和數(shù)字渠道（如web、移動和物聯(lián)網(wǎng)）之間的相互依賴性。

2.容量、速度、多樣性和復雜性：在不斷變化的現(xiàn)代云環(huán)境（如AWS、Azure和谷歌云平臺（GCP））中，從每個組件收集的大量原始數(shù)據(jù)幾乎不可能得到答案。Kubernetes和容器也可以在幾秒鐘內(nèi)上下旋轉。

3.手動檢測和配置：當IT資源被迫手動檢測和更改每種新型組件或代理的代碼時，他們大部分時間都在嘗試建立可觀測性，而不是根據(jù)可觀測性數(shù)據(jù)進行創(chuàng)新。

4.缺乏預生產(chǎn)：即使在預生產(chǎn)階段進行負載測試，開發(fā)人員仍然無法在將代碼投入生產(chǎn)之前觀察或理解真實用戶將如何影響應用程序和基礎設施。

5.浪費時間進行故障排除：應用程序、運營、基礎設施、開發(fā)和數(shù)字體驗團隊被拉進來進行故障排除，并試圖找出問題的根本原因，浪費寶貴的時間進行猜測，試圖理解遙測并找出答案。

6.多個工具和供應商的問題：雖然一個工具可以讓組織觀察到其應用程序體系結構的一個特定領域，但一個工具可能無法在所有可能影響應用程序性能的應用程序和系統(tǒng)中提供完整的觀測能力。

此外，并非所有類型的遙測數(shù)據(jù)對確定問題的根本原因或了解其對用戶體驗的影響都同樣有用。因此，團隊仍然需要在多個解決方案中挖掘答案，并費力地解釋遙測數(shù)據(jù)，這是一項耗時的任務，而此時他們可以將自己的專業(yè)知識用于立即解決問題。然而，有了單一的真相來源，團隊可以更快地獲得答案和解決問題。

Q10：企業(yè)在實際落地可觀測的過程中通常會陷入哪些誤區(qū)？

首先是開源和商業(yè)化如何平衡的問題。不管是可觀測性還是之前的監(jiān)控技術，都有大量的開源能力在支持，有很多的免費方案供使用。對于任何一個企業(yè)來說，是否在專注地去做這樣一個系統(tǒng)，還是說只是為了輔助主營業(yè)務來做系統(tǒng)疊加，前期的投入與最后的結果很可能是有較大落差的。

其次企業(yè)在可觀測性的建設過程中，總是期望大而全，這就需要考慮到幾點因素。第一點，系統(tǒng)需要人為去操作，組織架構中人的水平與素質(zhì)很大程度上決定了系統(tǒng)的使用能力上限。第二點，技術棧的繁雜性導致了數(shù)據(jù)治理需要較長的時間，而到了數(shù)據(jù)的實際使用場景，我們會發(fā)現(xiàn)，這其中涉及運維、研發(fā)、測試、業(yè)務等各部門的人員，部門間的數(shù)據(jù)孤島會對數(shù)據(jù)產(chǎn)生一定的割裂，導致數(shù)據(jù)無法真正統(tǒng)一在一起。

最后是成本問題。技術并不是一成不變的，從基礎監(jiān)控到網(wǎng)絡監(jiān)控，從 APM 到可觀測性，技術是不停在發(fā)展的，包括研發(fā)的過程，經(jīng)過了多次的更新迭代，才到了現(xiàn)在微服務的架構。因此要維護一個復雜的技術棧，后續(xù)的模型是不是能夠真正跟得上就很重要，這需要一個團隊持續(xù)去迭代，所以企業(yè)需要從綜合成本方面去考慮可觀測性的方案。