PingCAP“一號員工”唐劉：回顧我與 TiDB 的十年成長之旅详情 - 數據庫,分佈式 PingCAP 日志

導讀

作為 PingCAP 的“一號員工”，TiDB 研發副總裁唐劉親歷了 TiDB 從一個開源小項目到全球知名分佈式數據庫的蜕變。本文，唐劉從親歷者視角，回顧了 TiDB 的技術演進、產品迭代和全球化歷程，還分享了自己從程序員到技術管理者的成長與感悟。

這是一段關於技術理想、客户成功與團隊協作的旅程，也是一次對開源精神、創新勇氣和商業智慧的深度剖析。通過唐劉的視角，我們得以窺見 TiDB 背後的點滴故事，以及那些推動它走向成功的信念與堅持。

本文首發於知乎：https://www.zhihu.com/people/siddontang

人生最寶貴的財富，莫過於回憶與反思。

時間一晃，十年已過。從2015年4月1日 Max 在愚人節嚴肅地問我“願不願意一起創業”開始，我就踏上了 TiDB 這趟列車，一路跌跌撞撞，也一路風光無限。

這十年間，我完整地參與了 TiDB 從零到一，從開源小項目到全球化產品的每一步。如今站在時間的節點上，我想寫下這段旅程的真實經歷與感悟，既是記錄這段珍貴的歷史，也希望我的故事能給同樣熱愛技術與創業的朋友們一些啓發和幫助。

這一系列的文章，並不是要炫耀成功或者粉飾困難，而是想真誠地分享：

創業之初，一個單純的技術理想如何一步步走向現實；
技術開發與產品商業化之間，程序員經歷了怎樣痛苦而又必要的蜕變；
開源與客户成功如何成為 TiDB 最重要的成長基因；
全球化的征程上，如何用技術與產品贏得全球客户的信任；
作為一名程序員，又如何一步步成為一名管理者，甚至技術領導者。

我相信，這些真實的故事才是最有價值的，也是最值得被記錄下來的。

好了，廢話不多説，讓我們一起進入這場回憶與成長的旅程吧！

一：旅途的開始——4月1號的愚人節邀請函

愚人節那天，我收到了創業邀請

2015年4月1日，愚人節。對程序員來説，這通常只是個能放心開玩笑的日子，但我沒想到，那天居然收到了一條特別離譜的消息。

發消息的人是 Max，我們之前在開源社區有過不少合作，但從沒真正見過面。消息很簡單，大意是：

“我們打算創業了，做個分佈式數據庫，開源的。你願不願意一起幹？”

看到這消息，我腦袋一下子就短路了：這也太荒謬了吧？愚人節跟我開這種玩笑？

我當時毫不猶豫地回覆了一句：“你是不是在玩我？”

結果 Max 立馬回了一條：“我很認真。”

一瞬間，我愣住了——玩笑開得挺像真的。

為什麼會找到我？

為什麼 Max 突然會想到我？後來仔細想了想，這其實都得歸功於開源。

我們之前在開源社區裏合作了一些項目，彼此之間通過寫代碼、發 Issue、提 PR，雖然完全沒見過面，但早就摸清了彼此的技術品位和脾氣秉性。開源社區的好處就在這裏：程序員不靠相貌、靠代碼，大家的水平和性格，都寫在 GitHub 上。

如果沒有開源，我們完全是陌生人，哪怕面對面見了面，也不會產生信任。但開源卻讓我們在未謀面的情況下，迅速建立了相互的認可。

這麼説吧，開源社區就是程序員世界裏的“相親平台”，比見面喝咖啡有效多了。

兩個震撼：開源和遠程辦公

雖然心裏還是有點懷疑，我還是跟 Max 聊了幾句，越聊越覺得他們似乎真的不是在開玩笑。

畢竟，做個開源的分佈式數據庫，還要“影響世界”，這件事放在十年前，聽起來就是典型的程序員中二病發作的症狀。夢想是挺偉大的，但也挺傻的，尤其是我們幾個連數據庫源碼都沒碰過的程序員，居然敢幹這麼大的事。

不過我還是拒絕了，因為 Max 成立的公司在北京，而我那時候已經定居珠海，不想去北京。

但 Max 接下來的一句話，讓我直接傻眼了：“你可以不來北京，直接在家辦公就行。”

你要知道，那可是十年前啊！公司創始人居然主動提出讓員工遠程辦公，這在當時是非常前衞甚至瘋狂的事情。

這一刻我突然覺得，這家公司，要麼成不了，要麼就真的會很酷。

第一次線下見面，居然像多年好友

於是，我立刻買機票飛去了北京，見到了 Max，還有其他兩個創始人—— Ed 和 Dylan。

你們能相信嗎？那是我們第一次見面，但彼此之間居然沒有半點陌生的感覺，就像多年好友重逢一樣。這真的是非常神奇的經歷。

現在回頭看，為什麼我們能這麼快地建立信任？歸根到底，還是開源的力量。

從此，開源就成了 TiDB 骨子裏的基因，也成了日後我們走向全球市場的一把利器。

“真開源”，透明到幾乎“打臉”

從創立第一天開始，我們就決定走“真開源”路線。什麼叫“真開源”？

就是把幾乎所有的代碼、所有的問題、所有的 bug、所有的 issue 和 PR，全都公開放在 GitHub 上面，完全透明，讓客户和同行隨便看、隨便吐槽。

有人問我們：“你們這麼公開透明，bug 全都暴露在外，不怕客户看到嗎？”

我們卻覺得反而很放心，為什麼？因為這種透明反而讓客户更加信任我們。

