关于开发与运维，APP/架构师与DBA

    之前一直就职于工厂，开发成员少，借助快速开发工具（RAD），满足工厂的应用也足够了，也就没明显的开发、运维概念。因为一个需求及沟通，一个DBA负责规划、设计、开发，及一个RAD拖拉界面及报表格式，很有效率和成本优势的一个组合，当然，也可以说是不够专业的团队。

    离开工厂，进入新的环境，开发、运维、DBA、OS、安全、存储都完全分离了，非常专业的团队和岗位架构设计。但是，对于一个应用来说，开发质量很差（规划、设计不合理，性能效率及BUG），已经影响到业务运行了，将怎么办？

    开发的TEAM早已完工，应用项目早已验收，那么也可以说是跟开发无关了。

    跟运维也没关系，运维保障服务器在快乐的、正常地运行

    跟DBA也没关系，DBA会装好生产环境或测试环境，开通权限，提供支持

    跟OS、安全、存储就更没关系了

    一切都没问题！

    对于更多的项目，规划、设计、开发时，就缺乏DBA参予，不充分熟悉DB的APPer及架构师们总会对DB有一些误解或偏见，或者说从DBA的角度来说，对数据的规划和管理不够有效率、不够合理。从成本、产品交付因素来说，配DBA是个浪费，短期内也无法体现出其价值，只要产品交付，收入就能变现了，能快速交付，收益更大。

    常听闻产品经理、架构师及Apper提及的观念，千万不要把业务逻辑放在DB端，数据量到了千万级就一定要分表等，似乎成了定律。。。可能在一些场合下，也是个非常流行的办法，似乎也显得很专业。估计在更多的DBA来说，会不太认同。毕竟不同角色所站的立场不同，视角也不同，对数据的理解和管理方式也可能不同，但至少，通常，DBA的办法会更有效率，更合理，因为DBA会更深入理解DB内部运行机制，及产品所提供的特性去正确解决现实中出现的各种各样的数据需求。。否则，DBA还不该退出江湖呀

    倒不是说要以DB为中心来规划产品，只是说若有DBA参予、沟通，至少对产品质量及开发效率也是一个很好的补充。毕竟架构师或产品经理、Apper首先关注的是功能、开发效率，性能效率在很多场景下被忽略（在短期内也不会是一个大问题）。在很多团队，以Apper为主导的开发效率也有大量空间让DBA去发挥

    以上所提DBA：应该不限于仅做运维像备份或监控的职能DBA，应该要涉及开发、管理、规划，熟悉DB内部机制，熟悉客户端行为特点，熟悉与OS、硬件交互及特点、性能，有一定系统开发经历