我是一名軟件工程師，最近剛剛從亞馬遜跳槽到 Uber。我曾在亞馬遜公司的多個部門與地區工作了六年半。在剛剛入職的這一個月裡，我在西雅圖的 Uber 數據研發部門效力。

之所以寫下這篇文章，是為了回答我的朋友和同事們提出的問題——“在亞馬遜與 Uber 工作有什麼不同？”

本文不打算討論什麼

一家企業中的工程文化很難進行大致界定，因為其中的每一個團隊與組織都是獨一無二的。本文中提出的結論，只是基於我在與特定團隊及組織合作中的觀察，可能並不代表公司整體的文化。

本文與我的跳槽決定無關，所以這篇文章也不應被解釋為優劣的比較。

從亞馬遜到 Uber

兩家企業的工作文化之間既存在不少共性，也有諸多差異。其中一些可能與公司的規模有關，而另一些則源於企業自身的固有 DNA。這裡，我將概述自己發現的一些重要區別。

DevOps 負擔

DevOps 負擔可謂無處不在。在不妨礙快速創新與持續生產發佈的前提下，努力保持服務的高可用性一直是個難以解決的問題。對於亞馬遜及 Uber 這樣的大規模運營實體而言，情況自然變得更加複雜。兩家公司都專注於實現卓越運營，不過亞馬遜長期以來已經建立起解決問題的成熟流程，而 Uber 則仍在實驗哪種策略最適合自己。

亞馬遜給軟件工程師設定的運營負擔那是出了名的沉重（具體請參閱文尾旁註 1），包括全天候值班以及技術支持待命等等。但在我看來，實際上每家企業都需要面對那些高度造福一方系統可靠性的客戶，Uber 也不例外。因此，配合新興平臺的快速增長以及結構鬆散的運營流程，Uber 的 DevOps 負擔一點也不比亞馬遜輕，甚至可能還要要更重一些。

開源

在剛剛加入 Uber 時，開源軟件的廣泛使用成為我最大的驚喜。Uber 是一家開源優先型企業，這一點直接反映在其內部工具與技術的選擇上，也體現在 Uber 令人印象深刻的社區回饋記錄中（詳見旁註 2）。

圍繞開源技術構建內部基礎設施的作法，使得開發人員能夠自由選擇適合工作內容的工具，從而將主要精力集中在解決需要創新的業務問題身上。這也意味著我們能夠在互聯網上建立起多元化的開發者網絡，以幫助企業解決第三方庫調試問題時遇到的困難。相比之下，亞馬遜則更多依靠內部開發的基礎設施與工具，這雖然縮小了選項範圍，但同時也限制了遇到問題時可用支持選項的數量。

Uber 公司不會親自構建每一款開發者生產力工具（例如用於監控、儀表盤、分頁以及招聘等等），而是從提供軟件即服務的廠商處獲取各類方案。這些擁有專項產品組合的小型企業傾向於提供專長範圍內的最佳軟件，這種少而精的定位為 Uber 提供巨大幫助。作為開發人員，我們能夠用到最新、最好的工具，提高自己的工作效率並改善軟件開發生命週期。此外，這也能讓開發人員專注於軟件開發本身，進而解決 Uber 所面臨的獨特業務與功能問題。

透明度

在 Uber，我們每週都會組織一次領導層碰面會，各位高管在這裡回答員工們提出的問題。除此之外，執行鏈中各個層級的人員也都會定期與員工溝通。

作為開發人員，我們通過這種制度瞭解影響到我們自身以及相關工作的決策及其背後的理由。這有助於我們將自身與公司目標緊密聯繫起來，保證將精力投入到正確的問題當中。此外，這種方式還能夠讓軟件工程師瞭解到所在團隊或組織之外，企業面臨的其它挑戰。再加上對文檔記錄的高度重視，員工將有機會深入瞭解每項“理由”的答案。利用這些“理由”，我們可以更具體地指導自己做出的任何一項決策（無論是否與技術有關）。這裡假設一個場景，如果我的問題是“Uber 為什麼傾向於利用 Go 替代 Java？”或者“為什麼我們的組織結構是現在這樣？”那麼答案都能從對應的文檔當中找到。

這種極高的透明度（無論是否與技術有關）確實令人耳目一新，而且能夠幫助剛剛入職的新人快速瞭解現有基礎狀態。相比之下，亞馬遜的透明度機制則受到嚴格控制，員工只能接觸到自己有必要了解的信息。

告別 AWS

我很懷念在亞馬遜的那段能夠一鍵使用自動擴展、全託管 MySQL 兼容數據庫的日子。其實在 AWS 工作那會兒，我沒有真正意識到雲基礎設施即服務（IaaS）為軟件工程師開發生命週期帶來的寶貴便捷性。而在 Uber，使用雲服務是有代價的——我們當然可以選擇任何技術完成工作，但首先需要證明與自主管理 / 開發帶來的成本相比，選擇雲服務解決方案的成本確實具有優勢。