客户能直接看到我們是怎麼工作的，bug 是怎麼發現又怎麼修復的，產品是怎麼一步步成長起來的。事實也證明，這種透明度反而為我們贏得了巨大的客户信任，甚至比那些刻意隱瞞問題的企業更容易被客户所接受。

我們為什麼要做一個分佈式數據庫？

談到 TiDB 最初的起點，那就是“解決分庫分表（sharding）的痛苦”。

作為互聯網行業出身的程序員，我們深受 MySQL 分庫分表的折磨，每次修改表結構都要折騰到半夜，痛苦到懷疑人生。

於是，我們希望：搞一個真正能無限擴展（Scalable）的分佈式數據庫，徹底終結程序員的 sharding 噩夢。

這個想法最初特別樸素：我們只是想解決自己的痛點。但後來發現，這種純粹的初心，竟然成了 TiDB 的核心競爭力，也成了眾多客户選擇我們的重要原因之一。

不知者無畏，程序員開啓的“打怪升級”之旅

回想起來，我們幾個人當時並沒有任何數據庫開發經驗。我們只是數據庫的重度使用者，根本沒碰過數據庫源碼，更別説開發一個新的分佈式數據庫。

為什麼我們敢這麼幹？只能説，有時候無知反而是一種優勢，俗話説得好，“不知者無畏”。

正是帶着這種無知者的勇氣，我們踏上了 TiDB 這場充滿未知的冒險之旅。

而我，也因為當時一時腦熱，成了 PingCAP 的第一個正式員工，並從此開啓了我此後長達十年的 TiDB 開發旅程。

多年以後，我回想起當時的決定，依然覺得慶幸和自豪。

二：技術驅動的幸福時刻

做產品什麼時候最爽？

做技術的總喜歡問一個很哲學的問題：“寫代碼的哪個階段最快樂？”

可能每個人都有自己的答案，但對我來説，答案非常簡單： 產品還沒給客户用的時候，那段時光最幸福。

沒錯，客户沒進門之前，程序員只需要安心寫代碼，完全不用操心客户的抱怨、需求、緊急電話，更不用半夜爬起來救火。那是一種純粹的技術快樂，專注於代碼本身的樂趣。

但問題在於，做產品最終還是要給客户用的，這快樂的時光，註定無法長久。

從零開始造一個數據庫，我們真沒那麼瘋狂

TiDB 的開發一開始就讓人覺得是件很瘋狂的事情——畢竟，一個數據庫不是説寫就能寫出來的。

不過我們也不是毫無準備，畢竟這世上早有 Google 發過論文，比如 Spanner。除了論文，還有比我們早一年創辦的 CockroachDB（俗稱“蟑螂數據庫”）和經典的 HBase 都給了我們很多啓發。

程序員造輪子並不可恥，但如果閉着眼睛瞎造就挺蠢的。我們理智地站在這些巨人的肩膀上，借鑑了大量已經驗證過的架構設計思想。

為什麼我們選了 Go？

造數據庫第一步就是挑選語言。我們毫不猶豫地選了Go。

為什麼？因為我們幾個人最熟悉、最喜歡的語言就是Go。程序員都明白一個道理：在未知領域裏闖蕩，最安全的選擇永遠是自己熟悉的語言。

我們的策略也很簡單粗暴：先讓程序跑起來再説。

MySQL 兼容是好事，但坑也是真多

早期，我們決定兼容 MySQL 語法。這個決定直接奠定了日後 TiDB 成為最佳 MySQL 替代方案的基礎。

然而，這個決定背後的坑之深，遠超我們的想象：

MySQL各種奇葩語法坑；
稀奇古怪的兼容性問題；

只能説，MySQL 兼容是一把雙刃劍，但總體而言，好處還是大於壞處。

簡單粗暴的“優化器”和“執行器”

雖然今天 TiDB 已經有很先進的優化器和執行引擎，但當年我們完全沒有優化器相關的知識，也沒有人做過數據庫優化器開發。

怎麼辦？我們只能祭出程序員的萬能法則：“不懂就先寫個最簡單的”，於是搞了個 rule-based 優化器，簡單到讓人難以置信。執行引擎就更直接了，我們直接用了最經典的 Volcano 模型，也就是“火山模型”，一層一層往下next調用，簡單有效。

正是這種“無知者無畏”的簡單策略，讓我們迅速做出了第一個可用的版本。

“測試驅動”是真正的信仰

從 TiDB 開發的第一天起，我們就確立了測試驅動的策略。原因也很簡單，畢竟我們做的是數據庫，客户的數據可不是鬧着玩的，出一次大問題，我們就能直接失業。

我們甚至一度要求測試覆蓋率達到 100%，聽起來挺瘋狂，但確實幫我們抓出了大量潛在的 bug。

除了常規的單元測試，我們還幹了一些非常極端的事兒：

移植了 SQLite 的 sqllogic test，當時覺得這事兒有點浪費時間，現在回想起來，卻無比感謝當年咬牙做了這個決定。
學習 Clojure 語言，硬着頭皮做了Jepsen 測試，揪出了無數隱藏的事務 bug。
對核心算法用上了 TLA+ 形式化證明，雖然這玩意兒真不好搞，但做出來之後讓人睡得更安心了。
引入 Chaos 工程，搞了個 Chaos 測試工具，最後甚至做出了一個非常受歡迎的開源項目 Chaos Mesh。

Rust 和 TiKV 的誕生：避開 C++ 這個“大坑”

計算層搞定後，我們接下來面臨的挑戰是存儲層。當時我們堅決不選 C++，因為這玩意兒複雜到無法控制，招多少人可能都 hold 不住，直接放棄。

