編譯：深潮 TechFlow

注：本文收錄於深潮 TechFlow 專題《YC 創業課中文筆記》（每日更新，本篇為該系列最後一篇。），致力於收集整理 YC 課程的中文版本，第二十五篇為亞馬遜技術長 Werner Vogels 的線上課程《對技術和初創公司的經驗和見解》。

加入亞馬遜之前

在加入亞馬遜之前，我是一名學者，曾在康奈爾大學進行了十年的研究科學工作，並建立了大規模的分散式系統。在那之前，我並不是一個典型的電腦科學家。直到28歲才做出真正決定回學校深造。之前，我在醫院從事放射治療的工作，為荷蘭癌症研究所的癌症患者提供放射治療。有一天，我突然意識到我無法忍受身邊的人們一個個離世，於是我決定做一些與此毫無關聯的事情。電腦科學似乎是一個很好的選擇。

當時是80年代中期，電腦科學並不像現在這樣普及。但是，事實證明我擁有了一項天賦，雖然那時我並不知道。於是我開始深入研究，因為這正是我真正感興趣的領域。我獲得了博士學位，在葡萄牙的一個研究機構工作了幾年，然後受邀加入康奈爾大學。

在我在康奈爾大學期間，除了研究工作之外，我還經常諮詢像惠普這樣的大公司，以及其他我無法聽清的一些公司，並參與各種會議。有一次，亞馬遜邀請我介紹我正在研究的一些材料。一開始我感到有些意外和困惑：真的嗎？我需要去做這個嗎？

在當時，網路瀏覽和資料庫是多麼棘手的問題嗎？然而，當我開始上手時，我才意識到這其實是一個巨大的技術挑戰。亞馬遜不僅僅是一家零售商，它是一家技術公司，經營規模之大，我之前從未見過，也絕對不是我曾諮詢過的其他公司可以相提並論的。從分散式系統研究的角度來看，他們面臨的挑戰是驚人的。

當亞馬遜給我提供工作機會時，我毫不猶豫地接受了。

亞馬遜的規模運營與技術領先

我認為大多數分散式研究人員已經認識到這些大公司需要以何種規模運營，甚至不僅限於這些大公司。無論是網際網路公司還是數字公司，要想成功，都需要以巨大的規模運營。

回顧2004年，當我加入亞馬遜時，許多人可能會發現以當時亞馬遜的規模來運營是相對容易的。但這並不意味著你可以依靠一份職位或必不可少的基礎設施。因此，在雲技術和其他技術方面做出了很多工作，確保能夠充分利用它們提供的優勢。

亞馬遜在2004年只通過實踐就達到了一定規模，並沒有書籍或指南可以闡明如何建立可擴充套件的組織或公司。因此，我認為亞馬遜在技術應用、技術發展和運營規模方面走在曲線前面，領先了5到10年。這對於追求快速發展的公司尤為重要。

如果你希望成為一個快速發展的公司，你不能像傳統企業那樣。傳統企業往往面臨創新者的困境，一旦某些事情取得成功，就會變得非常緩慢。

如何建立一個持續快速發展的公司是完全不同的故事，你必須仔細權衡業務。例如，是否創造技術債務或容忍一些重複發生的事情，這在傳統企業中是不可行的，因為效率是它們的主要目標。

在亞馬遜，速度快、創新速度快，並且有著長期的實驗管道，這是最重要的。因此，你願意容忍一些重複發生的事情，允許產生一些技術債務，只要你知道必須還清它。

因此，在傳統的MBA書籍中，很難找到亞馬遜願意做出的這些折衷。大多數情況下，亞馬遜必須自己發展技術、流程和業務流程。當然，有傑夫·貝索斯這樣具有遠見的領導者，他真正瞭解未來的形態和現代世界應該是怎樣的。

實現增長的關鍵

儘管亞馬遜已經在規模上取得了巨大成功，但我們仍面臨著實現更大增長的挑戰。為了邁向下一個增長階段，我們需要更加嚴謹地思考和行動。

一個例子是效能方面的問題。如何度量效能？我們需要怎樣的基礎設施來進行測量？要成為一個真正的資料驅動公司、做出資料驅動決策，首先需要擁有資料，並建立一種文化，圍繞如何評估和解讀這些測量資料。

