今天的應用架構，正處在一個不可測的階段
採訪嘉賓 | 吳結生（Jason Wu） 阿里巴巴高階研究員
主持人 | 霍太穩 極客邦科技創始人 CEO
編輯 | 鄧豔琴
近幾年，“可觀測性”這個詞在國內的 IT 圈子突然走紅，阿里、百度、位元組、騰訊等大廠紛紛跟進可觀測性建設，更有多家基於可觀測技術創業的公司陸續成立，可觀測性領域的融資很火爆。這把名為“可觀測性”的火，甚至從後端領域，延伸到了大前端，一些移動開發團隊希望通過引入“可觀測性”概念解決更深層次的應用架構問題，改善效能和業務體驗。
然而，“可觀測性”並不是一個新詞，為探尋它翻紅背後的原因，InfoQ 採訪了阿里巴巴高階研究員、阿里雲智慧儲存負責人吳結生（Jason Wu）。在今年首期 C 位面對面中，他與 InfoQ 共同解讀了儲存技術的現在與未來，分享了他親歷過的一些重大抉擇與成長感悟，
觀點一：今天的應用架構，正處在一個不可測的階段。
觀點二：監控是系統具備可觀測的能力之後，上層提供的一種工程能力。
觀點三：可觀測性一直存在，現在只是翻紅。
觀點四：雲原生時代，產品更需要具備可觀測性。
Observability，可觀測性 or 可觀察性？
在談論可觀測性的現在與未來之前，我們先來聊聊這個詞語本身。
可觀測性的概念來自於國外的 Observability 一詞，但如果我們開啟各種翻譯軟體，輸入“Observability”，出來的翻譯結果往往都是“可觀察性”。
所以，為什麼不叫“可觀察性”，而要提“可觀測性”？我們發現，今天有不少技術團隊是混用這兩個詞語的，他們認為沒有什麼區別，甚至會覺得你們搞文字工作的真煩，在這裡咬文嚼字，真是吃飽了撐的。
但翻譯其實是一件非常嚴肅重要的事情，好的翻譯可以讓人一看就懂。舉個經典的反例，計算機領域有一個詞語叫魯棒性，如果不去查詢相關資料，你可能很難理解這到底是個什麼特性。
因此，是選擇“可觀察性”還是“可觀測性”，這件事還是有一些小小的討論價值的。
若我們引用國內已有的文獻，會發現這兩個詞都有相關的釋義。
可觀察性是 2014 年全國科學技術名詞審定委員會公佈的全科醫學與社群衛生名詞。
可觀測性是 1990 年全國科學技術名詞審定委員會公佈的自動化科學技術名詞。
看起來，沿襲可觀測性的叫法，會更加貼合。那麼從技術的角度來看，又是什麼情況呢？對於這一個問題，Jason 表達了他的看法：“這個問題我之前還真的沒有想過，但如果你去搜索，會發現可觀測的頻率更高一些。而我個人也會比較傾向於可觀測性，為什麼呢？因為，我們很多的系統，或者說，很多的應用架構，在今天其實是處在一個不可測的階段。既然不可測，那麼相對應的，可觀測可能就更契合一點。”
可觀測性是新概念嗎？
在針對可觀測性的討論中，也夾雜著一些批判的聲音：這實際上就是對監控 /Monitoring 的改頭換面而已，卻有人聲稱這是一種新技術，這都是供應商的陰謀。
這裡需要探討的有兩個問題，第一，可觀測性是新技術嗎？第二，可觀測性就是監控的包裝炒作嗎？
可觀測性的內涵一直存在
首先，可觀測性的內涵一直都存在，如果仔細回憶一下，你會發現以前大型的分散式系統，包括平行計算裡面，都是強調可觀測性的。再比如，Linux 裡面就有很多可觀測性的東西，開啟一些 FLAG，它就會給你收集很多效能指標或者日誌。在編譯程式的時候，開啟一些編譯選項，你可以有很多 Debug 的資訊，這些都是可觀測性的體現。
Jason 認為，從某種意義上來說，可觀測性就是系統或者產品的一種能力。你的產品和系統在具備了功能和效能這些基本屬性之外，還需要具備可觀測性，這是一種能力的體現。這樣的能力會帶來什麼樣的好處？你可以把軟體、產品、服務，從黑盒變成白盒，幫助你更好地理解它們，幫助你站在更高的層次來發現問題、定位問題、解決問題。
那為什麼可觀測性在今天被大範圍提起來了，還被提到了一個新的高度？
因為雲端計算的發展。容器、微服務、分散式系統的出現，讓系統變得越來越複雜，在這個環境下，大家對於當下的新系統的設計、產品的設計，就衍生出了一些新的訴求，而且這個訴求在變得越來越明顯。
舉個例子來講，今天，我們有非常多的業務採用的是微服務架構，有幾千個容器，這些容器之間相互依賴，通訊十分複雜。如果說，每個容器它自己不具備可觀測的能力，你要怎麼排查問題？
再舉一個例子，可能你的系統用了多種技術產品，一些業務是你自己的，一些是阿里雲產品的，一些是第三方提供的，這幾者相互交錯。如果你的系統不具備可觀測性的話，你又要怎麼排查問題？
總結下來，是兩個原因驅動了可觀測性概念的走紅，一是對系統從黑盒到白盒的訴求，二是對資源到業務的可觀測性的訴求。
第一點比較好理解，第二點我們需要再舉個例子說明。如果你在執行一個網站服務，你發現客戶的體驗非常慢，那你需要想辦法知道到底是慢在哪裡，這時候前後端都需要排查問題。類似於這種從業務視角去解決問題的機會越來越多，對可觀測性的要求也就越來越高。再比如，作為業務方，你用了非常多的容器微服務，用了很多雲廠商的產品，你要關心業務的穩定性的話，你需要知道自己的系統裡面發生了什麼事情，那些雲廠商的產品裡面又發生了什麼事情，這些事情怎麼串聯起來。這就是從資源到業務的可觀測性。
可觀測興盛於雲原生，它將如何作用於雲原生？Jaosn 表示，它讓大家意識到，不管是雲原生服務也好，雲原生產品也好，都需要具備可觀測的能力，這是一個基本的要求。“我們要提供一些輔助的工具，去幫助客戶理解和洞察他的業務裡面發生的行為，所以就出現了像 APM 這樣的一些工具和產品，能夠自動地去插入一些程式碼到客戶的應用裡面，去幫助他們去做效能監控，或是其他事情。”
可觀測性 vs 監控
第二個問題，可觀測性是不是就是監控？
關於這個問題，業界存在幾種觀點，有認為監控就是可觀測性的，有認為這兩者沒有區別，但是之前的監控做的不對的，也有認為監控是可觀測性的子集的，還有認為這完全不是一碼事的。
這裡需要額外提一下第二個觀點，這個觀點的支持者表示：“監控不是資料採集、資料儲存和資料展示，那和普通的 CRUD 有什麼區別？監控應該是有 Topo 的，如果某個 Metric 下降了，告警了，你卻不能告訴我為什麼，是有人為變更還是機器故障了，那你叫什麼監控？”
再回到我們的問題上來，Jason 認為，監控系統是系統具備可被觀測的能力之後，我們在上面提供的工程能力。你首先要具備可觀測性，才可被監控。當一個軟體、一個模組具備可觀測性之後，你就可以拿到 Traces 追蹤、Loggings 日誌、Metrics 效能等指標資料，再在上面去建立監控這種工程平臺。得益於此，你監控的維度可能也會更多。
可觀測性與儲存的奇妙結合
資料是可觀測性的核心，談到資料必然離不開儲存。作為阿里雲智慧儲存負責人，Jason 如何看待儲存和可觀測性之間的關係呢？
Jason 以阿里雲端儲存為例做了闡述。一方面，阿里雲將大量地在系統設計和產品裡面提供可觀測的能力，後面將推出一系列的一些產品的功能，來強化阿里雲產品的可觀測能力。以儲存產品為例，都會有好幾個 Lens，這樣一來，客戶就能知道，自己傳送一個請求到塊儲存或者 OSS 之後，這個請求在哪個地方花了多少時間，是什麼樣的一個狀態。另一方面，他們還會幫助其他產品和客戶的服務構建自身的可觀測能力，例如提供一些面向 Logging、Metrics、Trace 的高效的儲存系統和分析系統，或者在日誌服務中提供 AI 分析能力和根因分析能力。
可觀測的好處前面說了很多，但一旦涉及到資料，問題就變得十分複雜了。我們擔心，系統的可觀測性越強，資料安全合規的風險是否會越大？
“我覺得這是個非常好的問題。我們目前的思考是兩個方面，一是說在做系統設計的時候，我們會考慮到哪些是敏感資訊，哪些資訊是可以透傳出來的。另外一個，當我們在收集這些資料資訊的時候，我們會把一些敏感欄位給去掉，並且配套了類似日誌審計這樣的安全措施來幫助我們，保證這些可觀測性的這些資料，它是合理合規的。”Jason 還告訴我們，這是一個在不斷演進的過程，“我們所做的一些資料治理方面的工作，都是在圍繞怎麼樣讓資料更加合規，以及資料流動是在客戶可以預期的範圍內，就是說這個資料不能從這個區域流到另外一個區域。類似這樣的資料安全管理，是整個產品設計和服務裡面都要考慮到的。”
寫在最後
當前，我們正處於一個數據量爆炸的時代，這帶來了整個系統架構的演化。系統規模愈加龐大，容器與容器之間，資料與資料之間，關係錯綜複雜，一旦出現問題，排查起來相當棘手。打造具備可觀測性的系統是應對之策，AIOps 又是另一個可行手段。接下來，我們還將聯合阿里雲《雲桌派》欄目，帶來一篇深度專訪，探究可觀測性與 AIOps 如何在今天的架構運維中形成合力，敬請期待。
本文為阿里雲原創內容，未經允許不得轉載。