出现这种尴尬的状况,是有很多地方需要考虑的
1.我们是否真的了解过业务方的需求?理解有没有偏差?传达中有没有曲解?
也许业务方要的是个小圆,我们听到的就成了一个大圆,最终答复:无法实现
2.业务方搞不清楚我们技术究竟能做什么
业务方说我饿了,给我一个饼,我们这边除了饼,还有很多其他可口的饭菜,但业务方不知道,他认为我们只会做饼,所以他只要饼,这样导致饼买完了,其他的东西没卖,业务方在那里等着饼,饿死了
3.瓶颈究竟在那里?
从程序开发角度来看,他们更多的答复是没资源,没时间做这个东西,他们很少答复说这个东西我做不出来,因为他们更多关注的是功能,比如说某个资源信息的查询,业务方需要查询任何时间范围的信息,company_name,希望做全模糊查询,开发那边只要程序改改,这个功能就OK了,但轮到我们数据库,就要考虑这种并发稍微多点,会不会把数据库弄挂?现在的系统负载下能抗住这个压力吗?
给业务方的答复一个是我们没时间做,得等资源,另一个的答复是这个需求我们没办法实现,两种回答给人的印象是截然不同的所以导致业务方直接找到我们,要DBA给出个解决方法,当然我们这边确实容易成为瓶颈,
4.对自己的系统了解有多深刻?
也许业务方会问,究竟什么样的需求你们能做?什么不能做?你说系统压力大,哪我现在还能加多少需求上去?能不能给我个数?说到这点到真的有点哑口无言,如何比较准确的把需求换算成对数据库的压力负载,这个是没有固定公式的,这个得看你对业务了解的有多深刻,你对自己的系统掌握的怎样,才能判断,最简单的例子,用户需要分页每页的数据由10行变成20行,这样导致的是一个分页SQL的逻辑读可能由30边成50,如果这个SQL每秒执行次数达到1000次,也就意味着每秒的逻辑度增加了20000,如果按照你的经验植系统CR上到20000的时候,LOAD就会报警的话,显然这个需求就是不可接受的
如果是复杂点的需求,估算的难度会成倍的增加,在技术与业务上,就看你自己的拿捏的是否到位了
上面的都是些比较头疼的问题,不是说单方面可以解决的,也许应该多去轮岗,也许该更仔细的分析下statspack,也许大家可以心平气和的做到一个桌子上,你要一个圆,我能画个框,那我们能不能做一个椭圆,把这个事情给解决了算了?
不扯了,先干活吧
