汪小姐和宝总，像极了当年做DBA的我和服务过的业务

原创多明戈教你玩狼人杀 2024-01-15

1078

周末终于把跨年的热剧《繁花》看完了，剧里面诸多角色各自迎来各自的结局。虽然早就有了预期，宝总不会和汪小姐在一起，但是仍然还是为之惋惜。一个曾经是外滩27号的小汪，一个曾经是是思南路上的阿宝，互相成就又相爱相杀。也许宝总不是汪小姐最好的客户，但一定是她付出最多的客户。有那么几个桥段，甚至让我想起自己当DBA时，服务过的业务同事。

同事A，教培行业人力资源部

彼时的我，是一个刚入公司的萌新，工作时长也不够一坤年。刚刚开始对DBA这个岗位有点心得，却又总想着跃跃欲试做点大的。当时和我对接最多的，是HR部门的一个女生，她年纪估计和差不多，作为部门资历最浅的员工，很多其他同事都不愿意做的事都交给了她。也许是两个萌新没有什么历史包袱，我很多大胆的想法，她也都无比支持。

上一任DBA留下的备份方式是Oracle数据泵，但是每次往测试环境做恢复测试的时候，总要折腾几个参数，尤其是我那会对数据泵几乎没有什么使用经验。于是我跟业务部门说，要不以后咱们都改RMAN备份吧。业务部门的同事并不了解这两种区别，A却十分积极响应，我们俩在那段时间里，做了很多备份恢复测试。每次我把数据还原到测试环境，她总会积极地去验证。经过多次全备、增备、全量恢复、指定时间点恢复测试之后，我和A最终交给业务部门一项报告，主要内容是：

RMAN作为物理备份的手段，性能比数据泵要好
RMAN可以实现增量备份和归档日志备份，还原时间点更灵活
RMAN可以通过一个catalog服务器，实现多个数据库实例的备份管理
数据泵作为逻辑备份，可以作为次要手段保留，用于表空间或者表级别的数据导入导出

这份报告最终给到了两个部门领导，大家评估之后，最终将RMAN作为人力系统的备份恢复手段，而且后续我也将RMAN逐步替换了其他实例的数据泵，成为了全公司Oracle标准备份恢复手段。又过了大概一个财年，负责HR系统的同事调岗了，A顺理成章接管了HR系统，级别也从专员升到了主管。——不过，我没有什么晋升，至多只是在HR部门团建的时候邀请过我。

然而，等到她当了主管之后，我们的矛盾反而多了起来。周一跟我说XX功能跑得慢让我优化，周二跟我说磁盘容量怎么总报警，周三跟我说集团领导要看报表让我支持一下。直到有一个财年伊始，领导要看过去3年所有教师的薪酬和课时报表。当晚跑报表的时候，temp表空间不够了，又没有自增，报表毫无意外地没出来。第二天A受到了直属领导的严厉批评，随后就是我和她吵了一架，我跟她说，这么大查询没有提前跟我说，也没有扩容，她说我不够专业。

吵过一架之后，最终两人形同陌路。过去用电话沟通的事情，全都改为了冰冷的邮件文字。直到后面，我离职跳槽，两个人都没有再面对面说过一句话，后来我听老同事说，她没多久也跳槽去了其他公司，据说职级还升了。

繁花嫩叶，两个初出茅庐的职场新人，终究要奔赴各自新的码头。

同事B，金融行业审计部

和B的故事，就没有A那么热血澎湃了。审计部的同事，总是给我一种做事情很保守又很严谨的感觉，B也确实符合这种刻板印象。

每年的IT审计，数据库都是大头，外审都要驻场2个月以上，这期间就有各种材料要求我反复确认提交。作为审计的外行，我也生怕自己说错话做错事，什么事情都得和审计部门同事确认。而B当时是跟我们对接的审计部同事，每年那两个月，她恨不得要搬电脑到IT部门办公，生怕我们谁一句不经意的话，她就得用好几倍的努力圆回去。

有时候要取一些生产环境的日志和数据，就得避开业务高峰期，通常就得下班以后进机房去查。往往查完都已经过了饭点，这时候B会跟我一起去公司附近的面馆，吃的不是排骨年糕，而是一人一碗热汤面，边吃边吐槽外审的各种奇葩要求。我为了怕麻烦，都是让她买单开发票，加班餐报销的流程实在是太麻烦。而这期间，B也会跟我复盘，我在过去一年里，有哪些地方需要改进：

