Re: [請益] 開發營運的Java或DotNET系統遇到問題的 …

看板Soft_Job作者OriginStar時間13年前 (2011/05/16 13:04)推噓3(3推 0噓 15→)

留言18則, 3人參與討論串6/6 (看更多)

原PO還是要想辦法把效能數據與財務數字結合在一起，這樣子有實際數據，客戶內各部門的焦點就會集中在那邊，你說服了RD部門用你們的產品，但實際上付錢的又是另一個部門，但付錢的部門看不出原PO產品的成效，自然就會阻擋採購。我之前碰到一個系統要更新一個小功能讓整個工廠產線整個停掉的事件，而這個損失是可以計算出來的。或是系統某些未知的 bug 讓產線停了下來，有時光找原因就花去半小時了，這損失也是可以計算出來的。那假設原PO向我推薦產品的話，是展示這些系統有多好用多好用，還是拿出實際的數據說使用這項產品可以使我找 bug 的平均時間從 20 分鐘縮短為 15 分鐘，我們這邊產線的損失也可以降低 XXX 元(假設啦) ※ 引述《bravomao (資訊苦力)》之銘言： : 首先先謝謝您的回應，看得出來您真的對這些現象感觸良多... : : 其實這問題我很有感觸 : : 先講簡單的結論，有些人他們會認為找問題不重要， : : 因為他們就是知道系統有問題，他們預期你來的不是找出問題， : : 甚至找出問題的原因也沒有用，因為他們會說「哦那我知道啊可是沒辦法」。 : : 他們的心中一向都是「解決問題遠大於找出問題」， : : 所以很多觀測、profiling 的 tool 其實很難賣。 : : 甚至退一步好了，自動化的測試工具用過得都知道讚， : : 我一直認為測試是所謂的開發人員信心指數。 : : 問題是在台灣從開發、測試、到客戶端， : : 真正有機會會想要重視品質的通常是在開發的工程師端； : : （有機會不代表一定會） : : 測試黑盒可以測功能完備，但是他們不見得能驗出一些奇怪的地方， : : 如果有白盒測試可能會好一點。 : : 大部分時候連客戶都會懶得驗收，反正有問題到時候再找你維護就好。 : 我見過有些國內的大企業的主機是定時重啟的，不為別的，只希望能有尊嚴的重啟它 : ，而不是三更半夜的被call來。 : 其實問題一旦被確實定位之後，解決的時間真的就比較可以排程，不過以我自己以前的 : 開發經驗，長官通常是先排一段...時間，讓你把BUG修掉，但是BUG連頭緒都沒有，這種 : 安排法雖然鴕鳥，卻很常見! : 我們也嚐試提出開發時期就導入監測工具來確保單元測試、整合測試以及過版的一致性 : ，但是成效不彰..... : : ----------------------------------- : : 我的 SOHO 生涯中多是救火隊的職責， : 看到救火隊三個字就先致敬一下，真的是很苦的~ : : 加入一個專案，從無到有 build 一個系統，或者是維護現有的系統。 : : 有些時候你真的會看見很多人真的是把頭埋在沙堆裡假裝事情不存在。 : : 舉個例子來講，我曾經維護過一個萬人註冊的網站， : : 它的自動登入機制，竟然是明碼把帳密放在cookie裡。 : : 至少用個 sha1 去比一下是有這麼難...反正業主傻傻的不懂. : : 或者是某公司的超爛報表，跑一次要幾萬次的db query ，要跑上兩小時， : : 一失敗或碰到記憶體不足就是需要重新跑一次， : : 需要一個行政人員一個禮拜一天的時間在做這個報表。 : : 這種東西，你幫他們找出原因，他們會很感謝， : : 他們會願意花大錢找人把他做好，但不見得會花錢感謝你找出原因， : : 因為在它們的心中，問題仍然在那邊，需要花錢解決... : : 特別是 profiling 這件事，tune performance 這件事， : : 其實找出問題點，遠比真正加速它的方法來得重要， : : 你可以用可能很多種方法加速一個迴圈，其中最常用的是cache。 : : 但是同樣一個需要100ms的迴圈，在有些地方它被跑了幾萬次他就是很久， : : 有些地方他只被跑了一次就是不痛不癢； : : 不要去期待開發時期你就能知道哪裡是慢的， : : 我的經歷是通常都發現時間都花在奇怪的地方。 : : 比方說我維護某網站的例子是，他登入慢， : : 是因為他登入之後要先去另一個圖片網站抓圖片來更新自己的使用者圖片。 : : 然後剛好那個網站並不太穩，有時候會request 比較久， : : 但又有時候會很快，所以該網站速度會飄其實是因為......-_-# : : 這在我們用 StopWatch 認真的觀測到之前，根本就沒有人想到， : : 我們之前找了 db query ，找了 taglib 的執行者， : : 就是沒人會想到這一塊，因為他是從其它的地方掛過來的。 : : 觀測到之後解法很簡單，改成獨立 thread 去做事就好了， : : 找問題花了兩週，解決問題花三十分鐘。 : 您遇到的這些例子我在工作中也常常見到，有些找出來還有救，有些根本就是沒救了! : 舉個例子，您所說的呼叫外部系統導致穩定度下降這是很常見的，但是有些設計真的 : 是匪夷所思，一個網頁動作居然會檢查外部的LDAP達幾百次.... : 當然上述的例子還算是有救，更難救的就是所有的動作都是由一個Servlet當作 : Dispatcher來進行的那種網站，一但一個小地方出問題沒處理好，整個Thread P -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.120.59.50

推

lovdkkkk

05/16 13:09, , 1^F

05/16 13:09, 1^F

→

TonyQ

05/16 18:10, , 2^F

05/16 18:10, 2^F

→

TonyQ

05/16 18:10, , 3^F

05/16 18:10, 3^F