ReaderMX.
ITPUB

研发误删的库，凭什么要 DBA 承担责任

I天舟约 5 分钟
Image
三个角色
删库以及更宽泛的数据库变更场景中有三个角色，业务研发，DBA 以及使用的数据库变更工具：

  • 业务研发通常指的是后端研发。国内最主流的技术栈还是 Java，此外 Go 也有一部分，另有全栈的则使用 Node。这些语言通常会配备对应的 ORM 和数据库打交道，Java 的 MyBatis，Go 的 GORM，Node 的 TypeORM 等。

  • DBA 就是数据库管理员。有些公司即使没有全职 DBA，也会有看着数据库的那个人。

  • 数据库变更工具。公司业务稍微上了规模，一般会选择在专门的数据库变更工具上执行操作。
Image

生命周期

交代完出场角色，我们再来说一下，数据库变更的整个生命周期：

  1. 研发在数据库变更工具上提交了一个变更工单。

  2. 工具可能进行一些自动化检测，修改字段会提示锁表，删库，删表会警告破坏应用代码的兼容性。

  3. DBA 进行审核。

  4. 审核通过后，进行发布。

  5. 告警铺天盖地/客诉蜂拥而来，业务一排查，怀疑可能是之前的数据库变更引起的，拉上 DBA，实锤。于是再一起制定补救方案。

  6. 经过几天的奋战，最终修复了问题。

  7. 开始进行复盘。

之前回顾的Linear 删库故障就是这样一套流程。到了复盘阶段，国外普遍采用 blameless postmortem，对事不对人，但国内通常会给故障定主责和次责。安全生产的角度来说，定责任人的威慑力肯定更强。但对于数据库变更，往往一出就是大故障，承担主责往往意味着全年绩效最低档。所以每当业务研发和 DBA 还有他们的主管走进会议室，都会很认真地想着怎样把锅扣给对方一起复盘。
Image

场景模拟

我们先来模拟一个场景：
业务研发想在 MySQL 8.0 上把一个 VARCHAR 列的长度从 20 改成 100：
ALTER TABLE person MODIFY name VARCHAR (100); 
研发在数据库变更工具上提交了这个语句，因为 DBA 也读了 MySQL 8.0  官方文档，知道 MySQL 8.0 修改列不会锁表导致不可用，所以审批通过，然后 DBA 执行这条语句。业务居然挂了！原来 MySQL 8.0 里当把 VARCHAR 长度修改为超过 64 时，还是会锁表的！
切回复盘室里认真讨论的气氛。业务团队主张 DBA 主责，业务研发次责，因为：

  1. 工具没有自动检测出这个风险，进行提示。

  2. DBA 作为专业人员在审核阶段没有发现锁表问题。

  3. 最后是由 DBA 去执行了变更操作。

  4. 业务研发提交了导致问题的 SQL，但要求业务研发了解这个 MySQL 的执行细节有点强人所难。

DBA 团队主张业务团队主责，DBA 次责，因为：

  1. 业务研发应该为自己的业务负责，包括数据库在内。

  2. 问题 SQL 是由业务发起的。业务研发并没有提示业务风险，比如业务的重要性，业务的高峰期等。

  3. DBA 没有识别到这个问题，督查失职。

好了，到了这里两边其实都有各自的道理，小伙伴们可以停下来思考一下，更倾向于如何定责。下面说一下我的观点。
我认为这个情况应该是「业务团队主责，DBA 次责」。

针对业务团队的几个主张：

  1. 工具没有自动检测出这个风险，进行提示。

那好，既然 DBA 引入带自动检测的工具反而留下把柄，那大家还是提交在文档上吧，完全没有自动化检测。

  1. DBA 作为专业人员在审核阶段没有发现锁表问题。

双方这点都有共识，但光这条属于失查，次责。

  1. 最后是由 DBA 去执行了变更操作。

是 DBA 执行还是研发执行，这是流程的设计。谁去点执行按钮都改变不了这次故障的发生。

  1. 业务研发提交了导致问题的 SQL，但要求业务研发了解这个 MySQL 的执行细节有点强人所难。

没有错，但我们来换一个角度。研发写代码调用了一个 API，让 API 的维护者审核一下。结果 API 维护者也没有审核出来一个 bug，上线后导致故障。研发确实可以说让他了解 API 的实现细节有点难，但是研发为了完成自己的任务，使用了一个自己不熟悉的 API，那是不是应该由自己承担风险？

但在实际 PK 中由 DBA 承担主责的情况时有发生，往往是因为第 3 点，最后是由 DBA 点了发布按钮。但就像上面说的，我认为这点是站不住脚的。流程设计让 DBA 点那下，是因为由 DBA 来点效率是更高的，但如果因为 DBA 点了而要背锅，那 DBA 就会拒绝这个流程，甩给研发自己去发布，这样流程只会更加低效。这里也要澄清一下，也不是 DBA 点就一定是更高效的流程，但只想表达定责应该和谁最后点发布那一下无关。

Image

场景泛化

我们再进一步把这个场景泛化一下。在垂直业务团队和横向平台团队的协作中，因为业务开发造成的故障，通常应该都由业务团队承担主责，否则的话，就会造成权责不对等，把平台团队推向消极合作的情况。
这个就像老师带着小朋友和家长们集体活动，照看小朋友的第一责任人始终是家长，如果要让老师承担主责，大概率就不会组织活动了。当然这也有例外，比如假设老师罔顾家长的嘱托，携带小朋友参加不适合的活动，造成意外，那就是老师的责任了。
回到模拟的场景，业务研发应该做的，是给 DBA 更多的业务风险提示，比如说哪些高峰时段不能做变更。如果研发说了这些，但是 DBA 依然置若罔闻，发布造成事故，那 DBA 也自然难辞其咎。
故障定责是一个激烈的话题，关乎到大家的奖金，加薪，升职。本文尝试给出一个判定的原则，也欢迎大家留言探讨。回忆起那些年参加过的复盘会议，就像抄起刚一同肝完的啤酒瓶，朝对方劈头盖脸扔了过去。我心中不禁泛起丝丝寒意，想到了鲁迅的呐喊：「 从来如此，便对么？」
【DTCC2024最新大会议题】
👇👇👇

Image

Image

KEEP THE THREAD GOING

更多来源文章