[[213651]]

大家好，非常榮幸能夠有機會和大家一起分享，我叫陳斌。The Art of Scalability 的作者 Martin Abbott，是我在 eBay 工作時認識的。去年，我將這本書翻譯成了中文，名叫《架構即未來》。

我在 1993 年出國去到新加坡，擔任新加坡航空公司的高級系統分析員。之后到硅谷，在硅谷參加了各種創業的活動，在不少公司做過技術工作。

2001 年，我在日立美國擔任系統集成總監。隨后在 Abacus 擔任***架構師。2008 年，我在 eBay 和 PayPal 從事高級架構工作。在這段時間里，我有幸參與了 eBay 在架構方面的很多實踐，也就是這本書—— The Art of Scalability 中講的很多故事。

這本書是由兩位作者完成的，一位是 Martin，另一位是 Michael。

他們寫的***本書 The Art of Scalability，我翻譯后取名為《架構即未來》，第二本書在今年四月份出版的，書名為 Scalability Rules，中文譯名為《架構真經》。

這兩本書分別從互聯網管理實踐，架構和技術方面，做了很多非常好的總結。這本書非常出名，可能有的同學已經了解了部分內容，下面我將會和大家分享。

CTO 必備的管理能力：人員、組織、過程 

首先，我想從管理的角度和大家分享，主要涉及人員、組織和過程三個方面。

這三個方面在《架構即未來》書中，基本通過兩個循環作講解，分別是向上的正向循環和向下的負面循環。

所謂良性的循環（向上的循環），是指合適的人員在合適的組織方式的組織下，通過合適的流程所規定的活動，使項目和系統不斷地優化，不斷地向前發展。

向下的過程是指與此相反，過程不合理架構不合適。當處在這些不合適的情況下，各種活動及項目就會出現完成后成員互相埋怨對方沒有做好，導致越做越差的負面效果，而這種效應就會疊加。

所以我們希望我們的組織和團隊都有正向的良性的循環，不斷地從一個成功走向另一個成功，越做越輕松，越做越簡單。這就是人員組織過程主要講的內容的邏輯。

人員

這里要和大家分享的是書中提到的：領導力和管理能力的問題。

這也是我回到中國之后發現的，不僅僅互聯網而是很多企業都存在的共性問題：大家不區分領導力和管理能力。

領導能力是指如何帶動一個企業不斷地向前走，靠的是***個人的魅力，***對理念目標和使命的引導，去激勵大家。而管理能力是指把一個大的目標分解成小的目標，小的目標進一步分解，讓員工高效率地實現。

領導能力和管理能力的主要區別在于力量的方向。領導力是像火車頭一樣牽引團隊的動力。管理力是在團隊后面推動的力量，讓團隊向前走。

兩者所需要的技能是不一樣的。領導力需要以身作則，有自知之明，或很謙虛，使命為先。更多的是一種天賦，領導精神和犧牲精神。

而管理的能力呢，更多的是關注細節分解任務，要善于溝通，善解人意，能夠有很強的執行力。這是兩者的不同點。

本書還強調了企業及企業文化。他用一個花園來比喻企業，花園里的土壤就像企業的文化。我們談起企業文化，總認為只有中國才講究的話，其實到了美國更加講究企業文化。

良好的企業文化，就像花園土壤的土質很好，可以長出很多好的花花草草。那這些花草就是企業的員工。

當然有很漂亮的花也會有奇葩。奇葩或者不合適的草，即不合適的員工。而管理者就是企業這座花園里的園丁。園丁的責任：施肥除草，淘汰不合適的花草，進行選材。

我從硅谷剛回來的時候，很多人問我：能不能幫忙介紹一個硅谷的大牛，我們公司上市就差這么一位大牛了，或者是有了這位大牛，公司才能如何如何……

我們認為人員是組織過程中的首要元素，但人員沒有***，只有最合適。

我經常用 Steve Jobs 的例子來說明這個問題：Steve Jobs 在三十歲的時候呢，是一個很自負，孩子氣的一個人，不負責任，缺乏團隊精神，很多項目朝令夕改。

結果，員工和企業不歡迎他，被迫離開了蘋果。而當他四十一歲重返蘋果的時候，他變得很負責，很自律，不僅保持了自己的創新精神，還加強了產品的經驗。

那么同樣一個 Steve Jobs，為什么在十年前被企業掃地出門，十年后成為天才，帶領蘋果騰飛，使蘋果有了今天的成就？

原因就在于十年前他不是一個合適的人，并不是說他不是一個牛人，不能打造***的產品。但是十年后，經過歷練，他變得更適合團隊，也更適合環境，所以才會有他和蘋果當年的成功。

關于人員，要和大家分享的是，如何像園丁一樣對花園里的花花草草進行區別考評，優勝劣汰。這就是這本書里特別講到的 BP 模型。B 指 behavior，指員工是否符合企業文化，P 指 Performance，指員工是否具有能力創造業績。

