Steve Yegge對Amazon和Google平臺的長篇大論

來源：陳皓

Steve Yegge， Amazon的前員工，現任Google員工，其本來想在Google+上和Google的員工討論一些關於平臺的東西，結果不小心把圈子設成了 Public，結果這篇文章就公開給了全世界，引起了劇烈的反應。釋出後很快他就馬上把這篇文章刪了，不過，網際網路上早備份了下來——SteveY’s Google Platforms Rant。後來，Steve在其Google+上作了一些解釋，大體是說他喝多了，而且又是在凌晨，所以大腦不清，文章中的觀點很主觀，極端且不完整，還有Google的PR對他很好，等等，等等 。

幾個星期前看到時就一直都想翻譯一下這篇文章，不過因為最近事情太多，文章又很長，所以現在才翻譯完成，翻譯的不好，還請大家指正。

導讀

在你閱讀正文以前，我想說明幾點，希望你注意一下：

• Steve這個人非常喜歡寫長篇大論的東西。而且比較喜歡辛辣調侃和惡搞的文風，這點大家要注意！

• 文中先“罵”Amazon公司，再通過“罵”Amazon的創始人貝索斯Bezos並烘托出他的的悟性和雄心，最後教育了一下Google。

• 我把文章分成了三個部分，這樣方便大家閱讀和討論。第一部分只是個人情緒化的抱怨，第二部分是說Amazon的成長，第三部分是教育Google，我覺得第二部和第三部分是重點。

• 對於我們來說，我們應該獲取Steve那些關於平臺（Platform）相關的那些有價值的觀點。尤其是他說的Amazon如何進化成一個平臺性的公司，以及闡述Google應該怎麼做的那些觀點。

• 關於對Amazon的那些指責，我想說，6年，對於一個世界級的網際網路公司，已經很不一樣了。

正文

第一部分

我曾在Amazon工作了六年半，現在，我在Google的日子也這麼長了。對於這兩家公司，有一件事總是縈繞關我——這種感覺一天比一天強烈── 那就是，Amazon每件事都做錯了，而Google每件事都做對了。當然啦，這是很籠統的話，但卻是驚人的準確，相當的瘋狂吧。大概有一百甚至兩百種不 同的地方可以讓我們去比較這兩個公司，而Google可能在每一項都能勝出，如果我記的沒錯，除了其中3項以外。因為，我曾用電子表格把這些項都列出來 了，只是法務部門不會讓我給任何人看，即使人事招募部門很喜歡這個報表。

這裡，讓我先給你個例子讓你稍微體會一下：Amazon的人事僱用流程有根本上的缺陷，因為各個團隊各招各的人，以至於，各團隊之間的招聘標準相當 的不一致性，即使他們通過各種努力來統一標準，但是實際操作上卻是一團糟；他們沒有真正的SRE（陳皓注：Site Reliability Engineer ），工程師們什麼事都要做（陳皓注：SDE – Someone Do Everything）、幾乎沒時間編碼。當然，不同的部門有不同的情形，不過，這取決於你的運氣。他們不搞慈善，也不幫扶貧困人群，也不搞社群貢獻，或 是其它相似的活動。在那裡，他們從來不談這些，或許只有在說笑話的時候才會提到。他們的辦公環境是個灰塵及汙跡四處的像農場一樣的隔間，他們在公共區域連 一分錢裝修的都不會花，而且，他們的薪水和福利相當差，只是近來與Google和Facebook競爭人才，這個差距才變得非常地小。不過，他們沒有我們 有的津貼或額外獎金——他們只是給你錄用信上的那個數字，就這麼多。他們的程式程式碼完全就是災難，無論什麼都沒有任何的工程標準，除了各別團隊有一些。

公平起見，他們的確有套非常非常不錯的版本控管系統，而這是我們（Google）需要盡力趕上他們的地方，他們還有一個漂亮的釋出/訂閱系統，我們 也沒有相對應的東西。不過，就大體而言，他們有的不過是一堆蹩腳的工具，用關聯式資料庫來讀取或寫入狀態機裡的資訊中罷了。我們不應該這麼搞就算這樣做是可 以。

