效能瓶頸下的選擇傾向

約是在 2014 年前後,我想通了一件事,但一直遲未將想法化為文字。今天終於静下心來作這件事了,我想要說明的是,為何在某些效能瓶頸的關頭,我會主張作深度分析優化,而非立即性擴充資源緩解眼前的問題。

舉電商網站經營為例,資料量主要有會員、訂單、商品等資料,大致可初估資料的複雜度以 n^3 的速度在膨脹,因此所需的運算需求量也以這速度跟著成長。這可用下方這示意圖來表示:

View post on imgur.com

其中X軸為資料量,Y軸為硬體運算量,而運算資源需求則是原點連往A、B、C三點的這條曲線。

當網站逐漸成長,終於來到第一個效能瓶頸點(A) 時,網站又慢又卡、硬體滿載,並已危及正常運作的時候。我們有2個方向的選擇:

《方案一》直接擴充硬體。這可能馬上就解決了(假設是 1 天),相對而言較快速而簡單。

《方案二》分析軟體程式,找出並修正潛在的程式瓶頸。這工程相對耗時長,可能要耗上不少時間(假設是 5-14天),也會有相應的開發成本支出。

因為網站瓶頸會影響營業收入,所以在規避損失的心態下[1],多數人會選擇 《方案一》的路線,直接將資源從 L1 提升到 L2 ,以盡快脫離眼前損失的狀態。接下來發展的狀況大致如下:

1. 很快就擱置了改善軟體效率的念頭 
    A. 因為眼前壓力解除了 
    B. 有其他更重要的事 ( 應付眼前業務、新功能開發、...)·
    C. 非受迫性的額外支出 ( 需要另外撥出預算跟時間 )  

2. 資料量隨時間持續成長,然後又遇到新的瓶頸點 

3. 在瓶頸點再度面臨兩個選擇,但基於 
    A. 業務量較先前更大,相同時間的代價損失並上一次更高
    B. 營運壓力更大,工作人員比先前更加心有餘而力不足 
    C. 先規避眼前立即的損失再說

4. 再度選擇《方案一》,然後重複回到 1. 

最後反覆重覆上述流程,直到獲利跟時間餘裕都被最後吃光,再無法越過某個天花板為止。

那麼,若是一開始在 A 點時,選擇《方案二》的路線會是如何?

從圖中簡單的估計一下 A-P-Q-R 的路線,(假設資料量以每個月 1W 的速度成長),雖然一開始多花了 15 天的時間,但遇到資源關卡 L2 的時間(瓶頸點R) 可能約是 5.5 個月之後。相較之下, A-B-C 的路線,一開始只花 1 天,但可能約 2.5 個月就抵達資源關卡 L2 (瓶頸點B),然後不到 2.5 個月,就抵達資源關卡 L3 (瓶頸點C)。

於是,同樣過了 6 個月的時間,面對相同的資料量,兩者不管是在資源耗用度,或是在時間餘裕度上,都形成了此消彼長的差距。而這差異,其實早在第一個瓶頸點 (A) 當下的選擇就決定了。

最早我以為,有很大的可能,會在 A-B-C 的過程中,轉變另一個選擇。但是,當我不只一次遇到,已經發展到 C 狀態的苦主們,在討論解法時仍不死心的一再追問說”有沒有更快的方法”的時候,我就深深明白到,人的選擇是有慣性的。一旦選擇《方案一》的路線,除非個性或環境條件有變化,否則就只會一直選擇《方案一》下去,直到被迫不得不改變為止。

同樣的,選擇 《方案二》 的路線,一旦獲得了成功經驗後,也會持續的選擇 《方案二》 的路線下去。唯一不同的是,《方案二》 的路線中,任何一點要切換選擇 《方案一》 相對較容易,所以 《方案二》 比較是一開始選擇較辛苦,但後面的選擇空間是越來越寬裕的路線。

因此,這就是為何在效能瓶頸的問題上,我會主張優先作分析優化,而非立即擴充資源跳過眼前損失的原因。

思考1

“先緩解眼前的問題再說” 有錯嗎?

這没有錯,這是人務實生存的天性,即便我也是如此,而且如果病人已經快要死了,還去關心這個人的儀容整不整齊,也很不合理。所以,危機處理是必要的,我並不否定這件事。

真正的問題點在於,絕大多數的人在眼前的問題緩解後,就將問題給遺忘了。

如果你是個問題緩解後,仍會自發性的長期追蹤跟解決該問題的人,你一點都不需要在意這個問題[2]。但如果你是個問題緩解後,就很快的健忘,然後一再重覆遇到類似問題的人,那麼先忍住待在 “面對眼前問題的損失” 的這個痛苦之中,可能是唯一個能不斷刺激推動你徹底解決問題的唯一動力。

說到這裡,可能有不少人會抗議說:

“痛的是我,又不是你,講的好像很簡單一樣”

是的,完全没錯,這是個困難而且違反直覺的選擇。也正因為真正痛的人不是自己,而是落在作決定跟承擔決定的人身上,所以更需要溝通與說明觀念上的落差。這也是我花這麼多時間寫下這一篇文章的動機之一。

希望讓更多人能正視到,這些簡單決定背後隱藏的長期代價,並理解另一類型的想法為何。而最後不論你認不認同這個想法,最終的判斷跟決定權都還是完全掌握在您的手上(也應該完全承擔),這始終絲毫未變。

如果文中的觀點能帶給你一個新的角度,或是協助你解釋跟說明給另一個人聽,就太好了。
但若是因此在對方未認同下,擅自幫別人作決定而執行的話,我想就不是那麼好了。

也許你是在為別人好,但另一個角度來看,或許也是在迴避”解釋說明跟尋求共識”這條較困難但較長遠的道路。

思考2
另一個近期想通的是,這個想法角度,不只侷限在軟體程式與硬體資源的選擇問題上。
相同的問題也出現在程式開發上的程式架構選擇,開發流程,開發工具,工作方法上…
舉例來說,當我們在努力開發程式時,我們可能會為了跳過程式封裝的限制,而直接複製程式碼片段到我們要用的地方,或是作一些違反常軌的 workaround 。而隨著程式碼片段的複本越來越多,且更新狀態不一致,最後不斷增長的複雜度跟層出不窮的 bug 與斷點,就耗光了程式設計師的腦力跟時間。於是類似的命題或許就會像是:

“要快速拆裝 workaround 完成新功能再說,還是要花更多時間遵循架構,甚至重構改良某些元件?”

其他問題像是:
“要直接加班先出貨眼前的積存訂單,還是要花時間研究找出工作流程中的效率問題,以簡省未來的工作時間?”
“先把眼前這題型背起來再說,還是要花多一點時間了解題目背後原理,以應變未來不同的題目變化?”

在這許不同的事件上,都有類似的瓶頸問題性質。

思考3
這個思維不適用於生活中的所有面向,因為人生有限,每個問題都要這樣分析面對太累了,不可能。

以上,

希望以上幾點分享對大家有幫助。

[1]. 規避損失的傾向參考”展望理論”
[2]. 有趣的是,一個長期追蹤跟解決問題的人,還會遇到上述種種的問題嗎?

Leave a Reply

Your email address will not be published. Required fields are marked *