最近有一件事情讓我印象特別深刻，作為引子和大家嘮一嘮：我們?cè)趦?nèi)部做一些極端的流量回歸仿真實(shí)驗(yàn)時(shí)，在 TiKV(TiDB 的分布式存儲(chǔ)組件)上觀測(cè)到了異常的 CPU 使用率，但是從我們的 Grafana Metrics、日志輸出里面并沒(méi)有看到異常，因此也一度困惑了好幾天，最后靠一位老司機(jī)盲猜并結(jié)合 profiling 才找到真兇，真兇出現(xiàn)在誰(shuí)都沒(méi)有想到的地方：Debug 用的日志模塊(澄清一下：目前這個(gè) Bug 已經(jīng)修復(fù)了，而且這個(gè) Bug 的觸發(fā)是在非常極端壓力的場(chǎng)景下+日志級(jí)別全開(kāi)才會(huì)出現(xiàn)，請(qǐng)各位用戶放心)。

這篇文章并不是做 Bug 分析，我覺(jué)得更重要的是，找問(wèn)題過(guò)程中我們使用的工具、老司機(jī)的思考過(guò)程。作為一個(gè)觀察者，我看到年輕的同事看著老司機(jī)熟練地操作 perf 和在各種各樣工具和界面中切換那種仰慕的眼神，我隱約覺(jué)得事情有點(diǎn)不對(duì)：這意味著這門(mén)手藝不能復(fù)制。

事后，我做了一些關(guān)于基礎(chǔ)軟件用戶體驗(yàn)的調(diào)研，發(fā)現(xiàn)該領(lǐng)域的理論和資料確實(shí)挺少(大多數(shù)是 ToC 產(chǎn)品的研究，系統(tǒng)軟件相關(guān)的大概只有 UNIX 哲學(xué)流派)，而且缺乏系統(tǒng)化，依賴于作者個(gè)人「品味」，但是軟件體驗(yàn)的好和壞顯然存在，例如一個(gè)有經(jīng)驗(yàn)的工程師看到一個(gè)命令行工具，敲幾下就知道是否好用，是不是一個(gè)有「品味」的工具。

很多時(shí)候「品味」之所以被稱為「品味」，就是因?yàn)檎f(shuō)不清道不明，這固然是軟件開(kāi)發(fā)藝術(shù)性的一種體現(xiàn)，但是這也意味著它不可復(fù)制，不易被習(xí)得。我覺(jué)得這也不好，今天這篇以及可能接下來(lái)的幾篇文章(雖然后幾篇我還不知道寫(xiě)啥，但是先立個(gè) Flag)會(huì)試著總結(jié)一下好的基礎(chǔ)軟件體驗(yàn)到底從哪里來(lái)。

作為第一篇，本文將圍繞可觀測(cè)性和可交互性兩個(gè)比較重要的話題來(lái)談。至于為什么把這兩點(diǎn)放在一起聊，我先賣(mài)個(gè)關(guān)子，最后說(shuō)。

1、可觀測(cè)性

可觀測(cè)性是什么?這可從我兩年前發(fā)表的《我眼中的分布式系統(tǒng)可觀測(cè)性》[1]一文中可見(jiàn)一斑，相同的內(nèi)容我在這里就不贅述。隨著在 TiDB 中對(duì)可觀測(cè)性實(shí)踐的深入，對(duì)這個(gè)話題有了更深的理解，為了更好的理解，我們首先先明確一個(gè)問(wèn)題：當(dāng)我們?cè)诹目捎^測(cè)的時(shí)候，到底是誰(shuí)在觀測(cè)?

2、是誰(shuí)在觀測(cè)？

很多朋友可能會(huì)一愣，心想：這還用說(shuō)，肯定是人，總不能是機(jī)器。沒(méi)錯(cuò)，的確是人在觀測(cè)，但就是這么一個(gè)淺顯的道理往往會(huì)被軟件設(shè)計(jì)者忽略，所以這兩者的區(qū)別到底是什么?為什么強(qiáng)調(diào)人這個(gè)主體很重要?

要回答這個(gè)問(wèn)題，需要清楚一個(gè)現(xiàn)實(shí)：人的短期工作記憶是很有限的。大量的心理學(xué)研究表明，人類工作記憶的容量大致只有 4，即在短期同時(shí)關(guān)注 4 項(xiàng)信息[2]，再多的信息就要靠分模塊的方式記憶，如我們快速記憶電話號(hào)碼的方式，以 13800001111 為例，我們通常不是一個(gè)個(gè)數(shù)字背，而是形如：138-0000-1111 進(jìn)行分組。

在了解人的心智模型的一些基礎(chǔ)假設(shè)和帶寬后，我想很多系統(tǒng)軟件開(kāi)發(fā)者大概不再會(huì)炫耀：我的軟件有 1000 多個(gè)監(jiān)控項(xiàng)!這不僅不是好事，反而讓更多的信息破壞了短期記憶的形成，引入了更多的噪音，讓使用者在信息的海洋里花很多時(shí)間找關(guān)鍵信息，以及不自覺(jué)的分類(我相信大腦的一個(gè)不自覺(jué)的后臺(tái)任務(wù)就是對(duì)信息建索引和分類，注意這同樣是消耗帶寬的)，所以第一個(gè)結(jié)論：軟件應(yīng)用一屏的界面里面最好只有 4 個(gè)關(guān)鍵信息。那么，接下來(lái)的一個(gè)問(wèn)題是：哪些是關(guān)鍵信息?什么是噪音?

3、區(qū)分關(guān)鍵信息和噪音

這個(gè)問(wèn)題沒(méi)有標(biāo)準(zhǔn)答案。對(duì)于系統(tǒng)軟件來(lái)說(shuō)，我的經(jīng)驗(yàn)是：跟著關(guān)鍵資源走。軟件其實(shí)很簡(jiǎn)單，本質(zhì)就是對(duì)硬件資源的使用和分配，講究平衡的藝術(shù)。關(guān)鍵的硬件資源無(wú)非也就下面幾個(gè)，對(duì)于下面每一個(gè)關(guān)鍵資源在某個(gè)采樣時(shí)間段(單點(diǎn)沒(méi)有太多意義)，都可以通過(guò)一些簡(jiǎn)單的問(wèn)題的詢問(wèn)，得到對(duì)系統(tǒng)運(yùn)行狀態(tài)的大致圖景：

• CPU：哪些線程在工作?這些線程都在干嘛?這些線程各自消耗了多少 CPU Time?

• 內(nèi)存：當(dāng)前內(nèi)存中存儲(chǔ)了哪些東西?這些東西的命中率情況?(通常我們更關(guān)注業(yè)務(wù)緩存)?

