前言

幾週前我離開了 Airbnb，距離 2016 年初加入剛好十年。

受到 Reflections on Palantir 和 Reflections on OpenAI 的啟發，我想趁記憶還新鮮的時候，把這段日子的一些想法寫下來。這篇文章一部分想談我認為 Airbnb 特別的地方，一部分則是這些年來學到的東西。整體來說，我是帶著滿滿的感謝離開這家公司的，這篇也是用這樣的心情寫的。

公司

業務

2016 年初我加入時，公司正處在全力成長的階段，我最初幾年都在負責市場中房東那一側的成長。也是在那時候我學到，經營一個雙邊市場，關鍵大多在於設計出不會過度偏袒任何一方的誘因和規則。以立即預訂為例，房客不需要房東同意就能訂房，這對房客很方便，但也代表房東對「誰住進自己家」的掌控變少了。或者房屋守則，用來把期待講清楚很有用，但規則堆得太多，對房客就成了一種麻煩。經營一個市場，市場設計的重要性一點也不亞於成長曲線。

在高速成長好幾年之後，Airbnb 在 2019 年底宣布了上市的計畫。接著 COVID 來了：到 2020 年 4 月，總預訂晚數年減 72%，而隨著取消訂單暴增，淨預訂數甚至轉為負值，這是前所未見的狀況。在募資並全面撙節之後，Airbnb 做了一個艱難的決定：裁掉約 25% 的員工，大約 1,900 人，這至今仍是 Airbnb 史上最大規模的裁員。

隨著世界慢慢適應與 COVID 共存，我們的業務比多數同業更快復甦，因為旅遊需求轉向了國內旅行和鄉村目的地。在 10 萬個城鎮、220 個國家與地區都有房源，意味著不管需求在哪裡冒出來，我們在那裡都已經有房源了。事情峰迴路轉，Airbnb 就在那年 12 月上市，和世界各地的房東一起敲響了開市鐘。在所有人都剛熬過那樣一年之後，那是個很動人的時刻。

之後這幾年，Airbnb 一直在把核心產品精進到極致，現在則開始往外擴張。服務、體驗，以及進軍精品旅館，都是最新的幾個賭注。公司同時也在探索 AI 能為產品和業務帶來什麼。這些大多還在早期、還沒被驗證，但新的篇章確實已經開始了。

文化

對一家業務建立在「99% 的人都是好人」這個前提上的公司來說（畢竟你是要住進陌生人的家裡），Airbnb 在招募時也在找同樣的特質。除了標準的面試流程之外，Airbnb 還有文化面試，用來評估候選人和公司核心價值的契合度。在我的文化面試裡，我聊了一趟自己幫忙規劃的祕魯旅行。後來有人告訴我，我分享的那些故事體現了「Be a Host」這個核心價值。

所以也不意外，我最喜歡的核心價值就是「Be a Host」，而它會在一些細微卻很有代表性的地方顯現出來。我在 Airbnb 總部的第一天，看到大家幫我、也幫彼此開門、扶著門。這種舉動不只停留在日常的小禮貌，也延伸到大家實際共事的方式。我的同事都很聰明，但恃才傲物的人很少見。大家有競爭心，卻很少劍拔弩張。整體而言，這是一個少有內耗的地方，人與人之間相當尊重。

反過來說，這種想當個好主人的心態，有時候會過頭變成一味當好人，甚至是迴避衝突。這一點在建立共識的過程中特別明顯，那往往是個緩慢、有時候頗為煎熬的過程。對習慣了直接、不留情面回饋的人來說，這常常是個文化衝擊。

我確實相信幾位共同創辦人不想把文化搞砸，每當公司規模又長大一輪，他們都試著守住早期的那股精神。話雖如此，還是很難不懷念早期那些日子，那時公司比較小、也比較不正式。每週五我們有 nerds@，工程師會分享自己那週學到或做出來的東西。在 world@ 上，產品負責人常常會先放一些即將發表的東西給大家看。隨著公司變大，這些東西淡掉了一部分，我很希望我們能多留住一些。

運作模式