這就是我所所說的那3件事中的兩件事Amazon比Google強的，那就是的他們的釋出/訂閱系統以及版本控制系統。

我猜你也許會為他們爭辯到——他們要更快更早地推出服務並通過狂熱地迭代來不斷地改進和完善。他們把服務釋出的優先順序看得比任何事都重，包括工程紀 律或是其它一堆可能會讓其花時間的事務。所以，即使這麼做讓他們在市場上有了某種程度的競爭優勢，但也造成其他足夠多的問題，總之，這樣的做法算不上是個 漂亮的扣籃。

但是，他們有一件事做的非常非常好，其好到可以把其他政治，理念，技術上的消耗和混亂和完全彌補回來。

第二部分

Jeff Bezos是個臭名昭彰的微管理經理人，他的微管理都管理到了Amazon零售網站上的每一個顯示畫素。他僱傭了Larry Tesler——Apple的首席科學家，他可能是全世界最有名也最受尊敬的人機介面專家，然而，Bezos忽略了Larry三年來提出的每一個建議，直 到Larry最後——明智地——終於離開了公司。Larry本應做一些大型可用性（Usability）研究，並可以系統地瞭解那個根本就沒有人能夠搞 懂、使用那該死的網站，可是，Bezos對於那些畫素不放手，這些頁面上的那幾百萬個顯示畫素就像是他的孩子一樣。所以，他的這些孩子還留著，而 Larry沒有。

當然，微管理不是第3項Amazon做的比我們好的事。我的意思是，沒錯，他們微控管理做地非常地好，但我不會把這項列在他們的強項清單上。我這樣 說只不過是為了我下文做鋪墊，幫助你瞭解我後面要說的事兒。我們現在要說的這個人，是在多個嚴肅的公開場合說要來Amazon工作就應該付他錢才對的人。 當有人跟他意見不同時，他會遞出寫有他名字的黃色即時貼以提醒那個人“誰是公司的老大”。這傢伙是……，Steve Jobs，我猜。除了沒有品味和設計能力。千萬別誤解我，Bezos是個絕頂聰明的人，只不過他把那些正常的管控搞得像嗑了藥的嬉皮士一樣罷了。

所以，有一天，Jeff Bezos下了一份命令。當然，他總是這麼幹，這些命令對人們來說就像用橡皮槌敲擊螞蟻一樣。這個命令大概是2002年，我想誤差應該是在正負1年內 —— 這個命令釋出的範圍非常地廣，設想很大，讓人眼珠子鼓出來的那種，這種驚訝程度和其他的命令相比，就好像突然收到獎金一樣。

這份大命令大概有如下幾個要點：（陳皓注：這裡是本篇文章的要點！如果這真是Bezos發出來的，那麼太讚了，Bezos完全就是一個系統架構大師啊，那可是2002年左右啊。作者調侃Bezos完全是正話反說啊）

• 1) 所有團隊的程式模組都要以透過Service Interface 方式將其資料與功能開放出來。（陳皓注：Service Interface也就是Web Service）

• 2) 團隊間的程式模組的資訊通訊，都要透過這些介面。

• 3) 除此之外沒有其它的通訊方式。其他形式一概不允許：不能使用直接鏈結程式、不能直接讀取其他團隊的資料庫、不能使用共享記憶體模式、不能使用別人模組的後門、等等，等等，唯一允許的通訊方式只能是能過call Service Interface。

• 4) 任何技術都可以使用。比如：HTTP、Corba、Pubsub、自定義的網路協議、等等，都可以，Bezos不管這些。（陳皓注：Bezos不是微控經理嗎？呵呵。）

• 5) 所有的Service Interface，毫無例外，都必須從骨子裡到表面都要設計成能對外界開放的。也就是說，團隊必須做好規劃與設計，以便把介面開放給全世界的程式設計師，沒有例外。

