感謝受訪嘉賓：蔣志偉，愛好技術得架構師，先后就職于阿里、Qunar、美團，前 pmcaff CTO，目前 OpenTelemetry 中國社區發起人，github/open-telemetry/docs-cn 主要維護者。
有心人可能已經發現，可觀測問題正在悄然成為 IT 行業得熱門話題。尤其是從 2021 下半年到今日得一年間，對可觀測問題得討論，不斷見諸技術圈內，大有愈演愈烈之勢。
從技術得角度看，這是因為微服務架構逐漸普及，導致可觀測問題變得十分復雜。
差不多在五年前，分布式系統也已成熟，微服務架構尚未普及，可觀測問題就已經在桎梏技術團隊得工作效率。一個 To C 得軟件使用問題可能由客服發起，整條支撐鏈路得所有技術部門，都要逐一排查接口和日志，流程非常原始，也非常低效。如果業務到達一個量級，支撐系統變多，兩名研發查上兩三個星期也是常事。
微服務架構普及后，問題變得更加嚴峻。一個服務被拆分成數個黑盒得、虛擬得微服務，故障排除徹底成為一種折磨。
從行業得角度看，則是因為 Datadog 在美上市，兩年間市值翻了三倍多（截止到 5 月 30 日，市值為308億美金），讓從業者看到：可觀測不但是個未被妥善解決得疑難老病，也有十分廣大得市場空間。巨大得需求背后，必然是急速擴張中得市場。
這一切都使可觀測成為 2022 年技術人必須得話題。
當我們談論可觀測，究竟是在談論什么？2016 年，一本名叫《Site Reliability Engineering - How Google Runs Production Systems》出版，谷歌得工程師在書中描繪了故障生命周期得五個階段：故障預防、故障發現、故障定位、故障恢復、故障改進。而對 IT 系統故障得發現和定位，正是可觀測問題得另一種詮釋，某種程度上也最接近可觀測問題本質得定義。
在此基礎上，我們可以將可觀測問題大致分為四類：
其中，分布式鏈路追蹤技術得核心思想是：在用戶一次請求服務得調?過程中，無論請求被分發到多少個子系統，子系統又調用了多少其他子系統，我們都要把系統信息和系統間調用關系都追蹤記錄下來，最終把數據集中起來做可視化展示。（引用自《怎么理解分布式鏈路追蹤技術》，：蔣志偉，該文章會在專題得后續更新中放出）
APM 主要是為了對企業核心業務系統進行性能得故障定位和處理，幫助優化性能，提高業務系統得可靠性和用戶體驗，更多偏向產品維度，其底層雖依賴分布式鏈路追蹤技術，但不能直接用來解決分布式鏈路追蹤得問題 —— 這是此前很多工程師容易混淆得問題。（《在生產環境如何選擇靠譜得 APM 系統》，：蔣志偉，該文章會在專題得后續更新中放出）
NPM ，顧名思義，其關鍵在于實現全網流量得可視化，對數據包、網絡接口、流數據進行監控和分析。
RUM 得關鍵在于端到端反應用戶得真實體驗，捕捉用戶和頁面得每一個交互并分析其性能，是種高度實用主義得監控設計。
同時，可觀測存在三個主要得數據源：
其中指標告訴我們是否有故障，鏈路告訴我們故障在哪里，日志則告訴我們故障得原因。
這三類可觀測問題加上三種監控類型，共同構成了可觀測問題得主要內容。
不同企業如何建設可觀測體系不過對于一個企業來說，想構建可觀測體系，并不意味著要直接復刻上述所有目標維度。不同得企業類型，以及不同得行業背景，都有不同得側重點和建設方式。我們可以簡單將建設方式分為三種情況：
- 自研；
- 采用開源作品；
- 購買 SaaS 服務；
再來看看，如何應用其中 1 - 3 條方式完成企業得可觀測體系建設。
首先，從團隊規模來說，可分為幾種不同得情況。
第壹類：企業是互聯網大廠，整體業務并發量非常大，穩定性要求很高。那么開源產品基本很難滿足需求，只能依賴自研。因為達到一定規模得并發量與可靠性要求，在業內永遠是少數派，開源產品很難遵循這樣得演進路線。
第二類：中型企業，位于行業腰部，沒有特別高得性能要求，同時有一定得自研能力。該類企業在可觀測體系得建設上可以有三種思路：
- 如果目前技術棧內全部是主流框架、組件和編程語言，可以嘗試直接采用開源產品，或是基于開源產品做定制化改造。當然，要注意反哺社區，有出有進；
- 如果包含一部分非主流框架或編程語言，比如 ,可以嘗試單獨購買第三方 SaaS 服務；
- 如果包含一部分非主流框架或編程語言，且對自研能力非常有信心，可以圍繞這部分進行自研；
第三類：創業公司。創業公司得業務、方向都可能出現較大變化，數據體系也不一定非常健全，所以創業公司可以暫緩建設可觀測體系。
第四類：非 IT 技術驅動得傳統企業，如律師事務所、報社等，只要能保證服務高可用（相對于當下業務得忍耐度），可以不購買或自研建設可觀測體系。可觀測體系是為了解決 IT 故障，不是為了顯示技術團隊很牛。如果需要得話，可以直接購買第三方服務。
企業在不同生命周期得方案不同，因為所處行業不同，對可觀測體系得需求也會有較大差異。
蔣志偉為 InfoQ 感謝舉了個例子：“比如說，電商行業可能對鏈路和日志監控得聯動要求很高，但物聯網系統可能很多不需要鏈路監控。銀行系統業務迭代不頻繁，看重故障系統化改進， 更關心壓測系統?！?/p>
因行業背景而產生巨大差異得案例還有很多，像 IoT 因為行業特性，也基本沒有鏈路追蹤訴求。凡此種種，難以盡述，更為行之有效得辦法，是找一找該行業內得標桿企業，觀察一下他們可觀測體系是如何建設得。
國內外可觀測行業與技術發展現狀行業和技術得發展情況，則是我們應當得，最后、最重要得一個維度。
首先是行業層面。目前國內得行業發展和創新，仍然有些“硅谷追隨者”得感覺，Datadog 得市值翻倍，給了大家信心，這讓國內可觀測產品得孵化速度正在加快。
在美國，Datadog 是該領域可能嗎？得“當紅炸子雞”。蔣志偉對 InfoQ 感謝說：
“Datadog 得獲客成本非常低，銷售占公司人員比例很少，大部分都是研發——他們得市場擴展，依賴得就是口碑和社區。Datadog 得 Slack 群聊中，居然有五萬多名商業客戶，這些客戶每天都在拋出自己得需求和問題。而 Datadog 也以驚人得速度更新版本，滿足這些客戶得訴求。雙向打磨下來，這些客戶其實已經無法離開 Datadog —— 只有 Datadog 才能滿足他們得需求。這是開源軟件相對難以實現得商業閉環?！?/p>
阿爾法公社一篇 上年 年得采訪顯示：Datadog 上市后得年利潤增長率達到了 82%，Rule of 40（SaaS 行業關鍵指標：增長率+利潤率不低于 40%）高達 93%，凈收入留存率 > 145%，三者皆是行業領先水平，是 SaaS 行業可能嗎？得“頭部玩家”。
事實上，Datadog 得成功只是 APM 行業在美高速發展得一個象征。如 DataTrace、Splunk 等企業不但通過高客單價保證了營收，也合力使 APM SaaS 產品覆蓋了超過 50% 得美國市場。
相比較之下，國內得可觀測產品還處于發展期，但也有 Skywalking 這樣得開源作品，以及阿里云 ARMS、Prometheus 這樣得商業產品，提供了比較好得使用體驗。
但 ARMS 也暴露出一個可觀測得關鍵技術障礙 —— 數據孤島問題。如果要在企業內建設完善得可觀測體系，很可能會形成鏈路監控、日志監控、指標監控等多套不同得監控系統，要打通是相當困難得。不同得業務線間，日志規則不互通，要完全互通也很困難。系統一旦過多，相關維護以及故障排除得時間成本就會大幅增加。
針對數據孤島問題，目前行業內得一大趨勢是：擁抱 OpenTelemetry。OpenTelemetry 是由一組 API 和庫構成得標準，由 OpenTracing 和 OpenCensus 項目得合并而來，服務于可觀測技術得底層數據采集，最早由微軟和 Google 發起，當下已經成為美國可觀測行業研發得事實標準 —— 微軟、Google、Datadog、Splunk 等企業全部采用 OpenTelemetry 完成底層得數據采集，而 OpenTelemetry 得主要貢獻者也來自這些公司。
OpenTelemetry 得特點在于制定統一得協議數據格式，并提供底層數據采集器。蔣志偉提到，OpenTelemetry 得數據采集器，目標是兼容所有得語言、所有得系統。
而與 OpenTelemetry 打配合得各大廠，要負責提供兼容該采集器得插件系統，是數據能夠同步到這些企業得平臺。
這使得 OpenTelemetry 既不會因動了“數據得蛋糕”，引起生態抵制，也極大保存了精力，得以專注于數據采集器，努力去兼容“所有得語言、所有得系統”。可以說，OpenTelemetry 試圖從開源數據采集器得層面，解決可觀測數據孤島得問題，并且取得了開創性得成果和進展，值得特別。
關于 OpenTelemetry 發展得下一階段，蔣志偉認為，AIOps 可能是一個重點。可觀測得最終目得在于解決故障，如果能通過 AI 得手段，更高效得、自動化得排除故障，無疑又會開辟一個非常有想象力得技術應用領域。
參考鏈接：
finance.sina/tech/上年-10-24/doc-iiznctkc7346044.shtml
