前段時間熱播的電視劇《開端》想必不少人都看過的，其新穎的拍攝手法和不落俗套的劇情著實頗具亮點。

（圖片來自sohu.com)

為什么要說到這部劇呢？因為這部劇可以更好的幫我們理解什么是系統的可觀測性，讓你從一大堆技術概念中解脫出來。

我們都知道，為了保障一個軟件系統的正常運行，通常我們都會為它增加監控手段，這里邊主要有兩類監控：黑盒監控與白盒監控。

黑盒監控是指對服務器的監控，重點關注磁盤空間、CPU 使用率、內存使用率、平均負載等領域，這些是業內大多數人認為要監控的標準系統指標。

（圖片來自pandorafms.com）

白盒監控是對在服務器上運行的應用程序的監控，可能是從Web 服務器收到的 HTTP 請求數量到應用程序生成的響應代碼時間等的任何內容。

在劇情里，主角們發現異常后多次進行警告和報警，但是問題始終沒有完美解決。因為這個系統很復雜，甚至于牽扯到之前的一個系統問題（作案嫌疑人之女的交通事故）。僅僅是針對當前狀態的監控與告警，是無法讓這個系統快速的從故障中恢復，更別說進行一次有效的迭代提升質量了。

所幸，劇情中的循環就類似我們的代碼一樣，它可以重來讓我們充分的debug。一次次的重置就像一次次的上線一樣，那么問題來了，無論是劇情里還是現實中循環終究是有限制的，所以我們需要盡快找到解決問題的辦法。

如果我們把公交車看成一個應用系統服務器，那個爆炸就是系統宕機的話，我們就會發現，這簡直就是一部實現系統可觀測性的好教材。

當男女主角身在公交車內時，對應的就是系統的白盒監控狀態；當提前下車時，他們就和那些警察一樣處于黑盒監控狀態。

在兩種狀態相互交替下，他們會用心觀查每個乘客的細節：每個人的位置、雙肩包被緊緊抱住、行李箱非常扎眼、蛇皮袋被視若珍寶、高壓鍋用來裝肉等等，這些是什么？聰明的你一定想到了，這些就是應用系統的部分指標數據（Metrics）。

（圖片來自smzdm.com）

主角們記錄的精確到幾點幾分的動作/行為，不僅忠實的還原了當時的情況，同時也為排查問題助了一臂之力，這不就是系統的日志數據（Logs）么。

隨著劇情的推進，他們獲取了更重要的數據，包括每個人物的關系，以及不同循環里事件的發展路徑，這些也是對破案最為關鍵的信息，其實對應的就是系統的追蹤數據（Traces）。

到此，構建可觀測性的三大類數據支撐已經完備，我們也不難發現追蹤數據（Traces）才是定位問題和解決問題的核心。

劇情最后，在主角們多輪艱苦卓絕的努力下，問題終于得到了圓滿的解決。但是，我們該慶幸么？不，我們該反思。如果從一開始主角們就知道人物的關系和事件的先后順序，破案還會這么困難么？答案自然是否定的。

回到我們的軟件系統中，潛在復雜性的來源是永無止境的，監控可能變得異常復雜，以至于監控本身變得很脆弱、難以維護。因此，一套好的監控系統應該是簡單并有效的，提供源自基于時間序列的設備、已知故障模式以及黑盒測試的關鍵業務和系統指標，而不是提供成百上千無太大意義的指標，意圖“監控一切”的做法很多時候都是一種反面教材。

（圖片來自dockone.io）

但可觀測性則不同，它旨在提供對系統行為的高度精細的洞察以及豐富的上下文，非常適合指導調試并真正解決系統的問題。由于無法預測系統可能遇到的每一種故障模式，或預測系統可能出現異常的每一種可能方式，因此我們構建的可觀測性是用證據而非推測進行調試系統，這很重要。

可觀測性并不是在取代監控，它也不是一種我們通常理解的工具形態。準確的講，它是一種屬性的范疇，甚至在很多時候是種能力的體現形式，越復雜的系統越需要這種屬性或能力。

但是話說回來，可觀測性也并非萬能的，它可以引導開發人員找到準確的答案，但不能保證讓他們100%找到答案。這個過程當中依舊需要當事人對系統、網絡等有著良好的理解甚至直覺，才能讓定位問題變得輕松并高效。