恰巧這個時候 Rust 剛發佈 1.0 版本，於是我們咬咬牙選擇了 Rust：

Rust 性能好，內存安全性高，幾乎能做到代碼編譯過了就能穩定運行，這個特性簡直神奇。
Rust 社區很熱鬧，TiKV 因此也吸引了一大批社區貢獻者。

不過Rust的問題也很明顯：

編譯速度慢得要命，嚴重拖累開發速度；
早期生態幾乎為零，什麼輪子都得自己造，費了不少勁。

在提到 TiKV 的時候，不得不提犯的一個巨大的錯誤，就是起了個讓人誤解的名字 —— Region。

Region 本是 HBase 裏面的數據分片概念，結果碰巧雲計算廠商也用 Region 表示地理區域。結果現在跟客户聊 Region，經常雞同鴨講，痛苦無比。

這給我們敲了個警鐘：命名，真不是拍腦袋的事兒。隨便起個名字，將來可能要花巨大的代價去填坑。

現在想想，如果我們早清楚的看到雲的趨勢，我們也不會取這麼一個傻的名字了。

與 Spanner 的差距和妥協

雖然我們很多架構設計借鑑了 Spanner，但當年我們的客户基礎設施跟 Google 的環境差太遠了。Google 有TrueTime、Colossus 存儲系統，而我們客户都是傳統 IDC、物理機或虛擬機環境。

所以我們不得不做出妥協，設計了 Shared-Nothing 架構。

在當時，這個架構特別合適。但隨着雲時代的到來，這個架構逐漸顯現瓶頸，未來 TiDB 也必須逐漸擺脱這些舊包袱。

小結：技術驅動的黃金時代

回頭再看，TiDB 最初的那段時光，真的是程序員最幸福的時代：

天天專注於技術，單純而快樂；
不斷挑戰新的技術問題，收穫巨大的滿足感；
用純粹的技術熱情，吸引了大量志同道合的黑客們加入我們團隊。

這一切，也為我們後來的發展埋下了堅實的基礎。

三：商業化，我們怎麼活下去？

靈魂拷問：“客户在哪兒？”

TiDB 一開始的開發階段，大家沉浸在技術驅動的幸福裏，大家很難坐下來一起認真思考一個靈魂問題：

“我們到底靠什麼賺錢？”

對於當時的我們來説，寫出牛逼的代碼最重要，至於賺錢，好像沒那麼緊迫。再加上程序員普遍都有點“理想主義”，一聽到“商業化”、“賺錢”這些詞，總覺得俗不可耐。

但現實終究是現實。公司畢竟不是慈善機構，不賺錢遲早要涼。所以，越早解決“客户在哪”、“客户為什麼要買”這些問題，就越能少吃點苦頭。

現在回想起來，對我自己來説，真後悔沒早點想清楚這些問題。畢竟，早一點考慮客户的需求，對公司發展、對自己的成長都會更有幫助。

從“技術自嗨”到“客户導向”的痛苦轉型

程序員最難的轉型是什麼？答案可能就是從“技術導向”到“客户導向”。

我們早期吃過最大的一個苦頭，就是完全技術導向的思維，直接導致了一次慘痛的教訓。

TiDB 有個參數之前默認是 false，這樣性能很好，但宕機可能丟數據。我們在 2.0 版本做了個看似合理的決定：默認改成 true。

結果沒想到，這個小小的配置改動，給當時一些開源用户帶來了災難性的後果 —— 升級完性能暴跌，業務直接崩了。

事後我們才意識到：更好的處理方式是老用户升級保持舊配置，新用户默認新配置。這麼簡單的一個道理，我們居然沒想到，只因為腦子裏一直是“技術自嗨”，根本沒考慮真實的客户場景。

類似的錯誤後面也出現過幾次，每一次都像在提醒我們：

“做產品要以客户場景為中心，而不是自以為是的技術邏輯。”

慘痛的教訓：遊戲公司上線失敗事件

印象最深的一次教訓，發生在一家遊戲公司身上。這家公司要做一款全球化的遊戲，選中了我們 TiDB 作為底層數據庫。

上線當天，情況比我們想象的慘烈多了。我們親眼看着一個 SQL 熱點，生生把 TiDB 打崩了。當時那種感覺，真的是叫天天不應、叫地地不靈。

回頭想想，我們如果：

早一點 Review 客户的 SQL；
提前做一些熱點拆分的工具；

或許這次災難本可以避免。

但現實沒有“如果”，客户的業務因此上線失敗。這次慘痛的失敗，讓我們深刻認識到：

客户的真實場景遠比我們想象複雜；
數據庫生意不僅僅是技術問題，還涉及交付、服務和支持；
對客户業務永遠要保持敬畏。

從此，我們再也不敢輕易“技術自嗨”了。

銀行上線成功：轉型的關鍵里程碑

幸好，失敗之後，我們很快就有了一個翻身機會：一家銀行的核心繫統改造項目。

這一次我們徹底務實了一回：

和客户一起梳理了每一條業務邏輯；
提前 Review 所有可能踩坑的地方；
發現能力不足立馬改進；
做足了上線方案和應急預案。

最後的結果非常理想，項目順利上線，客户也給了我們非常大的肯定。這次成功，真正樹立了我們的信心，讓我們逐漸從“技術導向”轉變為“客户成功導向”。

那時候我們終於明白：

“產品好不好，客户説了才算。客户成功了，產品才真正成功。”

商業化轉型的漫長之路

客觀來説，從技術驅動到真正的商業化驅動、客户驅動，這個轉型過程是漫長而痛苦的。坦白説，到今天為止，我們身上依然有着技術驅動的“頑疾”。

