您的位置:  首页 > 技术杂谈 > 正文

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

2024-02-07 17:00 https://my.oschina.net/u/6148470/blog/11033087 Bytebase 次阅读 条评论

镇楼图

file

三个角色

删库以及更宽泛的数据库变更场景中有三个角色,业务研发,DBA 以及使用的数据库变更工具:

  • 业务研发通常指的是后端研发。国内最主流的技术栈还是 Java,此外 Go 也有一部分,另有全栈的则使用 Node。这些语言通常会配备对应的 ORM 和数据库打交道,Java 的 MyBatis,Go 的 GORM,Node 的 TypeORM 等。
  • DBA 就是数据库管理员。有些公司即使没有全职 DBA,也会有看着数据库的那个人。
  • 数据库变更工具。公司业务稍微上了规模,一般会选择在专门的数据库变更工具上执行操作,开源的产品里比较主流的有 Archery, Yearning, Bytebase。

生命周期

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

  • 研发在数据库变更工具上提交了一个变更工单。
  • 工具可能进行一些自动化检测,修改字段会提示锁表,删库,删表会警告破坏应用代码的兼容性。
  • DBA 进行审核。
  • 审核通过后,进行发布。
  • 告警铺天盖地/客诉蜂拥而来,业务一排查,怀疑可能是之前的数据库变更引起的,拉上 DBA,实锤。于是再一起制定补救方案。
  • 经过几天的奋战,最终修复了问题。
  • 开始进行复盘。

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

场景模拟

我们先来模拟一个场景:

业务研发想在 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 主责,业务研发次责,因为

  • 工具没有自动检测出这个风险,进行提示。
  • DBA 作为专业人员在审核阶段没有发现锁表问题。
  • 最后是由 DBA 去执行了变更操作。
  • 业务研发提交了导致问题的 SQL,但要求业务研发了解这个 MySQL 的执行细节有点强人所难。

DBA 团队主张业务团队主责,DBA 次责,因为:

  • 业务研发应该为自己的业务负责,包括数据库在内。
  • 问题 SQL 是由业务发起的。业务研发并没有提示业务风险,比如业务的重要性,业务的高峰期等。
  • DBA 没有识别到这个问题,督查失职。

好了,到了这里两边其实都有各自的道理,小伙伴们可以停下来思考一下,更倾向于如何定责。下面说一下我的观点。

我认为这个情况应该是**「业务团队主责,DBA 次责」**。

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

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

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

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

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

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

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

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

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

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

场景泛化

我们再进一步把这个场景泛化一下。在垂直业务团队和横向平台团队的协作中,因为业务开发造成的故障,通常应该都由业务团队承担主责,否则的话,就会造成权责不对等,把平台团队推向消极合作的情况。

这个就像老师带着小朋友和家长们集体活动,照看小朋友的第一责任人始终是家长,如果要让老师承担主责,大概率就不会组织活动了。当然这也有例外,比如假设老师罔顾家长的嘱托,携带小朋友参加不适合的活动,造成意外,那就是老师的责任了。

回到模拟的场景,业务研发应该做的,是给 DBA 更多的业务风险提示,比如说哪些高峰时段不能做变更。如果研发说了这些,但是 DBA 依然置若罔闻,发布造成事故,那 DBA 也自然难辞其咎。

故障定责是一个激烈的话题,关乎到大家的奖金,加薪,升职。本文尝试给出一个判定的原则,也欢迎大家留言探讨。回忆起那些年参加过的复盘会议,就像抄起刚一同肝完的啤酒瓶,朝对方劈头盖脸扔了过去。我心中不禁泛起丝丝寒意,想到了鲁迅的呐喊:

「 从来如此,便对么?」


💡 更多资讯,请关注 Bytebase 公号:Bytebase

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接