驗收測試之如何讓業務方與技術方該達成一致

　　最近收到業務方的投訴,他們說有很多好的想法,最終到了技術這邊,總是實現不了,不是沒資源,就是數據庫性能承受不了

　　出現這種尷尬的狀況,是有很多地方需要考慮的

　　1.我們是否真的了解過業務方的需求?理解有沒有偏差?傳達中有沒有曲解?

　　也許業務方要的是個小圓,我們聽到的就成了一個大圓,最終答復:無法實現

　　2.業務方搞不清楚我們技術究竟能做什么

　　業務方說我餓了,給我一個餅,我們這邊除了餅,還有很多其他可口的飯菜,但業務方不知道,他認為我們只會做餅,所以他只要餅,這樣導致餅買完了,

　　其他的東西沒賣,業務方在那里等著餅,餓死了

　　3.瓶頸究竟在那里?

　　從程序開發角度來看,他們更多的答復是沒資源,沒時間做這個東西,他們很少答復說這個東西我做不出來,因為他們更多關注的是功能,

　　比如說某個資源信息的查詢,業務方需要查詢任何時間范圍的信息,company_name,希望做全模糊查詢,開發那邊只要程序改改,這個功能就OK了,

　　但輪到我們數據庫,就要考慮這種并發稍微多點,會不會把數據庫弄掛?現在的系統負載下能抗住這個壓力嗎?

　　給業務方的答復一個是我們沒時間做,得等資源,另一個的答復是這個需求我們沒辦法實現,兩種回答給人的印象是截然不同的

　　所以導致業務方直接找到我們,要DBA給出個解決方法,當然我們這邊確實容易成為瓶頸,

　　4.對自己的系統了解有多深刻?

　　也許業務方會問,究竟什么樣的需求你們能做?什么不能做?你說系統壓力大,哪我現在還能加多少需求上去?能不能給我個數?

　　說到這點到真的有點啞口無言,如何比較準確的把需求換算成對數據庫的壓力負載,這個是沒有固定公式的,這個得看你對業務了解的

　　有多深刻,你對自己的系統掌握的怎樣,才能判斷,最簡單的例子,用戶需要分頁每頁的數據由10行變成20行,這樣導致的是一個分頁SQL

　　的邏輯讀可能由30邊成50,如果這個SQL每秒執行次數達到1000次,也就意味著每秒的邏輯度增加了20000,如果按照你的經驗植

　　系統CR上到20000的時候,LOAD就會報警的話,顯然這個需求就是不可接受的

　　如果是復雜點的需求,估算的難度會成倍的增加,在技術與業務上,就看你自己的拿捏的是否到位了

　　上面的都是些比較頭疼的問題,不是說單方面可以解決的,也許應該多去輪崗,也許該更仔細的分析下statspack,

　　也許大家可以心平氣和的做到一個桌子上,你要一個圓,我能畫個框,那我們能不能做一個橢圓,把這個事情給解決了算了?

　　不扯了,先干活吧

原文轉自：http://www.anti-gravitydesign.com