# 從將 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)（[[幻燈片](https://gotocon.com/chicago-2016/presentation/What%20I%20Wish%20I%20Had%20Known%20Before%20Scaling%20Uber%20to%201000%20Services)）。 它顯示了中國一些城市不斷增長的，有節奏的，波動的交通網絡。 世界各地的城市都在發生這種爆炸性增長的方式。 實際上，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) 用于結構化日志記錄。 ## 負載測試 * 想要在將服務投入生產之前進行負載測試，但是無法構建與生產環境一樣大的測試環境。 * 這也是生成實際測試數據以測試系統所有部分的問題。 * 解決方案：在非高峰時段對生產進行測試。 * 引起很多問題。 * 它炸毀所有指標。 * 您不希望人們認為負載多于實際負載。 為了解決該問題，它又回到了上下文傳播問題。 * 確保所有測試流量請求都具有表示此測試請求的上下文，因此請以不同的方式處理指標。 這必須貫穿整個系統。 * **我希望知道的內容**：我們真正想要做的是始終在所有服務中運行負載，因為許多錯誤僅在流量達到峰值時才會出現。 * 希望將系統保持在峰值附近，并隨著實際流量的增加而退縮。 * 希望該系統很早以前就已建立，可以處理測試流量并以不同的方式處理它。 ## 故障測試 * **我希望知道的內容**：并非每個人都喜歡混沌猴子那樣的失敗測試，??尤其是如果您稍后要添加它時。 * 如果您不喜歡，我們應該做的是對您進行故障測試。 這只是生產的一部分。 您的服務僅需承受隨機的殺戮，操作的減慢和干擾。 ## 遷移 * 我們所有的東西都是遺產。 全部都是遷移。 通常，從事存儲工作的人們正在做的事情就是從一個舊版遷移到另一個舊版。 * 有人總是在某處遷移某物。 不管人們在會議上怎么說，這就是每個人都在做的事情。 * 舊的東西必須保持工作狀態。 業務仍然必須運行。 不再有維護窗口之類的東西。 可接受的停機時間。 * 隨著您成為一家全球企業，沒有高峰時間。 總是高峰時間在某個地方。 * **我希望知道的內容**：遷移的要求很糟糕。 * 沒有人希望被告知必須采用某種新系統。 * 使某人發生變化是因為組織需要進行變化，而不是提供一個更好的新系統，因此顯然您需要接受這一新事物。 * 純胡蘿卜，不粘。 無論何時出現問題，除非與安全性或合規性有關，否則這是不好的，強迫人們做事可能是可以的。 ## 開源 * 沒有人同意建立/購買權衡。 你什么時候建造？ 你什么時候應該買？ * 屬于基礎架構的任何東西，看起來像是平臺的一部分而不是產品的一部分的任何東西，在某個時候都將成為無差別的商品。 亞馬遜（或某人）將提供它作為服務。 * 最終，您花了所有時間在做這件事，其他人會以更便宜和更好的方式來做。 * **我希望知道的內容**：如果人們正在使用某種平臺類型的功能，那么聽到亞馬遜剛剛發布您的服務即服務聽起來并不好。 * 您仍在嘗試合理化為什么應將自己的私人物品用作服務。 * 事實證明，那些人在這些文本編輯器的另一端。 人們對構建/購買權衡的判斷方式存在巨大差異。 ## 政治 * 通過將所有內容分解為小型服務，可以使人們玩政治。 * 每當您做出違反此屬性的決定時，就會發生政治事件：公司>團隊>自我。 * 您將自己的價值觀置于團隊之上。 * 團隊的價值高于公司。 * 政治不只是您不喜歡的決定。 * 通過擁抱高度模塊化的快速發展，非常快地雇用人員并盡快發布功能，人們開始傾向于違反此屬性。 * 當您重視以較小的個人成就來交付產品時，很難確定對公司有利的優先事項。 令人驚訝的權衡。 ## 權衡取舍 * 一切都是權衡。 * **我希望知道的內容**：如何更好地有意進行這些折衷。 * 當事情在沒有明確決定的情況下發生時，因為這似乎是事情的發展方向，即使沒有明確做出決定，也要考慮做出什么權衡。 ## 相關文章 * [關于 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 On Latency Tolerant Systems：由不可預測的部分組成可預測的整體](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 多個城市。 因此，請在帖子中更正此問題。 謝謝 這是我一生中讀過的最好的經驗教訓文章之一。 這是一項毫不廢話，誠實和實踐的知識共享活動。 許多公司正在努力適應不斷變化的新技術，例如帶有 Docker 的微服務，CI / CD，Paas，Saas 和 Cass。 正如他在視頻中正確指出的那樣，這始終是一種思維定勢/文化的挑戰，每個人對編程語言，方法等都有自己的看法。認識到這一事實并引導每個人實現業務需求的共同目標很重要。 難以置信！ 從頭到尾純粹基于經驗的演講 很棒的文章，有非常有用的信息。 完全基于經驗非常坦率非常實用。 他吸取的教訓是休息的智慧。