兩個披薩如何帶好互聯網團隊？

「宇宙對我們說不， 但我們以血肉之軀來回應，大聲說 『 是的！』」

——Ray Bradbury

成立於1994年的亞馬遜公司，一直以來都是頗具爭議的存在。多年來，Jeff Bezos 在用戶至上（Customer Obsession）的理念下，讓整個電商業務通過價格、選品和可用性（availability）聚焦於客戶體驗，並為獲取長期優勢而持續將收入投入到保持低價、擴大規模以及優化倉儲和物流等基礎設施上。

亞馬遜這種持續刻意的不盈利，不但使亞馬遜與華爾街的投資人之間的關係微妙而緊張（多年來從未對股東分紅，今後也不會！），而且其模式也不斷被質疑是旁氏騙局（Ponzi scheme）【注1】 。

同時，Jeff Bezos 對社會凝聚力的質疑以及其反傳統的管理方式【注2】也極大地塑造了亞馬遜內部帶有衝突的角鬥士工作文化，這樣的文化被具體化為14條領導力準則並用以指導整個公司範圍內從上至下的日常決策。

雖然對這種文化不乏指責的聲音，但也有眾多離開亞馬遜的員工表達了對這種工作方式的熱愛。

在這種文化指導下的技術研發工作也展現出非同尋常的特點：亞馬遜在物流管理、推薦引擎、Web2.0、雲計算、人工智慧、數據化管理、平台設計、DevOps 等領域一直走在行業前列，不乏叫好又叫座的產品。

但從外部看，其在開源社區和公開的技術演講中卻鮮有聲音，與外在的沉寂不同，在亞馬遜內部，研發則是另一番景象，一個又一個想法被不斷提出和嘗試，各團隊為了共同的目標高效地競爭與合作，知識和經驗被不斷的累積與分享……

我自 2009年加入亞馬遜至 2014年底離開，期間接觸了多個團隊的技術研發和研發管理的工作。

在離開亞馬遜加入創業公司後，研發團隊遇到的一些問題常常將我帶回對往事的思考中：「是什麼讓亞馬遜的研發如此不同？」，「如何學習亞馬遜的經驗來打造高效的研發團隊？」……。

本文正是我近幾年對亞馬遜研發和管理的一些思考，並結合了具體實施的一些經驗。

由於整個亞馬遜的研發和管理體系的複雜性，加之多數結論也是基於實踐的一些揣測，其中不乏不妥和錯誤之處，望閱讀的過程中加以斧正。

最後，亞馬遜那種直接鼓勵競爭性的角鬥士文化本身就有非常大的爭議，其本身確實不是以優先考慮員工感受為出發點。

但作為親歷者也確實能夠感受到在壓力下不斷創新和超越自我所獲得的滿足感。

因此，有關文化的討論並不是是非對錯的探討，讀者還需要自行判斷和採用。

亞馬遜飛輪

成為全球最以客戶為中心的公司，在這裡，人們可以找到和發現他們想從網上購買的一切。

—— 亞馬遜網站使命宣言

Bezos 通過一張圖（如圖1）詮釋了亞馬遜的運營邏輯，這逐步演化為整個亞馬遜電商的運營核心——飛輪（Flywheel）。這個飛輪簡單解釋如下：

亞馬遜提供豐富的選品和購物便利，而豐富的選品和購物便利帶來了更好的用戶體驗，用戶體驗的提升引發更多的消費者來到網站，流量的提升將吸引更多的供應商加入，結果進一步豐富了選品。

而這又使得亞馬遜可以通過供應商競爭以及在更寬泛的基礎上分攤成本來進一步降低價格，價格的降低又使消費者的滿意度進一步提升，這個良性循環持續發生，推動這亞馬遜整個平台越來越好。

圖1：亞馬遜飛輪

而 John Rossman 在《The Amazon Way》中（The Virtuous Cycle Goes Fractal: The Flywheel Effect ）更為詳細地論述了亞馬遜飛輪以及相關的三位一體（the holy trinity）：價格、選品和可用性。【注3】

亞馬遜飛輪背後暗藏著這樣的邏輯：一旦核心部分各就其位，飛輪被激活，飛輪就會隨著時間產生持續的動力並變得更強。

在整個循環中，每個部分會產生自己的能量，這又被用來驅動系統的其它正能量。

在亞馬遜的研發體系中，類似飛輪這樣的良性循環機制發揮著廣泛而巨大的影響，大到人員招聘和培養體系，小到事後分析機制的設計，甚至亞馬遜平台化的思路中也多有類似的飛輪思想。【注4】

另外，之後將要介紹的領導力準則，其各個部分往往也會相互影響，形成類似飛輪的機制。

正如 John Rossman 在《The Amazon Way》中所說，「一旦你在組織中建立起責任感（Ownership），它就會像飛輪一樣驅動著創新與簡化（Invent and Simplify）」。

領導力準則

「It would certainly be much easier and socially cohesive to just compromise and not debate, but that may lead to the wrong decision.」

Tony Galbato, Amazon vice president for human resources

Have Backbone; Disagree and Commit.Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting.

Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion.

Once a decision is determined, they commit wholly. They are willing to champion an unpopular or difficult message.

當我們去分析一個公司的企業文化時，其領導者的個性應該是重要的考量因素之一。

對於創業公司而言，這一點尤為明顯，創始人的行事方式幾乎會完全影響和定義公司的文化【注5】。

因此，不難理解，一個喜歡資本運作的老闆，很難關注用戶和產品的長期發展，其公司的快速衰落就在情理之中。

同樣的，一個靠投機獲得財富的人，天然地會利用互聯網作為更大的傳銷平台來兜售其狡黠的捷徑哲學，而本身並沒有像樣的產品和經得起推敲的方法論。【注6】

Richard L. Brandt在《一鍵下單》中詳細地講述了Jeff Bezos 的成長經歷，並描述了這位亞馬遜創始人不一樣的性格特點。

從這些資料以及網上公開的分析文章中，我們不難發現 Bezos 的高標準嚴要求、節儉、固執、不講情面、深入細節、相信數字、結果導向等等特點。

作為一個知名的例證，《一鍵下單》和其它一些文章談到了 Bezos 小時候勸說外祖母戒煙的故事，有趣的是，同樣的故事在3個地方被用來反映3個完全不同的主題！【注7】

首先，《一鍵下單》用這個故事表現 Bezos 缺乏同情心：

貝佐斯天生就沒有同情心。他10歲時，在和祖父母的一次旅行中，他試圖讓他的外祖母戒煙。

對於一個讓人難堪的話題，他靠的更多的是他的書獃子辦法而不是善解人意。他算出她所吸入的尼古丁含量會減少她9年壽命。

外祖母哭了。外祖父不得不教導他應該有更多的同情心。

「我外祖父注視著我，沉默片刻，然後平靜地輕輕說道，『 傑夫，有一天你會理解，做到善良比聰明更難。』」貝佐斯說。

其次，紐約時報的文章則用這個例子反映 Bezos 數據驅動的管理天分：

Jeff Bezos turned to data-driven management very early.

He wanted his grandmother to stop smoking, he recalled in a 2010 graduation speech at Princeton. He didn』t beg or appeal to sentiment.

He just did the math, calculating that every puff cost her a few minutes. 「You』ve taken nine years off your life!」」he told her. She burst into tears.

最後，Bezos 自己在普靈斯頓的畢業演講中，用這個例子來說明選擇比天賦更重要【注8】：

……My grandfather looked at me, and after a bit of silence, he gently and calmly said, 「Jeff, one day you』ll understand that it』s harder to be kind than clever.」

What I want to talk to you about today is the difference between gifts and choices.

Cleverness is a gift, kindness is a choice. Gifts are easy — they』re given after all.

Choices can be hard. You can seduce yourself with your gifts if you』re not careful, and if you do, it』ll probably be to the detriment of your choices.