即使網頁載入時間稍微延遲1.2秒，也會對客戶體驗產生負面影響。這只是說明了50%的客戶體驗變差，你需要了解情況有多糟糕。從工程角度考慮，像99%或99.9%的控制也變得更加重要。然後，你需要建立一個能夠真正掌握99%工程學科的機制，並將其與業務決策聯絡起來。

我認為在2004年，我們的可靠性相當高。有一些規則約束著我們，比如我們必須使用特定區域（SEA）的資料中心。無論你對這些SEA資料中心做了什麼操作，都需要在其他資料中心進行復制，這樣即使一個資料中心出現故障，客戶也不會受到影響。

雖然客戶可能會受到延遲的影響，但功能並不會受到影響。我們在處理所有這些規則方面非常擅長，直到有一天我們決定斷開其中一個資料中心的連線，看看會發生什麼。只需稍微調整網路，就可以將一個資料中心與其他資料中心隔離開來。

然而，實際上，所有這些在紙面上看起來都很好的東西，在實踐中並沒有像人們想象的那麼順利。雖然在首次嘗試時還存在很多手動過程，例如手動資料庫故障轉移，這一年我們一直在進行預演。而當你進行第三或第四次執行時，你實際上已經達到了幾乎可以在沒有人工干預的情況下自動化執行的程度。這對於確保系統的高可用性和容錯性至關重要。

在我們的努力中，我們還注重發展資料分析和洞察力。亞馬遜擁有大量資料，但如何從中獲得有價值的見解是一個挑戰。我們致力於構建強大的資料分析工具和模型，以幫助我們理解客戶行為、市場趨勢和業務機會。這種資料驅動的方法使我們能夠更好地做出決策，並提供個性化的產品和服務。

此外，我們還致力於改進使用者體驗。我們深入研究了使用者在購物過程中的需求和偏好，通過設計優化、介面改進和個性化推薦等方式提升使用者體驗。我們追求簡單、直觀和無縫的購物體驗，以滿足客戶的期望並贏得他們的忠誠。

CTO 角色的變化

成為技術供應商後，作為CTO的角色會發生改變。

我在一篇博文中談到了這個問題。在我看來，CTO有四種不同型別的職責：

• 首先是企業級的CTO，通常負責基礎設施管理，向CIO彙報，並負責管理大量的基礎設施。
• 第二種是年輕企業中常見的技術聯合創始人型CTO，他們具備技術遠見。但我認為這個角色存在一定風險，因為很多其他事情，比如工程團隊的管理等，都會被納入這個角色的職責範圍。CTO可能並不一定擅長處理這些事務，但我們稍後再詳細討論。
• 第三種型別是具有大思想家特點的CTO，他們推動創新的發展。例如像AT&T和朗訊這樣的公司，他們有CTO或CTO辦公室，致力於研究和實驗下一代技術。
• 最後一種型別是面向外部的技術專家型CTO，在其他公司擔任技術供應商時，他們負責與客戶進行深入的技術互動，瞭解客戶如何使用他們的產品，並尋找更深層次、更廣泛的模式和客戶的痛點。這種角色不僅關注自身技術，更加重視整體情況。

需要注意的是，這些角色更加以客戶為中心，而不僅僅是以技術為中心。重要的是將客戶的反饋帶回公司，並思考需要開發什麼新功能或產品，或者需要改變哪些流程，以更好地服務客戶。

因此，作為技術供應商的CTO角色具有更強的客戶導向性，而不僅僅關注技術本身。

亞馬遜特有的文化

因為亞馬遜是我的第一份真正的工作，我曾長時間以為其他地方的工作文化和亞馬遜相似，但實際上並不是這樣。

亞馬遜有一種獨特的文化，對於快速發展的公司來說非常有效。他們鼓勵團隊儘可能獨立，削減組織層級和結構。等級制度在他們看來是不自然的。

他們希望擁有自組織的團隊，僱傭那些真正想要獨立工作、擁有產品的人。年輕的企業尤其需要這點，而不是追隨者或編碼員。

亞馬遜有一套領導原則，包括客戶執著、所有權、深度挖掘等14個原則，這推動了他們的文化發展。

