上周 Bytebase 发布了 1.0.0，同时也推出了团队付费版。
Bytebase 的第一次提交发生在 2021.1.27, 到 1.0.0 版已经累计了 3500+ 的提交，近 15 万行代码：
而第一个对外 0.1.0 的开源版发布于 2021.7.9，我们基本保持 2 周一个迭代的速度，一步步地走到了 1.0.0 的版本。
Bytebase.com 应该是所有数据库相关产品里，在官网首页上，DBA 这个词出现的最多也是被放在最显眼位置的。之前看到 Bytebase 的同学来咨询，大致分为两拨人，一拨是开发者 (Developer)，当中不少不太理解这个场景需要一个工具。另一拨是 DBA，这其中相当一部分人眼中带光，因为总算有一个专业团队出来替他们做工具了。但也有 DBA 带着疑惑，就这玩意居然还能写 15 万行的代码，这不是我们一个 DBA 用 Django 2 周就能撸出来的东西么 (DBA 的工作效率确实是很高的，后文会提）？
对于开发者的反应，我们是理解的，但是对于后面那部分抱有疑问的 DBA，我想可能还是 Bytebase 对于目标用户，也就是 DBA 的价值传递还不够清晰，所以接下来这句话是重点：Bytebase 是一款为 DBA 量身定制的工具，而且 Bytebase 是想重新定义 DBA 的整个工作流，重新想象和定义 DBA 这个职业。这也是为什么 Bytebase 光自己的 schema 文件已经超过了 1000 行，代码行近 15 万，未来甚至可能破百万。我们带来的是重塑 DBA 这个工种的工具。在去年 Bytebase 开源版发布的文章中有下面这张图（后来还被大厂山寨了）：
上图里的 Figma 重塑了设计师工种，而 GitLab 则把开发工程师，运维工程师，安全工程师这几个工种的职责重新定义了一遍。再进一步说 Figma，Figma 不仅是定义了设计师和产品经理/前端工程师间的工作流，而且又通过比如 Design System 的产品能力帮助设计师的职责从切图扩展到了定义整个产品，整个公司的品牌，格调上。
再说另一个火的不行的工具 dbt，也重塑了数据工程师的工作流。
而通常 dbt 的上游是业务数据库，这些业务数据库就是由 DBA 团队来管理的。但当下 DBA 更多关注的还是数据库实例本身的运维工作，而更有价值的应用开发流程和业务数据本身并没有太介入。明明在业务数据的最上游，却只能放任自流，难道是 DBA 们不想么，在我看来，许多时候也是他们实在力不从心。
1. 接客压力大，公司里 DBA ：研发配比好点的 1 : 300，夸张的超过 1 : 1000。应该是所有产研工种里，和研发配比第二失衡的，更失衡的只有 CTO 和研发的配比了（当然也可能是并列的）。2. 责任重大，能把公司瞬间搞垮的人里，至少一半都在 DBA 团队（这点 CTO 往往还做不到）。天天在刀锋上行走，不小心一个 fat finger 就完蛋。而即使自己一直小心翼翼，业务研发一个误删库，往往整个 DBA 团队要几天连轴转去擦屁股，背后被各种 CXO 焦虑的眼神盯着，终于处理完问题后，还要被拉去开闭门复盘会。3. 天天被研发部门投诉，不让做变更，不给查数据，影响业务。4. 数据库云平台越做越好，业务研发绕过 DBA 自己搞的胆子越来越肥，但出了问题又要找 DBA 解救。
一面是云原生，微服务的滚滚洪流让系统复杂度越来越高，一面是人手不足的 DBA 团队整天疲于奔命。当运维们一边左手 k8s，右手 ELK，进行了生产工具的升级，一边捧着 SRE 宝典，念着可观测 (observability) 的经，逐步完成了职业的转型，DBA 们还是守着一堆祖传的脚本，用着自己挤牙膏时间搭出来的拖拉机工具，重复着告警，工单，汇报，背锅的无尽轮回。
诚然负重前行是痛苦的，但更让人绝望的是偶尔的抬头看天，却发现还是漆黑的一片。珍妮纺织机和蒸汽机重新定义了工人这个职业，VisiCalc 和 Excel 则拉开了电子办公的序幕。再看 Figma 之于设计师，dbt 之于数据工程师，生产工具的革新往往是工种革命的第一要素。多年前，曾在 Google 工作过的工程师研发了一个新的开源监控方案 Prometheus，时至今日 Prometheus 已经是业界的监控标配。凑巧的是 Bytebase 的两位创始人也来自 Google 云计算部门，我们虽然是研发背景，但负责过全球数一数二规模的 MySQL & PostgreSQL 集群，我本人还在蚂蚁集团负责过整个 DBA/开发者工具/生产力协同工具平台。这样的背景让我们成为了整个业界里最适合对 DBA 工具进行革新的团队。火种点燃黑夜，Bytebase 要赋予 DBA 全新的想象空间。Google 发明了 SRE 这个概念，当下的 SRE，有被当作工种的，有被看成工作流的，有被用作理念的，但不管哪种，传统的运维工程师戴上了 SRE 的帽子，舞弄着 Prometheus 们的棒子，总之是站上了云原生的舞台。Bytebase 在产品设计的过程中，也一直在思考 DBA 这个同样古典的职业，在云原生的时代下新的技能组合，竞争力，职业发展该是如何的。而 Bytebase 又如何像诸如 Prometheus 们之于传统运维一样，帮助 DBA 完成云原生时代的转型。
正好前两天，我读到了一篇 Datadog 数据库团队的案例 “How Datadog Ensures Database Reliability with Temporal” (BTW, 案例里 Datadog 团队面临的问题也是 Bytebase 希望通过更加产品化的方案去解决的），文中 Datadog 的 DBA 团队叫做 DRE (Database Reliability Engineering)，这个词给我带来了启发。
结合 Bytebase 的产品我又琢磨了一下，最终提炼的还是 DBA 这个词。只是这个 DBA 已经不再是传统的 Database Administrator，而变成了 Database Architect。Bytebase 的顶层设计，场景是面向企业级协同，核心是研发工作流和数据结构体系管理。Bytebase 也专门提供了 DBA 这个角色，来掌控整个数据库应用研发的流程体系。通过 Bytebase，DBA 可以收口所有业务研发和数据库之间的交互，同时 DBA 可以介入到业务架构（尤其是在早期设计环节）。这样 DBA 能在架构层面进行更高效的体系化管理，从被动的运维救火员转型成主动的架构规划师。
事实上，Bytebase 的一个愿景就是变成 DBA 的一项技能。像 Prometheus, Elasticsearch 这些产品一样出现在招聘 JD 上，写在 DBA 们的简历上。惊喜的是，确实有社区用户开始这样做了：
希望 Bytebase 早日能成为业界 DBA 们一致的选择，也一起去重新想象和定义 DBA，这个古典而永恒的角色。
DBA is Dead! Long Live DBA!
上周我们也刚建立了 Bytebase 用户群，面向 DBA 和开发者，目前已经有几十位同学了，我们会在每个工作日分享无论是 Bytebase 还是整个业界数据库领域相关的内容，也会进行产品方面的答疑，有兴趣的话，请扫码申请进群。
Bytebase.com 是一款聚焦在团队协作场景下的数据库结构变更和版本管理（database schema change and version control for teams）的开源工具，主要解决研发工程师和 DBA 在变更数据库结构时的协同问题。