但數據庫這門生意，我們越來越清楚：

它不只是一個技術產品，更是一整套服務體系；
除了產品本身的質量，交付、支持、售後缺一不可；
“客户成功”才是真正的終極目標。

小結：賺錢不丟人，客户成功才是真牛逼

寫到這裏，我想告訴所有程序員一句話：

“賺錢不是丟人的事，客户願意掏錢買你的產品，才是真正對你技術的認可。”

我們寫的代碼最終都是為了給客户創造價值，讓客户成功，公司才能真正成功，我們這些寫代碼的人，也才能真正實現自我價值。

四：可擴展性的力量

從被吐槽到爆發式增長：TiDB 3.0 的轉折點

早期 TiDB 雖然打着“分佈式數據庫”的招牌，但説句實話，性能真的不怎麼樣。經常客户用了就吐槽：“擴展性倒是好，可這性能實在是太差了。”

我們心裏很清楚，要真正贏得客户的認可，性能必須過關。於是，我們在 TiDB 3.0 版本上下了大力氣 - 在一些關鍵路徑上做了多線程處理優化，性能一下子提升了好幾倍。

3.0 版本發佈之後，我們驚喜地發現客户開始迅速增長——

“當性能過了門檻，擴展性立刻就變成了我們的超級武器。”

單車打不開的尷尬事故

擴展性強，意味着客户增長速度快。但客户規模上去了，問題也隨之變大。

記得有一次早晨，我出門掃碼開共享單車，突然發現打不開鎖，周圍一羣人也都在抱怨：“怎麼回事，今天單車都壞了？”

結果不久後得知，原來是我們 TiDB 數據庫掛了，導致整個單車系統無法開鎖。

那一瞬間我真的超級尷尬，自己的產品搞砸了自己的生活，這種滋味非常難受。

但也正是這件事情讓我第一次真正意識到——

“原來 TiDB 已經被很多公司用在了真正核心的業務系統上。”

客户相信 TiDB，就是因為相信它的擴展能力，但一旦我們掉鏈子，客户受到的影響也會更大。

磁盤爆滿的午夜驚魂

另一個印象深刻的案例發生在一個互聯網頭部客户的現場，當時客户的 TiDB 集羣規模已經超過百 TB。

結果有一天半夜，他們磁盤被寫爆了，TiKV 開始頻繁崩潰，整個系統岌岌可危。客户急忙找我們救火。

當時情況特別棘手：

刪除日誌、垃圾數據，結果發現刪的速度遠趕不上寫入的速度；
調度數據遷移，又因為 Raft Snapshot 也會佔用磁盤空間，越遷越爆。

我們在客户辦公室熬到了凌晨四點，最終想了個折中的辦法：

大幅降低調度頻率，控制 Snapshot 產生；
同時限制業務寫入速率，讓系統慢慢恢復平衡。

雖然最後解決了問題，但這個深夜的經歷，再次提醒我們：

“擴展性強意味着責任更大，客户越信任我們，我們身上的擔子就越重。”

為什麼客户放棄了競爭對手？

在海外市場，我們曾經輸給過某些知名競爭對手。客户一開始都會選擇更有名的競品，結果過了半年，客户又回來了。

原因很簡單：競品雖然名氣大，但到了真正業務規模上來之後，擴展性撐不住。

而 TiDB 卻能實實在在地經受住百 TB 甚至 PB 級別數據規模的考驗。

這個時候，我們才真正體會到，擴展性不是喊口號，而是客户真正選型時繞不開的剛需。

客户增長太快帶來的隱患

TiDB 在 3.0 後發展太順利，客户增長速度快到不可思議，甚至一度讓我們產生了盲目的自信。但後面我們逐漸發現，這種盲目自信埋下了不少隱患，尤其在產品質量上，後來爆發了不少問題。

但這一切，都是後話了。

小結：擴展性的力量與責任

TiDB 靠擴展性贏得了客户，也揹負了更大的責任。越是客户核心的業務系統，越容不得半點閃失。

這段時間我們深刻理解到一句話：

“擴展性，既是我們的超級武器，也是沉甸甸的責任。”

五：從混亂無序到初見曙光（產品驅動與客户成功驅動的轉變）

TiDB 4.0 的發佈之痛

TiDB 早期發展太快了，以至於我們逐漸陷入了一種無序而混亂的狀態。最典型的例子就是4.0版本的發佈。

當時我們延續着“一年一個大版本”的節奏，看似很穩，但實際內部非常緊張：每年大量的新功能堆疊在一起，導致測試周期嚴重不足，產品質量逐漸失控。

結果 TiDB 4.0 發佈後，我們連續發了 12 個補丁版本才把質量穩定下來，客户的抱怨、投訴幾乎把我們的信心打到了谷底。

那時候我經常半夜被電話吵醒，每天早上第一件事就是看有沒有客户因為版本 bug 又炸了。

痛定思痛，我們開始反思：

“是時候改變我們的做法了。”

沒有 PM 的自負

回頭看，我們當時犯了一個特別大的錯誤，就是整個公司幾乎沒有 PM（產品經理）的角色。

最搞笑的是，我們當時甚至自信滿滿地説：“我們不需要 PM，程序員自己就是最好的 PM。”

事實證明，這種想法蠢到極點。

沒有 PM 導致：

功能優先級沒人管；
產品戰略沒人想；
客户場景沒人深度研究；

最後，我們的產品變成了一鍋亂燉，沒有清晰的戰略方向，功能疊加得很隨意，也無法真正解決客户最核心的痛點。

PM 角色的引入：從技術到客户成功的轉型

後來，我們終於認清了一個事實：

