jeffyeh

最近一直被Challenge我負責的ERP效能的問題,但公司的系統複雜,有全省分公司,上百台的電腦在使用,而且也不是單我的ERP系統在執行,所以分析檢查起來,也更為困難.

不過今天剛好又有一名使用者反應系統慢,我就被網管給抓去使用者那罰站.

看了一下使用者的電腦效能,發現ERP的記憶體用量一直上升,CPU使用率是還好,而網路一直有封包在傳,整個畫面都卡住了,網管二話不說,就強制關了ERP程式,並且重新開機.

之後就請使用者再操作一次給我看,結果從使用者的操作習慣中,卻發現到一個習慣問題.

由於當初系統在設計時,為了方便使用者進行查詢,可以在查詢條件內用 % 的方式來做like.

執行查詢的button也有設快速鍵.

程式設計是會自動帶出預設查詢條件,例如AB200801,AB是單據類別2008年01月,而年月也是帶現在的年跟月.

這麼的做法,也是希望避免使用者下了太大範圍的查詢條件,帶回大量的資料.

但實際看這使用者操作時,竟然第一個動作就是把編號清到只剩AB,並加上%,用AB%為代號的查詢條件.

本來使用者還要打公司代號的查詢,結果可能"太熟練".

按快速鍵的速度快了一步,公司代號還來不及打. 就以AB%做為查詢條件,進行查詢.

這一查就不得了囉,幾百萬筆的資料開始從資料庫傳至使用者這邊.

瞬時整個網路滿載一段時間,再度重現剛剛使用者畫面卡住的情況.

開始又有一群使用者反應ERP速度慢.

唯一能立即做的就只有強制關了程式. 避免持續佔用大量網路頻寬.

從這次經驗,也大概能猜出,為什麼公司的ERP系統有時會突然很慢.

如果是程式設計問題,應該是"均慢"的情況,而不太會有不規則頻率的發生. 沒有大概時間點,也沒有大概的商業活動才會發生.

讓這種操作行為所導致的效能突降的可能性大增.

當初設計也是為了方便使用者,當然也有為了防止此問題發生與使用者討論過,使用者堅持要有"人性"設計,所以提議帶預設查詢條件的方式來防呆,雖然也有提出使用者可能會刪除,用AB%的方式來查. 但使用者堅持不會. 所以就造成今日的惡果.

有時想著,人性化的設計是很重要,但如何去防止人性的錯誤也很重要,不能用信賴原則來相信使用者不會,當系統愈來愈大時,發生錯誤就很難去查了.而習慣養成了,要開始去限制或改變時,使用者只會接受不變或更寬,限制愈多,反彈愈大.

如今,這惡果已經造成了,開始抱怨為了提升效能,硬體也花了不少的錢,但怎麼還是那麼慢. 如果提出這樣的改善方案,想必我又要被大家攻擊了吧.