在亞馬遜，招聘面試也主要圍繞文化匹配展開，因為一個不適應文化環境的僱員會對小團隊造成很大幹擾。亞馬遜非常推崇小團隊，通常由10至12人組成，每個成員都清楚自己的任務。

隨著企業的成長，技術長的角色也會發生變化，從最初負責所有技術相關事務，逐漸專注於團隊管理和確保工程師能夠交付所需的技術和產品。

與工程副總裁相比，技術長更加關注技術方面，如構建正確的技術和使用合適的工具等。

亞馬遜如何發展起來的？

亞馬遜內部經歷了一系列的變化。他們創造了獨立的團隊，這些團隊看起來像初創公司，並且掌握了自己的目標和創新議程。然而，在過去，亞馬遜為了快速發展，違反了體系結構原則，導致後端資料庫基礎設施脆弱且無法再增長。

為了解決效率下降的問題，他們轉向面向服務的體系結構，將系統拆分成獨立的功能構建塊，即微服務。

然而，隨著團隊的增加，每個服務都需要管理自己的資料庫，導致交流增加但創新減少。

為了改善情況，他們建立了共享服務平臺，採用虛擬化技術和API來管理伺服器。他們先在內部構建了這些技術，然後在外部推出產品，如Amazon S3和EC2，這些服務使得儲存和計算能力成為可程式設計和可擴充套件的，對企業來說非常划算。

亞馬遜的目標是實現網際網路規模的儲存和計算能力，併為各種型別的企業提供服務。

創新之路

亞馬遜的創新分為兩個層面：

• 首先是團隊級別的創新，每個團隊負責制定自己下一年的創新計劃，並獨立完成任務，例如改進推薦引擎以減少退貨數量。他們負責繪製路線圖、獲取新資料來源和與客戶進行不同方式的互動。
• 另一個層面是需要大量資本投資的創新，如Kindle和Amazon Prime。這些項目需要大量的資金支援。亞馬遜設定了一個規則，即如果一項創新項目有可能成功並對公司的資產負債表產生重大影響，那麼才會進行大規模的資本投資。

亞馬遜意識到在技術發展初期所做的一些決策非常明智，隨著規模的擴大，他們必須重新審視體系結構並開發適應變化的軟體。這涉及使用多個架構和版本來處理儲存引擎等技術挑戰。

此外，像其他公司一樣，亞馬遜也發現除了技術擴充套件之外，還需要解決銷售、解決方案架構、技術客戶經理和客戶支援等與技術無關的因素。這些因素都是構建成功的公司所必需的。

如何推出新服務？

我們希望所有的團隊都與客戶保持緊密聯絡，因為我們提供的大約95%的功能和服務都是為了響應客戶的直接需求。當初，我們建立的最早的服務幾乎可以滿足客戶的所有期望，包括基本的IT基礎設施、儲存、計算、資料庫、網路和安全等方面。

然而，隨著時間的推移，客戶提出了各種其他需求。他們需要分析功能、雲技術、移動開發以及現在的區塊鏈等其他技術，他們希望能夠使用這些技術而無需管理它們。因此，幫助客戶構建正確的特性和工具變得非常重要。

當我們推出新的產品和服務時，我們遵循一個強烈的文化氛圍，即以最小功能集推出（MVP）。但這只是作為構建業務所需技術的起點。我們不能只發布一些薄片式的東西，而是需要確保其穩定可靠。然後，我們與客戶一起探討其他功能的需求。

在產品初始階段，我們並不總是知道客戶需要什麼其他功能。例如，當我們推出DynamoDB時，並不知道客戶想要二級索引。我們沒有一開始就提供，但很明顯這是客戶想要的。我們通過以最小功能集啟動服務來觀察客戶如何使用產品，並逐步迭代和新增新功能和服務。

舉例來說，當我們推出Lambda時，它作為無伺服器環境，使開發變得簡單，只需編寫程式碼並將其部署到S3中，無需考慮伺服器等其他事項。你只需要支付你實際使用的部分，而不需要擔心閒置時間等問題。

這種方式改變了開發過程，我們可以觀察客戶如何使用產品。他們很快就開始採用類似X射線除錯環境的方式進行迭代，並使用階梯功能構建更復雜的應用程式。我們通過觀察客戶的使用習慣來了解他們的需求，例如在DynamoDB中，我們意識到輔助索引對於客戶比二級資料中心更重要。

