人非圣贤，孰能无过！合格的DBA虽然经过严格的培训，但是，可能由于自身或者外部的原因，他（她）的心理状态、身体状态都会有不稳定的时候，一旦出现状态不稳定就可能在工作中出错！
再厉害的DBA一天工作不出错容易，但在整个DBA生涯中不出错那就太难，而且几乎是不可能的！但是作为DBA这个职位来说，像特工007一样，时刻保证稳定的心理状态和身体状态是非常必要的，这是DBA重要的素质之一。
特别是数据库出现故障，那真的是分秒必争，零点几秒的耽误可能就会造无法挽回的损失。这是每个DBA都无法100%回避的问题，但是我们可以做到尽量避免出错的情况发生，那么作为DBA如何尽量做到在工作中零差错呢？
1、处理工单、维护数据库、解决故障之前，一定要梳理好流程，准备必要的资料，做到心中有数。
一个合格的DBA，第一要务不是求速度和效率，而是求稳。有经验的DBA喜欢复制粘贴，why？因为他们宁愿相信机器，也不愿相信自己和别人。每次处理工单、维护，都必须先整理好思路、梳理好工作流程，准备好线上服务器IP列表、需要的脚本、有可能使用到的命令、相关的文档等等。做到心里有谱、胸有成竹。即使遇到突发状况，也会从容应对，不要临时抱佛，不然你会非常后悔的。当然，在遇到紧急故障的时候可没有这么多时间给你准备，但至少也要准备常用的命令。这里有个小建议，使用在各种系统下能打开的类似记事本的程序保存常用的命令（涉及公司敏感信息不能有）。解决紧急故障是临场发挥，尽可能地避免手动输入，因为高度紧张的状态下，输入错误的概率比日常要高。对于DBA而言，输入错误带来的灾难将是毁灭性的。已经有很多类似的案例，在此不做展开。
通常故障是不是单点的，而是一个面、一个链条。究其原因，用户层、接入层、逻辑层和数据层每一层都可能有问题。处理故障之前，不要毫无目的的去试错去撞大运，因为事先分析故障盲目试错就像买彩票，一次不行，下次下下次依然如故的概率相当高，如果一直这样耗下去时间就不知不觉地浪费了，对于DBA来说，排除故障的时间可是比黄金还值钱。此时应该冷静下来，不能总把思维限定在数据层，要从整个技术链条考虑，说不定柳暗花明又一村。那么问题来了，互联网行业工作细分，DBA很大可能没有操作数据层之外的权限，碰到这个问题DBA该怎么办？下面我们来说下一个话题。
上面提到：DBA更多关注的是数据层，但是故障往往不是说一定就在数据层面，要从整体上定位故障点，和技术链条的其他节点保持信息畅通是非常重要的，这就是沟通能力。沟通能力不是指技术水平的高低。DBA在处理故障时，和监控、研发、测试、产品、运维等都有可能打交道。监控会反馈受影响的范围、延时情况等等，这属于用户层；研发、测试、产品会反馈业务故障、程序日志等，这属于用户层和逻辑层；运维会反馈网络情况、流量状况、Web服务器异常等等，这属于接入层。最后DBA会关注数据层，包括持久层和缓存层，然后结合不同链条的信息，综合分析，再进行相应的操作才能最终解决问题。
4、任何操作之前先备份，危险操作之前一定审核和确认。
对于DBA来说【备份重于一切】，修改任何配置文件之前先备份，慎用甚至不用 rm。对于有DROP和TRUNCATE的工单，再三审核和确认，避免无效操作。如果确实存在此类需求，应该首先确认是否有备份，备份是否可用。DBA应该对高危操作有明确的认识，除此之外，所有的恢复操作也需要了记于心，防患于未然。
故障是不可控的：人为、Bug、服务器硬件故障、网络故障等，故障的原因千奇百怪，不可控制，但是故障过后的Review、反思和总结我们可以控制。针对某个特定的故障，反思处理的流程是否有优化的地方，反思基础设施是否还有不完善的地方，反思团队出现的问题，反思和其他部门的合作是否有问题等等，然后形成会议记录、故障报告、故障总结，形成知识库，定期再次Review，避免下次出现类似的问题。这些文档还可以给新入职的员工参考，从真实案例中学习，这样进步会更快。