“程序員不可能做好所有的事情，產品必須由專門的角色負責。”

於是，我們開始認真引入了專業的 PM 角色。他們的加入，帶來了一個非常關鍵的變化：

明確了功能開發的優先級；
每個版本都有了明確的主題；
真正以客户需求為中心，逐漸轉變成產品驅動和客户成功驅動。

這次轉型帶來的最大變化，就是讓我們從“技術自嗨”變成真正“解決客户問題”，逐漸找回了客户的信任。

從“一年一版本”到“兩個月火車發佈”，再到“半年發佈”模式

TiDB 4.0 的發佈慘痛教訓，讓我們認識到： “一年一版本”看似穩定，實則風險巨大。

於是我們改成了“兩個月一次”的“火車發佈”模式，快速迭代、小步快跑，每次發佈的功能不多，質量更好掌控。

但新問題又來了：版本太多了，客户都不知道怎麼選。如果發現一個 bug，要在好幾個版本之間不停地 cherry-pick，研發成本又特別高。

於是，我們最後找到了折中的方案——“半年發佈”模式：

既能兼顧穩定性，又能控制版本數量；
同時也給研發團隊足夠的時間保證產品質量。

以質量為第一導向：從 6.0 版本開始的徹底轉型

經歷了 TiDB 4.0 的慘痛經歷後，我們在 TiDB 6.0 開始，把質量明確放在了第一位。

這一次，我們真正下了大功夫：

大幅優化了內存使用，解決了 OOM 的問題；
系統地改善了磁盤 IO 抖動問題；
將大量精力放在穩定性優化上，而不是盲目追求新功能。

結果 TiDB 6.0 發佈後，客户反饋一下子好了很多。

雲時代下，重新回到“一年一個 LTS 版本”

但云時代來了，情況又發生了變化：

我們可以在雲上快速發佈功能，讓客户提前用起來；
通過雲的快速反饋，驗證功能穩定後，再整合到一年一次的 LTS 版本發佈中。

這個策略讓我們既能保持產品創新速度，又能保證穩定性。用雲的力量實現快速反饋，再用LTS版本提供長期穩定的保障，這個組合拳效果非常好。

數據庫的本質思考：客户數據處理工具

走到今天，我們逐漸開始認真思考：

“數據庫的本質到底是什麼？”

答案其實很簡單：

數據庫不需要很多 fancy 的功能；
最重要的是能方便、穩定、安全地幫助客户處理好他們的數據。

這個認知徹底改變了我們後續的開發策略，TiDB 越來越成為一個真正面向客户場景的數據庫產品。

小結：從無序到產品驅動與客户成功驅動

回顧這段歷程，我們從混亂無序，逐漸走向了清晰的產品驅動和客户成功驅動。

這個轉型雖然漫長而痛苦，但最終我們看到了曙光，真正學會了：

PM 的重要性；
質量第一的原則；
“小步快跑”到“雲時代”的靈活發佈策略；
以及數據庫本質的重新思考。

六：TiDB Cloud，那段辛酸又收穫頗豐的雲旅程

雲時代的誤解：把數據庫“搬到雲上”就完事了？

TiDB Cloud 的故事説起來挺長的。坦白説，這幾年做 TiDB Cloud，真的是走了不少彎路。

最初我們對“雲”的理解實在太簡單了：

“不就是把 TiDB 數據庫放到雲上跑起來嘛，這有什麼難的？”

結果現實狠狠地教訓了我們一次又一次，才終於明白： “雲數據庫”絕對不是簡單地把數據庫搬到雲上這麼簡單。

這就像是剛接觸 Kubernetes（K8s）時，我們覺得：“不就是寫個 YAML 文件部署一下嘛？” 但真上了生產環境才發現，事情比我們想象得複雜百倍。

早期 Kubernetes 的坑與教訓

在很早（2018年），我們就決定把 TiDB Cloud 構建在 Kubernetes 之上。當時 AWS 還沒有成熟的EKS 服務，我們居然天真地選擇了一個叫 Gardener 的開源項目自己運維 K8s 集羣。

這一決定後來變成了我們巨大的噩夢：

Gardener穩定性奇差，維護成本爆炸；
我們甚至有專門的工程師每天被折磨得痛不欲生；
後來花了整整數年，才成功從 Gardener 遷移到雲廠商託管的 EKS 集羣。

這次教訓深刻提醒我們：

“雲時代，要充分相信雲廠商的進化速度。”

本地盤到雲盤的轉型：理念的顛覆

更嚴重的錯誤是我們早期過於固執於本地磁盤：

覺得本地盤性能好，死活不肯用雲盤；
為了讓 K8s 支持本地盤的調度，花了無數精力；
結果後面發現，雲盤性能突飛猛進，而本地盤運維實在複雜得嚇人。

客户增長後，光本地盤的運維成本，就能把我們活活折磨死。

現在回頭再看，我們早期的堅持真的是：

“程序員的完美主義，碰到了雲時代的現實，結果就是狠狠地被現實揍了一頓。”

雲服務運維的“新世界”：我們是賣服務的

做傳統的軟件公司，我們只管把軟件交付給客户，運維是客户的事。

但云服務不同，客户買的就是服務。

SLA 得管好；
運維窗口得規劃好；
安全合規問題一個不能落；
客户一旦出問題，我們得隨時頂上。

做了雲服務之後，我才真正體會到：

“能做好服務運維，比寫個好軟件難上十倍。”

但也正是這種痛苦的磨練，讓我們逐漸成長為一個真正具備雲服務意識的團隊。

下一代 TiDB Cloud：從 Shared Nothing 到 Shared Everything

