最近有一件事情讓我印象特別深刻，作為引子和大家嘮一嘮：我們在內部做一些極端的流量回歸仿真實驗時，在 TiKV（TiDB 的分布式存儲組件）上觀測到了異常的 CPU 使用率，但是從我們的 Grafana Metrics、日志輸出里面并沒有看到異常，因此也一度困惑了好幾天，最后靠一位老司機盲猜并結合 profiling 才找到真兇，真兇出現在誰都沒有想到的地方：Debug 用的日志模塊（澄清一下：目前這個 Bug 已經修復了，而且這個 Bug 的觸發是在非常極端壓力的場景下+日志級別全開才會出現，請各位用戶放心）。
這篇文章并不是做 Bug 分析，我覺得更重要的是，找問題過程中我們使用的工具、老司機的思考過程。作為一個觀察者，我看到年輕的同事看著老司機熟練地操作 perf 和在各種各樣工具和界面中切換那種仰慕的眼神，我隱約覺得事情有點不對：這意味著這門手藝不能復制。
事后，我做了一些關于基礎軟件用戶體驗的調研，發現該領域的理論和資料確實挺少（大多數是 ToC 產品的研究，系統軟件相關的大概只有 UNIX 哲學流派），而且缺乏系統化，依賴于作者個人「品味」，但是軟件體驗的好和壞顯然存在，例如一個有經驗的工程師看到一個命令行工具，敲幾下就知道是否好用，是不是一個有「品味」的工具。
很多時候「品味」之所以被稱為「品味」，就是因為說不清道不明，這固然是軟件開發藝術性的一種體現，但是這也意味著它不可復制，不易被習得。我覺得這也不好，今天這篇以及可能接下來的幾篇文章（雖然后幾篇我還不知道寫啥，但是先立個 Flag）會試著總結一下好的基礎軟件體驗到底從哪里來。
作為第一篇，本文將圍繞可觀測性和可交互性兩個比較重要的話題來談。至于為什么把這兩點放在一起聊，我先賣個關子，最后說。
可觀測性
可觀測性是什么？這可從我兩年前發表的《我眼中的分布式系統可觀測性》[1]一文中可見一斑，相同的內容我在這里就不贅述。隨著在 TiDB 中對可觀測性實踐的深入，對這個話題有了更深的理解，為了更好的理解，我們首先先明確一個問題：當我們在聊可觀測的時候，到底是誰在觀測？
是誰在觀測？
很多朋友可能會一愣，心想：這還用說，肯定是人，總不能是機器。沒錯，的確是人在觀測，但就是這么一個淺顯的道理往往會被軟件設計者忽略，所以這兩者的區別到底是什么？為什么強調人這個主體很重要？
要回答這個問題，需要清楚一個現實：人的短期工作記憶是很有限的。大量的心理學研究表明，人類工作記憶的容量大致只有 4，即在短期同時關注 4 項信息[2]，再多的信息就要靠分模塊的方式記憶，如我們快速記憶電話號碼的方式，以 13800001111 為例，我們通常不是一個個數字背，而是形如：138-0000-1111 進行分組。
在了解人的心智模型的一些基礎假設和帶寬后，我想很多系統軟件開發者大概不再會炫耀：我的軟件有 1000 多個監控項！這不僅不是好事，反而讓更多的信息破壞了短期記憶的形成，引入了更多的噪音，讓使用者在信息的海洋里花很多時間找關鍵信息，以及不自覺的分類（我相信大腦的一個不自覺的后臺任務就是對信息建索引和分類，注意這同樣是消耗帶寬的），所以第一個結論：軟件應用一屏的界面里面最好只有 4 個關鍵信息。那么，接下來的一個問題是：哪些是關鍵信息？什么是噪音？
區分關鍵信息和噪音
這個問題沒有標準答案。對于系統軟件來說，我的經驗是：跟著關鍵資源走。軟件其實很簡單，本質就是對硬件資源的使用和分配，講究平衡的藝術。關鍵的硬件資源無非也就下面幾個，對于下面每一個關鍵資源在某個采樣時間段（單點沒有太多意義），都可以通過一些簡單的問題的詢問，得到對系統運行狀態的大致圖景：
CPU：哪些線程在工作？這些線程都在干嘛？這些線程各自消耗了多少 CPU Time？
內存：當前內存中存儲了哪些東西？這些東西的命中率情況？（通常我們更關注業務緩存）？
網絡 I/O：QPS/TPS 有異常嗎？當前主要的網絡 I/O 是由什么請求發起的？帶寬還夠嗎？請求延遲？長鏈接還是短鏈接（衡量 syscall 的開銷）？
磁盤 I/O：磁盤在讀寫文件嗎？讀寫哪些文件？大多數的讀寫是什么 Pattern？吞吐多大？一次 I/O 延遲多大？
關鍵日志：不是所有日志都有用，只有包含特定關鍵字的日志，人們才會關心。所以，有沒有特定關鍵字的日志出現？
通過以上標準問題的靈魂拷問，必定可以對系統運行狀態有一定的了解。
更進一步的關鍵是，這些系統的指標一定要和業務上下文聯系在一起才能好用，舉例說明，對于一個支持事務的數據庫來說，假設我們看到 CPU 線程和 call stack，發現大量的 CPU 時間花在了 wait / sleep / idle 之類的事情上，同時也沒有其他 I/O 資源瓶頸，此時，如果只看這些的數字可能會一臉懵，但是結合事務的沖突率來看可能柳岸花明，甚至能直接給出這些 lock 的等待時間都花在了哪些事務，甚至哪些行的沖突上，這對觀測者是更有用的信息。
也并不是說其他的信息就沒用，而是相當多的信息的價值是后驗的，例如：絕大多數的 debug 日志，或者那些為了證實猜想的輔助信息，其實在解決未知問題時候幾乎沒有幫助，而且還需要觀察者有大量的背景知識，這類信息最好的呈現方式還是折疊起來，眼不見為凈的好。
如果打開 TiDB 的內部 Grafana 就會看到大量這樣的指標，如 stall-conditions-changed-of-each-cf（雖然我知道這個指標的含義，但是我猜 TiDB 的用戶里 99% 的人不知道），而且從名字里面我看到了寫下這個名字的工程師內心的掙扎，他一定很想讓其他人（或者自己）看懂這個名字指的是什么，但是比較遺憾，至少在我這里沒有成功。
觀察的下一步是什么？作出行動。
在做出行動之前想想，有行動的前提是什么？我們處理問題的行動大致會遵循下面模式（我自己總結的，但任何一本認知心理學的書都會有類似的概念）：觀察—>發現動機—>猜想—>驗證猜想—>形成計劃—>行動，然后再回到觀察，反復循環。
這個里面人（或者是老司機的經驗）體現比較重要地方是在從觀察到猜想這個環節，至于觀察的動機而言無非有兩種：
1. 解決眼前的故障；
2. 規避潛在的風險（避免未來的故障）。
假設系統沒有問題，也不太需要做出改變。 我覺得這兩步之所以重要，是因為基本上其他環節都可以用自動化，唯獨這兩步很難，因為需要用到：人的知識/經驗和直覺。
對于一個擁有好的可觀測性的系統，通常都是能很好利用人直覺的高手，舉個小的例子：當打開一個系統后臺界面時，我們試著不去關注具體的文字信息，如果界面中的紅色黃色的色塊比較多，我們的直覺會告訴自己這個系統可能處于不太健康的狀態，更進一步如果紅色和黃色大致都聚集在屏幕的某個具體位置上，我們的注意力一定會聚焦到這個位置；如果一個界面上全是綠色，那應該是比較健康的狀態。
怎么最大化利用人的直覺？或者說要引導到什么地方？我認為最好的點是：風險的預判。
人的直覺用在哪？風險的預判
此處需要利用一些先驗知識。在聊這個話題之前，我想分享一個我之前聽過的小故事，當年福特工廠里有個電機壞了，然后找了個老師傅，他聽了聽聲音，看了看機器運轉情況，最后用粉筆在電機上畫了一條線，說這個地方的線圈多繞了多少多少圈，將信將疑的工人們照做，果然問題解決了，然后老師傅開了個 1 萬美元的維修費（當時算是天價），福特的老板問他憑啥畫一條線就收那么多錢，老師傅開了個賬單：畫線 1 美元，知道在哪畫這條線 9999 美元。
故事的真假暫且不聊，假設是真的，我們可以看到直覺和經驗，真的是能產生很多的價值，我當時聽到這個故事的第一反應是，這個老師傅肯定這種情況見的多了（廢話），而且這個問題一定是常見問題。
其實解決問題最難部分是通過觀察（尤其是一些特征點）排除掉絕大多數不靠譜的方向，另外要相信常見故障的原因是會收斂的。這時一個具有良好可觀測性系統的第一步就是能給使用者的直覺指引方向，這個方向就需要前人的知識來給出可能性最大的故障點以及相關的指標（例如 CPU 使用率等）；第二步就是通過一些心理學小技巧把它展現出來。
下面以 TiDB 中即將會引入的一個小功能 TopSQL 加以佐證。這個功能說起來也很簡單，我們發現很多用戶故障都和少量的 SQL 相關，這類的 SQL 的特征是擁有和別的 SQL 有明顯不同的 CPU footprint，但是每一條 SQL 的 footprint 獨立看起來還挺正常的，所以 TopSQL 的功能就是回答：CPU 到底消耗了多少？在哪些 SQL 上？我試著不去解讀下面這個截圖，我猜聰明的你馬上就能知道怎么用：
你的直覺會告訴你，后半段那段密集的綠色占比好像和其他有什么不一樣，將整體的 CPU 使用率推高了，感覺有問題的樣子，沒錯，這大概就是正確的方向，好的可視化能夠利用人的直覺快速定位主要矛盾。
什么叫做“一個操作”？識別操作的真正的生命周期
剛才寫第一點的時候想到還有一個經常被人忽略的關鍵資源：時間。本來想把時間放到關鍵資源那節里面，但是想了想放在這里可能更加合適。
稍微形而上一點來看，我們現在的計算機都是圖靈機的實現，我小學就知道圖靈完備語言的最小功能集合：讀/寫變量，分支，循環。用文學一點的說法是：所謂程序就是無數個輪回，大輪回嵌套著小輪回（循環），每個輪回中根據現狀（變量）不斷的做出選擇（分支）。
我說到這里可能聰明的讀者會猜到我想說什么：如果我們討論可觀測性脫離了周期，就毫無意義。而周期的定義又是靈活的，對于人而言，大周期顯然是一輩子，小周期可以是一年一日，甚至周期可以不用時間跨度作為單位，比如一份工作的周期…
對于一個數據庫軟件而言，什么是一個合理的周期？是一條 SQL 的執行周期？還是一個事務從 Begin 到 Commit ？這里沒有標準答案，但是我個人建議，周期越貼近終端用戶的使用場景越實用。
譬如，在數據庫中，選擇單條 SQL 的執行作為周期不如選擇事務的周期，事務周期不如應用程序一個請求全鏈路的周期。其實 TiDB 在很早就引入了 OpenTracing 來追蹤一個 SQL 的執行周期內到底調用了哪些函數，花費多少時間，但最早只應用在了 TiDB 的 SQL 層內部（熟悉我們的朋友應該知道我們的 SQL 和存儲是分離的），沒有在存儲層 TiKV 實現，所以就會出現一條 SQL 語句的執行過程往下追到 TiKV 就到了一個斷頭路；
后來我們實現了把 TraceID 和 SpanID 傳到了 TiKV 內部這個功能才算初步可用，至少把一個周期的圖景變得更加完整了，本來我們打算就止步于此，但是后來發生了一個小事情，某天一個客戶說：為什么我的應用訪問 TiDB 那么慢？然后我一看 TiDB 的監控，沒有啊，SQL 到數據庫這邊基本都是毫秒就返回了，但是客戶說：你看我這個請求也沒干別的呀，兩邊怎么對不上？后來我們把 Tracer 加進來以后才知道客戶這邊的網絡出了點問題。
這個案例提醒了我，如果能做到全鏈路的 Tracing，這里的全鏈路應該是從業務端請求開始計算，去看待生命周期才有意義。所以在此之后我們在 TiDB 里面通過拓展 Session Variable，能夠支持用戶將 OpenTracing 協議的 Tracer 信息通過 Session Varible 傳入到 TiDB 的體系中，打通業務層和數據庫層，能夠真正實現的一個全生命周期的跟蹤，這個功能也會在很近的未來的版本中和大家見面。
說了這么多，總結幾點：
1. 時間也是重要資源。
2. 抓 Sample 也好，做 Trace 也好，選對周期很重要。
3. 周期越貼近業務的周期越有用。