• 網(wǎng)絡(luò) I/O：QPS/TPS 有異常嗎?當(dāng)前主要的網(wǎng)絡(luò) I/O 是由什么請(qǐng)求發(fā)起的?帶寬還夠嗎?請(qǐng)求延遲?長(zhǎng)鏈接還是短鏈接(衡量 syscall 的開(kāi)銷)?

• 磁盤(pán) I/O：磁盤(pán)在讀寫(xiě)文件嗎?讀寫(xiě)哪些文件?大多數(shù)的讀寫(xiě)是什么 Pattern?吞吐多大?一次 I/O 延遲多大?

• 關(guān)鍵日志：不是所有日志都有用，只有包含特定關(guān)鍵字的日志，人們才會(huì)關(guān)心。所以，有沒(méi)有特定關(guān)鍵字的日志出現(xiàn)?

通過(guò)以上標(biāo)準(zhǔn)問(wèn)題的靈魂拷問(wèn)，必定可以對(duì)系統(tǒng)運(yùn)行狀態(tài)有一定的了解。

• 更進(jìn)一步的關(guān)鍵是，這些系統(tǒng)的指標(biāo)一定要和業(yè)務(wù)上下文聯(lián)系在一起才能好用，舉例說(shuō)明，對(duì)于一個(gè)支持事務(wù)的數(shù)據(jù)庫(kù)來(lái)說(shuō)，假設(shè)我們看到 CPU 線程和 call stack，發(fā)現(xiàn)大量的 CPU 時(shí)間花在了 wait / sleep / idle 之類的事情上，同時(shí)也沒(méi)有其他 I/O 資源瓶頸，此時(shí)，如果只看這些的數(shù)字可能會(huì)一臉懵，但是結(jié)合事務(wù)的沖突率來(lái)看可能柳岸花明，甚至能直接給出這些 lock 的等待時(shí)間都花在了哪些事務(wù)，甚至哪些行的沖突上，這對(duì)觀測(cè)者是更有用的信息。

也并不是說(shuō)其他的信息就沒(méi)用，而是相當(dāng)多的信息的價(jià)值是后驗(yàn)的，例如：絕大多數(shù)的 debug 日志，或者那些為了證實(shí)猜想的輔助信息，其實(shí)在解決未知問(wèn)題時(shí)候幾乎沒(méi)有幫助，而且還需要觀察者有大量的背景知識(shí)，這類信息最好的呈現(xiàn)方式還是折疊起來(lái)，眼不見(jiàn)為凈的好。

如果打開(kāi) TiDB 的內(nèi)部 Grafana 就會(huì)看到大量這樣的指標(biāo)，如 stall-conditions-changed-of-each-cf(雖然我知道這個(gè)指標(biāo)的含義，但是我猜 TiDB 的用戶里 99% 的人不知道)，而且從名字里面我看到了寫(xiě)下這個(gè)名字的工程師內(nèi)心的掙扎，他一定很想讓其他人(或者自己)看懂這個(gè)名字指的是什么，但是比較遺憾，至少在我這里沒(méi)有成功。

觀察的下一步是什么?作出行動(dòng)。

在做出行動(dòng)之前想想，有行動(dòng)的前提是什么?我們處理問(wèn)題的行動(dòng)大致會(huì)遵循下面模式(我自己總結(jié)的，但任何一本認(rèn)知心理學(xué)的書(shū)都會(huì)有類似的概念)：觀察—>發(fā)現(xiàn)動(dòng)機(jī)—>猜想—>驗(yàn)證猜想—>形成計(jì)劃—>行動(dòng)，然后再回到觀察，反復(fù)循環(huán)。

這個(gè)里面人(或者是老司機(jī)的經(jīng)驗(yàn))體現(xiàn)比較重要地方是在從觀察到猜想這個(gè)環(huán)節(jié)，至于觀察的動(dòng)機(jī)而言無(wú)非有兩種：

1. 解決眼前的故障;

2. 規(guī)避潛在的風(fēng)險(xiǎn)(避免未來(lái)的故障)。

假設(shè)系統(tǒng)沒(méi)有問(wèn)題，也不太需要做出改變。 我覺(jué)得這兩步之所以重要，是因?yàn)榛旧掀渌h(huán)節(jié)都可以用自動(dòng)化，唯獨(dú)這兩步很難，因?yàn)樾枰玫剑喝说闹R(shí)/經(jīng)驗(yàn)和直覺(jué)。

對(duì)于一個(gè)擁有好的可觀測(cè)性的系統(tǒng)，通常都是能很好利用人直覺(jué)的高手，舉個(gè)小的例子：當(dāng)打開(kāi)一個(gè)系統(tǒng)后臺(tái)界面時(shí)，我們?cè)囍蝗リP(guān)注具體的文字信息，如果界面中的紅色黃色的色塊比較多，我們的直覺(jué)會(huì)告訴自己這個(gè)系統(tǒng)可能處于不太健康的狀態(tài)，更進(jìn)一步如果紅色和黃色大致都聚集在屏幕的某個(gè)具體位置上，我們的注意力一定會(huì)聚焦到這個(gè)位置;如果一個(gè)界面上全是綠色，那應(yīng)該是比較健康的狀態(tài)。

怎么最大化利用人的直覺(jué)?或者說(shuō)要引導(dǎo)到什么地方?我認(rèn)為最好的點(diǎn)是：風(fēng)險(xiǎn)的預(yù)判。

4、人的直覺(jué)用在哪？風(fēng)險(xiǎn)的預(yù)判

此處需要利用一些先驗(yàn)知識(shí)。在聊這個(gè)話題之前，我想分享一個(gè)我之前聽(tīng)過(guò)的小故事，當(dāng)年福特工廠里有個(gè)電機(jī)壞了，然后找了個(gè)老師傅，他聽(tīng)了聽(tīng)聲音，看了看機(jī)器運(yùn)轉(zhuǎn)情況，最后用粉筆在電機(jī)上畫(huà)了一條線，說(shuō)這個(gè)地方的線圈多繞了多少多少圈，將信將疑的工人們照做，果然問(wèn)題解決了，然后老師傅開(kāi)了個(gè) 1 萬(wàn)美元的維修費(fèi)(當(dāng)時(shí)算是天價(jià))，福特的老板問(wèn)他憑啥畫(huà)一條線就收那么多錢(qián)，老師傅開(kāi)了個(gè)賬單：畫(huà)線 1 美元，知道在哪畫(huà)這條線 9999 美元。