共同創辦人兼執行長 Brian Chesky 是設計科班出身，所以他把同一套設計思維也用在「打造公司」這件事上，一點都不讓人意外，而且他從不吝於向那些指標性的公司學習。

在 Airbnb 總部四樓的牆上，掛著一幅幅描繪房東與房客旅程的畫框，靈感來自華特·迪士尼當年設計《白雪公主》故事線的方式。COVID 之前那幾年，Brian 大量借鏡 Amazon，野心是把 Airbnb 變成一個超越住宿的旅程平台。最近他則轉向 Apple，重新形塑我們做產品行銷、產品發表和產品藍圖規劃的方式。每個時期都帶來各自的野心和各自的工作方式，而且通常也伴隨著新的領導團隊。

不過每一次改變，都有它自己的成長痛。COVID 之前是失焦的擴張：Airbnb 同時在做體驗、雜誌、商務旅行、旅館，甚至機票，分散在四個大致獨立的事業單位裡。COVID 之後，鐘擺又盪向另一邊，變成一年兩次的大爆炸式發表：高風險、全有或全無的產品發表，讓人更難分辨到底哪個東西真的有效。而 Brian 那場創辦人模式的談話，也在公司內外都掀起了不小的辯論。儘管有這些擺盪，我還是欣賞 Brian 有打造一家指標性公司的野心，也不怕調整和實驗，把公司本身當成一個需要反覆迭代的設計問題。

還有一個運作模式上的選擇值得一提：Airbnb 是少數幾家在 COVID 之後真正落實遠距優先的公司。我自己受惠於這份彈性，但我懷念和同事站在白板前把一個問題想通的感覺。要讓這種協作方式活下來是個難題。遠距讓我們在原本觸及不到的地方招到了優秀人才，不過也更難篩掉那些要的是彈性而不是這份工作的候選人。遠距和進辦公室之間的取捨很不容易，Airbnb 到現在都還在努力找出那個平衡點。

Airbnb 的資料

團隊

早期，整個資料團隊，內部叫做 A-team，小到一個房間就裝得下。成員多半是剛出社會不久的博士，背景各異：經濟學、統計、作業研究和社會科學都有。他們個個思路清晰，非常重視資料，也很貼近產品。

在組織上，個人貢獻者各自負責特定領域並成為該領域的專家，但全都隸屬於一位資料主管。近幾年則改成以去中心化的方式，分別向工程組織裡的各個主管報告。在我離開時，Airbnb 剛聘任了第一位資料科學副總，所以鐘擺或許又會盪回比較集中的資料組織。這種來回其實不罕見：LinkedIn 和 Facebook 都經歷過類似的演變。

Airbnb 和資料工程（Data Engineering）的關係一直很複雜。這方面的投資開始得很早：許多早期的資料工程師來自 Facebook，我們早期的資料倉儲也看得出這個痕跡。獎章架構（medallion architecture）和 core data 都深受他們在 Facebook 打造的那一套影響。大約在 2018 年，組織把資料工程團隊解散了，在我看來，這是 Airbnb 資料領導層犯過代價最高的錯誤之一。

幸運的是，我們留住了一些最強的工程師，其中不少人轉到了資料平台團隊。在新的領導之下，Airbnb 於 2019 年重新投入資料工程的招募，今天這個社群又重新強大起來。Airbnb 也是最早在這種規模下設立 Analytics Engineering 組織的公司之一，這一部分要歸功於我們在 Minerva 這類工具上的投資。

整體來看，角色的分工愈來愈專精：資料科學家和分析師專注在產品，analytics engineer 和資料工程師負責建置全公司共用的資料集，軟體工程師則打造底層平台。

平台

Airbnb 歷來偏好「自己做」而非「買現成」，也因此誕生了好幾個成功的開源專案，最有名的就是 Airflow 和 Superset。

