DBA计划外工作的一点思考

这是学习笔记的第 1936 篇文章

记得在多年以前，和一个出版社的朋友聊天，他无意问了个问题，说无意冒犯，你们DBA管理的数据库环境，在环境部署好以后，已经搭建好环境，后续还有什么要做的事情，当然他表达的比较委婉，不过这个问题着实让我沉思了好一会，好像从我和一个朋友后来的解释来看，罗列的都是一些比较琐碎的事情，这对于DBA来说可能是个坏消息。

我们整天都在忙些什么呢，这个问题其实不光是这个岗位，很多朋友每天都会有这样的哲学三问（我是谁，我从哪里来，要到哪里去），按照《凤凰项目》里面临危受命的技术副总裁的角度来看，工作分为了几个方面，业务项目，内部项目，变更和计划外任务，而在这些任务中，内部项目是最不受重视，而工作中的计划外任务的比例还是有点高。按照如上的工作类型，我们不妨给自己当前的工作打个分，或者做下比例统计，相信你会对自己的工作情况充满疑问或者不满。

尤其是这些计划外的任务，里面有不少的额外的沟通和支持任务，看起来比例不高，但是如果控制不当，这就会是工作中难以逾越的鸿沟。

我们团队内部下午的时候聊了下和开发人员的协作问题，发现大家工作中会有很多的碎片时间在这种协作的沟通之中。 大家讨论了一些原因，也发表了一些有趣的观点，集思广益，大家认为很多开发同学在不明确问题的时候就在咨询DBA会基于如下的一些原因：

• 咨询DBA的成本较低、
• 过往交付质量欠佳，没有根本解决问题
• 信任DBA，可以节约自己的时间
• 缺少自助查询错误的方法
• 协助开发人员调试的流程、标准不统一
• 无法查询服务日志
• 对组件机制的了解不够深入
• 客户端报错信息提供的信息量有限

对于这些问题，因为整个环节中都涉及到人，所以归根结底，这些事情涉及到服务，都是考验人性。

我们都希望业务尽可能减少无谓的骚扰，我们不妨这样设想下场景，可以和开发同学互相转换下角色，从对方的立场去考虑问题。我可以举出一系列具体的例子和解决方案。

首先，沟通我们要明确问题和背景，是什么问题，具体的IP,端口，问题的错误日志是否可以提供这些都是我们要展开讨论的前提，没有这些知识单纯的怀疑或者猜测，这种讨论的前提就是不够充分信任。信任这件事情是非常难培养的，也不是一锤子买卖，一定是一来二去，在你的工作中给到了让他决定值得尊敬的地方。 我在工作中其实是不大主张把问题的边界抛得那么清晰，这个问题归我管，这个问题不归我管等等，如果一个问题，你能在清晰的边界之外多做一些，可能是多花费一些时间，其实带给你的理解会更深刻一些。

在我的认知中，没有简单的问题，我是希望在哪些看似简单的问题中找到一个全新的角度去认识问题，这样你的时间才没有白花，如果问题有了答案，也不要忘了告诉业务同学，其实有时候他们听得不是很明白，但是如果能够用简单明了的方式告知他们，我想他们不会是一味的索取者。

大多数情况下，我希望大家能够反思下自己的工作状态，我们提供的是数据服务，不是陪聊服务，沟通要讲究效率和方法，而不是简单的说能做或者不能做。 如果很多需求都那么清晰就是一个简单的执行，那DBA存在的价值也就需要打个问号了。

在工作中，对于标准化，规范化是我们始终需要牢记的事情，哪些是原则性的，哪些是可以变通的，我们在内部需要有一个基本的认识。 从我的角度，我不希望把规范落实到纸面上，基本上效果都不大好，因为你没法要求别人关心哪些你认为重要的规范，规范可以分享，可以说教，最好的方式是揉入到流程里面，规范不应该是从纸面上看到的，至于问题的错误解释，包括错误的链接等等，这种事情哪怕你提供的再详细，我们也没法要求别人都一一吸收和消化。因为我们又是从我们的角度认为这些是应该做的。那么我们可曾为这些模糊的状态和边界指定一些清晰可见的标识，比如业务总是对某些服务存在疑问，我们不妨开放监控的权限，或者通过提供其他的自助服务来补充。

当然工作里面肯定没那么多阳光灿烂的日子，我们总是会碰到一些奇怪的人，或者有点小骄傲的人，可能很多问题在他们眼里都无所谓，不就是xxxx, 很简单的那种腔调的，作为DBA,我们需要改变他的这种自以为是的习惯。某种程度来说，我们需要增加对于不规范问题的处理代价。DBA的工作赋予的就是这份责任，我们因为无谓的妥协而渺小，因为坚持原则而显得古板，因为严谨认真而赢得信任。