回歸正題，在亞馬遜成立時，Bezos 就在思考如何避免公司隨時間變得官僚主義、揮霍無度以及驕奢安逸。

他想將他對工作的想法變成新人能夠理解的簡單指示，足夠通用以便適用於所有業務，並且足夠嚴格以防止他所擔心的平庸，其結果就是我們這裡探討的14條領導力準則（如圖2）。

我們可以通過亞馬遜招聘網站在線查看對領導力準則的簡單解釋。不難看出，這些領導力準則有些反映出 Bezos 個人的行事特點（如Frugality，Dive Deep，Have Backbone等）【注9】。

而有些則是其對亞馬遜運作方式的思考（如Customer Obsession，Ownership等）。

圖2 亞馬遜領導力準則

有別於其他企業夸夸其談、含糊不清的的價值觀，亞馬遜的領導力準則從來不是埋藏在員工手冊中的漂亮文字。

這些信條在整個公司範圍內——從上到下——被用來指導日常工作、績效評估、人員招聘，甚至被用來解決會議中的爭論、跨團隊的協作（如圖3）等等問題。

亞馬遜領導力準則就像亞馬遜這頭巨獸的血液，它在思想層面統一了亞馬遜人對做事方式和做事標準的認知，並提供了一套高效溝通的標準語言。【注10】

圖3 在日常郵件中使用領導力準則進行溝通，反饋問題，給出解決的建議。

此外，通過領導力準則在人員招聘和績效評估上的使用，亞馬遜將這些能力固化為亞馬遜人所應具備的標準競爭力（Competence）。

比如，亞馬遜的績效評估使用 OLR（Organization and Leadship Review）的機制，其中L就代表了領導力準則（Leadership Principle）。評估分成3個部分：員工自評，經理評價和360度互評。

這些評價都需要落腳到具體的領導力準則上，並且要給出具體的改進建議。

為了使這些準則明確和更具操作性，亞馬遜還為每位員工刊印了指導手冊，裡面具體解釋了使用方式以及使用過度和運用不足的情況（如圖4）。

而且，作為指導亞馬遜日常工作中決策的依據，其與公司戰略和人員情況始終保持著緊密的互動。

也就是說，這些領導力準則會被定期評審以判斷是否適用，例如，最近自我批評（Vocally Self Critical）就被好奇求知（Learn and Be Curious）取代。

圖4 領導力原則的具體操作指導

那麼，我們要如何學習亞馬遜的領導力準則呢？

我們必須要明白，亞馬遜所呈現的這些均是其發展的結果（現狀），這些結果是由亞馬遜發展過程中所遇到的問題所塑造的（path-dependent）。

因此，機械照搬亞馬遜的領導力準則肯定是行不通的，我們需要先清楚自己要解決的問題並明確要達到的目的，在這個基礎上進行選擇，必要的時候我們需要發展出自己的領導力準則。

圍繞亞馬遜的文化，公開討論比較多的是面向客戶（Customer-orientated）【注11】和建立遠景視圖（take a long-term view）——可以認為是遠見卓識（Think Big）的體現。

這方面的資料網上俯拾皆是——舉凡談及亞馬遜必然要討論到這兩方面，這裡就不在贅述。但這並不意味這這兩點不重要，也不意味著這兩點很容易達成。

事實上，對創業企業來說，這兩點毫無疑問是知易行難的代表。就我的經驗而言，在團隊內強調這兩點其實是非常必要的，因為聚焦客戶有助在企業內部建立一種面向客戶的服務意識（文化），這不僅會幫助團隊成員建立同理心（empathy）和共贏意識，而且可以潤滑團隊間的合作；

而願景視圖則可以幫助團隊在用短期方案解決眼前問題的時候養成思考長期方案解決根源問題的意識。

正如亞馬遜領導力準則所能達成的目的，為整個公司建立一種行事的標準和方法並依此標準來選擇或培養人員。

為了能在公司或團隊範圍內建立一種擔責、行動和服務的文化，我在創業公司通常會逐步要求客戶至上（Customer Obsession）、責任感（Ownership）、執行力（Bias for action）、聰明做事的方式（Invent and Simplify）、深入細節（Dive Deep）和達成業績（Deliver Result）。

這樣比較容易和快速讓整個團隊建立起服務意識（聚焦客戶的結果，業務團隊或者內部的依賴團隊都應該被當做客戶）、勇於擔責並且不推諉的做事方式（來自責任感，我們會明確的要求團隊不推事，要考慮整個公司或產品的目標，在明確超出範圍時，也要說明原因並幫助反映問題），並可以讓技術團隊自然的關注於業務（深入細節的要求）等等。

同時，在面試的過程中，也會著力考察面試者在責任感、執行力、深入細節，甚至遠見卓識（Think Big）上的情況，而不僅僅考察其技術能力。

當人員具備這些素質時，一個能打硬仗的自我驅動的團隊就不再是遙不可及的事情了。

此外，需要注意的是，這種標準需要在各個層面一致地進行貫徹，你不能一邊要求團隊有責任感一邊自己不擔責，另外，當團隊遇到問題時，要適時地進行教育，必要時需要建立紀律進行獎懲。

比如，我們的一個系統出了問題，研發人員在周五下班前發了一份郵件給異地的開發團隊，然後就心安理得的回家了，之後當被問及系統問題為什麼沒有得到及時處理時，該研發人員說已經給對方團隊發了郵件，認為責任不在自己（已經移交給對方團隊）。

我們在之後的會議上分析了這個問題，對雙方的團隊成員進行了批評，明確任何問題的責任人要對問題全程負責，不能認為發了郵件就沒自己的事情了，在沒有得到明確反饋時需要想其它辦法獲得反饋，並積極推動事情向前。

此後，類似問題發生後，郵件沒有得到快速反饋時，研發人員就會主動打電話聯繫對方的團隊成員或領導，並能快速地將事情的進展進行反饋。

Bezos 期望通過領導力準則讓每一個亞馬遜人成為企業的領導者（leader）或者主人（owner），他想讓你就像對待自己的事業一樣來推動亞馬遜的業務，而不只是來上班和社交。

這也正是許多企業主和管理者的所面對的問題，在這方面亞馬遜確實做得不錯，但是這樣的角鬥士文化並不適合每一個人。

對於企業而言，我們能夠借鑒亞馬遜建立更為適度的競爭環境？

而對於求職者來說，你是期望一個不斷將你踢出舒適區並不斷促使你成長的環境，還是一個舒適的工作，這取決與你的選擇。

合適的人

實現跨越的公司的領導人不會追求這樣一個領導模式：「先普遍撒網，後重點培養」。而是走這樣一條路線：「我們會事先花上大力氣進行嚴格的人員挑選。一旦找對了人，就會想方設法把他們留在自己身邊。如果不合適了，我們也會誠實地去面對，這樣我們可以繼續我們的工作，他們也可以繼續他們的生活。」

《從優秀到卓越》

文化的受眾、組成與影響的都離不開人，可以說，文化由人決定，又決定了人。

像亞馬遜或者 Google 這樣的優秀企業必須要有與其文化相適應的人員才能高效運轉，尤其是亞馬遜這種衝突性的角鬥士文化，必須不斷吸納在競爭力上能夠適應它的人（在國外，亞馬遜兩年內的流失率非常高）。

我們在介紹亞馬遜領導力準則時說過，亞馬遜的領導力準則會用於人員招聘和培養。這是如何做的？

一方面，在領導力準則中有兩部分與人員的選擇與培養相關：

選賢育能（Hire and Develop the Best）

領導者不斷提升招聘和晉陞員工的標準。他們表彰傑出的人才，並樂於在組織中通過輪崗磨礪他們。領導者培養領導人才，他們嚴肅地對待自己育才樹人的職責。領導者從員工角度出發，創建職業發展機制。