離線資料的部分，一切都放在 lakehouse 裡：資料存在 S3 上，以 Parquet 檔案的形式存放在 Iceberg 資料表中。資料通常依日期分區，我們盡可能以增量方式運算，不過有些延遲到達的資料（想想取消或更改訂單）會逼我們重寫整段歷史。批次運算主要用 Spark，串流用 Flink，互動式查詢用 Trino。在排程方面，Airbnb 跑著全世界規模數一數二的 Airflow 部署，規模常常大到開源社群還沒準備好去應付。

Airbnb 非常倚重以設定驅動的框架，倚重到有人開玩笑說，我們的資料契約完全建立在一堆脆弱的 YAML 檔案上。以這種方式打造的框架至今仍被廣泛採用：機器學習特徵平台 Chronon、作為語意層的 Minerva，以及一套叫做 ERF 的實驗平台等等。Python 是打造這些資料框架的主要語言。

在使用端我們投資得同樣多。Dataportal 是一套幫助大家找到正確資料的目錄和介面，底下則有一個統一的中繼資料服務，存放著其他所有資料工具都依賴的中繼資料，例如擁有權、資料到齊時間和資產標記。最近我們還做了一個內部的資料 agent，成效相當不錯，很大一部分是因為語意層和中繼資料服務早就把地基打好，讓它站得上去。

這段我有偏見。我認為和同業相比，Airbnb 的資料生態系相當成熟，而且被低估了。對資料的投資是我當初加入的原因之一，而這件事並沒有讓我失望。

語意層

在 Airbnb 的十年裡，有七年我都在做公司的語意層 Minerva。其他公司的人常問我們是怎麼把它推廣到整個組織的。並沒有哪一招特別關鍵，歸結起來就是：對齊公司層級的重點工作、找到願意站台的人，以及一種毫不鬆懈的當責心態。

早在 2018 年中，我們就已經在想，該把商業指標和實驗指標的定義整合到單一的真實來源之下。真正的催化劑出現在 2019 年前後，當時 Airbnb 正準備上市，資料品質（或者說品質的缺乏）變成了攸關存亡的問題。幾年前我們犯下解散資料工程團隊的錯誤，而我們一直在為此付出代價。不同團隊各自打造了自己版本的「訂房數」、「上架房源數」和「營收」。當 Brian 問起上週的訂房數字，他問不同的人會得到不同的答案。對一家即將要向公開市場報數字的公司來說，這是不可接受的。我們的技術長甚至憂心到宣告了「資料破產」。

在那份急迫感之下，誕生了三件事。第一是一項全公司的資料品質計畫，把最關鍵的商業資料模型從頭重建。但重建一次並不足以讓它們持續值得信任，所以我們建立了一套叫做 MIDAS 的認證流程，讓資料維持在一致的品質標準上。最後，我們投資在基礎設施上：讓資料生產者能為商業指標和維度定義出一個真正可被認證的唯一真實來源。Minerva 就順理成章成了這件事的歸宿。

上市的準備創造了急迫感，MIDAS 給了我們據以行動的專案和流程，而 Minerva 最後成為從中長出來的那條標準路徑。我們很早就和幾位關鍵主管密切合作，把它定位成這個角色，接著隨著戰果累積出動能，一個團隊一個團隊地推廣出去。大概花了兩年，Minerva 才成為分析工作的標準工具。從某個角度看，Airbnb 之所以會有 analytics engineering 這個角色，正是因為中間擺著這塊核心技術。

工作上的體會

關於打造軟體

在軟體工程和資料工程的交界處工作，我有機會向幾位非常傑出的軟體與資料工程師學習，是他們教我怎麼思考這門手藝。

我第一個大收穫是「軟體工程是程式設計對時間的積分」，這個定義因 Software Engineering at Google 這本書而廣為人知。設計模式和抽象是用來管理複雜度的工具，而不是目的本身。當一群理解程度和心智模型都不同的人在同一份程式碼上工作時，手邊有這些工具，是讓軟體持續演進、同時讓大家的理解不脫節的可靠做法。

說到設計模式，我學到它們是一套很有用的共同語彙，用來指認常見的問題和可能的解法。有幾個模式反覆出現：轉接器模式（Adapter），讓我們把不同的後端資料庫包在一致的介面之後；橋接模式（Bridge），我們用它把 Airflow operator 和它所承載的工作單元（我們稱為 Step）解耦；還有策略模式（Strategy），成了我們檢查資料品質那套稽核框架的骨幹。