• 6) 不這樣的做的人會被炒魷魚。

• 7) 謝謝，祝你有個愉快的一天！

哈哈！你們這群150位前Amazon員工，當然能馬上看出第7點是我開玩笑加上的，因為Bezos絕不會關心你的每一天。

不過第6點是很真實的，於是，所以人們都去工作。Bezos並派出了幾位首席牛頭犬來監督並確保進度，領頭的是和熊一樣大的牛頭犬：Rick Dalzell，Rick是以前是陸軍突擊隊隊員，西點軍校畢業生，拳擊手，和沃爾瑪的首席虐刑官 / CIO，而且他也是個高大、和藹、令人敬畏的人，還是經常使用”hardened interface”詞的人，Rick 本來的走路和說話都比較hardened interface，所以不用多說，每個人都得幹 出有重大的進展，這樣Rick才能看得見。

在接下來的幾年，Amazon內部轉變成面向服務架構SOA(Service-Oriented Architecture)，在這華麗轉身的過程中，他們學到了相當巨大的東西。我在的那個時候，世界上就有很多很多的關於SOA的學術文件，但在 Amazon的那種超大規模的面前，這些東西就好像告訴印第安納瓊斯（陳皓注：電影奇寶奇兵男主角）過馬路前要先看看兩旁有無來車一樣沒用，Amazon 的研發工程師們在這個過程中有了很多很多的發現。下面只是他們發現中的蒼海一粟：

• pager escalation（陳皓注：生產線上問題的尋呼系統）變得比較困難，因為ticket可能會轉過來轉過去（陳皓注：ticket就是處理問題的工 單），只到轉了20次，都找到真正能解決問題的團隊和人。如果每一個呼叫都花去團隊的15分鐘的響應時間，那在找到真正的團隊之前幾小時就過去了，除非， 你建造出很多很多的腳手架，測量標準和報告。

• 每一個和你的相關團隊突然間都可能成為一個潛在性的DOS攻擊者。沒人可以讓事情有進展，直到在每一個Service裡放上配額（quota）與節流閥（throttling）的機制。

• 如果你有上百個Services，而且你的程式只能通過由這些Services來跟其他團隊的程式做溝通，那麼，沒有一套Service發現機制 的話，你就不能找到這些Service。所以，你得先有一套Service的序號產生器制，這也是一個Service。所以，Amazon有一套全體適用的 Service序號產生器制，以例可以通過反射機制來找到Service，並知道Service的API，以及是否可用，在哪兒。

• 除錯其他人的程式碼以調查問題變得非常的難，幾乎都不可能，除非有一套全面性的標準的方式，他可以在可被除錯的沙盒裡執行所有的Services。

當我在2005年中期離開Amazon加入Google時，這個努力進化的過程還在進行時中，但那時已經相當的先進了。從Bezos頒佈法令的時間 到我離開的時候，Amazon已經把文化轉變成了“一切Service第一”為系統架構的公司，今天，這已經成為他們進行所有設計時的基礎，包括那些絕不 會被外界所知的僅在內部使用的功能。

那時，如果沒有被解僱的的恐懼他們一定不會去做。我是說，他們仍然怕被解僱，這基本上是那兒每天的生活，為那恐怖的海盜頭子Bezos工作。不過， 他們這麼做的確是因為他們已經相信Service這就是正確的方向。他們對於SOA的優點和缺點沒有疑問，某些缺點還很大。但總的來說，這是正確的，因 為，SOA驅動出來的設計會產生出平臺（Platform）。

是的，這就是Bezos的法令要達成的目標。他以前（現在也是）一點不關心各團隊是否好，也不關心他們使用什麼樣的技術，實際也不去管他們如果動作 他們的業務，除非團隊開始把事搞砸。但是，Bezos比絕大多數的亞馬遜人都很早很早就領悟到，Amazon必須成為一個平臺。

如果是你，你會想到要把一個線上賣書的網站設計成為一個有擴充套件性，可程式化的平臺？你真的會這樣想嗎？