最高標準（Insist on the Highest Standards）

領導者有著近乎嚴苛的高標準 — 這些標準在很多人看來可能高得不可理喻。領導者不斷提高標準，激勵自己的團隊提供優質產品、服務和流程。領導者會確保任何問題不會蔓延，及時徹底解決問題並確保問題不再出現。

另一方面，在亞馬遜的招聘過程中，會圍繞領導力準則所要求的競爭力進行重點考察。

讓我們先來簡單地描述一下亞馬遜的面試流程。（不確定亞馬遜的技術面試是否是世界上最難的，但持續時間長是一定的。【注12】）

從候選人的角度看，當候選人員通過了 HR 和技術的電話初篩，接下來就會被請到亞馬遜的辦公室進行 Onsite 面試。

整個 Onsite 面試通常有5到8輪——依據具體的職位會有所變化，時間通常會佔用半天到一天，由於面試後有可能會有內部輪轉的可能，因此，偶爾會遇到多個不同組進行多次 Onsite 的情況。

這裡以5輪面試為例，整個安排會是技術面試佔兩輪，其中一輪考察編程能力，另一輪考察設計能力，然後是招聘經理面試，HR面試，最後是Bar Raiser面試。

而從面試者的角度看，HR先將面試者的簡歷信息錄入到內部的面試管理系統，然後確定電話面試的面試官，電話面試通過後（可能會是HR和技術各一輪），面試的反饋會錄入系統備查。

之後，HR 和面試經理一起確定 Onsite 各輪的面試官，尤其是Bar Raiser人選。

在 Onsite 之前，會舉行一個快速的 kick off，在這個會議上，HR會簡單的介紹候選人和職位的情況。

然後，面試經理會和大家一起將1領導力準則和其它方面的面試內容分配到具體的面試上。

比如，第一輪的技術面試除了考察編程能力，還會重點考察候選人的 Ownership 和 Dive Deep 的能力。在面試的過程中，各個面試官會通過提問不斷探查（probe）和挑戰（challenge）候選人，以便客觀和全面的了解候選人的情況。

各面試官在面試後要在系統中詳細進行反饋【注13】，這些反饋包含：

明確的投票，錄取還是放棄

簡要的總結

候選人的優勢和劣勢

問題、回答以及分析

最後，Bar Raiser 會主持一個 debrief 會議，在會議開始，各個面試官會先花一些時間閱讀所有人的反饋信息，而後開始匯總和討論候選人的情況。

最後 Bar Raiser 和招聘經理會根據分析情況最終確定是否 offer 候選人。

這裡，我們看到亞馬遜面試設計的兩個特色。

首先，對敘述性文檔的鐘愛，在亞馬遜內部管理中，敘述性文檔是最常用的工具，而 PPT 除了技術分享外，是被禁止使用的。

這是因為 PPT 中只有少量信息，觀眾只能抓住那些要點，這種機制對演講者友好，但對觀眾卻很困難。

相對的，書寫文檔時，完整的句子和段落會促使作者深入的思考和更清晰的表達，這些文檔可以無需額外的解釋就能分享更多信息。

就候選人的反饋而言，由於整個面試過程通常是在紙上進行編程，因此，面試官在錄入反饋時需要將程序和問答細節都錄入系統，這確實是一個不小的負擔（通常會花30~60分鐘）。

但也正是這個過程，使得面試官在錄入的過程中能夠再次審視候選人，盡量客觀的對其進行評價。

另一方面，這樣的反饋工作也鍛煉了面試官的分析能力，並對其面試進行快速反思，從而使得面試官能夠更出色地完成未來的面試工作。

其次，Bar Raiser 的設定。Bar Raiser 是公司內部經過培訓的一些特殊面試官，他們會作為第三方參與到整個公司的面試流程中。

並且代表公司在人員招聘方面的長期利益，這種長期利益主要是來平衡招聘經理快速補充用人的短視訴求。在一個面試中，Bar Raiser 必須同意才能給候選人發 offer。

Bar Raiser是如何代表公司招聘的長期利益？在Bar Raiser判斷的過程中，他們需要考慮如下兩個問題：

候選人是否超過亞馬遜當前職位上50%人員的能力？

候選人是否能為亞馬遜帶來長期的影響？

正如之前論述飛輪時談及，Bar Raiser 就是推動人員能力持續優化的飛輪中的重要一環。

通過 Bar Raiser 的設定，亞馬遜期望通過不斷提升招聘門檻來提升整個公司的人員水平。整個面試循環如下圖所示。

圖5 通過不斷提升招聘門檻（Hiring Bar）來提升整個公司的人員水平

毫無疑問，亞馬遜的整個面試過程是很繁雜的。但考慮到亞馬遜招聘的主旨——Hiring The Best。這樣的流程就顯得穩妥而高效。

如果我們不假思索地將這樣流程直接用於初創公司，那一定會遇到問題！

當我最初加入某個創業企業時，拿著整套方法，期望通過敘事性反饋和基於反饋的debrief 來提高招聘的質量，但經過幾次嘗試，HR 和參與面試的人員就開始抱怨。

稍作分析後不難發現，多數創業公司的用人訴求是快速找到能幹活的人員，至於面試體系的優化、人員水平的提高或者人員長期的潛力都是次要得。

在這種情況下，我們可以對亞馬遜招聘流程進行一定的調整，形成一套適合自己的招聘體系：

明確公司內對人員的能力要求（如責任感、執行力、深入細節的能力等等）。

通過JD明確崗位對人員的技術要求。

安排 3~4 輪面試，其中技術 1~2 輪，招聘經理1輪，HR 一輪。在面試前與面試人員溝通需要考察的方向，尤其是能力上重點關注的方面。

面試後所有面試人員快速的討論。討論過程中，每個人說出該候選人員的優勢和劣勢，並適當補充自己觀察到的一些細節依據。最後大家投票確定去留。

有時對於一些比較重要的角色，需要考慮整個團隊的建設，這時使用Bar Raiser的思考方法是個不錯的選擇。

在實施過程中，還需要在公司內對潛在的面試人員進行定期培訓，培訓的內容主要是如何考察和分析候選人的能力與潛力，這方面可以參考 GitChat 之前的分享成為高效面試官的那些套路。

另一個常常遇到的問題就是大家對面試結果舉棋不定的時候，如果遇到這種情況就大膽的淘汰掉候選人。

通過前面的討論，我們知道這些通過面試的候選人很大的可能性會契合亞馬遜的領導力準則，優於該角色當前 50% 的人的能力。

而且其潛力能夠在將來對亞馬遜產生影響，那麼，在具體技術方面，亞馬遜對技術人員有怎樣的要求呢？這些要求又如何影響了亞馬遜研發的效率呢？

SDE：Someone Do Everything

SDE 全稱是 Software Development Engineer，他們是亞馬遜系統的建設者，是技術研發的中堅力量。

【注14】當我們探討亞馬遜對技術人員的要求以及研發效率的問題時，主要是針對這個崗位的人員。

在我們具體看亞馬遜對技術人員的要求前，我們先分析一下技術人員在亞馬遜所面對的問題。

亞馬遜零售網站，這部分被稱為Retail

電商業務涉及的所有支持系統，這部分被稱為OpsTech

內部支持工具的研發（應該是隸屬於Engineering Excellence）

與硬體相關的系統及其業務支持系統

雲計算業務與系統

戰略性預研工作的研究所，如神秘的Lab126

無論是#1~3這樣傳統的電商研發團隊，還是之後更為技術性產品的研發工作，這些工作在當時（甚至現在）都是前無古人的探索。

相應的，其技術團隊除了了解其所面對的問題外——有時對問題的了解都是模糊的，很少有現成的東西可以參考。

如此，當我們在技術崗位的 JD 上看到這樣的描述就一點都不覺得奇怪了：

