DBA职业建议和职业习惯

在 这是学习笔记的第 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脚本

互联网运维关注:

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

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2018-11-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏圣杰的专栏

DDD理论学习系列(1)-- 通用语言

1.引言 在开始之前,我想我们有必要先了解以下DDD的主要参与者。因为毕竟语言是人说的吗,就像我们面向对象编程一样,那通用语言面向的是? DDD的主要参与者:...

26590
来自专栏云加头条

刘金明:腾讯云 EB 级对象存储架构深度剖析及实践

腾讯云存储业务中心副总监-刘金明,在云+未来峰会上做了主题为《腾讯云 EB 级对象存储架构深度剖析及实践》的分享,以下内容整理自演讲。

54860
来自专栏Java架构

阿里资深技术专家总结:要怎样努力才可以成为公司主力架构师

最近有好多人问我说:“George,怎样才能成为公司里的前线主力架构师,我现在在公式已经干了快五年了,现在还是一个默默无闻的程序员,我也通过很多种渠道来突破我现...

16010
来自专栏云计算D1net

多云计算需要谨慎的IT成本分配

多云环境对企业来产有很多好处,但如果没有适当的管理,其成本分配将变得艰难。人们按照以下这些提示进行资源标记和预算警报。 单个云平台的成本分配和管理可能很困难,而...

29380
来自专栏微信公众号:Java团长

如何快速成长为技术大牛?

不管是开发、测试、运维,每个技术人员心里多多少少都有一个成为技术大牛的梦,毕竟“梦想总是要有的,万一实现了呢”!正是对技术梦的追求,促使我们不断地努力和提升自己...

16120
来自专栏技术文章

测评报告:热门项目管理工具哪家强?

现在市面上免费的项目管理工具多如牛毛,然而在工作中一旦用错了工具,就不是免费不免费的事了,如果对项目整体进度造成影响,就得不偿失了。本着让项目管理者省钱又省力的...

17900
来自专栏云计算D1net

公有云供应商加入无服务器计算的浪潮

无服务器计算正在所有云服务供应商间流行着,而AWS Lambda之类的工具将可能改变资源的利用方式,尽管这一切还在萌芽阶段。 无服务器架构是云服务提供商之间最新...

35260
来自专栏云计算

5种确保云成本透明度和准确分析的方法

这些提示将帮助您收集并准确分析所需的成本核算信息,确保您从多云战略中能最大限度节约。

50860
来自专栏知晓程序

App 打开小程序正式开放,我们都猜错了微信的方向

18440
来自专栏VRPinea

乖乖坐在键盘前?罗技与HTC Vive合作,尝试研发VR键盘

33490

扫码关注云+社区

领取腾讯云代金券