在整个运维管理岗位的序列中,数据库DBA一直是一个不怎么突出的存在,但是作为一个工作多年的打工猴,也一直想找到一些价值。如果因为业务系统发生了问题,你作为DBA力缆狂澜,那价值很高,但是这样的机会不会一直都有,大部分都是默默无闻,这个时候我们该做啥呢。又有什么好的工作方法,能在平常突出自己呢,在这里我分享一下自己的工作心得。
一、人员准备
数据库作为公司的核心数据资产,个人认为数据库管理DBA也要有主备岗,预防突发事件,数据库一旦出问题就不是小问题。
二、运维能力双路建设
即:人工运维能力和平台能力对等。
大部分公司的运维能力建设的路线是:人工->脚本->自动化脚本->平台。很多公司有了平台后,会慢慢的不怎么重视人工运维能力,但是平台本身也是一个不稳定的因素,我自己就多次经历过平台出现莫名奇妙的bug,导致核心功能不能用,导致开发测试推迟了好久。因此在参与平台建设的过程中,一定不能忘记自己的运维能力的提升,针对自己平常写的脚本或者故障排查方法要时常进行演练,在平台出现异常的时候,确保工具和脚本能够立马启用。特别是一些高危操作的功能,比如数据库启停,杀会话,灾备切换等,一定要有对应的人工运维工具。
三、工作内容要留痕
以前工作的时候不怎么重视平常的工作内容,总感觉DBA就是打杂的,能有啥价值。等到年终总结写周报,又不知道写啥或者突出不了重点。后来带团队的时候,发现并不是,其实有价值的东西很多,就看你怎么归类。比如
针对长期重点工作要有计划、进度、困难,解决方法等。
针对业务支持问题重点提解决了哪些问题。
日常工作中发现了哪些风险,风险的影响,怎么规避和计划。
性能调优中提出了什么建议,提升了多少倍和业务的沟通结果等。
平台建设的进度,新增了什么功能点,带来哪些收益。
总之把工作内容先按照模块划分好,每天的内容按照模块类别填进去,重点工作重点汇报。
以上所有的内容要落地到邮件,文档中,尽可能的留痕
三、工作过程流程化
数据库有个基本的要求是稳定,因此针对数据库的任何操作,做到尽可能地有操作流程支持。
很多公司都有自己的IT类的流程,也应该有一个数据库类相关的流程,通过流程去响应其他运维人员的数据库操作要求,合理合规。如果比较紧急,先请示,在补流程。
四、运维手段标准化
此部分和运维能力相辅相成,以前处理数据库问题时,后面总是围着一大堆人看着你操作,刚开始比较紧张,写错,删除重来,本来一个很简单的杀会话,很紧急的事情,要3分钟才搞定。因此在处置数据库问题的时候工作手段要尽可能的简单标准,把工具,脚本提前准备好,减少重复操作。可能说的比较简单,但是后面有很多工作。
1:标准的安装目录。2:经过大量演练的脚本工具;3:经过反复验证的故障排查思路流程。4:多次的熟悉。
五、故障梳理场景化
在和一个厂商聊天的时候,每次给他们提需求,他们都会把需求故事化,故事有背景,有内容,有目标,也有场景。我发现这个方法很好,很方便理解我要干啥。把这个方法放到我平常的工作中也很有用,特别是针对处理某些故障场景。比如:
标题:mysql innodb_force_recovery=6 数据库仍无法使用
背景:最近多次遇到mysql 文件损坏,把innodb_force_recovery=6 虽然能够启动,但是不能导出数据,数据库还是不能用
解决方法:直接读取物理文件内容或者应急切换
试用场景:机房故障,主机故障,异常掉电,网络异常、服务器异常卡掉死、文件损坏导致的数据库不
解决方法:xxxx
实际我们平常在处理故障和讲述故障的时候也是按照这个思路去做
六、运维能力零信任
很多运维人员对自己的写的脚本工具,检测手段有一些莫名其妙的自信,但是在实际执行过程又会遇到各种奇妙的问题。因此可以针对数据库要做一些突击演练,突出对运维人员,运维手段的零信任。从而检验运维人员的监控发现,应急处置的能力。
七、运维成果可视化
每个公司会有自己的工单系统,流程平台,监控系统,数据运营分析台。要充分利用这些平台,把数据库运维管理平台数据,日常运维内容对接到公司的平台中,推送给各个业务系统运维人员,通过流程,平台打通DBA和业务运维人员之间的关系,才会更好的体现价值。尽可能的把数据库当前状态,日常工作内容通过蜂窝大屏进行展示。