候選人能夠獨立地創造性地解決挑戰性（模糊的）問題。

因此，亞馬遜首先需要研發人員有解決問題的能力（Problem Solving），而且還要快、能夠獨立完成。

在2016的股東公開信中，Bezos 談及 High-Velocity Decision Making 時談到：

Day 2 companies make high-quality decisions, but they make high-quality decisions slowly.

To keep the energy and dynamism of Day 1, you have to somehow make high-quality, high-velocity decisions.

Easy for start-ups and very challenging for large organizations.

The senior team at Amazon is determined to keep our decision-making velocity high. Speed matters in business – plus a high-velocity decision making environment is more fun too.

We don』t know all the answers, but here are some thoughts.

從另一個側面看，決策要快就意味著業務快，而業務快就要求支持的研發必須快！那麼在業務驅動的大背景下，研發人員必須能夠在信息有限的情況下和業務團隊一起創造性的快速解決問題，這也是責任感的一種體現【注15】。

當然，亞馬遜的領導力準則仔細推敲起來就是要達到一種低成本、高質量的快速行動力。

再進一步看，當我們有一些想法，需要研發團隊配合開發一些支持系統，以便整個業務能夠運轉起來。

當業務運轉起來以後，通過系統了解業務的運轉情況，我們會有新的理解，而後就產生新的想法，研發了解並進行相應的開發，改進的業務運轉起來。之後繼續這樣的循環……

這個循環讓我們了解到第一個有關研發的事實：軟體研發本質上是一個學習的過程，尤其是快速學習相應領域中的業務知識。

我們對業務領域越是了解，我們開發出的系統就越簡單好用。

因此，亞馬遜的技術研發人員必須要有優秀的學習能力，考慮到業務和技術變化的速度，研發人員必須有快速學習的能力。

再進一步看，當我們了解了業務並清楚需求後，我們要把這些業務需求變成運行的系統，這個過程要涉及一系列工作：

產品設計（原型設計，交互設計等）

系統設計/軟體設計

編碼實現

測試

部署

運維

這些工作中，什麼是最核心的？從業務的角度看產品設計和系統設計是最核心的，編碼實現則更像某種翻譯工作。因此，我們得到第二個有關研發的事實：軟體研發本質上是設計。

如果我們將產品設計的工作交給TPM（類似產品經理）或者PM（業務人員），我們可以將這個事實針對研發人員進行改寫：軟體研發能力最關鍵的是設計能力。

至此，我們稍作總結，亞馬遜的 SDE 是什麼樣的人？

他們符合亞馬遜領導力準則所要求的競爭力，尤其是在客戶至上、責任感、執行力、深入細節、遠見卓識、創新簡化、達成業績方面，此外，他們還關注業務、快速學習，能夠通過設計、實現和運營系統來創造性地解決業務問題。

這大概也是你心目中對研發人員的要求吧？無論如何，我們在創業公司中是按這個要求尋找同行的小夥伴的！

為什麼亞馬遜內部將 SDE 戲稱為啥都乾的人（Someone Do Everything）？這可以引出亞馬遜內部有關研發工作的兩個有趣舉措：

人人都是（潛在的）架構師

開發人員完成一切

首先，我們來探討一下人人都是架構師。

人人都是架構師

正因為亞馬遜認為研發人員最關鍵的技術能力是設計能力，所以在崗位要求和面試安排上，系統和軟體的設計能力都是關鍵點。

比如，SDE1 需要了解設計，而 SDE2 就必須能夠獨立地進行設計工作，到 SDE3，需要把握複雜系統的架構。

當進入公司的研發人員已具備（或有潛力習得）設計和架構能力，並有問題解決能力，還可以深入細節、快速學習。

此時，單獨劃分出架構團隊的意義就不大了，而且一旦設置獨立的架構團隊則必然引入額外的溝通和決策過程。

而且架構團隊脫離具體的業務也很難給出適合的架構，這些架構團隊就會成為高效研發的桎梏。

近些年主流的看法是讓架構師參與到開發工作中，也就是架構師要參與編碼或者實際參與實現其架構。

亞馬遜的做法是從另一面入手，既然所有人都具備架構和設計能力，那麼就讓實際業務的開發人員做架構吧。

不可否認，即便對於亞馬遜的研發工程師，架構工作仍然是非常複雜的。為了讓開發人員能夠真正擔負起架構工作，一些措施必須就位來降低架構工作的複雜性。這些舉措涉及：

通過團隊劃分來降低問題規模

通過合理分工來分擔架構工作

通過內部框架限制選擇、提高效率

通過工具或服務封裝支持性架構和運營維護工作

通過制度保證知識積累

稍後，我們將涉及這些舉措，可以這樣說，正是這些舉措使具體的研發工作變得簡單高效。在此之前，先讓我們聊一下開發人員完成一切。

You build it，you run it.

2006年，亞馬遜 CTO Werner Voegls【注16】接受 ACM 訪談，在談及服務化過程中所獲經驗時，他給出亞馬遜研發人員同時負責研發和運營維護工作背後的理念——「You build it，you run it」，如下是摘自該訪談的內容。

There is another lesson here: Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view.

The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon.

You build it, you run it. This brings developers into contact with the day-to-day operation of their software.

It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.

這段談話給出讓研發進行運營維護工作的好處：

打破了開發和運營維護之前的牆，因此，研發和運營維護整體效率提升。

直面客戶，通過客戶反饋來提高服務的質量。這一點也促進了研發建立面向客戶的意識。

在這篇訪談的其它部分，談到如何確定該不該發布一個功能時，Werner Voegls 的回答透漏出當研發接手運營維護工作的另一個好處，就是與產品運營相關的數據意識的建立，而數據驅動和基於數據管理是亞馬遜非常重要的實踐。原文如下：

JGLet』s postulate that somebody has come up with an idea and the team has gone off and built something. How does the go/no-go decision get made?

WVIt may depend on the criteria for success that were defined up front. When the service is ready for beta testing, we will slowly introduce this to our customers, and then we measure relentlessly.

現在，讓我們將思緒放到 2006 年。3年後的 2009 年，敏捷社區才忸怩地提出 DevOps 的概念，而且那時還只是強調 Dev、QA 和運維人員相互協作；

而在2006年之前，亞馬遜已經讓研發人員承擔（大部分）測試和（應用）運維的工作。

而且以服務構建和部署為核心的整個研發運維支持體系（當時應該是ABB【注17】）早已完全就位，通過這些工具，研發人員可以將精力投注在業務學習和核心模塊的實現上。

系統搭建、部署、監控等支持性工作都能通過這些工具簡單地完成，這正是之前降低架構複雜性時提到的措施之一：

通過工具或服務封裝支持性架構和運營維護工作，這裡支持性架構通常是指物理架構、運維架構，可能還包含常見的系統架構（如，用以支持高可用和高並發的架構，或者基於消息的架構），雖然這些工作並不直接與業務相關，但確實又不能不做。

對於亞馬遜而言，業務部分是變化最快的，新的業務不斷湧現，舊的業務需要不斷優化調整，相應地，業務團隊和研發團隊應該將精力放在與業務相關的工作上。

與之相比，物理架構、系統架構和運維架構的問題解決往往有固定模式，也容易通過服務化的工具進行封裝和提供，其變化性更多來自服務的量級而不是內容。【注18】

當我們將這些知識和實踐用工具或服務封裝後，開發人員只需學會使用這些工具或服務即可，而不需要關心其背後複雜的知識。

因此，從系統開發實現的角度看，相關的設計、編碼、測試、部署、運維等等工作都可以由研發人員一力承擔，像 OpsTech 負責的多數內部服務系統，甚至連產品設計的工作也由研發完成。

這就是從誰構建誰運營（You build it，you run it）發展出的研發人員完成一切，如下圖。

