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

[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 Pool
就吃緊，這個時候根本就無法修了.....這已經不是撰寫技巧的問題，這是設計的問題...
更不用說廠商在建置Middleware時，根本就不會因應您的系統運作方式來幫您調整參數

我就經見過一個高負載而且使用者行程很長的系統，它用的Thread Pool設定是預設的
50個的.....

:         可是事實上，我們通常只重視那三十分鐘，搞不好還會覺得那兩週是白花的。
:         如果你有機會參與一個軟體開發，並且有機會碰到類似的事情，
:         請記得那個找出問題的時間，其實遠比解決問題來得重要的很多。
:         另外，資深工程師跟資淺工程師在我心中的差異點，
:         有一件事情就是看到一個問題時，定義問題的癥結點在哪裡所需要的時間。
:         新手很容易東飄飄西飄飄結果看見的都不是真正的問題，
:         但老手搞不好用過去經驗推一推就猜到問題在哪。
:         這件事其實蠻有趣的......值得觀察一下。

在我們進入一個企業之前，我見過最多的方法是土法煉鋼，也就是用log來除錯，但是
這種方法對於多緒的系統根本就很難有效的進行除錯，也許就像您所觀察到的，找問題
似乎被看輕了!不過以這種風氣來看，企業裡真的有架構師的位置嗎?也許我是井底之蛙
，看得還不夠多吧。

就我自己的拙見，我覺得應用系統的效能與問題管理在台灣仍舊是個很不被重視的議題，
儘管國外這類的產品已經賣得很好，但是在這裡我真的感覺還有很長一段路要走，甚至
我不知道這條路是不是能再走下去(換頭路...)。
我是一直覺得這類的東西是提升開發人員....阿~我們不講效率，至少是生活品質的一個
好東西，可惜被大大的低估了......

經由您的回應我也了解到您在專案執行時對於業主的想法，令人高興的是跟我所觀察到
的很接近，令人感到惋惜的是....唉!軟體開發真的是很辛苦!

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 220.229.63.63
→ TonyQ:也是很多沒救的案例，不過沒救了不講是因為講了也沒用。
→ TonyQ:反正案主鐵定是認為花了時間找出沒救的東西是沒意義的。
→ TonyQ:架構師在美國是一種職位，需要有專人擔任。
→ TonyQ:在台灣是一種運氣，運氣好你有架構師等級的人才你軟體就會有
→ TonyQ:有架構，事實上我認識的架構師都是一般開發人員，但是他就是
→ TonyQ:跟其他人不一樣，比較有機會負責比較大的區塊，負責比較多的
→ TonyQ:事情，有比較好的設計觀。可能也有比較多的薪水或者回不完
→ TonyQ:offer。但這種人其實還是非常稀有的，我很慶幸我曾經看過這
→ TonyQ:樣的強者，這堅定我往架構思考與前進的路線。
→ TonyQ:但雖然不是很樂觀，也不至於到悲觀。80%悲觀對20%樂觀吧我想
→ bravomao:可惜這樣的人才我常見到的就是被抓去當PM...不容易再親手
→ bravomao:設計系統，光是被專案進度追就快要死掉了 Q_Q
推 kimkao:推...好用的人才就是會被拿來實作彼得原理~無誤
→ lovdkkkk:牽扯到金錢與信用的專案比較容易看到正規編制
→ lovdkkkk:不只是需要他們的能力 也是要他們來扛責任保主管的