故事的真假暫且不聊，假設(shè)是真的，我們可以看到直覺(jué)和經(jīng)驗(yàn)，真的是能產(chǎn)生很多的價(jià)值，我當(dāng)時(shí)聽(tīng)到這個(gè)故事的第一反應(yīng)是，這個(gè)老師傅肯定這種情況見(jiàn)的多了(廢話)，而且這個(gè)問(wèn)題一定是常見(jiàn)問(wèn)題。

其實(shí)解決問(wèn)題最難部分是通過(guò)觀察(尤其是一些特征點(diǎn))排除掉絕大多數(shù)不靠譜的方向，另外要相信常見(jiàn)故障的原因是會(huì)收斂的。這時(shí)一個(gè)具有良好可觀測(cè)性系統(tǒng)的第一步就是能給使用者的直覺(jué)指引方向，這個(gè)方向就需要前人的知識(shí)來(lái)給出可能性最大的故障點(diǎn)以及相關(guān)的指標(biāo)(例如 CPU 使用率等);第二步就是通過(guò)一些心理學(xué)小技巧把它展現(xiàn)出來(lái)。

下面以 TiDB 中即將會(huì)引入的一個(gè)小功能 TopSQL 加以佐證。這個(gè)功能說(shuō)起來(lái)也很簡(jiǎn)單，我們發(fā)現(xiàn)很多用戶故障都和少量的 SQL 相關(guān)，這類的 SQL 的特征是擁有和別的 SQL 有明顯不同的 CPU footprint，但是每一條 SQL 的 footprint 獨(dú)立看起來(lái)還挺正常的，所以 TopSQL 的功能就是回答：CPU 到底消耗了多少?在哪些 SQL 上?我試著不去解讀下面這個(gè)截圖，我猜聰明的你馬上就能知道怎么用：

你的直覺(jué)會(huì)告訴你，后半段那段密集的綠色占比好像和其他有什么不一樣，將整體的 CPU 使用率推高了，感覺(jué)有問(wèn)題的樣子，沒(méi)錯(cuò)，這大概就是正確的方向，好的可視化能夠利用人的直覺(jué)快速定位主要矛盾。

5、什么叫做“一個(gè)操作”？識(shí)別操作的真正的生命周期

剛才寫(xiě)第一點(diǎn)的時(shí)候想到還有一個(gè)經(jīng)常被人忽略的關(guān)鍵資源：時(shí)間。本來(lái)想把時(shí)間放到關(guān)鍵資源那節(jié)里面，但是想了想放在這里可能更加合適。

稍微形而上一點(diǎn)來(lái)看，我們現(xiàn)在的計(jì)算機(jī)都是圖靈機(jī)的實(shí)現(xiàn)，我小學(xué)就知道圖靈完備語(yǔ)言的最小功能集合：讀/寫(xiě)變量，分支，循環(huán)。用文學(xué)一點(diǎn)的說(shuō)法是：所謂程序就是無(wú)數(shù)個(gè)輪回，大輪回嵌套著小輪回(循環(huán))，每個(gè)輪回中根據(jù)現(xiàn)狀(變量)不斷的做出選擇(分支)。

我說(shuō)到這里可能聰明的讀者會(huì)猜到我想說(shuō)什么：如果我們討論可觀測(cè)性脫離了周期，就毫無(wú)意義。而周期的定義又是靈活的，對(duì)于人而言，大周期顯然是一輩子，小周期可以是一年一日，甚至周期可以不用時(shí)間跨度作為單位，比如一份工作的周期…

對(duì)于一個(gè)數(shù)據(jù)庫(kù)軟件而言，什么是一個(gè)合理的周期?是一條 SQL 的執(zhí)行周期?還是一個(gè)事務(wù)從 Begin 到 Commit ?這里沒(méi)有標(biāo)準(zhǔn)答案，但是我個(gè)人建議，周期越貼近終端用戶的使用場(chǎng)景越實(shí)用。

譬如，在數(shù)據(jù)庫(kù)中，選擇單條 SQL 的執(zhí)行作為周期不如選擇事務(wù)的周期，事務(wù)周期不如應(yīng)用程序一個(gè)請(qǐng)求全鏈路的周期。其實(shí) TiDB 在很早就引入了 OpenTracing 來(lái)追蹤一個(gè) SQL 的執(zhí)行周期內(nèi)到底調(diào)用了哪些函數(shù)，花費(fèi)多少時(shí)間，但最早只應(yīng)用在了 TiDB 的 SQL 層內(nèi)部(熟悉我們的朋友應(yīng)該知道我們的 SQL 和存儲(chǔ)是分離的)，沒(méi)有在存儲(chǔ)層 TiKV 實(shí)現(xiàn)，所以就會(huì)出現(xiàn)一條 SQL 語(yǔ)句的執(zhí)行過(guò)程往下追到 TiKV 就到了一個(gè)斷頭路;

后來(lái)我們實(shí)現(xiàn)了把 TraceID 和 SpanID 傳到了 TiKV 內(nèi)部這個(gè)功能才算初步可用，至少把一個(gè)周期的圖景變得更加完整了，本來(lái)我們打算就止步于此，但是后來(lái)發(fā)生了一個(gè)小事情，某天一個(gè)客戶說(shuō)：為什么我的應(yīng)用訪問(wèn) TiDB 那么慢?然后我一看 TiDB 的監(jiān)控，沒(méi)有啊，SQL 到數(shù)據(jù)庫(kù)這邊基本都是毫秒就返回了，但是客戶說(shuō)：你看我這個(gè)請(qǐng)求也沒(méi)干別的呀，兩邊怎么對(duì)不上?后來(lái)我們把 Tracer 加進(jìn)來(lái)以后才知道客戶這邊的網(wǎng)絡(luò)出了點(diǎn)問(wèn)題。

這個(gè)案例提醒了我，如果能做到全鏈路的 Tracing，這里的全鏈路應(yīng)該是從業(yè)務(wù)端請(qǐng)求開(kāi)始計(jì)算，去看待生命周期才有意義。所以在此之后我們?cè)?TiDB 里面通過(guò)拓展 Session Variable，能夠支持用戶將 OpenTracing 協(xié)議的 Tracer 信息通過(guò) Session Varible 傳入到 TiDB 的體系中，打通業(yè)務(wù)層和數(shù)據(jù)庫(kù)層，能夠真正實(shí)現(xiàn)的一個(gè)全生命周期的跟蹤，這個(gè)功能也會(huì)在很近的未來(lái)的版本中和大家見(jiàn)面。

說(shuō)了這么多，總結(jié)幾點(diǎn)：

1. 時(shí)間也是重要資源。