需要注意的是，雖然多數情況下，SDE 會優先且儘力承擔研發中涉及的所有工作，但當需要更強的專業性時，亞馬遜也並不排斥在團隊中設置相應的角色，並將工作交給他們。

例如，服務供應商的 Seller Centre 系統，由於用戶體驗和交互對提高用戶使用效率非常關鍵，因此，整個大團隊會設置產品經理和前端團隊。

類似的，有些業務會需要數據工程師（Data Engineer）或者是嵌入式系統架構師（Embedded System Architect）這樣的研發人員，對這些人員而言，則需要學會這些支持性系統，有時甚至是必要的開發技能，以便在資源有限的情況下依然能夠保證業務推進和系統的運營維護。

另一個比較容易引起誤解的地方是對測試以及測試人員的定位和使用。毋庸置疑，測試是非常重要的工作。

只是對大多數系統或服務而言，測試更多地通過自動化和程序性的完成，即便還會有一些手工驗證的工作，這些工作也常常由系統的開發者內部消化掉。

在一些強調用戶體驗和可用性的系統或服務中——如移動端應用，也會設置專職的測試人員。

除了 QA，亞馬遜的 SDET（Software Development Engineer in Teast）是用程序來進行自動化測試的崗位。

近幾年非常流行的全棧工程師在亞馬遜內部並不會提及，既然亞馬遜對 SDE 的潛在要求是一人多能——盡量獨立、儘力全能（干），為了達成業績（Deliver Result）什麼都得學會，誰還會覺得多學一些東西是了不起的事情？畢竟，在這樣的環境下，全棧只是全能的一種副產物！

在目前的創業公司中，我們嘗試通過開源工具搭建出與亞馬遜相對應的支持工具鏈體系，如下圖，並讓研發人員完成一切開發和運維工作。

在近百人的研發團隊中，我們只保留了兩名傳統運維人員來負責機器、網路等基礎設施維護，而且完全沒有測試人員。

在 Werner Voegls 的訪談中，老爺子輕描淡寫說，「This brings developers into contact with the day-to-day operation of their software.」對於亞馬遜的 SDE，每天的運營維護工作可是很具體而且不那麼讓人舒服的……

7X24 OnCall

當研發人員開始運營維護自己的系統時，自然需要時時刻刻關注系統運行的狀況。

當生產系統發生問題時，監控和報警系統會捕獲這些問題，並生成與這些問題相對應的報障，這些報障會根據之前設定的負責團隊和排班情況自動找到對應解決的人，之後通過 pager 或簡訊進行通知。

此時，無論你身在何處，無論你從事何事——很有可能是睡覺，你都需要馬上打開電腦，快速跟進和處理問題，這也是你身邊的亞馬遜朋友總是背著電腦和你一同出遊的原因。【注19】

不難看出，7x24的 OnCall 確實是個辛苦的負擔，尤其是打擾到睡覺或私生活的時候，這個負擔會尤其痛苦，但這也恰恰正是讓 SDE 擔負 OnCall 的有趣之處。

當事情讓人痛苦時，我們可以採取兩種方式處理，一種是拍拍屁股走人，讓問題變得更糟；一種是留下來咬著牙把問題解決了，讓整個世界美好起來。顯然，無論哪種職場雞湯都會鼓勵後一種行為。

事實上，痛苦確實能夠激發創新，要知道亞馬遜的部署工具鏈和 Google 的應用運維繫統都是在研發人員完全不能好好睡覺的情況下被現實逼著開發出來的！

對於 OnCall 這種痛苦，研發團隊也會想一些辦法來緩解。

比如，早前有些團隊嘗試在印度組建支持性團隊來專門負責 OnCall 和解決 Bug，但運作一段時間後，此種方式的弊端就顯現出來了。

首先，支持性團隊的流動性非常高，解決問題這樣的工作不但工資不高而且少有成就感，很自然，這些支持性團隊的成員要麼離職要麼熟悉系統後轉為該系統的 SDE。

其次，系統的質量沒有得到明顯改善，支持性團隊的成員由於不直接對業務系統負責，因此他們更關注將遇到的問題解決掉，至於隱藏在問題背後的根源，那就要看相應支持性團隊成員的心情和人品了，結果有些問題會周而復始的重複發生。

另外一種方法則需要研發團隊在不同時區有研發組，這樣一來，大家可以相互負責處理對方晚上的OnCall，恩，終於可以安心睡個覺了！

OnCall 制度還有另外一些好處。

首先，通過 OnCall 可以讓新人快速熟悉業務和系統。有些團隊會在新人加入團隊後先讓其 OnCall 一段時間，這段時間新人通過解決實際問題了解了開發流程、工具、業務、系統，以及相關的人員。

另外，OnCall 還和 OE（Operation Excellence）相關，而OE在研發層面則會促進系統質量的提高和研發資源的有效利用。

當判斷一個系統質量好壞時，我們會採用什麼方法？顯然，線上系統問題的數量、類型和嚴重程度會給我們一個從外部洞察系統的機會。

一個總是發生問題的系統或者不時發生嚴重問題的系統，其質量自然不高，更糟糕的是，由於研發人員還要負責運營維護的工作，如果系統問題佔用了太多時間，那麼研發人員就沒有時間開發新的功能。

Google 通過 SRE 和故障預算來平衡研發和運維工作的比例，亞馬遜則是通過YOY（Year of Year）的 OE 目標來促使系統進步。

Bezos 要求：

研發團隊需要在業務持續增長的情況下，系統每年的問題數量下降10%，相應的支持性人員（工作）要減少10%……

舉個例子，如果團隊有10個 SDE，去年有1000個 Tickets，那麼今年系統 Ticket 數量要在900以內，而且還要解放出一個 SDE，這樣團隊就可以用同樣的人負責更多業務，如果業務沒有明顯增長則可以縮編。

這裡10%是一個用於參考的底線值，通常團隊會根據自身情況設置一個相對合理的值，如果數值低於10%或者無法完成，這種特例需要上報到高層管理批准。

由於 OE 目標是來自 Bezos 的要求，而且還作為各級管理者績效考核的內容，因此，系統問題的數量、趨勢，以及嚴重問題的事後分析會被每周的管理會議過問。

亞馬遜的事後總結與分析的方法稱 COE（Correction Of Error）。其通過識別問題的根本原因並追蹤識別的行動項來解決這些問題，從而提高服務（或系統）的整體質量並推進負責團隊的責任。

需要注意的是，COE 不是尋找問題責任人並進行處罰的過程！

COE 在形式和作用上類似 Google SRE 的事後分析，內容包容如下部分：

簡要描述出了什麼問題

問題對業務和客戶的影響

整個事件的時間線

通過 5Whys 給出問題根本原因的詳細分析

經驗教訓

糾正措施

行動項

通過 COE，研發團隊可以識別出問題的根本原因，並通過可追蹤和交付的行動項來解決問題的根本原因，最終，我們要防止問題再次發生。

而且，在這個過程中，我們需要將分析得到的經驗保留下來並與其他人分享。

總結一下：

通過 OnCall，研發人員可以切實地感受到系統問題帶來的影響，併產生解決問題的動力。

通過 OE，在制度上保證了運維工作在合理的範圍內，並且推動系統和團隊持續優化。

通過 COE，研發人員可以識別根本問題，並關注長期解決方案的落地。

讓研發人員直接負責在線報障可能是快速提高業務服務水平和系統質量的最好方法了。

我曾在兩個創業公司內嘗試建立由開發人員負責運營維護並進行 7x24 OnCall 的制度。

在第一家公司，其後來負責研發的老大認為應該保護研發團隊——運維的痛苦應該找專門運維的人員來負責。

最後，系統中的問題總是周而復始的重複出現。在第二家公司，我們為此建立了整個流程和支持工具，如下圖，效果真是誰用誰知道！

組織結構與 2 Pizza Team