嗯，第一件Bezos領悟到的大事是，為了銷售書籍和各種商品需要的基礎架構，這個基礎架構可以被轉變成為絕佳計算平臺（Computing Platform）。所以，現在他們有了Amazon Elastic Compute Cloud（亞馬遜彈性運算雲平臺EC2），Amazon Elastic MapReduce，Amazon Relational Database Service（亞馬遜關聯式資料庫服務），以及其他可到AWS aws.amazon.com查得到的一堆Service。這些服務是某些相當成功的公司的後臺架構，比如 我個人喜歡的 reddit 是這一堆成功公司的其中一個。

另一大領悟是，他知道他們不可能永遠都創造出對的東西。我認為，當Larry Tesler說他媽媽完全搞不懂怎麼使用那個該死的網站時，Bezos的某根筋被觸動了，當然，我也也不清楚到底是誰家母親，這無關緊要，因為沒有人的母 親能夠會用那個該死的網站。事實上，連我這個在那那工作超過5年的人都覺得Amazon網站的介面令人膽戰驚心。

我並不是很確定Bezos是如何領悟到的——領悟到他不能創造 出一個產品能適用於所有的人。不過，怎麼來的這不重要，重要的是他的確領悟了。這種事有一個正式的術語，叫Accessibility，這是計算機世界中最最重要的事情了。

最！重！要！的！事！

如果你在心裡面在想“哼？你是說，像盲人和聾人那種Accessibility嗎？”，那麼，你不是唯一這樣想的人，因為我已經知道有很多很多像 你這樣的人：這種東西對你們這種人來說是不可能有正確的Accessibility，所以這事你還不能理解。當然，不能理解也不是你的錯，就像眼盲，耳 聾，或是其他行動不便的殘疾人，這些也不是他們的錯。當Software——或ideal-ware——如果因為某些原因不能被存取或使用，那麼，這就是 軟體或是那想法的錯了。這就是Accessibility failure。

就如同生命中那些重大的事一樣， 有一個邪惡的雙胞胎姊妹，它在幼年都受到父母的溺愛，現在它已經成長為同等強大的復仇女神（是的，Accessibility有不只一個復仇女神），這個復仇女神叫安全性（Security），他們在一些總是爭執不休，冤家一對。

不過，我會和你爭論Accessibility要比安全性來的重要多了，因為零Accessibility就意為著你根本沒有做出產品來，而如果安全性為零，你仍然還是可以有一個某個程度上成功的產品，譬如說Playstation Network。

對了，也許你還沒注意到，我其實可以為這篇文章寫出一整本書，很厚的一本，其中填滿了那家我曾工作過的公司裡關於螞蟻與橡皮槌的事。但是，我可能就永遠無法發表這短篇的誇誇其談了，而你也就無法讀到除非我現在開始結尾。

第三部分

那三件Amazon比Google強的中的最後一件事是，Google很不會做平臺（Platform）。我們就不懂什麼是平臺。我們就根本不知道 平臺的內涵。你們其中一些人明白，但是你們是少數派。在Google過去這六年來，越清楚這一點就越讓我痛苦。我曾有一線希望，來自Microsoft和 Amazon，以及近來Facebook的競爭壓力，會讓我們全體人都清醒過來，並開始打造我們公司的Service。不是那種特製的或半生不熟的，而是 多少和Amazon的類似的那種：一次到位，真正的，沒有作弊或是欺騙，並且把它放在最高優先順序的位置。

但實際上卻不是，這個事被放在了好像是第10還是第11位，或是第15位，我不知道，反正是相當低。只有少數幾個團隊嚴肅地看待這個事，但大多數的團隊不是從沒有思考過這個事，就是隻有一很少的人很鼠目寸光地在看待這個事。