TiDB 最初架構是 Shared Nothing（共享無物），非常適合 IDC 時代，但在雲時代卻逐漸暴露了問題：

節點掛了就得重新調度數據；
存儲容量擴容依賴物理節點，擴容成本極高。

於是，我們開始大規模轉型：

將TiDB的數據存儲從雲盤遷移到 S3 對象存儲；
架構從 Shared Nothing 變成了更彈性的 Shared Everything 架構；
進一步服務化拆分，真正變成了微服務架構，極大提高了擴展性與靈活性。

有人問：“放到 S3 性能不就差了嗎？” 答案是：“不會，因為我們在緩存、訪問路徑等多層面都做了深度優化。”這個有空後面再説。

拆分微服務的最大好處就是資源利用率和靈活度明顯提升。比如：

可以把一些重 IO 的操作（如 Compaction）獨立成服務；
客户高負載時彈性擴展，低負載時迅速回收資源，雲成本下降顯著。

轉型之後，我們終於真正在雲時代找到了正確的打開方式。

小結：TiDB Cloud 的辛酸史與未來

回顧 TiDB Cloud 這段旅程，實在是一把辛酸淚，但也充滿了收穫：

早期對雲的誤解，讓我們交了不少學費；
從 K8s、磁盤選擇，到微服務架構，每一次的踩坑，都讓我們更接近雲的真諦；
客户運維體系的建立，也讓我們真正成長為一個雲服務導向的團隊。

如今，TiDB Cloud 已經佔了公司超過一半的營收。這説明了什麼？説明了雲不只是未來，更是現在。

儘管過程艱難，但我們終於找到了屬於 TiDB Cloud 的正確道路。未來，我們相信 TiDB Cloud 還能走得更遠。

七：全球化之路，程序員的國際化挑戰

國際化：這是一場信任遊戲

PingCAP 在真正走到全球市場面前時，我們就發現：

“為什麼全球的客户會相信一幫草根做出來的數據庫產品？”

畢竟數據庫不是一般的軟件，客户要把核心數據放進去，簡直就是把命運交到你手裏。

要建立信任，哪有那麼容易？

開源是我們全球化的最大底牌

好在 TiDB 從一開始就是開源的。這給了我們一個天然優勢：

客户可以直接下載代碼試用；
他們自己遇到問題可以翻翻代碼，看看 bug 怎麼回事；
信任的門檻一下子降低了很多。

我記得日本的一家支付公司就是這麼認識我們的：

他們最初用的是 AWS Aurora，但每次一搞促銷活動，Aurora 就會被業務負載壓垮。後來客户自己去 GitHub 翻開源數據庫時，找到了 TiDB，一試效果不錯，果斷遷移。現在他們的支付規模越來越大，TiDB 也成了日本市場支付行業的主流選擇之一。

開源的力量，真的不容小覷。

連續跑了三年，TiKV 崩了，我們卻笑了

更神奇的是上面這個日本客户，後來給我們報了個 bug：“我們的 TiKV 節點突然崩了！”

我們一看才發現：

“哥們，你這個節點三年都沒重啓過啊！”

居然有 TiKV 節點連續穩定運行了三年，我們先是嚇了一跳，接着是狂喜——

因為這説明了 TiDB 產品的穩定性已經到了一個新的高度。這件事也成了後來全球客户推廣時的最佳案例之一。

另外一次，日本 AWS 出現了 AZ 掛掉的嚴重事故，這個客户的業務服務受到了影響，但 TiDB 數據庫本身居然還能繼續對外提供服務。這件事直接大幅提升了全球客户對 TiDB 的信任。

捐贈 CNCF：開源不僅僅是放代碼

為了提高 TiDB 在全球的知名度，我們還幹了兩件大事：

把核心分佈式存儲 TiKV 項目捐獻給了 CNCF（Cloud Native Computing Foundation），成功成為 CNCF 畢業項目；
把內部開發的 Chaos 測試工具 Chaos Mesh 也捐給了 CNCF，讓更多開發者能用來驗證系統的可靠性。

這兩個項目的開源和捐贈，讓全球客户和社區更加認可我們，知名度也迅速提升。

Rust 語言帶來的“神助攻”

此外，我們早年大膽選擇 Rust 開發 TiKV，這個決定也給了我們意外的全球化助力：

Rust 社區本身全球活躍，TiKV 自然也吸引了全球開發者；
很多國外工程師願意貢獻代碼，TiKV 的生態不斷完善。

TiKV 逐漸在國際上成了 Rust 社區的明星項目，間接幫助我們拓展了更多海外客户。

國際化的真正挑戰：本地化做不好，國際化也沒戲

早期我們以為“國際化”就是把產品文檔翻譯成英文，日文或者其他，再派個銷售飛過去賣就行了。

後來我們才明白一句話：

“最好的國際化，就是本地化。”

不同地區的文化差異太大，技術再牛逼，客户支持做不好，客户一樣罵你沒商量。

於是我們開始認真做全球本地化：

在歐美、日本、東南亞成立本地研發中心；
提供 7x24 小時的全球本地化技術支持；
僱傭本地的銷售與售前工程師，真正理解客户文化和需求。

這才讓我們真正建立了全球化的競爭優勢。

參觀計算機歷史博物館的願望

記得 2018 年，我和 Ed 在美國 Mountain View 參觀了計算機歷史博物館。當時我們互相開玩笑説：

“希望有一天 TiDB 也能登上這裏的展櫃。”

如果那一天真的到來，那意味着 TiDB 真正被全球客户認可，變成了一個有國際影響力的數據庫產品。

這個夢想到現在依然激勵着我們繼續在全球市場努力前進。

小結：全球化，從程序員到真正國際化團隊