2002年左右，亞馬遜進行了其最為知名的一次組織和架構的調整。經過此次調整，亞馬遜在系統架構上從直接共享數據訪問的單體應用逐步調整到基於服務的 SOA 結構，在組織上則逐步轉變到以小團隊為基礎的複合型組織結構。【注20】

這種小團隊就是我們常說的 2 Pizza Team，關於 2 Pizza Team 的來源，可以參考 Fast Company 寫的 Inside the Mind of Jeff Bezos，這裡摘錄如下。

One of Bezos』s more memorable behind-the-scenes moments came during an off-site retreat, says Risher.

「People were saying that groups needed to communicate more. Jeff got up and said, 『No, communication is terrible!』 」 The pronouncement shocked his managers.

But Bezos pursued his idea of a decentralized, disentangled company where small groups can innovate and test their visions independently of everyone else.

He came up with the notion of the 「two-pizza team」: If you can』t feed a team with two pizzas, it』s too large. That limits a task force to five to seven people, depending on their appetites.

網上有關 2 Pizza Team 的文章很多，對其好處分析的比較詳細，我們在這裡不再多費鍵盤。從結果上看，小團隊還帶來了其它兩方面的好處：

其一，當業務系統按功能（或具體業務）分配到 2 Pizza Team 時，其所能處理的問題規模和複雜性將是有限的。

同樣的，團隊所要面對的架構問題的規模和複雜性也就相應的降低了——這正是探討人人都能做架構時，我們說的通過團隊劃分來降低問題規模。

其二，當人數變少後，官僚主義就很難發展起來，整個團隊更容易形成積極、自治的氛圍。

這也不難理解，在一個結果導向的角鬥士文化氛圍中，如果有人混或搞權謀的話，團隊就很有團滅的風險——不管你是不是自認為做了正確的事情。

以下是來自網路的一幅圖，大致描述了亞馬遜轉變後的組織結構。

在這種組織結構下，亞馬遜按業務線對組織進行垂直劃分，而技術通常在業務線內，如下圖【注21】。

業務線進一步劃分常常按業務+地區，而技術團隊通常會負責全球支持。

因此，技術團隊的進一步劃分通常會根據業務的需要按業務或者按系統。業務與技術的匯總一般發生在 VP 層，有時會在 Director 層。

另外值得一提的是，2 Pizza 團隊的原則適用於組織層級中任何部分，如果某個 Director 直屬人員過多就會進一步拆分，當然也會有特例。

這樣的劃分使技術團隊能夠專註解決對應業務的問題，或者說這是業務驅動技術在組織結構上的體現（或者說業務優先）。

由於此時團隊規模通常在 7+/-2 人，所以一般不會有特別複雜的工作，而有關業務的設計決策將在團隊內部消化。

這樣劃分的另一個好處是技術人員，尤其是技術團隊的領導，會對業務非常熟悉，因此，一些業務團隊的高層領導（Director 和 VP）都是從技術線上去的！

但一個具有挑戰性的結果是團隊增多，一個業務性的需求可能需要不同的團隊配合才能發揮作用，此時團隊的協調將是一個問題。

亞馬遜是通過計劃流程（Operation Planning）來幫助團隊在戰略性層面解決工作安排的問題，我們隨後討論。現在，我們先看看技術團隊和業務團隊要如何合作？

如上圖，技術團隊和業務團隊的合作並非經由上層協調，雙方主要的溝通都是團隊之間直接的水平的溝通，也就是說，在基層，需求、問題和日常交流都是由業務團隊直接反饋給技術團隊的負責人。

另外，在各個層面上都會有對等的水平溝通，向上的彙報機制主要用來反饋問題或者彙報業務進展情況。

讓我們看看需求提報後會的處理方式，如下圖。需求提報上來後，通常是接收方（團隊）來識別所依賴的外部系統，但這個工作會涉及很多溝通和對高層視圖（尤其是業務過程）的了解。

有時，業務人員可以幫助技術團隊識別被依賴的業務團隊，有時，技術團隊可以將這部分工作交給 TPM，但更多的時候，需要負責的技術人員自己搞定。

依賴一旦被識別出來，技術團隊將發揮完全的 Ownership，與相關技術團隊合作，推動功能最終實現。

OP1 & OP2

無論是團隊層面還是公司層面，產品和功能要進入開發前必須回答下面這些問題：

為誰做

為什麼做

做什麼

什麼時候做

怎麼做

從業務的角度看，產品計劃的一些工作需要指明前進的方向，在項目啟動階段，亞馬遜的研發經理或者業務經理會承擔一部分產品的職責，他們會通過新聞稿的形式來嘗試回答這些問題。

有關新聞稿的更多信息，可以參考 Chris Vander Mey 的《谷歌和亞馬遜如何做產品》。

團隊拆分後，業務性的需求可能需要不同的團隊配合才能發揮作用。計劃的過程中一個重要的工作就是識別出依賴團隊，並將自己的需求加入到依賴團隊的計劃中。

亞馬遜使用的方法是 Operation Planning。

這個 Operation Planning 一年要進行兩次，年初2月份左右一次，這是 OP1；

年中8月份來一次，對 OP1 做整理檢查同時增補一些新的需求，這是 OP2。

制定 OP 的過程，整個亞馬遜的團隊——從業務到技術都會動起來，將業務要做的事情、技術想做的創新和技術要填的坑都提出來，尤其是需要其它團隊配合的事情，要提到對方團隊的 OP 中。

這些集中在一起的需求經過研發和業務的商討細化、確定定優先順序和評估工作量後，排出一個大計劃。

這個計劃再按各自彙報線（業務和研發有各自的OP）向上匯總，逐級PK，最後匯總到姐夫那裡。

如下圖，是OP1計劃的一個示例，圖中文字故意模糊。值得注意的是，這個計劃中包含了優先順序、工作量估計、外部團隊依賴、初步業務價值的判斷、預計的交付時間等信息。

計劃表上部的小表格會自動計算出完成各優先順序項目累計需要人員的數量情況，並與當前人員數量對比，為接下來人員招聘的數量提供一個初步的建議。

在實際執行 OP1 和 OP2 的過程中，業務團隊仍然會有臨時需求，甚至是自上而下來自 Bezos 的需求。這些需求（除了Bezos的）都會由業務和技術團隊溝通，並依據其業務價值來與 OP 上的需求進行比較，進行計劃的調整。

亞馬遜的計划過程並不適合創業公司，但具有啟發意義：

在產品開始前，需要確定產品的用戶、策略、範圍等，除了新聞稿這種方式，還可以參考《用戶故事地圖》或者《敏捷武士》中的方法，這些方法更適合規模中等的互聯網產品的研發。

我們需要為產品的演進做一個中長期的計劃。

我們需要為產品的實現做迭代計劃。

我們已經談及通過組織結構層面的調整來簡化架構的複雜性，也了解了通過工具和服務封裝支持性架構和開發運維工作來降低研發工作的複雜性，接下來我們看看架構工作是如何在研發人員之間分配的。

SDE的職級、責任，以及其它角色

亞馬遜有一個內部文檔，其詳細地列出 SDE1 到 Senior Principal 各級的軟技能和硬技能的要求，以及從一個級別到更高一個級別要做的事情，以便研發人員自行對照修鍊。

如下圖，我們簡單地分析了各個級別所屬團隊、共享情況、職責和影響力。由於亞馬遜沒有專門的架構師團隊。

而且亞馬遜期望所有人都能進行架構工作，因此，越高級的技術人員就需要儘可能在這方面發揮更大的作用，可以說能力越大，責任越大。

雖然 SDE3 以上的研發人員需要隸屬於某個業務部門，但他們已經是某種程度的共享資源，其工作安排的順序是從部門內到部門外。

雖然其工作重心可能不再是專門實現小團隊量級的業務需求，但其依然會參與其中，尤其是在關鍵項目的攻堅上。