關於抽象：我一開始是用程序式的寫法實作我們的 write-audit-publish（WAP）模式，後來看著更資深的工程師把它換成一層抽象，不但簡化了我原本寫的程式碼，也讓之後要寫新東西變得更容易。另一個例子是我們引入的 Spell 抽象層，讓開發者可以加上 codemod 的能力，開發者和 CI 都能拿它來做設定驗證。它取代了多年來胡亂串接起來的一堆脆弱 shell 指令碼。現在，如果我發現自己不只一次在寫類似的、帶著和當下任務無關的實作細節的程式碼，我會停下來問：是不是有個有用的抽象可以把這層複雜度藏起來。

這一路上我還學到不少其他的技術心得：領域建模、為什麼選擇無聊的技術通常比較明智、組合優於繼承、依賴注入與反轉，還有快照測試。每一個大概都值得單獨寫一篇。共通點是，這些全都需要時間才能內化。我是在同一份程式碼裡待得夠久、親眼看到它們為什麼重要之後，才真正體會到它們的價值。

關於維護軟體

有一段時期，我們埋頭在建造和重構架構。但也有些時期，需要的是可靠與穩定，而不是敏捷和求快。在軟體生命週期的不同階段之間切換，需要調整你的思考方式和關注焦點，而對我來說，是經歷了幾次慘痛的事故之後才真正把這件事聽進去。

有一段時間，我們對待每一份資料集的優先順序幾乎都一樣。等到平台被全公司採用之後，很明顯，財務報表和高階主管看的儀表板，遠比某個人的臨時報表來得關鍵。我們引入了資料分級制度，讓運算資源可以依照每份資料集的層級和 SLA 需求來排定優先順序。我們也投資在可觀測性上。有很長一段時間，我們並不知道大部分系統「健康」的樣子長什麼樣，所以我們建立了分層的可觀測性：即時、日內、每日，並且為每個層級定義出什麼叫「好」。為了不讓低訊號的警報埋掉真正的問題，我們把警報導向對的負責人，並持續調整門檻值，直到會響的警報都是值得處理的。

為了讓系統更強韌，我們從每一次事故中學習並採取矯正措施。有個反覆出現的教訓：大爆炸式的發布很危險，因為波及範圍太大。我們轉向漸進式推出、功能開關和分階段部署，久而久之部署變得平靜多了。我們也調查了團隊成員覺得工作中哪些部分重複到難以忍受，然後盡可能自動化。重啟失敗的工作、驗證發布、手動清除警報是其中最嚴重的幾項，後來大部分都被我們自動化掉了。

有時候，我們需要做的是更大的改變。新的使用情境和技術債累積下來的重量，讓架構本身變得無法維護，唯一真正的解法就是把地基重蓋。七年裡我們對 Minerva 做過兩次這樣的事，而我預期隨著需求和使用情境持續演變，這種事還會再發生。

關於當責心態

在 Airbnb 資料平台工作了這麼多年，我逐漸相信，讓一個專案成功而非平庸的關鍵之一，是貢獻者投入的在乎程度，也就是那種讓你以自己的工作為榮的當責心態。

對我們來說，這種心態展現在每天的選擇裡。雖然做那種在智性上比較有趣的東西總是很誘人，但我們會反過來挑戰自己過度設計的提案，還不只一次直接砍掉它們，改採更簡單、能讓使用者往前走的做法。有機會的時候我們就清技術債，不是因為把債當成不惜代價都要避免的東西，而是因為我們知道這會幫到後面的開發者，即使使用者永遠不會注意到。而當使用者遇到問題時，我們以能快速幫他們排除障礙為榮。我們的 oncall 輪值是我們了解「什麼壞掉了」的地方，而不只是一件輪流應付的雜事。