對大多數的團隊來說，只要是讓他們以提供給別人那種可程式化的方式存取他們的資料與運算的方式來開發軟體，就算幾個小小的粗糙的Service，對 他們來說也是翻天覆地。他們大部分人都以為他們在做產品，但他們只是在提供那些悽慘粗糙的Service。回去看看前面我所列的那些部分的Amazon學 到的東西，然後告訴我，哪一個粗糙的Service能讓你有超凡脫俗。迄今為止，就我所知，一個也沒有。就算是這些粗糙的東西很不錯，不過這就好像要汽車 的時候，你卻只有汽車的零件。

沒有平臺的產品是沒用的，再精確一點，去平臺化的產品總是被平臺化的產品所取代。

Google+是我們完全失敗的不懂Platform最明顯的例子，從最高層的管理層（嗨，Larry、Sergey、Eric、Vic，你們好） 一直到最最底層的員工（嘿，你）都沒不懂。我們全部統統都不懂。平臺Platform的黃金守則是Eat Your Own Dogfood（吃你自己的狗食——自己都要用自己的平臺）。Google+這個平臺是個懷具的馬後炮。我們在在釋出它的時候完全沒有任何API。我查了 一下，目前也只有少得可憐的API。Google+的一個團隊成員在釋出API時告訴我這個事，我問：“這是Stalker API（用來偷窺的API）嗎？”，她鬱悶地說“是啊”。我的意思是，我那是是個玩笑話，但是，不，我們提供的唯一的API就是取得某人的資訊流，所以， 我想我把玩笑開到自己頭上了。

Microsoft知道“狗食守則”至少有20年了。這已經成為他們世世代代文化的一部分了。不能是你吃人類的食物而給你的開發人員們號狗食。那樣做只會是為了短期的成功而掠奪了平臺長期價值。平臺就是要你考慮得長遠。

Google+就像膝跳反射，一種短視的的東西，是基於以為Facebook其偉大產品的成功作出的錯誤判斷。但那不是為什麼他們能成功的東西。 Facebook的成功是因為他們建立了一個可以讓外界在其上上面開發的產品群。所以對Facebook對每個人來都不一樣。有些人把全部時間花在 “Mafia Wars”上，有些人則是花在“Farmville”（開心農場）。那裡還有成百上千個不同的高質量的時間消耗遊戲，所以，人們總是可以在那裡找到他們想 要的。

我們的Google+團隊看了看說：“哎呀，看來我們需要一些遊戲，讓我們去找一些人來為我們寫些遊戲吧”。你是否開始看到這樣的的思考有多麼不靠譜了嗎？問題在於我們試圖預測人們想要什麼，然後推出產品給他們。

你不能這麼做。真的不能。也不可靠。在這個世上，甚至在整個計算機的歷史上，只有極少數幾個人能夠這麼幹，Steve Jobs是其中一個。但是我們沒有Steve Jobs。對不起，我們真的沒有。

Larry Tesler有可能說服了Bezos相信他並不是Steve Jobs，但Bezos意識到他不需要成為Steve Jobs也能提供給所有人好的產品：大家感容易使用的介面與工作流。Bezos明白他只要有讓第三方開發人員來做的平臺，這些東西自然就會有的。

我要向一些人道歉，這些人會覺得我所說的是再明顯不過的了。是的，的確是巨明顯的。只是我們沒有去做。我們沒有領會平臺，我們也無法領會到 Accessibility。這兩者本來就是同一件事，因為平臺會解決Accessibility。而平臺就是Accessibility。

• 是的，Microsoft領會到了。而且你們也像我一樣知道Microsoft他們對這些東西一知半解。那是因為他們能夠了解平臺完全是他們商業上意外性的副產品，是他們一開始的業務就是提供平臺。所以他們在這個領域有著三十多年的經驗。如果你去看看 msdn.com，並多花點時間瀏覽一下，假設你以前從沒去看過，你等著被嚇到吧，因為那裡面的東西可是多得不能再多。他們擁有成千成千成千個API。他們擁有一個超巨大的平臺。說實話，太巨大了，因為他們要霸佔一切，但至少他們做了。

