# 從將 Uber 擴展到 2000 名工程師，1000 個服務和 8000 個 Git 存儲庫獲得的經驗教訓 > 原文： [http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) <iframe allowfullscreen="" frameborder="0" height="200" src="https://www.youtube.com/embed/kb-m2fasdDY?start=57" width="425"></iframe> 為了讓 Uber 看到增長的景象，請看一下以上視頻的前幾秒鐘。 它將在正確的位置開始。 它來自[和 Uber 的首席系統架構師](https://www.linkedin.com/in/mranney) [Voxer](http://www.voxer.com/) 的聯合創始人 Matt Ranney 發表的精彩演講：[我希望在將 Uber 擴展到 1000 個服務之前知道些什么[](https://www.youtube.com/watch?v=kb-m2fasdDY) 幻燈片）。 它顯示了中國一些城市不斷增長的，有節奏的，波動的交通網絡。 世界各地的城市都在發生這種爆炸性增長的方式。 實際上，Uber 現在已遍布 400 個城市和 70 個國家/地區。 他們有 6000 多名員工，其中 2000 名是工程師。 僅僅一年半的時間，只有 200 名工程師。 這些工程師已經產生了 1000 多種微服務，這些微服務存儲在 8000 多個 git 存儲庫中。 在短時間內瘋狂增長 10 倍。 誰經歷過？ 不太多。 就像您可能期望的那樣，這種獨特的，壓縮的，快節奏的，高風險的經驗必須教會您一些新知識，比以前理解的要深刻。 馬特不是這個游戲的新手。 他是 Voxer 的共同創始人，Voxer 經歷了[的快速增長](http://www.marketwired.com/press-release/walkie-talkie-app-voxer-soars-past-billion-operations-per-day-powered-basho-riak-1603652.htm)，但這是不同的。 您可以在觀看視頻時告訴您 Matt 試圖對他們所取得的成就表示滿意。 馬特是一個有思想的人，這是有根據的。 在[最近的一次采訪](https://www.infoq.com/articles/podcast-matt-ranney)中，他說： > 在 QCon 和其他活動上進行的許多架構討論使我感到不足夠。 像其他人（例如 Google）一樣，一切都明白了，但我卻沒有。 馬特（Matt）在這次演講中走出了漩渦，試圖從某種意義上講出一種經驗，試圖弄清一切。 他成功了。 瘋狂地。 這部分是智慧的談話，部分是悔。 馬特說：“一路上犯了很多錯誤，而這些正是從中汲取教訓的。 演講的腳手架掛在 WIWIK（我希望我知道的）設備上，該設備已成為互聯網的模因。 這是他建議給自己幼稚的一年半的幼稚自我，盡管當然，像我們所有人一樣，他當然不會聽。 而且他不會孤單。 許多人批評 Uber（ [HackerNews](https://news.ycombinator.com/item?id=12597232) ， [Reddit](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) ）。 畢竟，這些數字實在是太瘋狂了。 兩千名工程師？ 八千個存儲庫？ 一千個服務？ 一定是很嚴重的錯誤，不是嗎？ 也許。 令人驚訝的是，馬特對整個事情沒有判斷力。 他的詢問方式更多是質疑和搜索，而不是尋找絕對值。 他本人似乎對存儲庫的數量感到困惑，但是他給出了更多存儲庫與較少存儲庫的優缺點，而沒有說哪個更好，因為鑒于 Uber 的情況：您如何定義更好？ 優步正在全球范圍內展開激烈的戰斗，以構建一個能夠占領贏家通吃的市場的行星尺度系統。 那就是商業模式。 成為最后一個服務站。 在這種情況下，更好的意思是什么？ 贏家通吃意味著您必須快速成長。 您可能會變慢并顯得更有條理，但如果變慢，就會迷失方向。 因此，您可以在混亂的邊緣保持平衡，并將您的腳趾或整個身體浸入混亂中，因為這將成為您擴展成為全球主導服務的方式。 這不是一條緩慢的增長之路。 這敲門，采取一切策略。 認為您可以做得更好？ 真？ 微服務非常適合 Uber 想要實現的目標。 塞住你的耳朵，但這是康威定律的事情，你會獲得如此多的服務，因為這是那么多人被雇用并提高生產力的唯一途徑。 如此多的服務沒有技術原因。 沒有這么多存儲庫的技術原因。 這一切都是關于人的。 [老婆婆](https://news.ycombinator.com/item?id=12598893)很好地總結了一下： > 擴展流量不是問題。 擴大團隊規模和產品功能發布率是主要因素。 演講的一個一致主題是*不錯，但是有一些折衷，通常是令人驚訝的折衷，而您實際上只能在規模上體驗*。 這引出了我從演講中得出的兩個最大構想： * **微服務是一種用 API 協調**代替人類交流的方式。 與人們談論和處理團隊政治相比，團隊更容易編寫新代碼。 它使我想起了我很久以前讀過的一本書，不記得這個名字了，人們居住在戴森球體內部，并且因為球體內部空間如此之大，自由能量如此之多，以至于當任何一個群體與另一個群體發生沖突時， 他們可能會分裂并適應新的領域。 這是否更好？ 我不知道，但這確實可以并行完成許多工作，同時又避免了很多人的開銷。 * **純胡蘿卜，不粘**。 關于命令和控制的作用如此廣泛，這是一個很深的觀點。 您會很想執行政策。 *例如，您應該以這種方式記錄*。 如果您不這樣做，將會有后果。 那是棍子。 馬特說不要那樣做。 改用胡蘿卜。 每當棍棒冒出來都是不好的。 因此沒有任何授權。 您想要處理它的方式是提供非常明顯且易于使用的工具，以至于人們不會以其他任何方式使用它。 這是您必須真正了解的那些談話之一，因為除了文本以外，還有很多其他方面的交流。 當然，我仍然鼓勵您閱讀我的演講的掩飾:-) ## 統計信息（2016 年 4 月） * 優步遍布全球 400 個城市。 * 70 個國家。 * 6000 多名員工 * 2000 名工程師（一年半前有 200 名工程師） * 1000 個服務（數量近似） * 不同服務的數量變化如此之快，以至于很難準確計算生產中的實際服務數量。 許多團隊正在建立很多東西。 甚至都不在乎實際的數字。 * 超過 8000 個 git 回購。 ## 微服務 * 很高興將您所有的整體分解成更小的東西。 甚至這個名字聽起來也很糟糕。 但是微服務有其不利的一面。 * 事情最有可能破裂的時間就是您進行更改的時間。 即使是在 Uber 最忙的時候，周末 Uber 在工程師不做更改的時候也是最可靠的。 * 每當您進行更改時，都有可能破壞它。 永遠不要接觸微服務是否有意義？ 也許。 * 好 * 值得質疑的是，為什么我們要在微服務上投入如此多的精力？ 這不是偶然的，有很多好的結果。 * 微服務允許團隊快速組建并獨立運行。 人們一直在被添加。 團隊需要迅速組建起來，并在可以推斷邊界的地方開展工作。 * 擁有自己的正常運行時間。 您運行您編寫的代碼。 所有服務團隊都在征求他們在生產中運行的服務。 * 使用最佳工具進行作業。 但是最好的方式是什么？ 最好寫？ 最好跑？ 最好，因為我知道嗎？ 最好，因為有圖書館？ 當您深入研究時，最好并不意味著什么。 * 明顯的成本 * 運行大型微服務部署的成本是多少？ * 現在，您正在運行分布式系統，這比使用整體系統更難。 * 一切都是 RPC。 您必須處理所有這些瘋狂的失敗模式。 * 如果中斷怎么辦？ 您如何排除故障？ 您如何確定中斷在服務鏈中的何處發生？ 如何確保合適的人得到傳呼？ 采取了正確的糾正措施來解決問題？ * 這些仍然都是顯而易見的成本。 * 不太明顯的費用 * 一切都是權衡，即使您沒有意識到自己正在做到。 作為所有這些微服務的交換，您可以獲得某些東西，但是您也放棄了一些東西。 * 通過對所有事物進行超級模塊化，我們引入了一些細微而不明顯的問題。 * 您可能選擇構建新服務，而不是修復已損壞的內容。 在某些時候，始終圍繞問題解決和清理舊問題的成本已成為一個因素。 * **您發現自己為政治**交易很復雜。 您不必編寫笨拙的對話，而充滿了人類的情感，而是可以編寫更多的軟件而避免說話。 * **您可以保持自己的偏見**。 如果您喜歡 Python 以及與您喜歡的節點打交道的團隊，則可以使用自己喜歡的語言來構建新的東西，而不必使用其他代碼庫。 即使對于組織或整個系統而言，這可能并不是最好的事情，但您仍要繼續做自己認為最好的事情。 ## 擁有多種語言的成本 * 史前史：最初，Uber 被 100％外包。 看來這似乎不是技術問題，所以一些公司編寫了移動應用程序的第一個版本和后端。 * 調度：內部進行開發時，它是用 Node.js 編寫的，現在正在遷移到 Go。 * 核心服務：系統的其余部分，最初是用 Python 編寫的，現在正在遷移到 Go。 * Maps 最終被引入內部，那些團隊正在使用 Python 和 Java。 * 數據工程團隊使用 Python 和 Java 編寫代碼。 * 內部度量系統用 Go 編寫。 * 您開始注意到有很多語言。 微服務使您可以使用多種語言。 * 團隊可以用不同的語言編寫并且仍然可以相互交流。 它可以工作，但是需要付費： * 難以共享代碼。 * 難以在團隊之間移動。 在一個平臺上積累的知識不會轉移到另一平臺上。 任何人當然都能學到，但是要付出一定的代價。 * **我希望知道的內容**：擁有多種語言會破壞文化。 通過在任何地方都接受微服務，您最終可以扎營。 有一個節點營，一個 Go 營，等等。人們在部落周圍組織自然是很自然的，但是要接受在各處都擁有多種語言的策略是有代價的。 ## RPC 的成本 * 團隊使用 RPC 相互通信。 * 大量的人很快就真正加入了 HTTP 的弱點。 像什么狀態代碼？ 標頭是做什么用的？ 查詢字符串中包含什么？ 這是 RESTful 嗎？ 這是什么方法 * 所有這些事情在執行瀏覽器編程時看上去確實很酷，但是在進行服務器編程時卻變得非常復雜。 * 您真正想說的是在那里運行此功能，并告訴我發生了什么。 相反，使用 HTTP / REST 會遇到所有這些細微的解釋問題，而這一切都非常昂貴。 * JSON 很棒，您可以用眼球看一下并閱讀它，但是如果沒有類型，這是一團糟，但不是馬上，問題隨后就會出現。 當某人更改某些內容并在下游跳了幾跳時，他們依賴于對空字符串與 null 的某種微妙解釋，或者某種語言對另一種語言的某種類型的強制轉換，這會導致巨大的混亂，需要花費很長的時間才能解決。 接口上的類型將解決所有這些問題。 * RPC 比過程調用慢。 * **我希望知道的內容**：服務器不是瀏覽器。 * 當在數據中心中進行交談時，將所有內容都視為函數調用而不是 Web 請求，這更加有意義。 當您控制對話的雙方時，您并不需要所有多余的瀏覽器內容。 ## 儲存庫 * 最好的回購數量是多少？ 他認為最好的是一個，但許多人不同意。 * 許多人認為很多回購是最好的。 每個項目可能一個，甚至每個項目多個。 * 具有許多存儲庫是遵循具有許多小型模塊的行業趨勢。 小型模塊易于開源或交換。 * 一個倉庫很不錯，因為您可以進行跨領域更改。 您想要進行更改，可以輕松找到所有需要更改的代碼。 瀏覽代碼也很容易。 * 有很多不好的地方，因為這會給您的構建系統帶來壓力。 這會損害您瀏覽代碼的能力。 確保正確完成跨領域更改很痛苦。 * 一個不好的原因是，它將變得如此之大，除非您在頂部擁有一些瘋狂的精心設計的系統，否則您將無法構建或檢驗您的軟件。 如果沒有特殊工具，一個倉庫可能無法使用。 Google 有一個存儲庫，但它使用虛擬文件系統，好像您已檢出整個存儲庫。 * 超過 8000 個 git 回購。 一個月前有 7000。 * 有些人有自己的倉庫。 * 一些團隊使用單獨的存儲庫與服務本身分開跟蹤服務配置。 * 但是大多數是生產倉庫。 * 很多回購。 ## 操作問題 * 事情破裂了怎么辦？ 大型微服務部署會帶來一些令人驚訝的問題。 * 如果其他團隊無法使用您的服務，而該服務尚未準備好發布，那么其他團隊是否可以在您的服務中添加修復程序并將其發布？ * 即使您的所有測試都通過了，您擁有的正常運行時間也可以與其他發布您服務的團隊兼容嗎？ 自動化是否足夠好，團隊可以相互發布軟件？ * 在 Uber，這取決于情況。 有時是的，但通常答案是“否”，團隊將只需要阻止此修復程序。 * 大而小的團隊，每個人都在快速前進，所有功能都超級快地發布，但是有時您必須將整個系統理解為一臺大型機器連接在一起的一件事。 當您花費所有時間將其分解為微服務時，這很難。 * 這是一個棘手的問題。 希望將更多的時間花在保持上下文關聯上。 * 應該仍然能夠理解整個系統的整體功能。 ## 性能問題 * 鑒于微服務之間的相互依賴程度，性能肯定會提高。 * RPC 昂貴，尤其是當存在多種語言時，如何理解性能的答案完全取決于語言工具，并且工具都是不同的。 * 您已經讓每個人都以自己的語言進行編程，現在了解這些語言的性能是一個真正的挑戰。 * 嘗試使用 [火焰圖](http://www.brendangregg.com/flamegraphs.html) 使所有語言具有通用的分析格式。 * 當您想了解系統的性能時，嘗試解決性能問題時，一個很大的摩擦就是工具的差異。 * 每個人都想要一個儀表盤，但是如果沒有自動生成儀表盤，團隊將只把他們認為重要的東西放在儀表盤上，因此當您想追逐一個團隊的儀表盤時，問題看上去將與另一個團隊完全不同。 * 每個服務在創建時都應該具有一個標準的儀表板，其中包含相同的有用數據集。 應該能夠創建一個完全沒有工作的儀表板。 然后，您可以瀏覽其他團隊的服務，并且看起來都一樣。 * **我希望知道的內容**：不需要良好的表現，但您需要知道自己的立場。 * 一個大爭論是，您是否應該關心性能。 “過早的優化是萬惡之源”的類型思維催生了反對優化的人們非常奇怪的亞文化。 沒關系，服務并不那么忙。 我們應該始終針對顯影劑速度進行優化。 購買計算機比雇用工程師便宜。 * 對此有一定道理。 工程師非常昂貴。 * 問題在于，性能要緊要緊。 有一天，您將遇到績效問題，如果已建立起一種無關緊要的文化，那么突然之間變得至關重要很困難。 * 您想根據創建的所有內容獲得某種性能的 SLA，以便有一個數字。 ## 扇出問題-跟蹤 * 扇出會導致很多性能問題。 * 想象一個典型的服務，即 99％的時間在 1 毫秒內做出響應。 它在一秒鐘內響應的時間為 1％。 還算不錯。 用戶有 1％的時間會遇到這種情況。 * 現在，我們假設服務開始大張旗鼓，推出了許多其他服務。 響應時間變慢的機會迅速增加。 至少在 1 秒鐘內使用 100 個服務和 63％的響應時間（1.0-.99 ^ 100 = 63.4％）。 * 分發跟蹤是您跟蹤扇出問題的方式。 如果無法理解整個體系結構中的請求，將很難跟蹤扇出問題。 * Uber 正在使用 [OpenTracing](https://github.com/opentracing) 和 [Zipkin](https://github.com/openzipkin/zipkin) 。 * 另一種方法是使用日志。 每個日志條目都有一個公共 ID，該 ID 將所有服務組合在一起。 * 給出了一個棘手的例子。 頂層對所有相同服務均具有大量扇出。 當您查看服務時，它看起來不錯。 每個請求都是快速且一致的。 問題是頂級服務獲得了 ID 列表，并正在為每個 ID 調用服務。 即使同時進行，也將花費太長時間。 只需使用批處理命令即可。 如果不進行跟蹤，很難找到這個問題。 * 另一個示例是進行了數千次服務調用的服務。 盡管每個呼叫都很快，但大量呼叫卻使服務變慢。 事實證明，遍歷列表并更改屬性后，它神奇地變成了數據庫請求。 但是數據庫團隊說，由于每個操作都很快，所以數據庫運行良好，但是他們會想知道為什么會有這么多操作。 * 跟蹤的開銷可以更改結果。 跟蹤是很多工作。 一種選擇是不跟蹤所有請求。 跟蹤請求的統計顯著部分。 Uber 跟蹤約 1％的請求。 * **我希望知道的內容**：跟蹤需要跨語言上下文傳播。 * 因為所有這些不同的語言都在所有這些不同的框架中使用，所以獲取請求的上下文（例如請求的用戶是誰），是否經過身份驗證，所處的地理位置是什么，如果無處可放，則會變得非常復雜 將會傳播的上下文。 * 服務提出的任何依賴請求都必須傳播上下文，即使他們可能不理解上下文也是如此。 如果很久以前添加此功能，它將節省大量時間。 ## 正在記錄 * 擁有一堆不同的語言，一群團隊和許多新人，一半的工程團隊已經存在了不到 6 個月，每個人可能都傾向于以完全不同的方式登錄。 * 任務授權是一個棘手的單詞，但這是您真正想要做的，需要一種通用的日志記錄方法。 更為可接受的說法是，它提供的工具顯而易見且易于使用，人們不會以任何其他方式來獲得一致且結構化的日志記錄。 * 多種語言使得難以記錄。 * 如果存在問題，日志記錄本身可能會使日志記錄過多而使這些問題更加嚴重。 日志中需要背壓以在過載時刪除日志條目。 希望早些時候已放入系統中。 * **我希望知道的內容**：關于日志消息大小的一些概念，以便可以跟蹤誰產生了過多的日志數據。 * 所有日志發生的事情是通過某種工具將它們編入索引，以便人們可以搜索它們并學習事物。 * 如果免費記錄，則記錄的數據量是可變的。 有些人會記錄很多數據，使系統不堪重負。 * 對于計費系統，當將日志數據發送到群集以建立索引時，可以將帳單發送到服務以進行支付。 * 的想法是給開??發人員以更大的壓力，使他們更聰明地記錄日志，而不是更難。 * Uber 創建了 [uber-go / zap](https://github.com/uber-go/zap) 用于結構化日志記錄。 ## 負載測試 * 想要在將服務投入生產之前進行負載測試，但是無法構建與生產環境一樣大的測試環境。 * 這也是生成實際測試數據以測試系統所有部分的問題。 * 解決方案：在非高峰時段對生產進行測試。 * 引起很多問題。 * 它炸毀所有指標。 * 您不希望人們認為負載多于實際負載。 為了解決該問題，它又回到了上下文傳播問題。 * 確保所有測試流量請求都具有表示此測試請求的上下文，因此以不同的方式處理指標。 這必須貫穿整個系統。 * **我希望知道的是**：我們真正想要做的是始終在所有服務中運行負載，因為許多錯誤僅在流量達到峰值時才會出現。 * 希望將系統保持在峰值附近，并隨著實際流量的增加而退縮。 * 希望該系統很早以前就已建立，可以處理測試流量并以不同的方式處理它。 ## 故障測試 * **我希望知道的內容**：并非每個人都喜歡 Chaos Monkey 等失敗測試，??尤其是如果您稍后要添加它時。 * 如果您不喜歡，我們應該做的是對您進行故障測試。 這只是生產的一部分。 您的服務只需要承受隨機的殺戮，運行減慢和干擾。 ## 遷移 * 我們所有的東西都是遺產。 全部都是遷移。 通常，從事存儲工作的人們正在做的事情是從一個舊版遷移到另一個舊版。 * 有人總是在某處遷移某物。 不管人們在會議上怎么說，這就是每個人都在做的事情。 * 舊的東西必須保持工作狀態。 業務仍然必須運行。 不再有維護窗口之類的東西。 可接受的停機時間。 * 隨著您成為一家全球企業，沒有高峰時間。 總是高峰時間在某個地方。 * **我希望知道的內容**：遷移的要求很糟糕。 * 沒有人希望被告知必須采用某種新系統。 * 使某人發生變更是因為組織需要進行變更，而不是提供一個更好的新系統，因此顯然您需要接受這一新事物。 * 純胡蘿卜，不粘。 無論何時出現問題，除非與安全性或合規性有關，否則這是不好的，強迫人們做事可能是可以的。 ## 開源 * 沒有人同意建立/購買權衡。 你什么時候建造？ 你什么時候應該買？ * 屬于基礎架構的任何東西，看起來像是平臺的一部分而不是產品的一部分的任何事物，在某個時候都將成為無差異的商品。 亞馬遜（或某人）將提供它作為服務。 * 最終，您花了所有時間在做這件事，其他人會以更便宜和更好的方式來做。 * **我希望知道的內容**：如果人們正在使用某種平臺類型的功能，那么聽到亞馬遜剛剛發布您的服務即服務聽起來并不好。 * 您仍在嘗試合理化為什么應將自己的私人物品用作服務。 * 事實證明，那些人在這些文本編輯器的另一端。 人們對構建/購買權衡的判斷方式存在巨大差異。 ## 政治 * 通過將所有內容分解為小型服務，可以使人們玩政治。 * 每當您做出違反此屬性的決定時，就會發生政治事件：公司>團隊>自我。 * 您將自己的價值觀置于團隊之上。 * 團隊的價值高于公司。 * 政治不只是您不喜歡的決定。 * 通過擁抱高度模塊化的快速發展，非常快地雇用人員并盡快發布功能，人們開始傾向于違反此屬性。 * 當您重視以較小的個人成就來交付產品時，很難確定對公司更有利的優先事項。 令人驚訝的權衡。 ## 權衡取舍 * 一切都是權衡。 * **我希望知道的內容**：如何更好地有意進行這些折衷。 * 當事情在沒有明確決定的情況下發生時，因為這似乎是事情的發展方向，即使沒有明確做出決定，也要考慮做出什么權衡。 ## 相關文章 * [關于 HackerNews](https://news.ycombinator.com/item?id=12697006) * 關于在 HackerNews 和 [上的視頻](https://www.reddit.com/r/programming/comments/54y5by/what_i_wish_i_had_known_before_scaling_uber_to/) [的精彩討論，關于[Reddit]](https://news.ycombinator.com/item?id=12597232) * [擴展流量高的 Feed 的設計決策](http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html) * [Google 延遲容忍系統：將不可預測的部分做成可預測的整體](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) * [Uber 如何擴展其實時市場平臺](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html) * [Uber 變得與眾不同：使用駕駛員電話作為備份數據中心](http://highscalability.com/blog/2015/9/21/uber-goes-unconventional-using-driver-phones-as-a-backup-dat.html) * [Uber 如何使用 Mesos 和 Cassandra 跨多個數據中心每秒管理百萬個寫入](http://highscalability.com/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html) * [用 Matt Ranney 縮放 Uber](http://softwareengineeringdaily.com/2015/12/04/engineering-at-uber-with-matt-ranney/) * [InfoQ 播客：Uber 的首席系統架構師，介紹其架構和快速發展](https://www.infoq.com/articles/podcast-matt-ranney) * [分布式 Web 架構：Matt Ranney，Voxer](https://gaming.youtube.com/watch?v=pXT0mF9bMyA) * [Riak at Voxer-Matt Ranney，RICON2012](https://vimeo.com/52827773) 優步遍布 400 多個城市。 因此，請在帖子中更正此問題。 謝謝 這是我一生中讀過的最好的經驗教訓文章之一。 這是一項毫不廢話，誠實和實踐的知識共享活動。 許多公司正在努力適應不斷變化的新技術，例如微服務，CI / CD，Paas，Saas 和帶有 Docker 的 Cass。 正如他在視頻中正確指出的那樣，這始終是一種思維方式/文化挑戰，每個人對編程語言，方法等都有自己的看法。認識到這一事實并引導每個人完成業務需求的共同目標很重要。 難以置信！ 從頭到尾純粹基于經驗的演講 很棒的文章，有非常有用的信息。 完全基于經驗非常坦率非常實用。 他吸取的教訓是休息的智慧。