那么公司管理者最喜歡的是既符合企業文化又有能力的人，即處于***象限，要保留的精英。相反，如果是對企業文化不認同，技術的能力又差的員工，就是需要淘汰的人。

而第二象限代表的員工，是管理者需要培養的員工。這類員工有專業的能力，是不同領域內的專才，但是企業文化方面比較差，這樣的員工可以通過培養讓他成為精英。

關于人員，還有一件事要和大家分享：如何使我們的人員能夠在一個企業里留得住，發展好。我從美國回到易寶支付之后有一點感觸非常深刻，就是這么多人，卻連一個架構師都沒有。

一個總監領著大家做，可能會有一些初級研發啊、中級研發、高級研發，但是沒有架構師，大家做的事都是一樣的。

***我們做了一些改變，我們有研發架構、測試架構、網絡架構、安全架構、配置架構、系統架構和數據架構。

那這些架構師是怎么培養呢？首先，工作經驗很關鍵，因為架構師需要一定的經驗積累。我們認為七年以上的工作經驗足以勝任一個架構師，從而給員工成長的空間。

組織

《架構即未來》這本書里還提到了一個非常有價值的概念，也是我觀察到的，硅谷的企業和國內的企業之間的一個差別：即在業務和技術之間溝通上的問題。特別是主管一級人員溝通的問題。

比如說業務主管會強調要完成什么業績；而技術主管在討論的時候經常強調有什么問題，什么技術細節，什么 Bug，什么無法解決的問題，這兩者很難溝通到一起。

原因是很清楚的：因為業務主管和技術主管在教育背景、經驗背景和性格特質上差別很大。一個內向，一個外向；一個是學理工的，一個是學經濟和管理的。

特別是他們成長的路徑，業務主管往往是業績做得好，技術主管往往是項目做得好研發做得好。

組織內的沖突，是我們探討人員的時候必須要強調的。

組織內的沖突：一種是認知型沖突，一種是感情型沖突。當我們在做一個項目的時候經常有疑問：誰來干這件事？這就是一種感情型沖突。

人作為一種高級動物，我們都會有保護自己的本能，而這樣的情況往往在我們做項目的過程中是存在一定破壞性的。

作為一個架構師，應該及時發現這種沖突，制止這種沖突。我們在項目進行的過程中需要沖突，但不是感情型沖突，而是認知型沖突。

那什么是認知型沖突？認知型沖突是指在決定要做某個項目，對執行方案有不同意見時，我們要從中選出一種***方案。

所以當一個團隊在討論什么是***方案的時候，***的組織方式是討論時，參與人員有年齡差異，也有崗位和職能差異，能從各個不同的角度對方案提供不同的意見。

我們再從中選取一個***的方案，這是保證項目或研發走向成功的基礎。只有當選擇的方案和策略是對的時，結果才有可能是正確的。

還有一件讓我印象深刻的事：在我們的互聯網企業，特別是國有企業或者是大型的傳統型企業中，常常分成兩種思維模式：

• IT 思維模式。
• 產品思維模式。

所謂 IT 模式，指的是 IT 部門往往服務的是企業內部客戶。比如說公司的 IT 部門，其提供的服務可能是 CRM 系統或某種業務系統。

那么在工作過程中，這個部門主要考慮的是成本，因為 IT 部門的成本是直接計入公司成本，需要盡量節省成本。

還有一個要考慮的因素，是公司內部的客戶的滿意度。在這種情況下，產品做出來后，如果內部客戶反饋不好，常常是采取企業內培訓的方式，培訓到用戶會用為止，可能產品很差，但是培訓跟得上，這就是 IT 思維。

而產品思維，特別是互聯網產品思維呢，他不知道他的用戶是誰，在哪里，或僅知道用戶某種類型，但不具體。

那么這個時候就會采取試錯的辦法，做出一個產品后投放到市場上，根據市場反饋，作相應的修改。而關于成本，產品人員更多考慮的是產品能賺回多少錢，而不是花掉多少。

我們再來探討組織，人員都是要靠組織組成起來的，那什么樣的組織最合理？

《架構即未來》書中講了一個兩張披薩的故事。亞馬遜 CEO Bezos 曾提到，溝通是很可怕的事情。他要求亞馬遜的團隊規模不能超過兩張比薩餅能喂飽的人數。兩個披薩能喂飽多少人呢？

我們簡單計算一下：八寸的這種披薩大概兩張能喂飽八個人左右。所以團隊的規模不能太大，過大的團隊會造成噪音的存在。規模***是七到八個人，其中有主管、架構、項目管理、研發和測試。

說完了組織規模，還要考慮組織的結構。大家都知道我們現代社會的工業或企業的組織結構是按照軍隊的線性結構設計的：騎兵在一起，步兵在一起，通訊兵在一起，炮兵在一起。各兵種之間有縱向的領導和橫向的合作關系。

隨著工業發展，當我們提供軟件服務，這就需要研發人員、測試人員、運維人員、項目管理人員和產品人員，大家天天在一起去討論問題、解決問題。當項目結束，軟件研發成功后，團隊解散。這就是矩陣型結構，非常適合軟件行開發企業。

