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

[TonyQ (沉默是金。)]

※ 引述《bravomao (資訊苦力)》之銘言：
: ※ 引述《OriginStar ()》之銘言：
: 謝謝您的回應，其實我所支援的產品本身就是做長期的文字(exception等等)以及
: 數據(單一元件與函式)的資料蒐集與記錄。而我的工作就是透過這些文字以及數據
: 來協助客戶快速的定位出系統的可能問題發生點。
: 長時間的在客戶端運作讓我覺得不少的企業對於系統的管理真的有著一個斷層，有些
: 東西在系統運作時居然是系統與開發兩科都不願意去處理的(例如應用系統的調校)。
: 我所觀察到的現象是開發與管理兩個單位對於這類的問題的定義以及處理的權責有著
: 先天的歧見，所以在這樣的環境下，其實我看到的是管理人員與開發人員都是很痛苦的!
: 前面有先進有提到台灣的開發環境比較短視，所以對於這種工具的錢是能免則免，這
: 跟我的工作經驗真的很吻合!常常遇到數據證實了一些東西，客戶也得到了一些幫助，但
: 是一談到要採購，卻又百般推拖....這其實不止是對業務有影響，老實說對於支援的技術
: 人員傷害也是滿大的@@" 因為成就感實在是很受打擊!
: 而我發此文的目的其實滿單純的.....我是真的想多聽聽在一個開發案中，遇到效能
: 有瓶頸甚至是系統根本就不定時當機時，開發或是系統管理人員的心情與想法。
: 謝謝~


        其實這問題我很有感觸


        先講簡單的結論，有些人他們會認為找問題不重要，

        因為他們就是知道系統有問題，他們預期你來的不是找出問題，
        甚至找出問題的原因也沒有用，因為他們會說「哦那我知道啊 可是沒辦法」。


        他們的心中一向都是「解決問題遠大於找出問題」，
        所以很多觀測、profiling 的 tool 其實很難賣。


        甚至退一步好了，自動化的測試工具用過得都知道讚，
        我一直認為測試是所謂的開發人員信心指數。


        問題是在台灣從開發、測試、到客戶端，

        真正有機會會想要重視品質的通常是在開發的工程師端；
        （有機會不代表一定會）

        測試黑盒可以測功能完備，但是他們不見得能驗出一些奇怪的地方，
        如果有白盒測試可能會好一點。

        大部分時候連客戶都會懶得驗收，反正有問題到時候再找你維護就好。


        -----------------------------------


        我的 SOHO 生涯中多是救火隊的職責，
        加入一個專案，從無到有 build 一個系統，或者是維護現有的系統。


        有些時候你真的會看見很多人真的是把頭埋在沙堆裡假裝事情不存在。


        舉個例子來講，我曾經維護過一個萬人註冊的網站，
        它的自動登入機制，竟然是明碼把帳密放在cookie裡。

        至少用個 sha1 去比一下是有這麼難...反正業主傻傻的不懂.


        或者是某公司的超爛報表，跑一次要幾萬次的db query ，要跑上兩小時，

        一失敗或碰到記憶體不足就是需要重新跑一次，
        需要一個行政人員一個禮拜一天的時間在做這個報表。


        這種東西，你幫他們找出原因，他們會很感謝，

        他們會願意花大錢找人把他做好，但不見得會花錢感謝你找出原因，
        因為在它們的心中，問題仍然在那邊，需要花錢解決...



        特別是 profiling 這件事，tune performance 這件事，
        其實找出問題點，遠比真正加速它的方法來得重要，


        你可以用可能很多種方法加速一個迴圈，其中最常用的是cache。



        但是同樣一個需要100ms的迴圈，在有些地方它被跑了幾萬次他就是很久，
        有些地方他只被跑了一次就是不痛不癢；

        不要去期待開發時期你就能知道哪裡是慢的，
        我的經歷是通常都發現時間都花在奇怪的地方。


        比方說我維護某網站的例子是，他登入慢，
        是因為他登入之後要先去另一個圖片網站抓圖片來更新自己的使用者圖片。


        然後剛好那個網站並不太穩，有時候會request 比較久，
        但又有時候會很快，所以該網站速度會飄其實是因為......-_-#


        這在我們用 StopWatch 認真的觀測到之前，根本就沒有人想到，
        我們之前找了 db query ，找了 taglib 的執行者，
        就是沒人會想到這一塊，因為他是從其它的地方掛過來的。


        觀測到之後解法很簡單，改成獨立 thread 去做事就好了，
        找問題花了兩週，解決問題花三十分鐘。

        可是事實上，我們通常只重視那三十分鐘，搞不好還會覺得那兩週是白花的。


        如果你有機會參與一個軟體開發，並且有機會碰到類似的事情，
        請記得那個找出問題的時間，其實遠比解決問題來得重要的很多。



        另外，資深工程師跟資淺工程師在我心中的差異點，
        有一件事情就是看到一個問題時，定義問題的癥結點在哪裡所需要的時間。

        新手很容易東飄飄西飄飄結果看見的都不是真正的問題，
        但老手搞不好用過去經驗推一推就猜到問題在哪。

        這件事其實蠻有趣的......值得觀察一下。


--
另外還有一件重要的事情是，有部分的工程師不太有系統觀，
他們只知道幾個功能的區塊，沒辦法思考全局的架構觀。

他們只知道他們做了哪些功能，哪些程式碼關係到那些功能；


哪些地方可以偵測到真正的問題，要下logger的話下哪比較好，他們搞不好都不太清楚，
這種視野我認為是沒有朝架構師之路前進覺悟的人，不太會有機會去看見的。

--
我：一半的日子讓你說，我聽你說你的所有______________________________________
______________________________________一半的日子我想說，對你說過去的所有：我
        _______________________________________________________

        在討論中妥善扮演兼具聆聽與分享的角色，是我們一生的課題。
        _______________________________________________________

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.81.13.13
※ 編輯: TonyQ           來自: 111.81.13.13         (05/15 23:25)
推 lucky17:推薦這篇文章.
推 Hiigara:理解問題才可能解決問題，profiling 很重要 Orz
→ Hiigara:不過我看過的業界狀況是「SA=pg 年資 level up」，跟實際
→ Hiigara:戰力通常沒有直接關係...Orz
推 Hiigara:這類擺老架構師出來的架構，很讓人害怕...
推 bravomao:其實很多時候設計系統的人沒有辦法陪系統走到最後...
→ bravomao:看不到最後的設計者很難從設計的錯誤上吸取教訓，反覆如
→ bravomao:此，系統設計的品質跟經驗都很難累積，更不用說系統交給
→ bravomao:別人之後，疊床架屋，原始文件佚失....都不認得是自己設
→ bravomao:計的了>
→ TonyQ:其實樓上說的正是我們在這個領域中還值得去探索的區塊。;)
→ TonyQ:正因為這是個問題而且還是個問題，才有我們去面對並嘗試的價
→ TonyQ:值。至少可以分享失敗經驗，了解經驗傳承可能在哪失敗等。
→ TonyQ:如果有這類的案例其實頗適合做案例分享。
→ TonyQ:如果有這類的案例其實頗適合做案例分享。這也是soft_job的原
→ TonyQ:意與值得期待的方向！
推 atpx:很棒的實務經驗, 怎麼可以不推!!
→ viper9709:推~~這篇講出了很多重點~~