导读
今天我们一起来看看运维DBA的工作究竟是怎么样的，经各位小伙伴的分享，可以看出各行各业的运维DBA的工作区分还是蛮大的，大家说法不一，不知你属于哪一类运维DBA。不管你是哪一类DBA，都得小心麻烦跑出来。那如何快速定位问题，避免麻烦？东方龙马将分享一些秘诀，让你避开那些不必要的坑。
本文部分文案内容摘抄自知乎平台，版权归原创所有，如需转载，请注明。
运维DBA
分享那些事儿
发言人：假装很淡定
devops
以前见过一个没有多少经验的dba，被业务和开发逼着解决一个问题，开发说：“这个问题很简单，xxx命令一敲就可以解决，真的，网上到处都是案例”，这个dba真的把xxx命令一敲，然后回车。。。后面的杯具故事我就不说了。做运维就是这样的，催你的人越多，越是要淡定，是你要对你敲下去的命令负责，而不是催你的人。。
发言人：姚毅捷
知乎政治敏感锦标赛十强
身为运维我就看看，这么闲的我都没见过，天天给写代码的擦屁股背黑锅我见了不少
发言人：百度用户
来源于百度
我们这的DBA分几种角色，一是常规运维角色，处理业务需求、看监控告警、优化线上系统等；二是平台开发角色，研发监控告警、容量管理、运维自动化、备份等DB运维平台类的需求；三是项目管理角色，跟进一些长期的项目，包括业务扩容、数据搬迁等协作类比较明显的任务。
通常来讲，DBA的一天涵盖了上面三种角色，因此DBA的时间管理要做得计划和细致，否则一天过去了会看不到自己的产出。
从现在DBA的趋势来看，DBA已经趋向于全栈DBA的能力，既能做数据库调优也能开发管理系统。有一些C底子比较厚实的DBA还自己琢磨数据库源码，搞出一条分支出来适合自己公司的业务场景。
发言人：百度用户
来源于百度
运维和DBA都挺伟大的，运维在中国的中小企业已经完全沦为打杂的职业，敲得了代码，修得通网络，弄的了服务器，搞的了电脑。。。杂碎事一大堆
大企业运维就很专业了，泡在机房里面，一般只是和服务器，数据库相关的打交道，及时处理故障，没有小企业那种乱七八糟的事情
朋友们调侃说，运维是个把脑袋别在裤腰带上的活，更有人说，运维是个把脑袋别在他人裤腰带上的活，苦劳没人认，有锅就有得背！
测试的同学说：“吃瓜群众很难感知运维背后的付出，倒是出了事情更能体现我们的专业性。”小样儿，你这是还没有掉坑里过。
所以，最好就是减少麻烦的出现。
但是，麻烦来了，大家就得定位问题，找出问题，甭管你是运维、产品、测试还是开发，总得有个人出来走一走，对吧？
现在，我们就来谈谈运维DBA怎样少不必要的麻烦，。
运维DBA的形势是很恶劣，但再恶劣也比不过当年红军过草地。红军当年靠三大纪律八项注意度过了难关，若运维DBA认真执行，也能度过背锅难关。
三大原则是规矩-Rules，九项注意是指导原则-Guidance。
做运维的人，不能总说这个我们没想到，哎呀，没想到这也不行。这是爬雪山，过草地，不注意就陷进去了，哪里会留时间给你瞎BB？
1、对生产环境心怀敬畏
你也许没听过“一个tnsping干翻6台P595”，你也许没听过“一个cp命令让营业系统停止使用30分钟”，你也许没听过“建一个索引让所有核保业务不能用了”，你也许没听过“我本来是要shutdown我的虚拟机的，没想关生产库”… …
你没听过的事情很多，你没干过的事情更多，因为你还年轻。
但是一定要对生产环境心怀敬畏。
所有操作命令不是网上搜来就可以用的，你要尽可能搞清楚这个命令的副作用，这个命令下去最坏的可能，可能是什么？不懂的就虚心求教，DBAplus社群这么多大牛，实在不好意思，就先砸个大红包过去再问。
2、保持24小时开机
做运维的没有彻底休假之说，不要以为你休假了就关机大吉了，那离你关门大吉也不远了。嗯，所以有些公司把这条也列为纪律之一。
我曾遇到过这样一个情况，某个DBA请假了，刚好有个环境的密码只有他知道，而这个环境现在出了点问题。可想而知，当时人是多么着急？ 嗯，那个DBA休假回来就长时间离开现场了。
3、多请应用的人唠唠嗑
完全不懂业务的DBA不是一个合格的架构师。
要去懂业务、懂应用、懂服务，就一定要跟应用的人唠嗑、吃饭、抽烟，平时尊重人家，人家愿意跟你说，你就越来越熟悉业务。慢慢的，你就可以为推动业务采用更合适的架构方案。
4、不要在上班时间做普通变更
什么叫普通变更？就是你本来可以提前一天做的变更。
比如扩表空间、增加用户权限、创建索引……并非是为了解决紧急故障而导致的变更。
提前做好变更规划，尽量争取每次免考核时做完所有重要的变更。
5、定期做好数据库检查
数据库没有发生故障，不代表是DBA做得好，而是故障自己还没有发生，不是不报，实时候未到。
所以，确定好检查规则，定期做好数据库检查，并进行整改。涉及到其它配合方的整改一定要邮件抄送，并电话确认。
6、数据库部署要给予最小化权限
安装必要的最少组件，赋予必要的最小权限，是主动避坑的有效手段。很多数据恢复，操作问题，如果能够从权限上把把关，后面就能省很多事情。
7、所有的保障手段，都要去验证其持续可行性
部署了高可用系统，上线前要做高可用切换测试。
部署了容灾系统，要做定期容灾演练。
部署了应急系统，要做定期应急演练。
做了数据库备份，要做定期数据库恢复测试。
说起来容易，做起来难。全国90%的系统没有做到这一点。所以你才会经常听到异常恢复的案例。特别是哪些用存储容灾，或者用OGG应急的。不是技术本身不行，而是管理不行。
8、绝尽全力推行自动化运维
在看到这条之前，你也许心里一直在暗暗的骂道，都什么时代了，还这么古板。
其实不管你是否已经开始了自动化运维，前面的每一条都值得你好好去做好，对你有益无害。
但是，去做自动化运维，是运维DBA绕不开的路径。就像从昆明到上海，最开始是只能靠马帮，后来逐渐通了高速公路，现在开始沪昆高铁了一样。
这个自动化运维怎么做？完全靠自己重复造轮子显然不完全靠谱。如果你不是BAT，也不是京东新美大饿了么，最好的方式，是找专业运维的公司研发的自动化运维平台，是骡子是马拿出来遛两下，你就喜欢上了。
9、起步始于交流，收获源于分享
做过讲师的人，都会有这样一个共识，就是讲完东西，自己其实比听课的“学生”收获更大。这一点互联网公司做得非常好，不管是BAT还是新的巨头，都纷纷成立技术学院，领衔的也往往是业界大佬，把企业内部的技术分享组织得有声有色。
作为传统企业的DBA来说，一家企业往往没有这么个学院，但是互联网上的平台很多，比如DBAplus社群，甚至还有其他一些社群都提供这样的机会。
为什么我们团队工作一年的新人，可以拥有其他公司工作四五年DBA所具有的能力，除了复杂的硬件环境外，每月的分享也功不可没。
运维没有尽头，注意事项也没有尽头，你有更好的建议，不妨说说。
1、听指挥
在运维团队中，不管什么行动一定要听指挥！听谁的指挥呢？听运维经理、运维总监、CTO、CEO的指挥。
团队中最忌讳的是具有不懂装懂、藐视领导或前辈经验、心高气傲的人，遇到这种人团队领导要及时校正或者剔除，否则这就是你背锅的最大来源。有运维同事和我抱怨说：团队里有那么一个三脚猫功夫、自以为是的同事，把他坑得无比的惨。当初想动手的时候不够坚决，最后祸起萧墙，只能弓着腰给客户和领导死命的批评。这就是一颗老鼠屎搅坏一锅汤。
团队领导在选择运维成员时，要选择上进、踏实、沟通能力强的年轻人，用心培养，往往事半功倍。
2、红线很危险，千万不要碰
一是按指挥行动，及时请示和汇报。二是不要擅自主张，一定要严格遵循方案。
所有变更需遵守以下原则：一切变更必有方案，凡方案必经过评审方可执行，凡执行必严格遵循方案，重大变更需要有人核实。
以上其实是为了规避误操作，误操作就是人为故障。在所有故障中人为故障占比一直是很高。
所有影响到业务的故障，不管是硬件故障、软件故障还是人为故障，必须第一时间通知到部门经理。
这一条是为了规避，技术人爱钻牛角尖，看见故障钻进去就出不来，贻误战机，把快速恢复业务的大好时机给浪费了。
3、备份恢复必须做
备份要做，恢复更要做。如果是企业没有相应备份设备，DBA非常有义务督促领导购置所需的软硬件设备。因为一旦出现意外，DBA的直接领导往往也担不了这个责任，毕竟数据都保护不了，用户还怎么相信你这个企业，不论你是央企还是国企。
4、休假前的容量规划
要想轻轻松松过节日，无忧无虑出去玩，除了做好备份之外，最重要的是做好容量规划。最基本的表空间、文件系统空间、历史告警等等基本情况横扫一遍，起码要能安全等到你休假回来。
对于一些特别的电商系统，节假日可能正是高峰期，那就不仅仅是空间这点事了，还要做好性能预测和解决方案预案。
数据库/中间件 | 全系列性能管理 | 智能运维 | 大数据
北京 | 上海 | 广州 | 成都 | 安码龙
4008-906-960
