关闭

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

907人阅读 评论(0) 收藏 举报

    之前一直就职于工厂,开发成员少,借助快速开发工具(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、硬件交互及特点、性能,有一定系统开发经历

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:6306次
    • 积分:266
    • 等级:
    • 排名:千里之外
    • 原创:18篇
    • 转载:0篇
    • 译文:0篇
    • 评论:3条
    文章分类