對於 Principal，他們常常會做一些前沿性的探索和開發工作，比如，AWS 上無比好用的 SWF（Simple Workflow）就是一個 Principal 帶領 SDE3 做出來的。

對於 SDE3 以上的技術人員，公司層面會有一些附加性的職責，如設計評審、輔導新人和傳播理念。

就 Principle 而言，亞馬遜有一個稱為 Principle Talk 的定期分享，Principle 會被要求講一下他目前從事的工作中的一些新的技術和想法。

對於設計評審，現有功能的擴充通常不需要進行設計評審，新功能的設計評審通常在團隊內部完成。

當涉及的業務影響比較大或者技術上有一定的挑戰時，團隊經理會在本部門內（通常是沿組織結構向上）尋找高級別的技術人員對設計進行評審，偶然也會跨部門找某些領域的專家來進行評審。

雖然偶爾需要刷臉或者需要更高層面的管理者介入協調，但研發人員通常是比較熱心的——一封言辭真切的郵件就足夠了，再者，作為亞馬遜人，在Ownership的名義下臭不要臉是必須的！

日常工作中，還有幾個角色常常與 SDE 打交道，他們是 SDM（Software Development Manager）、TPM（Technical Program Manager）和 PM（Program Manager），亞馬遜對 SDM 和 TPM 有技術性要求，也就是說，他們需要懂編程和設計。

所以，當你在亞馬遜辦公室漫遊時，看到一個SDM抱著一堆AWS產品的技術說明文檔啃，這是一點都不奇怪的，因為他們要上雲了。

亞馬遜的 SDM 首先是 People Manager，還是 Project Manager，甚至有時還要做 Product Manager，這也算是一人多能的表現。

對於 TPM，具體看團隊的要求，他們通常是懂技術的 Product Manager——會畫原型，有時會做 Project Manager——可以幫助團隊識別被依賴的團隊，甚至和這些團隊確定介面細節，以及推進項目前進。

PM就是我們常說的業務人員，這些人常常可以自己根據需求畫出產品原型……

架構，民主還是集權？

架構工作的一項內容就是對不同解決方案的進行選擇。這種選擇即可能涉及業務層面，也可能涉及技術層面。系統的架構更多是技術層面上的選擇。

不難理解，技術層面的某些問題具通用解決方法，相對應的，這些方案就成為一些固定的（或推薦的）選擇，如下圖所示，這些方案在專制水域。

經驗告訴我們，專制帶來效率上的優勢，但同時抑制了創新。

那麼，在一個公司內，如何讓這樣的選擇簡單高效，但又不會抑制創新？

在公司範圍內，亞馬遜對一些關鍵的技術架構做了強制或推薦。

比如，RPC 必須用 Coral，定時任務應該用 DJS（Distributed Job Scheduler），工作流推薦用 SWF，消息中間件推薦 SQS 等等。

有時，同樣的問題可能會有多個框架在專制水域，它們各自可能對某些特定情況有更好的表現。

相對應的，在各團隊內部，其系統所用的語言、框架都可以自行確定，甚至對重新發明輪子也會足夠寬容。但如果系統的影響較大，而且使用了非推薦的技術，那麼在設計評審時就必須用證據來說服參與的人員，尤其是那些高級別的SDE——他們經常會問為什麼不用某某已有的技術。

某些情況下，當某個團隊的某項工作被證明有更為廣泛的影響時，這些工作會從民主水域上升到專註水域，成為公司範圍內的推薦解決方案。

比如，SWF 最初只是一個 Java 的庫，後來在業務中被證明可以極大地簡化開發工作，其不但成為 AWS 上的服務，還成為公司內工作流推薦解決方案。

知識共享

如前所述，軟體的開發過程就是一個學習的過程。每一天，會有大量的問題產生，每一天，會有大量的知識累積。利用好這些知識將會極大地節省後來者的時間。比如，亞馬遜會將歷史上遇到的問題做成視頻供大家觀摩學習。

亞馬遜一直重視知識的積累和共享工作。這裡我們簡單地介紹一下：

WIKI：這是整個知識系統的核心，所有和業務、系統、流程有關的信息都按某種固定的格式書寫下來，方便閱讀和分享。

郵件列表：亞馬遜的郵件列表是一個開放服務，每個人都可以創建，一些固定的郵件列表用來在公司範圍內尋求幫助，比如 Linux，Java 等等。

SAGA：一個類似 StackOverFlow 的內部問答社區，用來替代郵件列表的問答功能。

Broadcase：一個類似 Youtube 是內部視頻分享網站，這裡可以查到所有Bezos的內部講話、Principal Talk，或者是某些系統的培訓。

Community：亞馬遜內部的技術社區，維護了內部的一些開源項目和討論。

Amazon Patterns：UI設計的規範，各個產品線可以給出自己的規範和使用指南。

Issues：一些業務性問題的跟進工具，也可以做類Scrum的項目管理工具，其用來取代 JIRA 和一部分 Ticket 系統的能力。

OminSearch：代碼搜索工具，方便 Copy/Phase 別人的代碼。

CodeBrowser：代碼瀏覽工具。

Simple Search：內部搜索工具，可以搜索 WIKI、郵件列表、Issues.

由這些工具還可以看出亞馬遜對代碼的態度，除了某些關鍵性項目，亞馬遜並不限制員工查閱和學習其它團隊的代碼。

從某種意義上看，亞馬遜對數據的態度則更為嚴格，曾有瀏覽核心數據直接走人的先例。

另一點就是，支持性工具始終處於不斷演化的狀態——內部支持性系統和工具也是這樣，隨著規模擴展，更高效和易用的工具會被創建以便提升研發人員的效率。

比如 Simple Search，在12年左右推出，可以同時搜索亞馬遜內部3個主要的知識庫。

最後，亞馬遜無論業務和是研發，其對工具和自動化有著與生俱來的痴迷。根據不完全統計，其內部用於研發和管理的工具總計有近50個，這些工具多數是自研的，而且多數都在日常工作中使用。

至此，與研發效率直接相關的方面大致都已涉及，接下來我們聊聊亞馬遜內部一些有趣的事情，他們有些間接地影響了研發效率。

Good Intention Doesn』t Work，Mechanisms Work。

在 2008年2月的全員大會上，Bezos 分享了這個想法。這中間最有趣是，Bezos 談到他和亞馬遜客服團隊參考豐田 TPS 中的安燈拉繩創建了客服安燈拉繩的故事。

這個故事的細節在前同事張思宏的《亞馬遜的成功其實很簡單，但你就是做不到！》中有詳細的描述，強烈建議大家學習一下，由於篇幅，我這裡就不再贅述。

這個故事給我們的另一些啟發是：作為公司高層的 Bezos 對效率的持續關注和對新知識的了解。

就我的了解，亞馬遜在2008年之前已經實踐過 ToC 和 Lean，而且是得到老闆親自關注的，這就是我常常調侃的——你們公司效率低是因為你們老闆效率低。

另一點就是亞馬遜那種面向問題解決問題的文化，在這種文化下，亞馬遜很少談論概念。

平台化（Platform）與自服務（Self-Service）

在亞馬遜工具研發中——對內和對外，自服務和平台化的特點是其重點關注的特點，這方面 John Rossman 在《The Amazon Way》的附錄中有兩篇文章涉及，建議讀者朋友研究一下，下面摘錄了其中 Bezos 對自服務的看法。

「I am emphasizing the self-service nature of these platforms because it is important for a reason I think is somewhat non-obvious,」 wrote Jeff Bezos in his 2011 Letter to Shareholders.

「Even well-meaning gatekeepers slow innovation. When a platform is self-service, even the improbable ideas can get tried, because there』s no expert gatekeeper ready to say, 『That will never work!』 Guess what? Many of those improbable ideas do work.」

Day 1，還是 Day 2？

