业务方与技术方该如何达成一致
最近收到业务方的投诉,他们说有很多好的想法,最终到了技术这边,总是实现不了,不是没资源,就是数据库性能承受不了
出现这种尴尬的状况,是有很多地方需要考虑的
1.我们是否真的了解过业务方的需求?理解有没有偏差?传达中有没有曲解?
也许业务方要的是个小圆,我们听到的就成了一个大圆,最终答复:无法实现
2.业务方搞不清楚我们技术究竟能做什么
业务方说我饿了,给我一个饼,我们这边除了饼,还有很多其他可口的饭菜,但业务方不知道,他认为我们只会做饼,所以他只要饼,这样导致饼买完了,
其他的东西没卖,业务方在那里等着饼,饿死了
3.瓶颈究竟在那里?
从程序开发角度来看,他们更多的答复是没资源,没时间做这个东西,他们很少答复说这个东西我做不出来,因为他们更多关注的是功能,
比如说某个资源信息的查询,业务方需要查询任何时间范围的信息,company_name,希望做全模糊查询,开发那边只要程序改改,这个功能就OK了,
但轮到我们数据库,就要考虑这种并发稍微多点,会不会把数据库弄挂?现在的系统负载下能抗住这个压力吗?
给业务方的答复一个是我们没时间做,得等资源,另一个的答复是这个需求我们没办法实现,两种回答给人的印象是截然不同的
所以导致业务方直接找到我们,要DBA给出个解决方法,当然我们这边确实容易成为瓶颈,
4.对自己的系统了解有多深刻?
也许业务方会问,究竟什么样的需求你们能做?什么不能做?你说系统压力大,哪我现在还能加多少需求上去?能不能给我个数?
说到这点到真的有点哑口无言,如何比较准确的把需求换算成对数据库的压力负载,这个是没有固定公式的,这个得看你对业务了解的
有多深刻,你对自己的系统掌握的怎样,才能判断,最简单的例子,用户需要分页每页的数据由10行变成20行,这样导致的是一个分页SQL
的逻辑读可能由30边成50,如果这个SQL每秒执行次数达到1000次,也就意味着每秒的逻辑度增加了20000,如果按照你的经验植
系统CR上到20000的时候,LOAD就会报警的话,显然这个需求就是不可接受的
如果是复杂点的需求,估算的难度会成倍的增加,在技术与业务上,就看你自己的拿捏的是否到位了
上面的都是些比较头疼的问题,不是说单方面可以解决的,也许应该多去轮岗,也许该更仔细的分析下statspack,
也许大家可以心平气和的做到一个桌子上,你要一个圆,我能画个框,那我们能不能做一个椭圆,把这个事情给解决了算了?
不扯了,先干活吧
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:八神 来源: 八神
- 标签: 业务 协调
- 发布时间:2009-10-14 18:27:07
- [73] Twitter/微博客的学习摘要
- [65] find命令的一点注意事项
- [63] IOS安全–浅谈关于IOS加固的几种方法
- [63] Go Reflect 性能
- [62] 如何拿下简短的域名
- [62] android 开发入门
- [61] Oracle MTS模式下 进程地址与会话信
- [60] 流程管理与用户研究
- [58] 【社会化设计】自我(self)部分――欢迎区
- [57] 图书馆的世界纪录