第三種情況，是指將所有項目人員放在一個團隊里，即敏捷型組織。這種敏捷型組織呢，所有的人在一個團隊，溝通更順暢，更容易形成合力解決問題。

這種方式最適合 SAS 服務，即對外提供的是軟件為基礎的服務。我們可以根據自己企業所處的不同階段，所提供的不同產品和服務，選擇合適的組織機構。

過程

除了人員和把人員合理地組織起來工作以外，還有一個重要的事情是過程。過程是指將所有人組織起來的活動中，大家按什么邏輯和方向來走。

很多公司，包括易寶支付，我都發現這樣的問題：一個公司，特別是運維系統發生一些問題，管理人員會怎么辦？

大家往往會追究是誰的責任，然后處理責任人，如扣獎金、記過處分、甚至開除。往往把處理人作為主要的目標和主要的手段。

這里有張伯克利一位教授的圖，借用他的圖，我們來說明上面這個問題：一個系統由軟件硬件測試、腳本、網絡等很多要素構成，圖中每個紅點代表的是軟件中的 fault 或 Bug。

平常的它們相安無事，當外界用戶的輸入進入，如某種輸入情況、某種流量或某種 profile，可能會引發這些 fault 或 Bug 出現問題。

如果你的系統有合理的監控，能觀察到這些蛛絲馬跡，系統就可以避免出現大的問題。相反如果觀察不到，系統就會失去目標從而出現大的問題。

所以，當我們在考慮過程中所出現的問題時，我們應該聚焦在系統，也就是軟件硬件網絡當中的 fault 上。一定要在每件事情發生之后聚焦為什么會發生這種問題，其根源在哪里，而不是聚焦在人上。

當我們把這些紅點，fault 都解決掉，那么系統就不會在同一個地方栽兩次跟頭。這就是我們強調的，要聚焦優化過程和優化架構，而不是聚焦人。

除了優化架構、優化過程以外呢，《架構即未來》書中還多次強調了 CMMI。CMMI 是由美國某大學同國防部在承包項目過程中制定的一種流程管控的辦法。

這種辦法認為，無法度量的流程是差的流程，而好的流程不僅可度量，還能很細致的度量，***的情況則是流程擁有一個成熟度模型，能夠分級評估。

即使企業不提供外包服務，我們也需要優化流程：有合適的人員、合適的組織方式、合適的流程、合適的決策使項目不斷地從一個成功走向另一個成功。這部分就是我跟大家分享的《架構即未來》書中提到的關于管理的內容。

架構設計理念

關于架構設計的理念，其中提到的時間，均在《架構即未來》和《架構真經》中有提及，讓大家了解架構師如何做設計。

今天要講的理念是：非技術設計。所謂非技術設計是指在設計互聯網或信息系統架構的時候，要像建筑師一樣去考慮問題：設計一座房子時，我們要考慮房子的結構，承重強度等。

當我們在做架構設計時往往考慮的是：前端用 Java 語言、Tomcat，然后通過 MySQL 放在某某服務器上、某某存儲上，然后由某某路由器來負責完成。

如果不知道的人看到這種設計一定會說架構師是收了人家錢在打廣告吧。實際上，真正的架構設計是不應該考慮任何產品的，而是為了滿足用戶的需求，選取最合適的手段和方式來完成。

架構設計要回歸事情的本源，這里講一個故事：當年美國和蘇聯太空競賽，雙方遇到在太空無重力狀態下無法寫字的問題。美國的做法是花巨資研發一種新的太空筆，當這種筆研發出來后，他們發現競爭對手蘇聯卻一直在用鉛筆寫字。

這里是想告訴大家，我們在設計系統時，必須要從事情本源出發，而不能只考慮用什么系統、什么技術，因此歸納出這個概念：非技術設計。

在設計的時候從非技術角度考慮，不要一開始就給出技術解決方案，或許要解決的問題因為某個業務上的改動或者某個流程上的變化，就不需要幾個月的開發工作了。

這里有兩個過度設計的例子：設計一個空調。如果設計一種空調在絕對零度到零上三百度都可以用，你也許能夠實現，但需要耗費大量資源，卻完成了一件沒有必要的事情，就如同美國太空筆一樣。絕大多數人不需要在這樣極端的環境中使用空調。

過度設計不僅指超出實際需求的設計，還包括過度復雜的設計。比如你要求你的助理把附近某便利店中的所有商品一種買一樣，卻只用其中一樣，然后把剩下的商品都送回去。

這樣的做法聽上去很愚昧，但實際上，我們在架構設計和系統實施過程中經常會發生類似問題：我們在調取一個數據的過程中，經常會把數據庫中的所有數據都搬出來，卻只找其中的一個記錄。

這兩個例子啟發我們：在架構設計的過程中，不要過早考慮技術因素，而是脫離技術，回歸到事情本源去解決問題。