基本上，客戶重新定義了我們的路線圖，我們開始提供對他們最重要的功能。這是非常重要的一部分。即使看起來像MVP，我們也不能將其視為MVP，因為人們會在此基礎上構建業務並依賴它。因此，在產品周圍形成了一個不同的文化結構。

去年我們有1400個新功能和服務的釋出數量，隨著團隊數量的增加，這個數字當然會繼續增長。我們在AWS中使用相同的結構，每個團隊都與特定的客戶群體合作，並根據他們的需求構建路線圖。隨著服務越來越多，路線圖也越來越多。

然而，這是一個快速推進的環境，軟體構建方式發生了巨大變化。如果我們能夠決定客戶應該如何開發軟體，那麼我們可能仍然按照五年或十年前的方式進行開發。相反，我們需要通過與客戶密切合作，讓他們驅動我們的創新引擎，從2020年或2025年開始開發軟體的方式。

因此，我們不能為客戶做決策，而是需要與他們緊密合作，讓他們驅動我們的創新引擎。我們需要密切觀察客戶如何使用我們的產品，並根據他們的反饋不斷迭代和改進。

總的來說，亞馬遜 Web Services（AWS）在創新方面採取了團隊級別和資本投資的雙重層面。通過與客戶緊密合作，瞭解他們的需求並觀察他們的使用習慣，AWS能夠提供滿足客戶需求的功能和服務。同時，AWS也投入大量資本用於研發和推出新的產品、服務和功能，以滿足不斷變化的市場需求。

這種創新方法使得AWS能夠與客戶保持緊密聯絡，確保他們能夠提供穩定可靠、符合客戶期望的解決方案。通過基於最小功能集的釋出策略和持續迭代的方式，AWS能夠快速響應客戶需求，並不斷提供更多先進的功能和服務。

亞馬遜的創新之路是一個不斷演變和發展的過程，始終以客戶為中心。通過深入理解客戶需求、觀察客戶使用習慣和持續投資研發，AWS在不斷推動技術和業務的前進，為客戶提供卓越的雲端計算解決方案。

構建客戶驅動的產品

我們無處不在，無論是從客戶那裡開始工作還是在亞馬遜內部。作為一家技術公司，我們非常注重開發對客戶真正重要的東西。儘管我們是一家重型技術公司，但工程設計和工程師也承擔著風險。

我們關注的是產品，而不僅僅是技術。我們想知道我們可以為客戶做些什麼。我們致力於構建令人驚歎的技術，但這並不是我們行動的唯一動力。我們關心的是解決客戶的問題。

為了確保我們持續關注客戶，我們採用一種稱為逆向工作的過程。首先，我們編寫一份新聞稿，清楚簡潔地描述我們將要構建的東西。然後，我們準備一個包含20個常見問題的文件，並用簡單明瞭的語言回答這些問題。在更復雜的情況下，我們可能需要反覆修改這兩個文件，直到我們完全清楚我們要構建的東西。

接下來，我們編寫使用者體驗（UX）文件，詳細描述客戶如何使用我們的產品以及他們與產品的互動方式。我們還編寫使用者手冊、術語表等其他相關文件。

最後，我們會得到一套四個精確描述我們要做的事情的文件。

作為亞馬遜，我們始終遵循著這個原則：我們的賬單不會超過我們承諾的內容。我們不會隨意將第二個版本的功能新增到第一個版本中。我們專注於構建我們承諾的功能，並且只關注這一點。這種方法提供了一個強大的結構，幫助我們思考客戶需求、產品體驗以及技術等方面。

在亞馬遜的會議中，我們不使用幻燈片或主題演講。我們有一個稱為六頁備忘錄的檔案，每個人在會議開始前30分鐘默讀它。這份備忘錄非常重要，因為它確保每個人都對我們討論的內容有清晰的理解。

寫一個故事是困難的，所以我們鼓勵協作和反饋。我們會多次修改並完善這份備忘錄，直到我們清楚地描述出特性、產品或業務領域。經過30分鐘的閱讀，會議室裡的每個人都在同一頁上，這有助於高質量的討論。

