最近两天也看到了一些文章，里面提到了关于DBA这个岗位的不务实，或者说这个岗位存在着一些危机，从我的视角来看，这是一件挺好的事情，算是给我们这个岗位敲响了警钟。
从认知和立场来说，每个人都有自己的选择，而且很难以改变，根深蒂固。但是用最通俗普适的视角来看待一些不寻常的现象，除了存在即合理之外，也有不合理的一些缘由。
我想简单提3个观点供参考。
第一个，关于云数据库和私有云服务的必要性和差异，我之前整理过一个简单的对表和对比，还有更详实的一些数据。大体的意思是公有云在一些中小型企业业务探索期是一种很不错的选择，而如果业务长期持久存在，而且对于性能，稳定性和服务响应效率和业务需求更贴近，私有云应该是更合适的选择。
所以我的小结是，如果公司规模很小，完全上公有云，由运维直接全面接管所谓DBA的工作也是一种相对合理的方案，而如果规模较大，这种玩法就难以适应了，到了这个层面，需要的是更加贴近业务的专业支持，只是有些时候DBA团队自己泛业务化了。
第二个，关于DBA工作中不务正业的一些说法，我觉得需要分两面看，一面是人少事多，或者业务边界不清晰，所以就会不清不楚的做一些看似跨越边界的事情，这种情况确实比较难以避免，但是需要尽量控制。另一面则是DBA团队内需要考虑我们整天在忙些什么，什么样的工作是我们专业的，能稳稳拿在手里，而且需要投入大量的精力了持续改进的。如果通泛的划分，我是把日常的一些工作划分为三类，第一类是基础运维工作，比如监控报警，备份恢复，安装部署等，这些是基础中的基础工作，学习成本不高，而且相对流程固化，第二类是优化类工作，比如慢日志优化，系统优化，实例优化，架构优化等，这个部分的工作有一定的门槛，也会随着公司规模的变化存在很大的差异性。随着分布式技术的落地，反而这部分的优化工作没有以前那么繁重了。第三类我归类为数据传输，也是我想重点提到的一类工作，假设我们所说的数据传输是一个大类，包括数据同步，数据流转等等，那么这个类别的工作是更贴近业务需求，而且肯定是需要DBA全力支持才可以实现的，恰恰这又是我们容易忽略的。比如数据库从单机模式改造为分布式数据库，底层的逻辑是什么，在某种程度上也和数据分布密切相关，而如果我们所谓的数据传输能够从底层机制，应用服务方面能够更全面的考虑这些，其实数据传输会成为一个四通八达的服务。
第三个，我觉得需要深刻反省自身的工作定和发展，我在这些年已经很多次被问到DBA到底要不要开发。这件事情的思考应该先是基于岗位的定位，这个岗位最基本，最核心的职责是什么，然后在这个基础上需要拓展哪些能力，这应该是需要先有核心，然后再有外壳的过程，而有没有开发能力，如果通泛来说，最好要有，如果降低要求，需要有编程思维。从职业发展路径来说，你对自己的要求和能力边界定位是高的，那么横向扩展和转型都是相对容易的，从这个视角来看，不要把自己局限在一亩三分地以内，需要在保证当前工作的前提下去扩展自己的能力边界，不光在深度上，在广度上也有扩展。
最后，DBA这种工作本来就是偏后端的，不出问题都不知道，一出问题都是大问题。而且有些基础建设的工作周期长，相比于20年前那种救火队长拯救系统于危难这种的大起大落来说，要显得平淡和清苦，所以从心态上也不要总是指望那么多的鲜花和掌声。还是需要提一下，DBA得给自己敲响警钟了。如果我们当前的工作方式不合理，但是还可以保持现状，那么有些故事还可以继续讲下去，不过得绷着一根弦了；如果你当前的数据平台很不错，你需要清醒的认识到那是平台的属性优先级高，而不完全是因为人；如果你所在的公司盘子不大，但是人在江湖，身不由己，做一些看似不合理的事情也未尝不可，需要问自己，我的目标是什么。