• Amazon也領會了到了。Amazon的AWS(aws.amazon.com)相當的驚人。去看看吧，四處點一下。令人羞恥吧。我們今天什麼都還沒有。

• 很明顯Apple也領會到了。他們做些在基礎上不開放的選擇，具體來說是移動平臺。但是他們明白什麼是Accessibility，並且他們知道 如何燃起第三方開發團體的力量，而且他們吃自己的狗食。你知道嗎？他們的狗食做得很好吃啊。他們的APIs比Microsoft的要乾淨不知道多少倍，而 且是遠古的時候就這樣了。

• Facebook也領會到了。這正是讓我所擔心的。這使得我不得我抬起懶惰屁股寫下這些東西。我恨寫Blog。我恨……Plus（指Google Plus）不管怎麼稱呼它，反正在Google+上發表長篇大論，就算這是個糟糕的地方，但是你還是希望Google能成功.我真希望！我的意思 是，Facebook想挖我，而且很容易就去了。但Google是我的家，所以我堅持我這個小小的家庭干涉，就算你不舒服。

等到你為Microsoft與Amazon提供的平臺感到神奇後，當然，我想也你可能會被Facebook嚇到（我不敢去看，因為我不想讓我太沮喪），讓我們回頭看看 developers.google.com 。是不是有很大的差別？我們的這個平臺看起來像是你家小學五年級的侄子搞出來的東西一樣——讓一個小學五年級的他，試著描述一個強大的的平臺公司，如果這家公司什麼都有，會整出個什麼東西來？

這裡請不要誤解我——我知道一個事實，dev-rel 團隊為了釋出這些API曾經不得不去“搏鬥”。據我所知，這個團隊很不錯，因為他們知道什麼是平臺，並且他們如英雄般努力掙扎地要做出來，然而遇到的卻是“平臺冷漠”的環境，難聽點是那種有敵意的環境。

我只是在直白地描述出一下 developers.google.com 在外人眼裡是什麼樣子。它看起來很幼稚。Maps APIs在哪呢，老天爺啊？其中有有些東西還是實驗性的專案，我點進去看的APIs……他們都毫無價值。他們很明顯都是些狗食。甚至都稱不上是好的有機食品。跟我們內部APIs比起來，他們全部簡直就是豬屎馬糞。

當然，也不要錯誤地理解我對Google+的看法。他們還不算是最差的。這是文化氛圍的事。我們現在做做的簡單來說就是要進行一場戰爭，是一場失敗很多的少數的平臺派和那些強大的信心堅持的產品派的戰爭。

那些從頭到尾明白理解供外部可程式化的平臺概念的團隊都是受壓迫的人——Maps跟Docs團隊浮現在我腦海中，而且我也知道GMail是這個方向 的先頭部隊，但是他們很難得到資金注入，因為這不是我們文化的一部分。Maestro的資金完全沒發和Microsoft Office開發平臺的資金相比：就像小毛兔和暴龍相比一樣。Docs團隊知道自己永遠無法和Office競爭，除非他們能趕上Office的指令碼能力， 而且他們得不到他們相要的資源。我的意思是我假定他們沒有，現在應用的腳只在電子表格中有，而且沒有為API設定鍵盤快捷鍵。在我看來，這個團隊完全沒有 被重視。

具有諷刺意的是，Wave是個偉大的平臺，願他能安靜地長眠。我們需要知道，做一個平臺並不會馬上給帶來成功。平臺需要殺手級應用。 Facebook——他們供應了的塗鴉牆和朋友等其他東西——則是Facebook平臺的殺手級應用。但是，如果你說沒有Facebook平臺，僅有 Facebook應用也能像今天這樣成功，那麼，這會是個一個非常嚴重的錯誤。