2. 抓 Sample 也好，做 Trace 也好，選對(duì)周期很重要。

3. 周期越貼近業(yè)務(wù)的周期越有用。

6、可觀測(cè)性能救命的時(shí)刻：事后觀測(cè)

我相信沒(méi)有人會(huì)沒(méi)事天天看著監(jiān)控界面，其實(shí)仔細(xì)想想，當(dāng)我們需要可觀測(cè)性的時(shí)候，多數(shù)是已經(jīng)出現(xiàn)了可感知的故障或者很明確的風(fēng)險(xiǎn)。此時(shí)的系統(tǒng)可能已經(jīng)“病入膏肓”，或者在火燒眉毛的時(shí)候還不知道啥原因?qū)е拢渲械母蚧蚴侵澳硞€(gè)時(shí)間的一些不太顯然的異常變化，這時(shí)候發(fā)現(xiàn)之前除了正常的 Metrics 外并沒(méi)有更多的信息，我們當(dāng)然不會(huì)永遠(yuǎn)開(kāi)著 CPU Profiler，通常 Profiler 都是手動(dòng)觸發(fā)，但是如果是在事后復(fù)盤(pán)原因的時(shí)候，能夠有事發(fā)之前的 CPU Profile 記錄，對(duì)于問(wèn)題的解決和歸因會(huì)有巨大的幫助，所以一個(gè)比較好的方案是：在一個(gè)相對(duì)短的時(shí)間間隔下(比如分鐘級(jí))自動(dòng)的開(kāi)啟 Profiler，自動(dòng)把診斷結(jié)果保存下來(lái)，就像定期做一個(gè)深度體檢記錄一樣，老的記錄定期刪除就好了，萬(wàn)一出事，可以快速往前回溯，救命的效率會(huì)更高。

另外相信我，做 Profile 其實(shí)也不會(huì)有什么明顯的性能損耗(何況還是間歇性的)，這個(gè)功能我們叫做：Continuous Profiling，這個(gè)功能很實(shí)用，也會(huì)很快和大家見(jiàn)面。

根據(jù)我們的經(jīng)驗(yàn)，結(jié)合上面一節(jié)，有了完善的 Tracing 系統(tǒng)，大部分的 Debug 過(guò)程在 Tracing + Log 就能找到問(wèn)題的根因。

7、最好的可觀測(cè)性是能夠指導(dǎo)用戶：“我接下來(lái)該做什么？”

上文中提到了行動(dòng)，我在觀察老師傅處理問(wèn)題的時(shí)候發(fā)現(xiàn)一個(gè)特別有意思的現(xiàn)象：有經(jīng)驗(yàn)的開(kāi)發(fā)者總是能夠很快通過(guò)觀測(cè)，決定自己接下來(lái)該做什么，不需要查閱資料什么或者等著別人指導(dǎo)，完全處于一個(gè)心流的狀態(tài)(例如在 TiDB 里面看到數(shù)據(jù)在集群內(nèi)部分布不均或者有熱點(diǎn)，就知道去修改調(diào)度策略或者手工 split region)，但是新人在這一步總是會(huì)卡著，要么去 Google 要么去翻文檔，內(nèi)心OS：「我看到問(wèn)題了，然后怎么辦?」，如果這個(gè)時(shí)候，系統(tǒng)能夠給一些接下來(lái)應(yīng)該觀測(cè)哪些指標(biāo)，或者行動(dòng)建議，會(huì)更加友好，目前能做到這一點(diǎn)的系統(tǒng)不多，如果能做到這一點(diǎn)，相信你的系統(tǒng)已經(jīng)在可觀測(cè)性上做得很棒了。把這個(gè)點(diǎn)放在可觀測(cè)性的最后其實(shí)是想借著這個(gè)話題引出可交互性。

8、可交互性

在聊基礎(chǔ)軟件的可交互性之前，我想先和大家回顧一下計(jì)算機(jī)的歷史，在我看來(lái)計(jì)算機(jī)歷史的一個(gè)側(cè)寫(xiě)就是人機(jī)交互的進(jìn)化史：從第一張圖，看著一堆線我也不知道怎么操作，到現(xiàn)在我從來(lái)沒(méi)看過(guò) iPhone 的說(shuō)明書(shū)就能夠熟練使用，這個(gè)背后其實(shí)是多個(gè)學(xué)科的進(jìn)步(包括不限于心理學(xué)、認(rèn)知科學(xué)神經(jīng)科學(xué)、哲學(xué)、計(jì)算機(jī)科學(xué))。

回到我們這個(gè)領(lǐng)域，基礎(chǔ)軟件這個(gè)領(lǐng)域因?yàn)殡x大眾確實(shí)有點(diǎn)遠(yuǎn)，過(guò)去很多設(shè)計(jì)是由工程師完成的，我們這類人，普遍有點(diǎn)缺乏對(duì)人性的理解(no offense )，一個(gè)很典型的邏輯是：“我自己是人，所以我了解人。我的設(shè)計(jì)自己能理解，因?yàn)槲沂侨耍詣e的人也能理解。如果別人不會(huì)用，就去看看文檔就好了(此時(shí)還有一個(gè)嫌棄臉)”。

當(dāng)我們復(fù)盤(pán)一些故障時(shí)，經(jīng)常會(huì)得出「使用者操作不當(dāng)」的結(jié)論，但是這真的是根因嗎?我在之前的公司曾經(jīng)歷過(guò)一個(gè)事故給我留下了深刻的印象：當(dāng)時(shí)內(nèi)部有一個(gè)自己做的分布式文件系統(tǒng)，就像所有的文件系統(tǒng)一樣，它有一個(gè) shell，可以支持一些 UNIX Style 的命令操作。

有一次，一個(gè)工程師執(zhí)行了一行命令：rm -rf /usr /local/...(注意 /usr 后邊的空格)，然后系統(tǒng)很聽(tīng)話的開(kāi)始刪除自己...最后這件事情的復(fù)盤(pán)并沒(méi)有責(zé)怪這個(gè)操作者，而是懲罰了這個(gè)系統(tǒng)的設(shè)計(jì)者(當(dāng)時(shí)那個(gè)公司的老板)，因?yàn)檫@是個(gè)壞的交互設(shè)計(jì)，哪怕在刪除重要文件夾前確認(rèn)一下或者通過(guò)權(quán)限系統(tǒng)保護(hù)一下都不至于發(fā)生這個(gè)事情，機(jī)器確實(shí)在按照邏輯工作，這個(gè)地方也沒(méi)有 Bug(甚至這個(gè)刪除還很高效，畢竟分布式系統(tǒng) LOL)。

