来源 | 云游格
作者 | 陈天舟
写这篇文章是最近接连发生的几个事情：
国外大厂纷纷裁员，就连硅谷最佳养老院 （不过确实是有太多摸鱼的人了）。
之前在 Google 同一个产品组的一个同事 David 也被裁了，我怎么会知道的呢，因为他跑到领英上发了一个离职帖，火了。
年过完回来，第一天上午，我们的微信用户群就炸了。上午开完周会，就看到大几百条消息，还有我在的其他几个数据库用户群也类似，原因是这篇公众号「 」。
然后那个被裁的 David，虽然职位是 SRE，但因为所在的是数据库组，而 Google 内部又因为没有 DBA，所以也承担了 DBA 的职责。他离职贴里还提到，有一次搞了一个大事故，让 Youtube 挂了半小时。以 Google 的各种 Infra 保障来说，也确实只有操作数据库的 DBA 有那么大能耐了（不过对于这个组里的 SRE 来说也还好，因为他们都有能把整个 Google 公司搞垮的数据库操作权限）：
读到这是不是以为接下来我也同意那篇公众号的观点，认为公司里不再需要 DBA ，把他们都裁了呢？如果是这样的话，这篇文章的标题后半句就应该是「哪个技术岗位最先遭殃」。而既然标题写的是「哪个技术岗位可以独善其身」，我其实接下来想表达 DBA 该是技术岗位里最稳的（在管理层保持理智的前提下）。
我自己的故事
我自己是研发背景，当时在 Google 的数据库组，我们负责的是 Google Cloud SQL，给内外部提供 MySQL，PostgreSQL 数据库云服务。当时和我们研发团队一起的，还有一支 SRE 团队，组内有不少经验丰富的 MySQL DBA，比如像业界知名的 Jeremy Cole。Jeremy 给 MySQL 贡献了不少的祖传代码，不过他的强项不在于写代码，而是帮大家排查各种线上问题。记得有一次我值班，排查一个客户的慢查询花了好久，都没看出问题来，正好瞄到 Jeremy 从旁边飘过，就赶紧叫住他，让他帮个忙，Jeremy 盯着屏幕扫了一会，就立马指出了问题所在。即使我们的研发团队不少也有扎实的数据库经验，像我之前也是开发数据库内核，但从排查数据库故障的实战能力来说，Jeremy 他们完全是在另一个等级的，团队例会上复盘客户的疑难问题，也都是他们 carry 全场。
后来我加入了蚂蚁，来到了真正的 DBA 团队，虽然我主管的是数据库平台工具这块，但是本身作为 DBA 团队，还是要承担 DBA 的职责，钉钉群的消息永远没有停过，各种给研发同学排查问题，答疑解惑。
蚂蚁和 Google，分别代表着国内外最顶尖的软件研发实力，在内部我也都看到相同的情况：
90% 的研发连基础的 SQL，数据库原理都不明白。
绝大多数线上的数据库问题，剩下的 10% 研发也搞不明白，只能靠百分比忽略不计的几个 DBA / 数据库 SRE 出马解决。
DBA 的技能点
PostgreSQL 的可以看 PostgreSQL DBA Roadmap https://roadmap.sh/postgresql-dba
另外也可以结合着看 ，作者本身也是一名久经沙场的 DBA：
Bytebase 的公众号也曾写过一篇「 」，做过一些阐述。
另外再举一个具体的例子吧：
类似 XID wraparound 这样的问题，云厂商也都是提供监控的。但是对于普通的研发，大家又怎么能参透这背后的玄机呢。就连 dtrace 作者 Bryan Cantrill 这样的工程师也只能感慨，吃过亏才能长记性。DBA 凭着经年累月排查故障攒下的经验，具备了无法替代的兜底技能，培养了像 Jeremy 那样瞄一眼我屏幕就能看出问题所在的直感。而在线上数据库出现故障时，这就显得尤为重要，因为如果让普通研发去处理，不仅是耽误处理的时机，也很有可能因为手忙脚乱，让问题雪上加霜。台上一分钟，台下十年功。
研发组织的视角
首先小的研发组织确实是不需要专职 DBA 的，随着云基础设施的完善，尤其在国外，无论是公有云大厂，还是像 PlanetScale，Neon 这样提供 Serverless 的 MySQL / Postgres 数据库，还是 Supabase 这样提供 PostgreSQL 数据库的 PaaS 平台，都大大降低了应用开发者使用数据库进行开发工作的门槛。尤其让许多之前的前端研发变成了全栈工程师。但这只是降低了入门使用的门槛，但数据库的专业性和复杂度还是在那里的。就像 Excel 人人都会用，但本身还是博大精深。数据库是计算机技术里皇冠上的明珠，我们把数据库最核心的部分叫做数据库引擎，也是因为它就像一台精密的引擎一样。当研发团队开始扩张，就需要有专人可以维护这台精密的引擎，因为这是驱动业务前进的核心。
而从组织分工来说，DBA 也是安全生产的最后一道防线，因为业务研发团队总是希望快速上线，如果组织里没有 DBA 把关的话，对于数据库一知半解的研发就很容易造成生产故障。如果没有人提醒，有多少研发能意识到给数据库加一个新字段/做一个 SELECT 查询，都可能导致整个数据库无法访问？像 David 那样身经百战的 DBA 也会操作失误，给 Youtube 造成半小时的全球宕机，如果让研发直接操作数据库的话，那数据库变更/查询 -> 数据库故障 -> 服务中断的这条故事线，可能就是接二连三地发生，直到整个团队像 Bryan Cantrill 说的一样都吸取了惨痛的教训。
Ops 里的其他职能或许都能交给 Dev，去搞 DevOps，但唯独数据库这块真的很难。因为通常研发看到的数据库大概是长这样。从另一个角度看，如果数据库不是那么的博大精深，Oracle 就不会成为最大的软件公司，国内外大厂的数据库研发团队就也不会都是独立的汇报线。
另外想着裁掉几个 DBA，省点钱的，可以去读一下 里提到的故障复盘报告，只要一年出一个这样的故障，给组织带来的损失就会大于雇佣一个 DBA 的成本。另外我也基本了解过国内一线互联网公司的 DBA 团队情况，都已经是最基本的生命维持配置。有好几家国内上市互联网公司，整个公司专职 DBA 就 2，3 个，就像开大卡车的司机一样，轮流开车，持续行驶在无尽的研发轮回中。
可是 Google 并没有 DBA ？
对，但你的公司也没有 Google 广告这样的印钞机业务。因为你没有那么多钱，所以：
Google 能招的程序员平均分是 100，你招的就只有 60。
Google 里最厉害的一帮程序员又去做了一个叫 Spanner 的数据库，如果内部的 Spanner 是 100 分，那外面的这些开源数据库也就 30 分。
Google 里比较厉害的程序员又会去做开发工具，Google 内部的研发工具体系是 100 分，那外面的可能也就 50 分。
这三点结合起来可以举一个最常见的数据库 Schema 变更场景来进行对比。Google 内部对 Spanner 数据库的变更流程完全是走 GitOps，Schema 存在 Google 统一的代码大库里，研发发起变更时指定的，也是类似于像 Terraform 那样，面向终态的全量 Schema，而 Spanner 会自己算出需要变更的差异。而外面大多数地方的做法：
指定的是面向过程的 ALTER DDL 语句 。
也不会用 GitOps，许多时候就研发在开发环境执行一下，然后把要在生产执行的语句通过聊天软件或者文档工具发给 DBA，再手动跑一下 。
可以看到 Google 无论是在 Schema 的变更方法和开发工作流上都更具先进性，更雪上加霜的是：
Google 的业务压力是 100 分，而外面的业务压力大概是 150 分，像国内的话差不多 300 分。
其他公司数据库这块的底子差了 Google 一大截，心气又那么高，这之间的差距，绝大多数是要靠 DBA 们人肉填上的。
最后
作为一个在一线写了 10+ 年代码的程序员，写过数据库内核，管理过 10 万级的数据库实例集群，也待过数一数二的 DBA 团队，面对网上现在出现的去 DBA 声音，还是要站出来说几句。
确实现在整体云原生， DevOps，然后到去年开始起势的平台工程 (Platform Engineering)，都在往让 Dev 承担更多职能的趋势发展。像 Ops / SRE 和 Dev / Platform Engineering 之间的关系，确实是此消彼长，但数据库领域绝对是一个例外，因为这是由从事数据库这项工作的特性决定的：
复杂度和危险系数双高的数据库运维工作，就需要设立 DBA 这样专门的岗位。
希望这篇文章可以让更多的人对数据库及其相关运维工作有足够的敬畏。不然的话，就比较容易受误导，觉得 DBA 也像之前的 PE 和 Ops 一样，随着 DevOps 和云服务的完善，可以化整为零，消失在组织架构中。
即使公司经营状况不好，技术线如果要做裁员，也非常不建议要裁本来就人数很少的 DBA。而且作为一个专家型岗位，优秀的 DBA 往往又会呈现出「善战者无赫赫之功」的感觉。
现在公司不再做梦去追逐上限，都切换到生存模式，保证下限。而在所有的技术岗位里，DBA 就是那个下限的兜底，保障着公司的最核心资产，业务数据的生命线。
对于一个中大型研发组织，如果没有 DBA，我可能无法想象一旦出现严重的线上数据库故障，他们将该如何应对。但我知道的是，当下一次再出现故障的时候，被追责的工程 VP 或是 CTO 不再会是那同一个人了。
最后贴一下和本文有关的几篇公众号文章和链接：
PostgreSQL DBA Roadmap https://roadmap.sh/postgresql-dba