當責心態在艱難的時期更為重要。有些時期，可靠性問題傷害了團隊的聲譽、人員流失讓我們嚴重人手不足、使用者要的東西我們排不進優先順序。在那樣的時刻，我們誠實地把問題講出來，並在它們燒成大火之前採取行動。當困難是結構性的，是組織方向沒對上而不是技術上的落差時，我們也不怕去說動領導層做更大的改變。

我很幸運待在一個每個人都展現出高度主動性和當責的團隊。這也是為什麼 Minerva 能在 Airbnb 的資料社群裡撐這麼久的原因之一。

個人的體會

轉換角色

我在 Airbnb 幾個關鍵的時刻，都發生在我踏出既有的角色、從頭開始的時候。

2016 到 2019 年，我以資料科學家的身分，協助我們在幾個不同的市場分級中壯大房東社群（還記得 Airbnb Plus 嗎？）。當公司解散資料工程組織時，我是少數幾個一頭栽進那片殘骸、從那裡重新建起來的資料科學家，而且我發現我喜歡這份工作。建立資料管線、產出高品質的資料集，讓我體會到對的工具能帶來多大的槓桿，所以 2019 到 2021 年，我轉去做產品管理，幫忙把 Airbnb 的語意層從 0.5 推到 100。2021 年之後，我以軟體工程師的身分待在 Minerva 團隊，從頭重建我們的技術堆疊。

你的興趣轉了向，並不會自動換來組織相信你能在新角色裡做出成績。每一次往新領域的跨越，都是組織在你身上下的一個賭注，而讓這個賭注有回報是你自己的責任。我每一次用的劇本都一樣：把手上的事做到好、累積起會替你先說話的名聲、找到一個你感興趣的相鄰領域、找到一位願意支持你的人，如果這一步能推動成長就轉過去。

換職能會讓你的成長重新加速，但這也不是免費的。它可能拖慢你在任何單一階梯上往上爬的速度，而你累積的專業至少會有一段時間退到背景裡。你必須願意和那份不適共處，並且對自己的學習曲線誠實（下一節會多談一些）。

回頭看，這是我在 Airbnb 待這麼久的主要原因。那感覺像是十年裡塞進了三份不同的工作，每一份都給了我截然不同的歷練和各自的成長機會。在 AI 的時代，我認為那些能夠跨出單一角色運作的人，會是最有機會發展得好的人，而我也很好奇這會把我帶去哪裡。

成長的陣痛

每一次轉換都伴隨著成長的陣痛。在 Airbnb 有兩個故事到現在還跟著我。其中一個，我立刻迎了上去；另一個，我畏縮了好幾個月才把它扭轉過來。

我接下 Minerva 團隊產品經理的第一週（對，就是第一週！），我們遇上了團隊史上最大的一次事故，內部代號 CIM-198。它嚴重到我們必須對 Minerva 下凍結令，禁止使用者再往平台上提交新的語意。我當下的工作是對外說明事故的範圍以及我們打算怎麼修。更大的任務則是和工程師一起找出系統的缺口，做出短期和長期的修補，讓它不會再發生。

整件事感覺像一場延長的面試，考的是我當時根本還不太具備的產品管理能力。我們的使用者很有耐心，領導層給了我們空間，我也和工程端緊密合作擬出了一份紮實的計畫。我們交付了好幾個新功能，包括離線回填，它到今天都還在架構裡扮演關鍵角色。這次事故印象深刻到我們後來還印了 T 恤，上面寫著「I survived CIM-198」，一枚我希望永遠不必再頒發的榮譽徽章。我對那第一週有很好的回憶，也認為自己處理得不錯。

第二個故事發生在我剛轉去做軟體工程的時候。我跟著一位非常有能力、標準也很高的導師。他的風格和氣場都很有壓迫感，這讓我很沒安全感。和 CIM-198 那場危機不同，這裡沒有任何期限逼著我行動，所以我沒有迎上去，反而做了相反的事。我不斷擔心別人怎麼看我，怕浪費他的時間、怕問出天真的問題、怕顯得自己很笨。我會悶著頭一路把東西實作完，中途也不跟他確認一下，結果等 PR 送出來已經太晚，來不及有什麼有意義的回饋。這情況糟到有一天他直接問我：「你是在躲我嗎？」那真是當頭棒喝。