在后來(lái)作為工程師漫長(zhǎng)的歲月中，我漸漸理解到一個(gè)道理：最好的工程師能在邏輯和感性中間找到一個(gè)平衡，良好的設(shè)計(jì)源于對(duì)技術(shù)和心理的理解，畢竟我們是在為人寫(xiě)程序。

作為軟件的使用者，我們與其說(shuō)是在使用，不如說(shuō)我們是在和軟件「對(duì)話」。那既然是對(duì)話，那么就意味著這是一個(gè)交互的過(guò)程，什么是一個(gè)好的交互體驗(yàn)?zāi)?我試著總結(jié)一些寫(xiě)給軟件設(shè)計(jì)者的原則，試著第一次干這事，不排除以后會(huì)補(bǔ)充。

9、沒(méi)人讀文檔：一條命令啟動(dòng)和探索式學(xué)習(xí)

承認(rèn)吧，沒(méi)有人會(huì)看說(shuō)明書(shū)。我們拿到一部新的 iPhone 時(shí)候，第一反應(yīng)一定是開(kāi)機(jī)(很神奇吧，我們似乎下意識(shí)就知道開(kāi)機(jī)鍵在哪)肯定不是看說(shuō)明書(shū)找開(kāi)機(jī)按鈕，開(kāi)機(jī)就開(kāi)始通過(guò)手指來(lái)探索新的世界，很淺顯的道理，為什么在系統(tǒng)軟件領(lǐng)域就要先熟讀文檔才能上崗呢?

我經(jīng)常教育我們年輕的產(chǎn)品經(jīng)理：“你的用戶充其量會(huì)在你的 GitHub 首頁(yè)或者文檔的 Quick Start 部分上停留 10 秒，甚至連看完這個(gè)文檔的耐心都沒(méi)有，他們的潛意識(shí)會(huì)尋找「深色背景的字」(shell 命令)，然后把里面東西復(fù)制到自己的終端里看會(huì)發(fā)生什么，除此之外啥都不會(huì)做，如果這第一條命令失敗了，不會(huì)再有后面什么事了，所以記住你只有一次機(jī)會(huì)”。

一個(gè)小例子就是當(dāng)時(shí)在做 tiup(TiDB 的安裝部署工具)的時(shí)候，我反復(fù)告誡 tiup 的產(chǎn)品經(jīng)理，首頁(yè)里不要廢話，就一句命令，貼進(jìn)去就能用：

tiup 的首頁(yè)(tiup.io)截圖

其實(shí)這個(gè)例子可以更延展一點(diǎn)，我記得疫情之前有一年我在布魯塞爾參加 FOSDEM，晚上在會(huì)場(chǎng)附近的酒吧和一位來(lái)自英國(guó)的 DevOps 聊天，可能也是喝多了，他說(shuō)：“不能用一個(gè) apt-get install 就安裝成功的系統(tǒng)軟件不是一個(gè)好軟件。”，話糙理不糙。

那你可能要問(wèn)，如果確實(shí)有一些信息或者概念需要傳遞給用戶，如果用認(rèn)知心理學(xué)里面的概念，可稱之為構(gòu)建 Mental Model(心智模型)，最好的方式是什么呢?我自己的經(jīng)驗(yàn)是：探索式的學(xué)習(xí)。支持這種認(rèn)知構(gòu)建模式的系統(tǒng)通常需要有 Self-Explanatory 的能力，即告訴用戶第一步(例如 iPhone 的開(kāi)機(jī))之后用戶的每一步都能夠利用上一步行為的輸出，決定下一步的行為完成學(xué)習(xí)。

舉個(gè)例子：MySQL 的系統(tǒng)表想必 MySQL 的用戶都不會(huì)陌生，你只要用一個(gè)交互式的 mysql-client 鏈接到一個(gè)實(shí)例上，也不用等著系統(tǒng)告知 INFORMATION_SCHEMA 里面有什么，只需要用戶 SHOW TABLES 一下就知道了，然后再使用 SELECT * FROM 語(yǔ)句就可以一步步探索 INFORMATION_SCHEMA 里面具體表的內(nèi)容。這就是一個(gè) Self-Explanatory 的絕佳例子(這個(gè)例子里面有個(gè)前提就是 SQL 作為統(tǒng)一的交互語(yǔ)言)。

另一個(gè)特別好的例子是 Telegram 的 Botfather，我相信給 Telegram 寫(xiě)過(guò)機(jī)器人的朋友一定會(huì)對(duì) Botfather 的好用程度印象深刻，我放一張圖你就懂了：

用 Telegram 的 botfather 創(chuàng)建聊天機(jī)器人的過(guò)程

Telegram 是一個(gè)聊天軟件，Botfather 巧妙的利用了 IM 的交互模式應(yīng)用到了一個(gè)相對(duì)枯燥的 bot 開(kāi)發(fā)流程里面，而不是冷冰冰的丟給用戶一個(gè) URL，讓用戶自己研究去。

這一節(jié)最后一句話想送給大家，有一個(gè)無(wú)從考究的都市傳說(shuō)是這么說(shuō)的：魚(yú)的記憶時(shí)間只有 7s，我想說(shuō)，人也一樣。祝你做出一個(gè)“魚(yú)”都能用好的軟件。

10、幫用戶多想一步，告訴用戶半步，讓用戶自己走半步

我很喜歡看科幻小說(shuō)，很多科幻小說(shuō)探索的一個(gè)終極哲學(xué)話題：我們是否真的有自我意識(shí)?盡管我們認(rèn)為我們有，但是在軟件輸出 Unknown Error 的時(shí)候，你肯定希望有一個(gè)聲音告訴你接下來(lái)該怎么辦，對(duì)吧?

一個(gè)優(yōu)秀的基礎(chǔ)軟件，在輸出負(fù)向反饋的時(shí)候，最好的做法就是建議開(kāi)發(fā)者接下來(lái)該干嘛。我舉一個(gè)很經(jīng)典的例子，所有的 Rust 開(kāi)發(fā)者都有過(guò)被編譯器調(diào)教的日子，但是這個(gè)過(guò)程嚴(yán)格來(lái)說(shuō)其實(shí)并不痛苦，比如，看下面的截圖：

之所以不痛苦是因?yàn)榫幾g器明確告訴了你哪里有問(wèn)題、原因，以及下一步應(yīng)該干嘛，普通編譯器可能打印一個(gè) cannot borrow as mutable 就仁至義盡了，但是一個(gè)好體驗(yàn)的編譯器會(huì)多幫你想一步。

