Large-scale Software System
Large-scale Software System 是我研究的其中一項主題，我認為是資訊軟體領域中一項很重要的基礎技術。許多實務的技術做法，會因為不同等級的「Scale」，而有不同的解決辦法。比較直觀的想像是，外送 1 個便當，和外送 100 個便當，具體上的做法，當然會有些不同。
所謂的「大型」，並不是完全是超負荷的概念，反而更接近的是大量生產的概念，它是更符合現實的職場環境的。商用環境為了要分工效率化，許多人的工作都是大量專注在類似的事務上。許多我們在學校學習的方法，只需要交一次作業成功就好。在商用環境上則是日復一日面對各種例外案例，各個面向的數量級提升上去的時候，穩定運作本身就已經是一種挑戰了。
事實上，遮掉 Software 的 Large-scale System 是一個更廣泛的研究領域。軟體和應用領域絕對是密不可分的一環，所以也會納在這篇的討論之中。不過為了聚焦說明，本篇會以資料庫系統的角度出發，我認為多數概念都可以適度轉換到其他用途上。
我在思考這個主題時，一方面用在於反省自己的盲點，另一方面則是增進工作效率，自認為是很有幫助的。我的觀察是，多數富有職場經歷的前輩們或多或少都已經自然發展出這部份的能力了，所以練習去思考這類主題是有實質效益的事。
數量規模、時間規模、整合規模、文化規模，是我自己會去思考的規模面向。
數量規模
「數量」本身也可以再細分多個面向來探討：資料、資料庫、人員。其中資料面的可以參考先前文章「資料庫的四大問題分類」的介紹，在此就不再贅述。
如果你是管理人員，要管理 1 個資料庫和管理 100 個資料庫，顯然需要考慮不同的方法。資料庫數量一多，系統資訊的掌握、佈署和監控，都遠超過腦容量的大小，你需要導入多種自動化的工具，也需要各種記錄表格來幫助你快速取得需要的資訊。
你可能不是一個人，例如你有 10 個夥伴共同管理數百個資料庫，那就會有資訊同步、共同作業的問題，確認資訊一致性、撰寫作業手冊等行為就會成為日常的一部份。進階的開發者也可以善用平行處理的技術，爭取更多的系統資源。
時間規模
系統是會改變的，你的資料庫可能是昨天建置的，也可能是 10 年前建置的。作業系統和資料庫的版本很可能差距很大，建置的方式也截然不同。不想要負擔時間規模成本的話，建議可以定期進行系統升級，以縮小時間規模。
資料面的時間規模，例如依規定需要保存 10 年以上，你可能會遭遇儲存成本衡量的問題，也可能會有資料查詢的阻礙，而需要設計不同的資料結構及流程以妥善處理它們。
技術和應用方式都會隨時空背景有所調整，長期維運的系統和短期測試的系統設計想法很可能截然不同。設定軟體的系統生命週期，而不是等到快不能用了才來收拾殘局（一般現實），是我認為可以考慮的事。
整合規模
系統整合是很重要的事，因為資料庫是無法單獨形成一個應用服務的。試著瞭解不同軟體系統、不同硬體系統、不同程式語言、不同使用者與資料庫之間的整合情況，有助於調整系統規模至最適當的狀態。
你需要準備好面對有許多是自己無法百分之百掌握的事，風險管理是大型軟體系統必然要面對的事。軟硬體相容性、需求變更、人為疏失、單點故障、災難復原等等，有時候一整天都沒有發生系統問題，反而會有點不安感呢。
你應該準備好多種不同規模的系統設計，在新案建置時納入系統規格，更重要的是，留存規模設定的依據。除了自我保護之外，也確認系統設計的方向是明確的。
文化規模
直接來說就是參與人數的規模，必須要接受每一個人都不一樣，而我們需要每一個人都能發揮他擅長的一面。而文化規模代表的是，在軟體技術的推行上，需要儘可能相容各種不同的學識背景。
當然你可以限縮每一個參與的人都俱備很接近的高規格，但很可惜人不像伺服器可以一次買幾十台同等規格的主機。如果你需要更多的同仁可以平行地分擔工作，那平時的教育訓練和文件更新就不能少，或者變更技術方案以適應每個人也是可以考慮的。像是 VMware 的 EVC mode，可以讓不同世代的 CPU 一同分擔大量虛擬機的負載。
職場上本來就是互補的，我們都努力著用智慧去彌補各種文化及背景的差異性，相輔相成才是長期經營之道。
不要過度設計，但試著準備下一步
如同前文所述，完美的做法難求。設定了不適宜的「Scale」，過度設計只會造成大家的困擾而已，反而會阻礙技術的推展。不要去假設一個「無限」的虛擬標靶，而是具體地設定一個符合現實的規模範圍大小。並且試著準備下一步，可能是擴大規模，也可能是縮小規模，必須視團隊的最佳利益而定。
「Large-scale」要的不是小題大做，而是小以成小，大以成大。