TiDB 的全球化之路，充滿了艱難和挑戰，但也收穫了無數寶貴經驗：

開源為全球化打開了信任之門；
Rust語言和 CNCF 項目，幫我們在全球社區建立了聲譽；
本地化才是國際化的真正精髓；
全球化團隊建設，是真正支撐全球客户成功的基石。

如今 TiDB 已經在全球擁有了大量客户，我們終於能夠自豪地説：

“我們是一個全球客户信任的開源數據庫。”

八：客户成功，是程序員最大的驕傲

客户成功到底是什麼？

客户成功，是 PingCAP 成立以來最核心的價值觀。

作為程序員，我們最開始都以為：

“寫出優雅、高效、牛逼的代碼，就是成功。”

但做了幾年數據庫後，我們才慢慢明白：真正的成功，只有一個標準——

客户成功。

如果客户的業務因為使用了我們的數據庫而變得更好，那麼我們的數據庫才真正算成功。

客户是最好的老師

我們為什麼這麼強調客户成功？

一方面很現實：客户掏錢買單，公司才能活下去，我們也才能安心寫代碼。

但更重要的一方面是，我們發現客户本身就是我們最好的老師：

客户往往比我們更懂業務場景；
客户的真實需求推動我們技術進步；
客户甚至幫我們突破了想象不到的邊界。

我記得北美有個客户，他們的研發負責人以前在 Google 負責 Spanner 和 Bigtable，整整幹了 20 多年分佈式系統。當我們 TiDB 出現一些問題時，他們給了我們不少寶貴建議。

這種來自客户的“高手過招”，真正讓我們團隊水平大幅提升。

客户推動 TiDB 突破邊界：50TB 單表導入

更誇張的案例發生在另一個北美客户身上，他們提出一個我們完全沒想到的需求：

“能不能支持導入單表 50TB 的數據？”

50TB 單表，這在當時對我們來説簡直就是一個瘋狂的要求。最初幾次嘗試全部失敗了，客户非常憤怒，甚至威脅：“一個星期內搞不定，合同就終止！”

我們連夜死磕技術難題，優化流程、提升性能，最終成功了。

剛想鬆口氣，又有個客户來了更大的挑戰：“我們這裏有個單表要導入 100TB 數據，可以嗎？”

幸好有之前的 50TB 經驗，客户自己竟然導入成功了。

這次經歷給了我們巨大自信：

“原來 TiDB 可以做到我們從沒想過的極致場景。”

SaaS 場景與百萬表支持：客户教我們做產品

另一個讓我們印象深刻的是一個頭部的 SaaS 客户。

客户問：“TiDB 能不能支持 100 萬張表？”

我們當時非常震驚：

一般 OLTP 系統咋可能有這麼多表；
但這家公司是 SaaS 模式，每個租户單獨數據庫，每個數據庫又幾張表；
因為租户數量巨大，一個集羣必須承載百萬張表的需求。

這種規模，我們之前從未考慮過。

為了滿足客户需求，我們直接對TiDB底層架構做了大規模重構：

優化 Schema 層；
重構優化器；
大量減少單表管理的內存佔用。

最終成功支持了百萬張表的極限場景。

後來其他 SaaS 客户聽説了這件事，也開始嘗試和選擇了 TiDB。可以説，這個客户需求，直接幫助我們打開了一個全新的市場領域。

研發支持客户，到底值不值得？

TiDB 研發早期，有一種爭論：“研發要不要直接支持客户？”

畢竟研發團隊都喜歡安靜地寫代碼，誰也不願意天天接客户電話、跑客户現場。

但我們最終還是決定：研發必須支持客户。

我們甚至專門成立了一個叫 Customer Advocate 的項目：

對於重要客户，分配一位研發負責人；
研發負責人需要深入理解客户場景和需求；
一旦客户有問題，可以求助這位研發負責人協調解決。

有一個研發負責人一年跟同一個客户開了超過 200 次會，聽起來簡直瘋狂。

但結果卻非常好：

客户獲得了最專業的支持；
工程師獲得了最真實的場景反饋；
產品獲得了更高的客户滿意度和忠誠度。

客户自己也開始用腳投票，先將他們的 HBase 切換到 TiDB，現在開始切更大規模的 Aurora。

客户成功的價值：最好的產品，來自客户的場景

回頭看，我們才深刻認識到：

客户是真正的專家；
真實的業務場景比紙面上的技術設計更重要；
只有深入客户一線，我們才能真正做出客户想要的數據庫產品。

這種堅持客户成功的策略，也為我們贏得了大量全球客户的認可。

小結：程序員最大的驕傲是客户成功

從“技術導向”到“客户成功導向”的轉變，對我們這羣程序員來説，並不是一件容易的事。

但當我們真正做到時，我們才發現：

“客户成功，才是我們作為程序員最大的驕傲。”

客户的每一句感謝，每一次信任，每一次業務的成功，都成為我們不斷前進的動力。

而TiDB能走到今天，靠的正是這種“客户成功”的理念。

未來，我們仍將堅定地踐行：

以客户成功為唯一目標，持續打造更好的數據庫產品。

九：我的十年成長，從程序員到技術管理者的蜕變

作為“員工一號”的十年旅程

十年前，我以 PingCAP 第一個正式員工的身份加入，親身參與了 TiDB 從零到一的全過程。這十年間，公司的快速成長與變化，也帶動了我個人成長的巨大轉型。

從一個單純熱愛技術的程序員，到如今帶領整個研發團隊的技術管理者，這條成長之路充滿挑戰與收穫。

程序員到管理者的第一次挑戰：尊重康威定律