回到自我意識(shí)的問(wèn)題，我之前聽(tīng)過(guò)一個(gè)段子：一個(gè)測(cè)試工程師走進(jìn)一家酒吧，要了 NaN 杯 Null，一個(gè)測(cè)試工程師化裝成老板走進(jìn)一家酒吧，要了500杯啤酒并且不付錢(qián)，一萬(wàn)個(gè)測(cè)試工程師在酒吧門(mén)外呼嘯而過(guò)，一個(gè)測(cè)試工程師走進(jìn)一家酒吧，要了一杯啤酒';DROP TABLE，最后測(cè)試工程師們滿意地離開(kāi)了酒吧，然后一名顧客點(diǎn)了一份炒飯，酒吧炸了 LOL。

這個(gè)故事告訴我們，作為軟件設(shè)計(jì)者，你永遠(yuǎn)沒(méi)有辦法窮舉使用者的想法，與其讓用戶放飛想象力，不如你自己設(shè)計(jì)好故事線，一步步讓用戶跟著你的思路走。但是為什么還要留半步?我的答案：

1. 「參與感」會(huì)帶來(lái)幸福感，人有時(shí)候挺矛盾的，一邊希望機(jī)器自動(dòng)干完所有的事，一邊還期待自己有主動(dòng)權(quán)。有時(shí)候即軟件已經(jīng)知道下一步一定是做某些事情，但是留下臨門(mén)一腳讓操作者完成相當(dāng)于把成就感都賦予了操作者。

2. 選擇的權(quán)利交給操作者，尤其在面對(duì)一些單向門(mén)的決定時(shí)，go or no-go 還是應(yīng)該交給人。

對(duì)于這點(diǎn)，我還有幾個(gè)小建議：

1. 對(duì)于一些操作可能會(huì)引發(fā)多個(gè)連續(xù)操作的模式(例如 terraform 的部署腳本，或者集群變更之類的功能)，提供一個(gè) Dry Run 模式是必要的，只輸出操作，不執(zhí)行操作。

2. 對(duì)于上面這種批處理型的操作，盡可能設(shè)計(jì) save point，不用每次都重新來(lái)(類似斷點(diǎn)續(xù)傳)，體驗(yàn)會(huì)好很多。

3. 遇到真的 Unknown Error 要輸出各種幫助 Debug 的上下文信息，最后在錯(cuò)誤日志里提示用戶到哪個(gè)鏈接提 Github Issue，然后最好在 URL Link 里幫用戶把 Issue Title 填好(讓用戶自己決定是不是發(fā) Issue)

這節(jié)最后分享一個(gè) react-create-app 的例子：react-create-app 的例子(這個(gè)例子也是后面提到的關(guān)于正確反饋的好例子)。

11、統(tǒng)一語(yǔ)言：控制器和控制對(duì)象

我訪談過(guò)很多系統(tǒng)工程師，我有個(gè)必問(wèn)的問(wèn)題：你心中最好用的(數(shù)據(jù)庫(kù)) cli 工具是哪個(gè)?絕大多數(shù)幾乎下意識(shí)的回答 redis-cli。其實(shí)我自己也會(huì)給出同樣的答案，后來(lái)我想這是為什么呢?

「控制器」-「被控制對(duì)象」是一個(gè)在基礎(chǔ)軟件中非常常見(jiàn)的模式，就像我們?cè)诓僮麟娨暀C(jī)的時(shí)候，絕大多數(shù)時(shí)間是通過(guò)遙控器一樣，所以可以認(rèn)為用戶對(duì)電視機(jī)的第一和大多數(shù)觸點(diǎn)其實(shí)是遙控器，所以類比到基礎(chǔ)軟件中，對(duì)于控制器的設(shè)計(jì)其實(shí)非常關(guān)鍵，做好控制器，我覺(jué)得關(guān)鍵點(diǎn)是：

1. 構(gòu)建統(tǒng)一的交互語(yǔ)言

2. 自洽且簡(jiǎn)潔的概念模型

我稍微用 redis-cli 作為例子解讀一下。使用過(guò) redis-cli 的朋友都知道，所有的操作都遵循 [CMD] [ARG1] [ARG2] ... 的模式，在 redis-cli 沒(méi)有例外，不管是操作數(shù)據(jù)，還是修改配置，所有的一切都在一個(gè)統(tǒng)一的交互語(yǔ)言下，而且這個(gè)語(yǔ)言一目了然，而且這個(gè)語(yǔ)言里面有一些很自然的約定，例如命令(CMD)永遠(yuǎn)是幾個(gè)不包含符號(hào)的字母組成。

redis-cli 的交互例子

其實(shí)這點(diǎn)在剛才提到探索式學(xué)習(xí)那節(jié) MySQL 的例子也是一樣的，SQL 本身就是一個(gè)統(tǒng)一的交互語(yǔ)言，只是沒(méi)有 Redis 這么直觀。

第二點(diǎn)是概念模型，Redis 的優(yōu)勢(shì)在于它是一個(gè) Key-Value 數(shù)據(jù)庫(kù)，所以概念很簡(jiǎn)單：一切都是 Key-Value，觀察它的 cli 工具，你仔細(xì)品一品就知道，作者在嘗試將所有的功能和交互都往這個(gè) Key-Value 的模型上映射，這個(gè)是很自然的，因?yàn)槲覀冎詴?huì)使用 redis-cli，首先是我們接受了 Redis 是一個(gè) KV 數(shù)據(jù)庫(kù)的現(xiàn)實(shí)，所以在使用 redis-cli 的時(shí)候的一個(gè)自動(dòng)就成立心智假設(shè)就是 Key-Value 模式，這在使用 cli 的時(shí)候一切的操作都會(huì)變得很自然。這一點(diǎn)在很多優(yōu)秀的數(shù)據(jù)庫(kù)軟件里面應(yīng)用的很多，例如 Oracle，理論上可以依賴 SQL 來(lái)對(duì)軟件本身做所有操作，因?yàn)橛脩糁灰谑褂?Oracle 就默認(rèn)應(yīng)該是知道關(guān)系模型和 SQL。

