DBA职业建议和职业习惯

Posted 2021-04-29 杨建荣的学习笔记

在 这是学习笔记的第 1792篇文章

对于DBA的定位在如今看来已经发生了重大的变化，有些是职业定位上的，有些是心理定位上的，在团队内部也分享过一次，现在总结分享出来。

分享的脉络如下，会相对比较零散的聊到如下的几个问题：

1. DBA定位

2. 小启示

3. 容易被忽略的环节

4. 紧急需求该如何处理

5. 不成文的规定

6. 处理问题的态度

7. 学习的动力

   
   

一。DBA的定位

首先对于DBA的定位，在2017年在旧金山参加OOW的时候，我看了这样的一个DBA分类，想了蛮多。

其实不管是哪种类型的DBA,最终你在不同体量的工作环境下能够深耕下去，一定有一个清晰的发展方向。从我的感觉来说，我希望大家能够转换一个思路，你可以作为一个数据库用户来重新看待DBA的工作内容。

当时在分享的时候，我抛出了第一个问题：

    上班做的第一件事情是干什么？

接下来抛出了第二个问题：

    上班应该做的第一件事情是什么？

不同的人应该会有不同的答案，但是我觉得不论你是使用了物理机，虚拟机，还是ECS,RDS你首先需要对数据负责，那么怎么负责呢，就是备份，所以我的建议就是先看备份，如果备份都没有，后面的事情都是无用功。

看看行业里的最近发生的事情，事后反思起来，其实都是简单的一个环节，一个简单的问题。如果如果，但是在数据面前我们没有那么多的如果，丢失了数据，DBA就失去了一个安身立命之本，有的同学说我用RDS,需不需要备份，如果你有相应的预警和安全级别，绝对不会把身价都放在一个篮子里面。

所以说，备份重于一切，确切的说，这都是DBA 1.0时代去做的事情了，到了现在DBA 3.0,4.0的时代，却还有这么多的问题。这里需要反思。对于备份的深刻理解不是备份了就行，而是需要明白如下两点：

• 没有恢复，备份就没有意义，有效的备份

• 计划外的恢复，效率都很低，不定期的演练

而在这个之外，总能听到各种不备份的理由，有些是个人能够解决的，有些是需要公司体制内需要解决的。

• 数据量太大，所以不做备份。数据重要吗，很重要，那为什么没备份？

• 系统也很稳定，要备库干什么，就是个摆设，多浪费，缩减一下预算吧。

•  服务器现在已经过保了，得换一台新机器了。那现在服务器不是好好的吗？

二。容易被忽略的环节

在我们的工作中，总是会碰到各种无形的问题，比如服务器宕机，数据库宕机等等。在做好容灾和高可用的同时，我们有了备份，我们需要深刻理解以下的基础内容：

• 恢复练习

• 故障模拟

• 监控和报警

这些看起来实在是太基础了，但是我们似乎没有太当回事，比如发生故障的时候，一般都是计划外的事件，很可能是工作外的时间，那么排查问题和定位边界就是一件很痛苦的事情。 原本计划内10分钟搞定的事情，可能计划外就需要2个小时甚至更久。数据丢失了要恢复，有备份，但是恢复速度可控吗，如果恢复一个数据库恢复了10个小时，那和丢失数据基本就是一个级别的。所以光有备份，但是恢复效率太低，也是一个很值得思考的问题。

然后是监控和报警，这是运维入口最基础的保障，如果你一天中没有收到任何报警，应该需要怀疑，这很可能不是一件好事。

三。紧急需求该怎么处理？

我们的工作之中总是会有很多的紧急需求，每每业务同学催起来，很多都是火烧眉毛。

如果长期处于救火状态，其实就是一个不好的开始，你需要反思自己的状态，是疲于应付，还是在处理中不断的思考和改进。 

第一个，很多紧急需求可能是伪需求或者压根不着急，事务性的工作我们需要做好权衡和取舍，如果你一天的工作效率在早上最高，那么早上可以做一些更具有挑战性的任务，而可以把这些任务稍往后排一下，如果你2个小时内能解决，一般开发同学是不会催你10分钟内解决的。

另外紧急需求太多也不是一件好事，如果业务总是有此类的需求，说明业务放没有做好规划或者不够重视。紧急需求对于业务同学来说需要付出额外的代价，那么额外的代价是什么，如果需求合理，但是没有按照已有的业务流程审批，那么我们可以做一个补充环节，那就是邮件，可以在邮件中声明需求，抄送领导，那么这个事情就是公开透明的，如果反复提出需求，那么就需要多次发送邮件，我想没有人会喜欢反复抄送领导的。所以紧急需求做好本源控制可以做到反向的促进，不能一味在我们这里做催化剂。

四。不成文的规定

在职场里面，总是会有很多不成文的规定，我抛砖引玉来说一下。

• 业务确认不需要备份，我们仍然需要备份，比如业务要drop一个表，明确说不需要备份，但是从职业态度来说，我们需要做好备份。

• 口头需求不算数，要有邮件或书面的形式

• 做事情的形式很重要，有时候要有仪式感，比如我们成立一个虚拟小组，做一个项目，开源项目等，做好角色划分和时间计划，远比友情支持要长久。

• 不做甩手掌柜，要对结果负责，也要对过程负责，如果做事情毛毛糙糙，只是为了完成任务，那么对于你的提升空间实在有限。

• 低头做事，抬头看路

• 谁都想安安静静的做好底层技术，那一定是有人帮你分担了碎片的事情。

  这里需要建议的是对于时间的管理，在工作里面要做好取舍。

• 要想成为高手，一定会有“案底”，每个人都会犯错，但是犯错之后我们怎么总结经验，怎么去弥补。

• 处理问题的数量和质量，和你成为专家的水平是线性关系

五。处理问题的态度

对于处理问题的态度，我觉得很多同学都存在态度问题，那就是太粗糙。工作里要有刨根问题的习惯，在合理范围内，我们可以不断的下钻，直到把一个基本问题能够上升一个问题层级。

很多简单的问题分析起来能够分析出来深层次原因，这样你处理了一个问题，其实解决了一类问题。

• 表面现象

• 潜在问题

• 问题本质

• 解决方案

• 测试验证

• 解决隐患

在这个基础上，捷径就是要勤总结，勤能补拙。

六。学习的动力

我们很多已经开始有了 滑坡式许愿 的迹象，需要注意。

我喜欢这个有些直白的信条：

• 能理解在的理解中执行

• 不能理解的在执行中理解

最后是运维理念的转变：

传统运维理念：故障驱动，项目驱动

互联网运维理念：运维开发驱动，批量/海量自动化操作，自助服务

传统运维关注：

基础运维，运维管理，shell脚本

互联网运维关注：

运维管理，运维架构和优化，开发技术