工作場所內的社交互動

由於 Uber 公司西雅圖辦公室的員工不多，所以工作場所也顯得比較緊湊，我會接觸到很多所在團隊之外的員工。午餐時間的社交活動與專門的文化交流，幫助我很快融入到這個團結而統一的集體當中。相比之下，亞馬遜公司的主體運營單位是小型職能團隊，我的社交互動也僅限於”雙披薩團隊“之內（除非你刻意參加公司範圍內的其它社交活動，但必須得說，這類活動總是「人滿為患」）。

工程技術挑戰

兩家公司在工程技術挑戰方面倒是沒什麼區別。無論是在亞馬遜還是在 Uber，受到規模與可用性要求的影響，我們都得面對現有解決方案無法解決的業務用例（在某些領域中，AWS 的要求可能比 Uber 還更高一些）。雖然兩家公司的具體業務問題可能有所不同，但從工程技術的角度來看，難題仍有共通之處：需要設計的系統必須規模更大、性能更強、使用更便捷，而且在速度上優於現有解決方案。這些解決方案專為滿足企業內複雜而多樣的具體業務用例而量身定製。二者最大的不同，可能在於負責解決實際問題的工程師數量。在亞馬遜需要一個”雙披薩團隊“處理的問題，在 Uber 這邊可能只需要一名開發人員。

參與制定戰略決策與路線圖

在亞馬遜，這方面工作主要取決於員工所在組織的定位，以及行政領導層設定的職能方向。我就遇到過那種自上而下貫徹的硬性項目，要求我們在工程技術圓桌討論中為產品制定未來 2 到 5 年的發展計劃。在 Uber，我所參與的每一個內部產品相關決策都只由自己把控，包括確定現有差距到定義成功指標等等。我在 Uber 的供職時間還不長，但能感覺到這似乎是組織中的運作常態（這是一種平臺型組織，而非產品型組織）。總而言之，與亞馬遜相比，Uber 的員工擁有更多自主權。

遠程辦公條件

在亞馬遜，我曾經在西雅圖總部工作，能夠在 10 分鐘之內與所有利益相關者、合作伙伴以及上游合作伙伴進行當面交流。但在 Uber，這些利益相關者以及合作伙伴則分佈在不同地方。雖然跟我在兩家公司的具體職位有關，但這樣的變化確實給我的工作方式帶來了很大影響。對於遠程合作伙伴與利益相關者，我們往往需要付出更多精力才能完成協同。視頻通話不可能完全取代現場會議與面對面交流。偶爾進行的跨辦公室溝通，也不像大家身處同一辦公空間內直接喊話那麼輕鬆自然。

創新活動

Uber 公司鼓勵軟件工程師們在與本職工作以及團隊章程無關的領域內尋找並解決問題。如果大家發現了一個能夠讓 Uber 受益的工程問題，那麼管理層一般會允許你花點時間解決這個問題——即使其與你的日常工作沒啥關係。相比之下，在亞馬遜我們甚至很難理解其他部門面臨著哪些挑戰。因此如果不是真的被調派到其他團隊當中，那麼幫助對方解決問題基本上沒有可行性。

午餐 / 辦公室裡的零食（非常重要）

亞馬遜方面並不為員工提供免費午餐，辦公室裡也沒有能買到健康午餐的那種咖啡吧；Uber 則提供免費午餐以及全天候的美味點心。雖然乍看起來這麼一點小差別在企業整體運營中似乎無關緊要，但根據我的切身體會，在辦公室裡吃午餐再隨時配上點小零食，確實提高了我的工作效率。畢竟在餓了的時候，我用不著跑到擁擠的市區餐廳花上半個小時只為吃點東西。

總結

在完成了自己的新人過渡之後，我已經積累了不少關於 Uber 特色的經驗，並意識到這家公司特別注意將核心價值觀 / 原則滲透到日常工作當中——這也正是亞馬遜所擅長的。作為開發人員，這些原則有助於推動決策流程，並使整個組織擁有更為統一的視野。當然，我還在繼續學習，並將在後續的文章中不斷分享這些心得體會。

旁註 1：雖然非常辛苦，但全程跟進歸屬於我的系統絕對是整個職業生涯中最有意義的經歷。這敦促我從頭開始編寫出能夠良好且安全運作的系統，我認為每一家企業都應該採用亞馬遜的這套呼叫與運營流程模式。

旁註 2：參與的社區包括 Cadence、M3、Ludwig、Fx 以及 Marmaray 等。

原文鏈接：

https://medium.com/swlh/amazon-to-uber-from-the-lens-of-a-software-engineer-e5bd1c38caba