谁是DBA背锅侠的幕后黑手？说说那些不懂装懂的人

最近整体的风向都朝着不好的方向在走，或许到底了就好了，根据一些专家和经济学家判断，我们还能坏到哪里去。当然今天说的不是经济，而是DBA到底应不应该当背锅侠，或者谁是DBA当背锅侠的幕后黑手。

最近有几个朋友和我私下诉说工作的一些不顺心，大部分可以总结出几点：

1 工作中的数据库使用的太单一，导致技术能力提升慢，尤其金融领域中部分抑郁的DBA2 工作中遇到口谕就是圣旨的领导，工作根本没法开展，天天郁闷之极的DBA3 工作中因为整体的项目架构设计有重大的问题，最终由数据库DBA买单的正在掉头发的DBA

4 工作流程有问题，导致DBA的工作过程不畅，导致的各种沟通成本太高的问题，导致DBA有苦说不出，苦瓜脸DBA

最终总结出来一句话，不懂装懂的人，害死个人呀下面我们就用传统相声八扇屏来说说， 想当初我说说你听听，在想当初 ！话说在一个大型项目初始的时候，有一群“专家” ，架构师，高级开发，项目经理等一大堆。1 外键，必须有外键，否则如何通过程序来标定，表和表之间的关系，约束数据，保证两个表之间数据的关系2 必须大量使用存储过程，通过存储过程来削减，程序和数据库之间的交互，提高整体应用的系统的效率3 项目必须使用三范式，严格要求表中不会有重复的字段，通过严格遵守三范式保证数据库表设计的正确性4 DBA负责数据库的，运行维护的稳定性，正确性，出现数据库问题，都是DBA 的责任

这个大项目的一些海内外专家，项目管理专家一致的意见下，项目轰隆隆的开工了。此间DBA小喽啰们，提出了各种建议，如这个项目并发高，要不要使用物理分库的方式，同时基于数据经常频繁更改，项目里面也没有设计redis等缓存式数据库，全部用传统的单体数据库来进行支撑，后期可能会陷入垂直硬件升级的陷阱，同时存储过程将限制整体项目的扩展性和灵活性，以及项目在高并发 ，高访问量下使用存储过程的不可控的问题，可能会导致性能瓶颈出现在数据库层面，导致整体系统CRASH的可能性增加的问题。当然在基于整体项目由海龟博士作为系统架构师总负责项目和有着多年大型国有项目管理经验的项目管理专家的把持下，DBA的言语，轻如鸿毛，在大师的眼里，DBA就是一个打杂的小虾米。项目启动后，进展顺利，此时只有DBA在项目里面天天担心，杞人忧天。最终项目上线顺利，架构师，项目管理，开发小哥哥，都得到大大的赞赏，并和领导表示，我们设计的系统万无一失，后面就看运维和DBA的工作情况了，希望这些人，能好好守护好，24K纯金打造的伟岸系统。系统上线前，DBA就之初一些问题，如这个系统日志系统使用了BLOB数据类型，并且每天产生的系统日志都存在业务数据库里面，传统数据库作为唯一的项目的数据库，为什么就不能与时俱进，用mongodb来进行存储和解耦， 得到的答复是，你在教我做事咯 ！同时在系统运行一段时间，经常有因为前端数据控制输入不规范，导致频繁数据库对于数据进行，主键冲突，键值冲突，唯一索引冲突，check值冲突，以及主外键约束级联等方面的工作，导致数据库只要并发一大，就出现性能问题，而架构师和项目管理者，不以为然，提出这就是硬件的问题，提高硬件内存到2个T ，CPU加到200核的，问题就解决了，这不是系统设计的问题，这是我们业务访问量大的问题，仔细一问，每天并发访问不足50。最后，没有办法，领导只能责问DBA ，你们怎么干的活，人家架构，开发和项目经理都投诉你们1 OXXX数据库没有维护好，为什么每天业务数据量才1G ，日志就100G，让系统运行的性能都耗费在日志的插入上，你们要优化，你们必须整改

2 项目工作中，表设计索引为什么不早添加，当然SQL语句没有给你们，表设计逻辑说明文档也没有给你们，你们怎么就这么没有主动性吗，非要人家都给你这些你们才能干活 ，不会猜吗 ？3 系统备份要恢复几条数据，让你们用全备50多个T的备份恢复，找这几条日志数据，有那么难吗，为什么推脱，虽然项目我们都花在了研发上，硬件是差了点，磁盘是不够，但是你们不能拿出主人翁的精神？不要和我说，巧妇难为无米之炊，你们是DBA不是巧妇，天天给我在这里打嘴仗，不会恢复一点，看看有没有，删除在恢复一点，在看看吗 ？有那么难吗？你们要学会沟通，学会检讨，学会反思，提高服务意识，提高技术水平，我作为这个项目的领导对你们很不满意