在 Bezos 1997年的股東公開信提到了 Day 1 的概念，在2016年的股東公開信談到 Day 2，有興趣的可以深入了解一下 2016 Letter to Shareholders、2016 Letter to Shareholders。

另外，《The Amazon Way: 14 Leadership Principles of the World』s Most Disruptive Company》中也有解釋。

結語

亞馬遜的研發有什麼特點呢？

它有著一種鼓勵競爭的角鬥士文化。

它通過一整套機制找到符合文化的合適的人。

它通過工具不遺餘力地簡化研發工作的複雜性。

它通過組織上的制度促進自治的小團隊。

它鼓勵試錯。

它讓研發人員儘力完成一切工作。

它專註於持續改進。

它毫不憐憫地讓研發人員親自體驗運維繫統的痛苦。

它面向問題，尤其是根本問題。

它熱愛數字，通過數字來管理和說明一切。

它理解偉大的創新多來自掌握技術的研發人員，因此，它要建立尊重工程師的工程師文化。【注22】

行文倉促，還有一些話題沒有涉及，有一些也沒有深入，如績效評價 OLR 和 Dog Fight、Engineering Excellence、工具鏈等等，期望未來可以更深入的思考和總結。

亞馬遜有一個內部宣傳標語：「Work Hard，Have Fun，Make History！」。

我們常常調侃說只需要 Work Hard，其它兩條可以忘記。但離開亞馬遜兩年後，卻發現亞馬遜對自己的歷練和改變如此巨大……

最後，以《The Everything Store》中的 Bezos 的話紀念我和一幫前同事在亞馬遜的日子：

你可以超時工作、勤奮工作、動腦工作，但在亞馬遜，你不能三選二。

注釋

注1：由於自2015年，亞馬遜開始連續盈利，這樣的質疑聲已不再，現在沒有人懷疑亞馬遜是21世紀的商業巨人（the titan of twenty-firstcentury commerce）。

注2：Bezos 和 Jobs 都是臭名昭著的壞老闆，屬於經常咆哮（yelling）和羞辱下屬的人，請從以下金句中領會：

「Are you lazy or just incompetent?」

「I』m sorry, did I take my stupid pills today?」

「After an engineer』s presentation: 「Why are you wasting my life?」」

注3：Rossman 在這裡解釋了飛輪中的Growth部分，這源自 Bezos 對互聯網的判斷，他認為「it』s still Day One of the Internet」，「the Internet』s potential for growth is gargantuan and still fundamentally unexploited」。

因此，「So he』s ready to slash prices and create programs like free shipping to cultivate customer loyalty and drive sales growth toward the unimaginable heights he foresees. Then he invests the revenues generated back into 「the holy trinity」: price, selection, and availability 」

注4： 複雜的商業系統背後，其本質往往是簡單的，只有騙局才故作高深並且無比複雜；與之類似，研發體系的整個基石梳理到最後往往也很簡單。這裡所謂的複雜是指 complex，比如，供應商入駐過程會涉及十幾個系統的對接，其過程可以說非常繁雜（complicated），但其原理卻並不複雜（complex）。

注5：所有的公司都有企業文化，最不濟也是老闆文化！

注6：不要以信眾的數量來評判一些互聯網大V言論的正確性，因為蕭伯納說過，「瓜慫雖傻，但還有更傻的『瓜慫』為其喝彩！」

注7：這也提醒我們獨立思考的重要性，盡信書不如無書！

注8：國內有個定期刷屏的類似理念——人品比能力更重要。

注9：John Rossman 在《The Amazon Way》中則將 Bezos 的性格特點與亞馬遜的領導力準則（Leadership Principle）建立起對應關係。

注10：幻想狂劉先生這篇《識得這個老媽否—淺談太平天國的特色修辭發明學》讓人從側面看到語言對組織的一些另類影響力。

注11：國內的互聯網媒體上經常刷屏的一個流行詞就是不忘初心，我覺得 Bezos 在行動上算是這方面的典範，每年的致股東的公開信都要附上1997年的股東公開信。

國內馬雲也是有心人，你今天都能看到當年馬校長推銷中國黃頁的視頻。各位，買好錄音筆和攝像機，用得上！

注12：調侃一下我的另一個前東家，自12年某個平台將其評為最難的面試公司之一後，其後每年的市場文章都會時不時的拿這個出來撩撥一下。

注13：面試官在完成自己的反饋之前是無法看到其他人的反饋情況的，這樣做避免了面試官之間相互影響判斷。

注14：我之前在內部分享中有看到將 SDE 稱為 System Development Engineer，其實我覺得這個定位似乎更為準確。

注15：在互聯網高速發展的大背景下，一切都需要快起來。國內有兩個類似的理念，一個是互聯網唯快不破，另一個是這兩年流行起來的搞定，這個搞定其實就是問題解決的能力、責任感與執行力的結合。

注16：我第二喜歡的胖子，我技術上的精神導師……

注17：ABB 代表如下系統：

Apollo：服務部署系統。關於 Apollo 的信息可以參考

Brazil：包構建系統

BSF：第一代RPC框架。Steve Yegge 在 Google+ 上著名的吐槽中，誇獎的就是 BSF，但是他吐槽的時候已經離開亞馬遜幾年時間，那時 BSF 已經被新一代的 RPC 框架 Coral 替代，所以有些亞馬遜的員工用這個調侃了他。

現在整個工具鏈主體是ABCP，P代表了持續部署的Pipeline。有關亞馬遜交付系統的信息可以參考一下，本文不會深入講解這些系統的原理。

注18：由於亞馬遜業務上的訴求更重要而且更頻繁，相比較，高並發和穩定性這樣的要求只有極少數面向大量用戶的系統需要，如 Retail 網站，因此，Google 的 SRE 制度是不可能從亞馬遜這樣的公司產生的，而且當 Apollo 和 Coral 這樣的系統和工具就位後，大多數高並發和穩定性的問題的處理會變成簡單的操作性問題。

在資源維護的層面，亞馬遜應該有類似 Google Borg 這樣的分散式資源調度系統，不過從應用開發和維護的角度看，在系統雲化後，這種調度反映出來的服務就是 ASG（Auto Scaling Group），至於資源的切換和物理機的管理，對 SDE 則是完全透明的！

注19：亞馬遜內部的在線報障被分成1-5級，數字越小問題越嚴重，只有Serv1 和 Serv2 的問題才會通知 Oncall 人員並要求快速處理。

如果不巧你沒有在指定的時間響應，那麼 Serv1 的問題會通知 Bezos，而 Serv2 的問題則會一路上報到 VP，恭喜你，這個時候整個世界都在找你，即便你的經理找到人解決，你還是要複製之後的跟進和事後問題分析，當然你還要表達必要的歉意。

1-4級的ticket都有對應的SLA，相應的績效數據會被定期分析。

注20：傳說中，2002年，Bezos給全公司發了一封信，吹響了整個架構演進的號角：

從今天起，所有的團隊都要以服務介面的方式，提供數據和各種功能。

團隊之間必須通過介面來通信。

不允許任何其他形式的互操作：不允許直接鏈接，不允許直接讀其他團隊的數據，不允許共享內存，不允許任何形式的後門。唯一許可的通信方式，就是通過網路調用服務。

具體的實現技術不做規定，HTTP、Corba、PubSub、自定義協議皆可。

所有的服務介面，必須從一開始就以可以公開作為設計導向，沒有例外。這就是說，在設計介面的時候，就默認這個介面可以對外部人員開放，沒有討價還價的餘地。

不遵守上面規定，就開除。

注21：這裡會有看似的特例，比如負責內部支持性工具開發的組應該是隸屬於 Engineering Excellence 的，但其實他們的業務就是服務內部開發。

注22：顯然，亞馬遜並不在意你的工作和生活的平衡，它只是尊重你的想法和工作成果，當然一切看結果。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！