作者：唐刘｜PingCAP
导读
作为 PingCAP 的“一号员工”，TiDB 研发副总裁唐刘亲历了 TiDB 从一个开源小项目到全球知名分布式数据库的蜕变。本文，唐刘从亲历者视角，回顾了 TiDB 的技术演进、产品迭代和全球化历程，还分享了自己从程序员到技术管理者的成长与感悟。
这是一段关于技术理想、客户成功与团队协作的旅程，也是一次对开源精神、创新勇气和商业智慧的深度剖析。通过唐刘的视角，我们得以窥见 TiDB 背后的点滴故事，以及那些推动它走向成功的信念与坚持。
人生最宝贵的财富，莫过于回忆与反思。
时间一晃，十年已过。从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 上面有更多的故事，不过这个就是后话了。
编辑于 2025-04-19 14:12・广东