總之，我們擁有獨特的文化和流程來確保我們始終專注於解決客戶問題，並提供卓越的產品和服務。

容器技術

越來越多的公司跳過容器技術，特別是在追求更微服務環境的發展中。容器技術成為流行的原因之一就是它能輕鬆實現元件的上下擴充套件，與微服務理念相契合。許多人開始從整體階段分解出容器來進行開發，尤其是圍繞無伺服器環境的開發。

然而，在使用容器技術之前存在一些問題，特別是在交付Fargate之前。你需要管理多個容器在多個可用區域內執行的情況，而且需要將它們對映到虛擬機器上。因此，雖然容器是一個很好的開發選擇，但仍需投入大量工作來執行和管理這些容器。為了簡化這一過程，我們提供了一種名為Fargate的解決方案，它基本上取消了對底層虛擬機器的所有管理，只需將容器放入其中即可執行。

未來，我認為會有越來越多的工具、支援平臺和基礎設施，圍繞構建更復雜的無伺服器環境的能力進行開發。與其他服務更好地整合將成為發展方向之一。

*深潮注：Fargate是亞馬遜網路服務（Amazon Web Services，AWS）提供的一項計算服務，它是一種無伺服器（serverless）的計算引擎。Fargate使得開發人員可以更輕鬆地管理和部署容器化的應用程式，無需關心底層的基礎設施和伺服器。

容器技術是一種虛擬化技術，通過將應用程式及其依賴項打包到獨立的、可移植的容器中，以實現應用程式的快速部署和可移植性。容器技術使用容器引擎（如Docker）來建立、管理和執行容器，使得應用程式能夠在不同的計算環境中保持一致的執行方式，而無需擔心底層基礎設施的差異。容器化技術在現代應用開發和部署中得到廣泛應用，它提供了更高的靈活性、可伸縮性和便攜性。

保護客戶

然而，我認為安全性問題將成為人們關注的焦點。在未來五年裡，每個人都應當將安全作為首要任務，無論是CEO、CTO還是工程師，我們都需要具備安全意識並扮演安全工程師的角色。過去幾年每週都發生大規模資料洩露事件，作為技術專家和數字商務領袖，我們應該感到尷尬和憤怒。保護客戶資料是我們的責任，因為如果不保護客戶，就沒有生意可言。

我們需要開始思考如何保護從客戶處收集的資料，無論是租車還是其他消費服務。安全性需要成為預設的一部分，例如在持續整合和持續部署管道中觸發安全事件，確保新增新的開源庫時進行審查和評估。

開發管道本身也需要是安全的，並配備各種自動化工具進行漏洞測試。特別是在醫療和金融領域，需要遵守各種規定和監管要求。

在五年內，我希望我們都能對安全問題保持高度意識，並將保護客戶放在首位。在亞馬遜，無論是智力資本還是金融資本，保護客戶將永遠是我們的首要投資領域。

初創公司在使用 AWS 時的常見錯誤

首先，對於那些有傳統資料中心經驗的人來說，初次使用AWS可能會導致信心不足。儘管AWS在彈性和可利用性方面具有優勢，但如果不使用更高階別的服務（如安全、資料分析和移動），我們就無法充分發揮其潛力，特別是在追求高可靠性的大規模開發方面。

其次，關鍵是要確定公司的型別和目標。有兩種不同的公司風格：一種是追求快速增長、大量客戶的公司，它們不太注重收入，而是通過大量投資來快速擴張並可能被收購；另一種是追求可持續發展的公司，希望建立長期業務而非只關注收購。

這兩種型別的公司對AWS的使用方式完全不同。對於追求快速增長的公司，它們可以更加放心地利用AWS提供的容量和服務，因為不需要過多擔心成本問題。對於追求可持續發展的公司，他們需要構建不同的體系結構，更加關注成本控制，並確保成本與客戶獲取之間有明確的關係。

對於創業公司的創始人來說，Jeff Bezos常常將他們區分為僱傭軍和傳教士。僱傭軍是為了追求金錢而投身於創業，而傳教士是出於對產品的熱愛。兩者都是有效的創業方式，但技術支援和構建的技術體系結構會有所不同。

因此，要明確自己是哪種型別的公司，並相應地選擇合適的技術支援和體系結構。