查看原文
其他

DBA, Database and Developer 十日谈

Lucy Bytebase 2022-05-27

Note: 本文为真实故事,虚构背景。十日谈的10个故事均直接翻译自 Hacker News 上的讨论帖 Ask HN: Is DBA still a good job? (https://news.ycombinator.com/item?id=31309729) 中的回答。


故事

10 个背景各异、来自不同团队的开发者还有 DBA 醒来后发现自己被关在一个封闭的房间中。门上悬一块牌匾,上书三个字母——「DDD」,门窗落锁,屋里放了不少水和食物。

大家面面相觑,此时,挂在一面墙上的电子屏突然闪烁一下,屏幕亮起,上面写着离开房间的方法:「每人每天讲一个和 DBA 有关的故事,十天之后方可离开。」
其中一人不屑:「好蠢的规则,不讲故事又能怎么样?」
电子屏上换了一句话:
「不讲故事也可以离开,代价是所在公司 / 团队的数据库将被 全部删除。」
屋中一片死寂。沉默半晌后终于有人开口:
「那…我来贡献第一个故事?」


Day 1 真希望我们能有个 DBA

大约 6 年前,我们公司有一个 DBA,他是我合作过的最聪明的人之一,对他的领域内的东西了如指掌。我会向有扩张想法的人强烈推荐DBA。老实说,我觉得当时要是没有他,我们就不会扩大规模。我从他那里学到了很多东西。
他因为脾气太差被炒掉了,我们决定不再找新的 DBA。我为他的离开感到难过,但也很高兴没人对我大喊大叫了。说起来有点蠢,但我对整个事情的感觉真的很不稳定,很复杂。我非常喜欢他这个人,喜欢和他谈论音乐和电影;但他会在瞬间川剧变脸,毁了你的一整天。
说实话,我希望我们有一个 DBA,我最后承担了他的很多责任。我很想有一个可以向他学习的人。基本上,我已经对优化报告感到非常厌烦了。
电子屏闪了闪,在众人惊异的目光下总结了第一天的故事:
「真希望我们能有个 DBA」


Day 2  都很出色,都是混蛋

说来离谱,也很有趣;我合作过的仅有的两个 DBA 完全符合昨天故事里的这种描述。

第一个人很容易生气,经常大喊大叫,说他有权因我们错误的架构决定对我们进行惩罚,我以为他是在开玩笑。我只是笑了笑,但他更生气了。五到十秒钟后,我明白了——他是在口头上惩罚我们对数据库的查询太多。
第二个人的情况类似,但没有大喊大叫。他对于自己的领域保护欲很强,对我们与数据库的整合几乎持反对意见。
这两个人都很出色,教给我的东西比我在这里能叙述的还要多,他们都很搞笑、很有趣......但也都是混蛋,两人都或多或少因为这个原因被炒掉的。
当产品成熟、系统也优化到比较好的状态时,公司就把他们解雇了。
电子屏闪了闪:
「都很出色,都是混蛋」
在座的 DBA 们眼皮跳了跳。


Day 3 消失的 DBA

这是 DBA 走火入魔故事集吗?
我曾在一家公司工作过,想雇一个人做 Postgres DBA。我以前在另一家公司认识的他,他是 MS SQL DBA,我希望他能来担任这个角色,他说他可以的。在之前的公司里,这家伙救过我们一命。
我们给了他一个月的时间来熟悉 Postgres。这位大哥消·失·了,我们把他的 vpn 密钥吊销了,因为所有人都觉得他在搞鬼。一个月后,他发了一封很长的邮件,说他如何与警察发生争执,然后被关进了监狱......这封邮件啰啰嗦嗦,实在没办法认真对待。我们问一个共同的朋友这到底是怎么回事,他说,由于他工作太忙,他的妻子把他的手机没收了。
我想在那之后,我们叫他 「ballgag ***」(请自行用你最不喜欢的人的名字填空)。
不过这些人的能力是毋庸置疑的,我听说他后来得到了一份在微软的工作。
电子屏闪了闪:
「消失的 DBA」


Day 4 他应该 「无所不知」

我在和一个年长的 DBA 相处时有过非常相似的经验,他 40 多岁的时候正在上大学,同时在外面工作。他很擅长他自己领域内的知识,对优化 ETL 过程有很大的帮助,但是他可以在瞬间变得很让人讨厌,而且对有大学学历的年轻分析师有很大的意见。

唯一的问题是,这家伙在 SQL 和 Bash 之外没有任何编程经验。每次他在会议上遇到关于调用 Java 程序的问题时,他都会等到会议结束,私下抓紧时间向我请教。因为他的专业角色应该是 「无所不知」的,意味着他不能问一些过于基础的问题,也不能尝试(至少是公开尝试)学习他领域之外的东西,这是一个公认的弱点。
最后,我们迁移到了亚马逊的 Redshift 上,而他也逐渐被调到了一个越来越小的角色,现在他只是负责一些两年前就已经创建的 JIRA 工单。他可能也知道如今没法在其他地方找到类似的高薪工作了。
电子屏闪了闪:
「他应该‘无所不知’」


Day 5 「别碰我的数据库」

你们之前讲的和我与两个非常、非常优秀的 DBA 合作的经历很相似。
我现在在想,是不是这个工作本身的一些特点导致了这些特定行为的出现。一会儿,他们让人心旷神怡,乐于助人而且态度和善;可是一眨眼,他们就会因为一些看似轻微和随机的过失而把人骂得狗血淋头,并说一些诸如 「 你**的是在破坏我的数据库 」的话。
现在想想,这些人让我想起了「爆裂鼓手 」中的 JK Simmons 角色。
电子屏闪了闪,这次是一张画:


10 个人中的 DBA 们耐心地听了 5 天,看到这幅画终于忍不住了,开始讲述自己的经历。


Day 6 对 DBA 不满意,就自己成为 DBA

我曾经是一名开发人员,由于需要而成为了一名 DBA。在我过去只是一个开发人员时,我无法从 DBA 那里得到我需要的支持,所以现在我努力让自己变成过去的自己所需要的人。
当 DBA 是一场无休止的战斗,需要对抗一些开发者试图创造的混乱。数据模型确实应该由具有更多知识和经验的人进行验证。另外,一些年轻的开发者提出了一些疯狂的想法(例如,我们不应该使用外键)。还有人想加载疯狂的数据在数据库中进行处理,而不是预处理,或者使用一个暂存数据库。正在实施的坏主意源源不断。
当一个糟糕的想法被实施时,真的很难撤销它,而且往往会造成更多的混乱:你需要物化的视图来解决糟糕的建模,或者奇怪的视图来补偿重复的数据,等等。
所以,是的,DBA 是一个非常重要的角色。关于它是否是一份好工作,这取决于你的公司是否认真对待它,并把你放在开发过程中,否则你将会有很多压力。
电子屏闪了闪:
「对 DBA 不满意,就成为 DBA」


Day 7 对那个公司而言,我的作用是无价的

我不愿意想象有多少初创公司甚至没有创建索引,而只是认为这是一个数据库问题,只是一味增加 CPU / RAM 的大小。
我曾在一家半创业公司担任过几年的数据库工程师,我的职责是指导开发人员编写高性能的 SQL(并为他们编写索引),架构他们的模式以符合我们未来的计划和其他各种数据库任务(管理查询计划,成为数据库功能集的专家等等)。我甚至创建了一个内部课程:SQL 学校,学生包括了董事/客户支持团队。
对于那个特定的公司来说,我的作用是无可估量的,有了专家编写查询和处理数据库,新功能只需要原来 1/2 的时间就可以建立完毕。我对我们有 20 年历史的代码库进行了程序化分析,有5000个各不相同的查询,如果考虑到动态 SQL,还另有 3000 个。不瞒你说,这完全是个烂摊子,但如果我不存在,他们会需要更多的数据库资源。这是一个糟糕的代码库,任何重构和避免这种混乱的计划仍然需要我的角色来完成。
我喜欢那份工作,但要过渡到其他的角色是非常困难的,现在使用其他的解决方案更容易。
电子屏闪了闪:
「对那个公司而言,我的作用是无价的」


Day 8 疲惫但收获颇丰

我认为在大多数组织中,DBA 这个角色实际上是外包的,而且这种策略会带来所有的权衡因素。我恳求我的前雇主订购一家好的 PostgreSQL 支持公司。出人意料的是,我们选的那家公司自己也在不断寻找新的DBA来维持增长.....

在过去的 10 年里,我在一家小公司担任数据库工程/管理职位。这份工作很累,因为管理层觉得依靠一个人去管理整个数据栈这件事没什么。不过也让我收获了成就感,因为这表明 CEO 眼中的我比实际上的我更加聪明,我对 SQL 的了解足以让我显现出突出的价值。
我花了几年时间抱怨我的同事们对数据库不够了解,这导致了不必要的错误和糟糕的性能。
我希望公司能够提供一些关于我们所使用的数据库的基本课程,特别是对那些初级的开发人员。
相反,我们换了 11 次数据库,现在我也不知道这个数据库了。
但是,错误和糟糕的性能仍然存在。
电子屏闪了闪:
「疲惫但收获颇丰」


Day 9 冲突来源于缺乏理解

我认为这种冲突往往来自于开发人员对网络工程师 / DBA 所负责的底层技术没有太多的了解而产生的挫折感。
网络和数据库是抽象的,但它们本身又很容易出错,而开发人员往往希望把它们当作神奇的黑盒子,也就不去深究它们内部的工作原理、约束、权衡等。这使得网络工程师或 DBA 和软件开发人员之间的接口成为一个自然的冲突场所。
(你甚至可以在这个主题贴中直接看到这一点,有人抱怨说 DBA 正在惩罚开发人员 「查询数据库太多」。最有可能的是,DBA 实际上是对他们查询数据库的方式感到不满,而不是说他们查询得太多,但开发人员希望它 「能查到就行」,所以这种区别对他们来说并不重要)。
电子屏闪了闪:
「冲突来源于缺乏理解」


Day 10 失落的艺术 —— 数据建模和 SQL

在我以前的工作中也是如此,我们确实有一些人在某些方面非常出色,并且对数据库很感兴趣。我们有非常扎实的 Redis 和 PostgreSQL 设置,以及一些用于处理 Redis 中简单数据的高级玩意儿——但是一旦这些知识随着人员流失而消失,为继续个人发展提供空间,同时使用两个完全不同的 DBMS 在一个小团队中工作很困难的,因而它就一直是大家所不愿涉猎、不喜欢、甚至是被永远抛弃的。
老实说,我认为大多数公司在 hosting 方面损失最大的事情就是开发人员没有正确使用数据库,100% 是这样的。数据建模和 SQL 已经成为一门失传的艺术。
电子屏闪了闪,流下几滴电子眼泪:
「失落的艺术—数据建模和 SQL」


尾声

最后一个故事讲完后,门窗的锁都开启了,大家急忙赶回各自的办公室,检查过后发现数据库无恙,于是安心开始了一天的工作,专注得仿佛过去的 10 天不曾存在过。

一切其实都起源于这句话:
「 现如今当 DBA 还算是有一份好工作吗?」

我们在 Hacker News 上提出了这个简单的问题,没想到一石激起千层浪,收到了几百条回答与讨论。评论者所站的视角、提出的观点五花八门,其中不乏许多很有趣的论点,除去对 DBA 这一职业本身的关注外还涉及到不同角色之间的关系、不同时代对于从业者技术要求的变迁以及对数据库和数据相关知识的看法。
看过这些热切的讨论后,我们不愿意这样精彩的争鸣随着时间流逝变成一个沉底的贴子,于是决定根据讨论内容整理 D·D·D (DBA, Database, and Developer) 系列文章,从而让这些观点得以留存,并且让大家对于 DBA 这一职业有更加丰富和多维的了解
而作为本系列的预热和第一篇,则是从评论中整理出了 10 个有关 DBA 的小故事。评论者们中有些做过全职 DBA,有些作为开发者与 DBA 打过交道。希望大家看得开心。如果当中的故事能够引起有 DBA 经历的朋友的共鸣,我们也很期待能够了解和记录您所经历过的故事,如果您恰巧是 DBA,是开发者,或者在工作中和数据库相处过,添加小助手,备注暗号 「DDD」 来表明身份,让自己的声音也可以在我们的系列中被听到。


⚠️ 严正声明:没有开发者或者 DBA 真的被绑架到小黑屋里过。

从 SQLite 到 PostgreSQL
康威定律的边界 - Project (项目) 的设计脉络
解读 Retool 团队升级 4TB PostgreSQL 踩坑
我们有一个可以上 HN 首页的点子,就差一个前端/全栈 实习生了╮(╯▽╰)╭



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存