管理組織的第一個重要原則，我學到的是“康威定律”（Conway’s Law）：

“組織結構是什麼樣，產品結構就是什麼樣。”

要想開發出好的產品，先要設計出合適的組織結構。

我們 TiDB 是分佈式的，組織結構也必須是分佈式的，這意味着管理起來挑戰更大：

大家分佈在不同地區，如何保持高效溝通？
如何避免信息孤島？如何保證團隊協作的效率？

最開始，我們的確吃了不少苦頭，但慢慢摸索出了高效的異步溝通和協作方式。

異步協作的奧義：代碼和文檔勝過會議

全球化分佈式的團隊，想開個會都難，這種情況下，我們只能充分利用 GitHub 平台，以代碼和文檔為中心，完全異步溝通：

每個功能都需要有明確的文檔；
每個重要的設計決策，都要經過公開的設計文檔 Review；
日常交流圍繞文檔， Issue 和 Pull Request 進行。

事實證明，這種方式比起開無數會議高效得多。

術語（Terminology）的力量：溝通的關鍵

最開始我們很少重視術語的統一，結果全球同事在交流時經常混亂不堪：

一個詞在不同部門、地區間會造成巨大誤解；
導致很多問題浪費大量時間在澄清概念上。

後來我深刻意識到術語定義的重要性，親自牽頭了很多術語的標準化定義工作。大家統一術語之後，溝通效率大大提升，團隊協作也更加順暢。

管理角色的進階挑戰：從 Leader 到研發部門負責人

從單純寫代碼的 IC（Individual Contributor）成長為 Leader，本身已經足夠有挑戰了。但再往上到部門負責人，管理的不再是單個工程師，而是管理者時，這個挑戰就更復雜了：

我必須學會放權，信任團隊；
我必須更注重團隊氛圍和文化，而不是親自解決所有技術問題；
我必須開始思考如何激勵下屬的下屬，讓整個組織高效協作。

這些能力遠遠超過單純技術能力的要求，對我來説無疑是一次巨大的挑戰。

組織轉型：產品驅動與客户成功導向的文化建設

管理這麼大一個團隊，我還學到一個非常重要的經驗：

團隊的文化，比流程、制度更重要；
團隊文化建設的核心，就是“客户成功導向”。

我們不再單純以技術為導向，而是不斷強調：

“我們做的一切，都是為了客户成功。”

在每次會議、每次 Review 裏，我都會反覆強調客户成功的重要性。慢慢地，整個團隊都形成了一個共識：

“寫代碼不是為了自我欣賞，而是為了客户真正的需求。”

這種文化建設最終深刻影響了我們的產品質量和客户滿意度。

個人成長的反思：什麼才是真正的“技術管理者”？

十年過去了，回頭看自己的成長，我經常問自己：

“什麼才是真正優秀的技術管理者？”

以前我以為技術牛逼就夠了，現在我才明白：

技術只是基本功；
溝通能力、組織能力、同理心、客户視角同樣重要；
真正優秀的技術管理者，不僅能寫代碼，更要懂人、懂業務，懂客户。

這才是我十年成長最大的收穫和反思。

小結：下一個十年，我的旅程才剛剛開始

在 TiDB 走過的十年，讓我從一個普通的程序員成長為一家全球化科技公司的技術管理者。

我見證了產品從零到全球客户使用的全過程，也見證了自己從技術專家到管理者的轉型與成長。

而十年之後的今天，我依然充滿期待：

期待自己繼續成長；
期待帶領團隊創造更大的成功；
期待自己能真正成為一名優秀的技術領導者。

就像當年加入 PingCAP 時一樣：

“我的下一個十年旅程，才剛剛開始。”

十：再見十年，迎接下一個旅程

講到這裏，這十年 TiDB 與我的故事終於告一段落。當然了還有太多的東西沒有提及，畢竟 10 年裏面發生了太多的事情。

回頭看，這一路有太多的意外、太多的挑戰，但更多的是驚喜與成長。從當初愚人節那天 Max 的一句話，到如今 TiDB 已經成為全球知名的開源分佈式數據庫；從當初單純地追求技術完美，到如今牢牢抓住客户成功這個根本目標；從最初簡單的創業理想，到如今成就全球化、雲時代的數據庫產品，這段旅程帶給我遠遠超出我想象的成長與收穫。

如果一定要總結，我想説：

開源是一種信念，讓我們能夠快速贏得客户與社區的信任；
產品驅動與客户成功才是企業成長的真正核心；
可擴展性不僅是技術能力，更是企業發展與客户成功的強大基石；
國際化是開源創業必經的挑戰，也是一次難忘的文化與思維拓展之旅；
作為一名程序員，最終的驕傲不是寫了多少行代碼，而是客户真正因為你的產品而成功；
從技術到管理的成長，痛苦但必要，它讓我學到了太多代碼之外的東西。

TiDB 走過了十年，而我的旅程也剛剛開始。我相信，下一個十年我們還會繼續成長、繼續挑戰，也會繼續以客户成功為目標，持續為全球客户提供更好的產品。

感謝這十年裏每一位幫助過我們的客户、夥伴和同事，是你們的信任與陪伴，讓這一切成為了可能。

期待我們下一個十年的再次相遇！

致謝

這篇文章是我口述，通過 ChatGPT 錄製，生成文字記錄，然後基於文字記錄，通過 GPT-4.5 整理生成了文章。我大概率猜測 GPT-4.5 通過我的口述，大概知道了一些我的寫作風格，所以寫出來的文章，我只是做了一些大概的修改。AI 真的越來越強大了。下一個十年，TiDB 也會在 AI 上面有更多的故事，不過這個就是後話了。