他後來跟我說的一句話，我一直記到現在：就算我一開始的判斷有 99% 是錯的，只要我願意回過頭去想為什麼錯，我的品味就會隨著時間變好。那才是真正的成長路徑。這需要一些心理上的功課，但我意識到，要好好地重新開始，就得擁抱這些成長的陣痛、放下自己的自尊。我後來確實迎向了那份不適，也改變了自己的做事方式。我開始多做 pair programming、更早發問，也允許自己看起來沒把握。六個月後，同一位導師告訴我，團隊裡另一位受敬重的工程師認為我是他共事過最可靠的人之一。

這兩個故事的差別，在於我多快放下自尊、擁抱那份成長的陣痛。我願意相信，這些年下來我變得快一些了。

追求影響力

在多數公司裡，成長是用你在職涯階梯上的層級來衡量的。這是個有用的外部計分卡，但如果你把整個職涯都繞著它轉，最後可能會變成在追逐層級和頭銜，而不是那些真正讓你有熱情的工作。

我是以慘痛的方式學到這件事的，那是我還在當 PM、負責推廣 Minerva 的時候。從多數外部指標來看，一切都很順利。我有實際的影響力、和很好的人共事、產品成長得很快。但日復一日的工作還是把我磨得很累：不斷的情境切換、沒有時間好好深想、同時要向上、向下、橫向管理。我開始認真考慮離開公司。

改變我想法的是和另一半的一次對話。她聽我抱怨完，然後說：「聽起來你對這家公司和團隊的使命還是很有熱情，你只是待錯位子了。」她說對了。我依然在乎 Airbnb、在乎團隊和使命。真正發生的事情是，我漂流到了一種不適合我的工作型態裡，而我一直沒有對自己誠實面對這件事。我被「有影響力」的感覺牽著走，卻不再問工作本身對不對。

那次對話推著我去爭取回到更技術性的角色，一個為深度解決問題而生的位子。這在表面上不是個順理成章的選擇，畢竟是放棄 PM 的職位、回去從工程的個人貢獻者重新開始。但就我希望自己的日子長成什麼樣子而言，這是對的決定，也開啟了我在 Airbnb 最充實的一段時期。

沒有人會比你自己更努力去爭取你熱愛的工作。你的主管有其他優先事項要兼顧，組織有它自己的慣性，而職涯階梯不管你要不要，都會一直把你往下一個層級拉。夠了解自己、懂得在該推回去的時候推回去，以及擁有這麼做的勇氣，比我拿過的任何一次升遷都更重要。

結語

我從沒想過自己會在 Airbnb 待這麼久。

回頭看，那感覺像是在三家不同的公司做了三份截然不同的工作。職涯不是線性的，而保持自我覺察，是讓我一路上得以修正航向的關鍵。在這個過程裡，我逐漸明白自己擅長什麼、享受什麼，以及想要更多的是什麼。我做出了實質的影響，也很幸運能和一些我所認識最善良、最有才華的人共事，其中有些人現在是我很珍惜的朋友。

我會非常想念 Airbnb。我很期待看看下一個篇章長什麼樣子，而這十年已經給了我足夠的東西去面對它。

—

謝謝 Jason 帶我進 Airbnb，也因此有了長達十年的友誼。謝謝 Vaughn 教會我關於 Airbnb 的一切，以及什麼叫做為這門生意做對的事。謝謝 Aaron 教我資料工程。謝謝 Ricardo 和 Cuky 相信我能成為一名資料科學家。謝謝 Jeff 在我毫無 PM 經驗時，賭我能帶起 Minerva 團隊。謝謝 Shao、Dave 和 Vyl，在我開口時幫我轉往軟體工程。謝謝整個 Minerva 團隊這些年來與我並肩。謝謝 Philip、Krist 和 Clark 一直是 Minerva 團隊的中流砥柱，陪著彼此走過起起伏伏。謝謝 Toby、Chris、Barak 和 Ginter，讓我看見什麼叫做一位出色的工程師。