[工作日誌] #4 專案規模的成長路

小系統，大系統

如果專案本身規模小，或處理量小，在程式架構設計沒有重大瑕庛的情況，測試程序完成上線後，

要遇到的問題或收到bug回報的機會本身就比較小，往往feedback的問題也比較無關痛癢，或者不會到需要系統功能掛維護，或者整個系統crash。

大規模的系統往往無法單憑人工檢查，就可以得知受災範圍，或者做資料修正，ㄧ旦有事，往往大事。

小規模系統出事的處理經驗，很難套用於大規模專案的處理。

越大的系統處理成本越高，應該是可以預期的，觀念上應該做好有這樣的心理準備。

各方面影響也都不同，沒人敢說成本可以控制成線性成長。

處理10萬資料的系統，要花10萬塊成本的話，有人敢說處理100萬資料的系統，只要花100萬嗎？不一定，很難講。

自然而然的事情

如果以一樣的設計基準點，每個小時處理上百個資料的業務計算，和每個小時處理上萬個資料業務計算，誰比較有可能出狀況不用明說。

拿個現實上的比喻。

為什麼現代人比起古代，更多的人口比例得癌症。

文明病是真的文明病，主要原因還是人類平均壽命拉長，活得越久本來就越有得癌症的風險。

細胞分裂越多次，身體機能越老化，分裂發生錯誤的機會當然跟著提高。

有些人成天依據自己的意見，或者次因怪東怪西，不如看看20歲以下的人口得到癌症的比例是多少。

看待事情若無法得知原理，起碼要相信真實的數據。

修問題如治病，先了解病因和病況，確認原因後再治療。

若是生大病，怎麼可能用小病的治療方式，讓身體恢復健康。

頭痛醫頭，腳痛醫腳，是無法治療內分泌失調。


遇到嚴重的新問題，會頭痛的困難點有兩個

1. 如何判斷是大病？

大概有些特徵，譬如說過去經驗無得參考，成因複雜難以簡單分析出來，規模大才會發生的問題，極端狀況才會遇到的問題。

正向思考一下，對目前來講都是大病，當我們夠經驗了，經歷過了，在未來就是小病，也意味著我們可以作規模更大更精密的系統了。

假設某個設計方式可能存在缺陷，系統經過那個部分，發生錯誤的機率是萬分之ㄧ，系統規模小，每天只執行10次，運氣好可能好幾年都沒發現那個地方有缺陷。

承上，假設系統使用的頻率變高了，每天執行1000次，可能一個月就遇到了問題發生，能解決就是經驗，下次設計時避免掉，這個問題對我們來說就不是什麼大事，已知用火。

再假設又後來，開發新系統預期有更龐大的使用量，採取應付更龐大使用量的設計，

發生錯誤的機率是10億分之ㄧ ，流量少，起初每天只執行1000次，難遇到，改天使用量成長到每天100萬、200萬，不用太久時間就會有遇到的時候。

原因更難找，更難判斷，但是客服了，不就代表著能作出可行的處理幾百萬量的系統。

2. 舊的治療方式不管用？

病因不一樣，理所當然不管用，所以要找出新的治療方式，追求達到對症下藥。

現實層面

理想是骨感的，現實是殘酷的，實務上不會有人想要讓系統一直發生錯誤，造成公司和客戶困擾，然後給你再學習機會，

之後再讓你開新系統專案，再讓你發生錯誤，等你學習後才讓系統趨於完善和穩定。

越多人使用的系統，越大的品牌，越廣為人知道事務，越難容忍它出錯，世界上什麼不是這樣。

既然有這種認知，就要做很多事前預防措施，那麼公司願意花多少成本在做這件事情上面？

這是看不見的績效，然後想要東西好，想要達成目標，卻沒事先準備好願意付出的代價。

如果想要保證系統到某種非常優秀穩定，可以應付絕大多數非預期狀況發生時，或極端狀況發生時，系統有能力自動處理好。

願意花多少？假設這代價是等同原本專案的開發成本，假設甚至超過原本系統的開發成本，願意嗎？敢提議嗎？

有沒有注意到，「保證系統到某種非常優秀穩定」 >>> 這本身就是另一個隱藏的專案需求。

如果確定需要，為什麼不付帳？

To one single question: What are you prepared to sacrifice？