所有的登录日志都必须保存好，甚至备份，这不仅仅是为了审计，也是为了保护自己
给业务部门的权限，一定要越少越好，仅仅够业务日常使用，多一个权限就多一个雷
DBA日常可能有些紧急情况会绕过流程，事后一定补个流程单
对公司外部人士谨言慎行，相关工作以外的工作内容一句话不要说

因为那段时间频繁在公司附近一起吃饭，甚至我俩之间有了八卦。但是平心而论，我和她真的只是比较熟的工作关系，偶尔有点暧昧气氛，都会很有默契地转移话题。年底审计一结束，和她之间的交集立刻又少之又少。偶尔在楼里见面，大家也只是闲聊几句。——当然新的八卦也有了，我和她“和平分手”。一时之间，不知道是该哭还是该笑。

和B最后一次打交道，是我离职之前的审计。她仍旧是一边吐槽着我的工作，一边审核我的系统权限和日志。完成之后，我俩分别签字确认，事情也就算告一段落。那天晚上，我唯一一次请她吃饭，她问我为什么要离职，我的答案也很简单，上不去。如同成不了成不了汪科长的虹口小汪，离开这个看似风光的外滩27号，才是我的归宿。而B在IT审计这里慢慢做出成绩，也获得了领导认可。离职以后，大概率以后也不会再有交集，排骨是排骨，年糕是年糕。

繁花似锦，无论留下还是离开，我们都有光明的未来。

同事C，地产行业销售部

和C的相识，源自一次不同寻常的业务沟通。彼时我已经工作多年，而C却是一个应届毕业生。

有一天公司内网的聊天工具，一个其他城市业务部门的女生，突然问我：“领导（城市公司的同事喜欢这么称呼总部同事），请问XXX系统数据出问题了怎么办？”这个系统不是我管，也仅仅是后台数据库我运维着，更没有改数据的权限。于是我告诉她，可以联系XXX同事，他是这个系统的负责人，我只是负责运维数据库，具体业务数据我没有权限。隔了一会，她又问我：“我们真的很着急，那位领导又联系不上您能帮我改一下数据？”这个显然是不合规的，我只能找到负责那个系统同事的直属领导，拉个群让他们自己沟通。在相关领导同意之后，我才帮她跑了一条update语句。

事情结束之后，我好奇问她，为什么这事会找到我，她说入职的时候新员工培训见过我，当时我说自己负责公司数据库管理，愿意为大家服务。我这才依稀记起这个女生，因为我们新员工培训社招和校招往往一起。但是实际课程和课后活动，还是社招和社招，校招和校招。所以虽然课堂上有过交集，但是并没有直接接触，我们找到当时新员工培训的群互加了微信。

后面一段时间里，C问了我很多有关公司IT部门的规范和流程。我这才意识到，新员工培训的时候，有关IT部门的培训几乎没有，所有和IT部门相关的工作内容，都是老员工和新员工口口相传。

也许是做销售的人又总是大胆积极，终究有一次在对接客户时没有规范使用系统，挨了领导的批评，这时候她求助我，到底该怎么办，于是我又花了一些时间，去给她讲系统运维的一些东西：

作为DBA，是不可以直接修改业务数据的，只有获得业务部门和IT部门相关领导批准
业务数据包含敏感信息的时候，导入测试环境必须要脱敏
生产和测试严格隔离，既有网络的，又有数据库权限的

最后，她用我给她的IT制度规范，拼凑出一篇检讨书。我不仅仅当了小汪，还附带把金科长和爷叔的活也都干了。只是这个小阿宝，不知道什么时候能成为宝总。这件事请之后，我和她聊天的内容也不再仅限于工作。C和我说，什么时候来她所在城市，带我去某某地方玩玩。虽然凯迪拉克她送不起，但是一盒她所在城市的特产美食，还是能管够的。

离职以后，我们慢慢不再联系。从她朋友圈动态看到，她后面有了男朋友，慢慢开单有了业绩，但终究躲不过地产行业的那一刀。不久之前，我去到她所在的城市，去到了她曾经说要带我去玩的地方。朋友圈里，C为我的照片点了个赞。我翻了翻她的动态，她已经离职不再做地产销售，转型去做其他岗位了。

繁花若烬，一个故事一段回忆伴随着一个行业的崩塌之中无声落幕。