你知道嗎？人們總是在說Google的傲慢自大。我是個Google人，所以我和你一樣當聽到那些話都會覺得很憤怒。但總體而言，我們並不傲慢。我 們大約99%不自大。我在文章開頭時就寫到——如果你回去看看—— 我是這樣描述Google的“所有的事都做對了”。我們知道人們為什麼要這麼說我們自大，因為我們沒有僱用他們，或是因為他們對我們的政策不爽，或是那一 類的事情。他們推斷出我們自大是因為這樣會讓他們心理平衡一些。（陳皓注：作者在這裡的反話正說）

但是，當我們擺出那種我們知道怎麼給使用者設計出完美的產品的姿態時，你最好相信我，我們就是笨蛋。你可以說是自大，天真，或是別的什麼，無所謂，但最終的結果就是我們乾的很愚蠢。因為，這世界不可能有一個產品對所有人都是完美的。

你看，我們的瀏覽器居然不能讓人設定預設的字號。這就是我們對Accessibility的公然冒犯。我的意思是，我總有一天會老的，我也會得老花 眼，並會變瞎的。我的意思是我不會變瞎，但是如果你到了40歲，你的老花眼讓你看不清近的東西。那麼，字號的選擇會成為生和死的問題：某使用者就會被完全排 除在產品之外。但是Chrome團隊就是這麼NB傲慢：他們想要開發出無需配置的產品，他們對此相當自豪，去你TMD是瞎子還聾子，管你是誰，在你剩下的 日子每訪問一個頁面都按一下Ctrl-+吧。

並不僅是他們。是第一個。問題是，我們是一家“產品”公司，一直一直都是。我們開發的最成功最有吸引力的產品——搜尋引擎，那樣巨大的成功讓我們產生了很多定式和偏見。

Amazon過去也是家產品公司，一道神祕的力量使得Bezos領悟到他們需要平臺。那道神祕力量來源於，他們被 逐漸蒸發的市值逼到牆角了，不得不想方設法突圍出來。但他當時所擁有的只有一群工程師和他們的一堆計算機……除非他們能變成印鈔機……你可以看到他們是怎 麼搞出來AWS的，而不是像我們Google+一樣事後諸葛亮。

Microsoft從一開始就是個平臺，所以他們有很多很多的實踐。

Facebook：我有些沒看透。我不是專家，不過我很肯定他們一開始也是一個產品，並且成功了很長時間。所以我不知道他們什麼時候開始轉變成為平 臺的。應該是很久以前的事了，因為他們要成為平臺後，Mafia Wars這玩意才會出現（而Mafia Wars也很老了）。

也許，Facebook只是看一眼我們，就問到：“我們如何擊敗Google？他們少了什麼？”

我們面對的問題非常的龐大，因為我們需要經過劇烈的文化轉變後，我們才能迎頭趕上。我們沒有內部的SOA平臺，所以我們外部也沒有。這就是說，我們 整個公司都“沒有領會到”：產品經理沒有，工程師沒有，產品團隊沒有，沒人領會到。就算是個別人有，比如你你有，那也相當於沒有，除非我們在生死存亡的時 候。我們不能這樣不斷推出產品，並裝作我們以後會把這些產品轉變成迷人美麗的可擴充套件式的平臺。我們試過了，不行。

平臺的黃金守則，“Eat Your Own Dogfood 吃自己的狗食”，換句話說，“先打造出自己使用平臺，然後把它用在所有的地方”。你不能事後再做，那樣做就太困難了——你去問問那些把 MS Office平臺化、把Amazon平臺化的人。如果你放在後面做，那麼你比一開始要花十倍的精力才能做對。你不能作弊，你不能讓內部軟體走祕道去取得特 定的優先許可權，不為什麼，你必需從一開始就要解決這個問題。

我不是說現在做已經太遲了，但我們等的越長，我們就會越接近——“太遲了”。

老實說，我不知道這篇文章怎麼收尾。我今天在這裡說得太多了。因為這篇文章花了我6年時間。請包涵我言語冒犯之處，包涵我可能誤解了一些產品，團隊，或某個人。也許我們真的在開始做了很多平臺方面的東西，只是我沒看到。我只想說聲對不起。

但是，我們必始在開始時把事做對！