說(shuō)了正面的例子，我們聊個(gè)反例：大家知道 TiDB 主項(xiàng)目(不包括其他工具，例如 cdc、binlog)至少有 3 個(gè) Controller 工具：tidb-ctl /tikv-ctl / pd-ctl，雖然 TiDB 確實(shí)是一個(gè)由多個(gè)組件組成的分布式系統(tǒng)，但是對(duì)于用戶來(lái)說(shuō)，多數(shù)時(shí)候使用對(duì)象其實(shí)是 TiDB 作為一個(gè)整體(數(shù)據(jù)庫(kù)軟件)，但幾個(gè) ctl 的使用方式都不太一樣，比如說(shuō) pd-ctl 是一個(gè)可交互式的控制器，而且影響的范圍大概是 pd 本身和 tikv，tikv-ctl 的功能上也有一些交集，但是只是針對(duì)單個(gè) tikv 實(shí)例使用，這點(diǎn)太令人費(fèi)解了，tikv 明明是一個(gè)分布式系統(tǒng)，但是 tikv-ctl 卻是一個(gè)針對(duì)單點(diǎn)的控制器?那么控制 tikv 到底應(yīng)該用的哪個(gè) ctl 呢?答案：多數(shù)時(shí)候用 pd-ctl(驚不驚喜，意不意外?)。

就像你有一個(gè)電視機(jī)，但是需要用三個(gè)遙控器來(lái)控制，而且真正控制電視的那個(gè)遙控器叫做：機(jī)頂盒，這種問(wèn)題在日常生活中大家都認(rèn)為是一個(gè)理所應(yīng)當(dāng)?shù)脑O(shè)計(jì)問(wèn)題，但是在基礎(chǔ)軟件領(lǐng)域大家的容忍度怎么似乎突然就變高了?

12、No Surprise: 不怕麻煩，就怕驚喜（驚嚇）

我不知道是否是一個(gè)普遍現(xiàn)象，基礎(chǔ)軟件的用戶在面對(duì)錯(cuò)誤(尤其是因?yàn)閴慕换ピ斐傻?，通常會(huì)先自責(zé)和內(nèi)疚，認(rèn)為是自己的問(wèn)題，很少會(huì)歸因于軟件。尤其是當(dāng)能夠比較熟練的操作一些復(fù)雜又分裂的軟件的時(shí)候，很多人會(huì)覺(jué)得這是一種「技能」，畢竟沒(méi)有人愿意別人看著自己的笨拙操作。

這背后其實(shí)有著很深層次原因(Hacker Culture 里面多少有點(diǎn)崇尚復(fù)雜的傾向)，但是我想說(shuō)：這就是的軟件的問(wèn)題!就像我從不避諱說(shuō)我就不會(huì)用 gdb，不是因?yàn)槲抑巧滩恍卸且驗(yàn)檫@個(gè)東西真是太難用了。

但是我見(jiàn)過(guò)很多人真的是以熟練使用命令行 gdb 作為炫耀的資本，回到前面提到的那個(gè)反例，我在一個(gè) TiDB 的深度用戶那邊觀察他們的操作員做日常的運(yùn)維，這個(gè)操作員非常熟練的在各種 ctl 之間切換和操作，他不覺(jué)得有啥問(wèn)題，甚至覺(jué)得有點(diǎn)厲害，后來(lái)我想了下，人的適應(yīng)性還是很強(qiáng)的，真正讓人困擾的事其實(shí)并不是麻煩，而是當(dāng)你在對(duì)系統(tǒng)做出一個(gè)操作的時(shí)候，通常會(huì)帶著一個(gè)下意識(shí)的假設(shè)，例如一個(gè)功能的名字叫「xx開(kāi)關(guān)」的時(shí)候，用戶在打開(kāi)開(kāi)關(guān)的時(shí)候的預(yù)期應(yīng)該是有一個(gè)正反饋，但是如果結(jié)果并不是這樣的話，用戶會(huì)非常有挫敗感。這里有個(gè)真實(shí)的故事，我們?cè)?TiDB 5.0 里面引入了一個(gè)新功能，叫做 MPP (Massively Parallel Processing)，即大規(guī)模并行處理，我們有個(gè)開(kāi)關(guān)配置叫做：tidb_allow_mpp

不知道大家有沒(méi)有注意到問(wèn)題：作為一個(gè)開(kāi)關(guān)型的配置，當(dāng)設(shè)置成 OFF 的時(shí)候，是一個(gè) 100% 的負(fù)反饋，這沒(méi)有問(wèn)題，但是問(wèn)題在設(shè)置成 ON 的時(shí)候，這個(gè)功能是否啟用會(huì)依賴優(yōu)化器的判斷，也就是有一定概率 MPP 功能不會(huì)生效，這就像一個(gè)房間里有個(gè)控制燈的開(kāi)關(guān)，當(dāng)你關(guān)的時(shí)候，燈一定不會(huì)亮，當(dāng)你開(kāi)開(kāi)關(guān)的時(shí)候，燈不一定亮(燈覺(jué)得房間內(nèi)的光線足夠，沒(méi)必要亮...)，你一定不會(huì)覺(jué)得這個(gè)燈智能，你一定會(huì)覺(jué)得燈壞了。上面這個(gè)配置的一個(gè)更好的寫(xiě)法應(yīng)該是：

這個(gè)寫(xiě)法我都不用解釋，你也不用看文檔，是不是一眼就明白怎么用?好配置應(yīng)該是自解釋的。通常來(lái)說(shuō)，配置項(xiàng)是破壞用戶體驗(yàn)的重災(zāi)區(qū)，后邊講反饋的時(shí)候展開(kāi)講講。

UNIX 哲學(xué)里面有一條「安靜原則」，說(shuō)的是如果程序沒(méi)什么特別事情要表達(dá)，應(yīng)該保持安靜。具體的一個(gè)表現(xiàn)就是鼓勵(lì)命令行程序如果成功執(zhí)行，不需要輸出東西的話，就直接以 0 作為 return code 退出就好了，其實(shí)對(duì)于這一點(diǎn)我是持保留意見(jiàn)的，用戶的行為如果是符合預(yù)期的結(jié)果，應(yīng)該用一個(gè)明確的正向反饋?zhàn)鳛楠?jiǎng)勵(lì)(例如打印一個(gè) Success 都好)，不要忘了人性大師巴普洛夫。

13、反饋：暴露進(jìn)展，不要暴露內(nèi)部細(xì)節(jié)

剛才正好提到了反饋，我覺(jué)得將反饋稱為好體驗(yàn)中最重要的一環(huán)都不為過(guò)。學(xué)過(guò)控制論的朋友的都知道反饋是非常重要的概念，前面提到的 Self-Explanatory 之所以是個(gè)好體驗(yàn)就是因?yàn)榉答伒募皶r(shí)性。

