效能瓶頸下的選擇傾向
約是在 2014 年前後有了新的體悟,但一直遲未將想法化為文字。今天終於静下心來作這件事了,我想要說明的是,為何在某些效能瓶頸的關頭,我會主張作深度分析優化,而非立即性擴充資源緩解眼前的問題。
舉電商網站經營為例,資料量主要有會員、訂單、商品等資料,大致可初估資料的複雜度以 n^3
的速度在膨脹,因此所需的運算需求量也以這速度跟著成長。這可用下方這示意圖來表示:
其中X軸為資料量,Y軸為硬體運算量,而運算資源需求則是原點連往 (A)、(B)、(C) 三點的這條曲線。
當網站逐漸成長,終於來到第一個效能瓶頸點 (A) 時,網站又慢又卡、硬體滿載,並已危及正常運作的時候。我們有2個方向的選擇:
《方案一》直接擴充硬體。這可能馬上就解決了(假設是 1 天),相對而言較快速而簡單。
《方案二》分析軟體程式,找出並修正潛在的程式瓶頸。這工程相對耗時長,可能要耗上不少時間(假設是 5-14天),也會有相應的開發成本支出。
因為網站瓶頸會影響營業收入,所以在規避損失的心態下[1],多數人會選擇 《方案一》的路線,直接將資源從 L1 提升到 L2 ,以盡快脫離眼前損失的狀態。接下來發展的狀況大致如下:
1. 很快就擱置了改善軟體效率的念頭
1-1. 因為眼前壓力解除了
1-2. 有其他更重要的事 ( 應付眼前業務、新功能開發、...)·
1-3. 非受迫性的額外支出 ( 需要另外撥出預算跟時間 )
2. 資料量隨時間持續成長,然後又遇到新的瓶頸點
3. 在瓶頸點再度面臨兩個選擇,但基於
3-1. 業務量較先前更大,相同時間的代價損失並上一次更高
3-2. 營運壓力更大,工作人員比先前更加心有餘而力不足
3-3. 先規避眼前立即的損失再說
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
這個思維不適用於生活中的所有面向,因為人生有限,每個問題都要這樣分析面對太累了,不可能。 但如果是一個反覆發生的問題,且連動到你的生產力或是每日動線上時,或許你可以好好考慮嘗試不一樣的選擇方式。
思考4
> 先求有,再求好
這個大概是兵臨城下,要解然眉之急最常聽到的說辭了。但是常常,求有
之後,幾乎就再也沒有 求好
這回事了。但是兵臨城下之際,確實也只能 先求有
。但對於自我要求較高的人,其實是看在對方願意 求好
或有想徹底解決問題的份上,才投入幫助的。事實,多數結局是令人失望的。
問題在於,是否在一開始就識別有無 求好
的方式? 依我個人經驗,有下列特徵的對象是比較有希望的:
- 隨身會備有一份重點問題清單
- 有規律 review 問題的習慣(至少每週)。例如: 主動定期回診
- 有不定時主動還舊債的習慣
以上,
希望以上幾點分享對大家有幫助。
[1]. 規避損失的傾向參考"展望理論"
[2]. 有趣的是,一個長期追蹤跟解決問題的人,還會遇到上述種種的問題嗎?