但是我驚訝的是，很多基礎(chǔ)軟件在交互反饋部分設(shè)計(jì)得糟糕得令人發(fā)指，舉一個(gè)我熟悉的例子，某些數(shù)據(jù)庫(kù)軟件在接收到一個(gè)復(fù)雜查詢的時(shí)候，當(dāng)敲下回車，通常就 Hang 在那里了，可能確實(shí)數(shù)據(jù)庫(kù)程序在后邊辛苦的檢索和掃描數(shù)據(jù)，然后隔了幾分鐘直接返回一個(gè)結(jié)果(或者掛了)，過(guò)程中并沒(méi)有反饋掃描了多少數(shù)據(jù)和預(yù)期要掃描多少數(shù)據(jù)，其實(shí)這個(gè)體驗(yàn)是很差的，因?yàn)檫@個(gè)信息就是進(jìn)展(這點(diǎn)上 ClickHouse 做得很好)。反饋是需要精心設(shè)計(jì)的，我的幾個(gè)經(jīng)驗(yàn)是：

1. 反饋一定要即時(shí)，最好是敲完回車后 200ms 內(nèi)一定要有反饋(人的生理反應(yīng)時(shí)間，超過(guò)這個(gè)時(shí)間反饋人就會(huì)有卡頓感)，順滑的感覺(jué)是靠反饋創(chuàng)造的。

2. 反饋進(jìn)展，不要反饋細(xì)節(jié)，不要反饋需要上下文才能讀懂的細(xì)節(jié)(除非是 Debug Mode)，這里給出一個(gè)我們自己的反例：

這個(gè) Case 壞在哪里呢?很顯然，對(duì)用戶來(lái)說(shuō)，Region 是一個(gè) TiDB 內(nèi)部概念，一個(gè)很自然的問(wèn)題是：什么是 Region(我在前面埋了個(gè)伏筆，不知道你注意到?jīng)]有)?為什么 Select 數(shù)據(jù)和 Region 相關(guān)?為什么 Region is unavailable?我該怎么解決這個(gè)問(wèn)題?暴露給用戶這個(gè)信息是無(wú)用的，反而給用戶創(chuàng)造了噪音。這個(gè) Case 的原因是 TiKV 太忙，無(wú)法返回需要的數(shù)據(jù)，一個(gè)更好反饋應(yīng)該是：具體的哪臺(tái) TiKV 因?yàn)槟男?shù)據(jù)(用用戶能理解的形式，如：哪張表，哪些行)讀取不出來(lái)是因?yàn)?TiKV 太忙，最好還能告訴用戶為什么忙，怎么解決，實(shí)在解決不了至少貼個(gè) FAQ 的鏈接(我見(jiàn)過(guò)有軟件直接貼 StackOverflow 的 Search URL 的 LOL)。

3. 對(duì)正反饋設(shè)置一些 milestone，例如一個(gè)服務(wù)器程序開(kāi)始正常對(duì)外提供服務(wù)的時(shí)候，打印一個(gè) Ascii Art，不同日志級(jí)別用一些帶顏色 Label，這是給用戶一個(gè)明確信號(hào)，這點(diǎn) redis-server 做得很好。

通常對(duì)于可交互命令行程序的反饋還是容易設(shè)計(jì)的，一個(gè)非常麻煩的事情是，基礎(chǔ)軟件通常非常依賴配置文件，配置的問(wèn)題就是修改配置到確認(rèn)生效的反饋周期通常很長(zhǎng)，一個(gè)經(jīng)常的場(chǎng)景是：修改配置 - 重啟 - 觀察效果，而且通常配置是存儲(chǔ)在配置文件里面，這也造成修改文件操作的反饋感是極差的，因?yàn)橛脩粢膊恢赖降走@個(gè)操作有沒(méi)有生效，尤其是一些配置的生效并不是太明顯，一些比較好的實(shí)踐如：程序在啟動(dòng)的時(shí)候打印一下讀取了哪個(gè)配置文件以及這個(gè)配置文件的內(nèi)容是什么;設(shè)計(jì)一個(gè)類似 print-default-config 之類的命令行功能，直接輸出模板配置，省得用戶自己 Google。

另外對(duì)于分布式系統(tǒng)來(lái)說(shuō)，配置的問(wèn)題更加復(fù)雜，因?yàn)榇嬖诓⒉皇潜镜嘏渲煤腿峙渲玫膮^(qū)別，以及更新后的配置分發(fā)的問(wèn)題，包括滾動(dòng)重啟的問(wèn)題(重啟進(jìn)程才能讓配置生效本身就不是一個(gè)好設(shè)計(jì))，老實(shí)說(shuō)目前我還沒(méi)有特別好的方案，可能的思路是是使用類似 etcd 這樣的分布式全局配置中心或者(對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō))通過(guò)一些全局的配置表來(lái)實(shí)現(xiàn)。但是總體的原則是：集中比分散好;即時(shí)生效比重啟生效好;統(tǒng)一交互(修改和讀取配置的方式)比多種方式交互好。

14、寫(xiě)在最后

終于寫(xiě)得差不多了，但是這篇文章我覺(jué)得僅僅是拋磚引玉，一定還有很多好的實(shí)踐沒(méi)有總結(jié)出來(lái)，也希望有想法朋友找我一起探討，我揭曉一下最開(kāi)篇留下的一個(gè)懸念，為什么要在第一篇文章中將可觀測(cè)性和可交互性放在一起寫(xiě)，其實(shí)這個(gè)是來(lái)自經(jīng)典的認(rèn)知心理學(xué)中的人行動(dòng)的模型[3]：

當(dāng)用戶使用軟件時(shí)，需要面對(duì)的兩個(gè)鴻溝：一個(gè)是執(zhí)行的鴻溝，在這里，用戶要弄清楚如何操作，與軟件「對(duì)話」;另一個(gè)是評(píng)估的鴻溝，用戶要弄清楚操作的結(jié)果。我們作為設(shè)計(jì)師的使命就是幫助用戶消除這兩個(gè)鴻溝，正是對(duì)應(yīng)到文章中的可觀測(cè)性和可交互性。

設(shè)計(jì)出使用起來(lái)令人愉悅的軟件是一門(mén)藝術(shù)，也不見(jiàn)的比設(shè)計(jì)出一個(gè)精妙的算法或者健壯的程序簡(jiǎn)單，從某種意義上來(lái)說(shuō)更加難，因?yàn)檫@要求設(shè)計(jì)者真的要有對(duì)人和軟件兩者都有深入的理解以及傾注感情，最后送給大家一段來(lái)自 Steve Jobs 的話共勉：

The design is not just what it looks like and feels like. The design is howit works.

參考:

[1] 我眼中的分布式系統(tǒng)可觀測(cè)性, 黃東旭, 2020

[2] Overtaxed WorkingMemory Knocks the Brain Out of Sync | Quanta Magazine

[3] The Design of Everyday Things, Donald Norman, 1988