「開賣三分鐘就掛，廠商說要加機器，報了一個我看不懂的價」
演唱會票十點開賣，十點零三分網站白畫面。工程師回你：「容器撐不住，要重打映像檔，前面加負載平衡，再設自動擴容做水平擴展。」你真正聽懂的只有最後一句：「這要另外報價。」
這五個詞是同一條生產線上的五個環節，少一個都動不了。廠商只報其中一項，通常代表估價漏了東西，而漏掉的那塊最後都變成加價單或當機。
名詞 1：容器（Container／Docker）
定義：把程式和它需要的環境打包成一個能整組搬走的單位。
類比：行動餐車。餐廳開分店要重裝瓦斯、調爐火，口味就跑掉；餐車把瓦斯、鍋具、食材全裝在車上，開到哪味道都一樣。容器就是那台餐車，程式碼、PHP 版本、套件、設定全鎖在裡面（見 Docker 官方文件）。
實例：聯合診所把網路掛號搬上雲端，舊主機 PHP 7.4、新主機 8.2，健保碼驗證套件跑不動，查了兩天。用容器這兩天不會存在——以 NT$1,600／小時算，白燒 NT$25,600。
名詞 2：映像檔（Image）
定義：容器的出廠母版，照著它能複製出無數台一樣的容器。
類比：餐車的施工圖。映像檔不是餐車，是「怎麼做出這台車」的規格：幾號爐、哪個牌子的冰箱。拿著它今天做一台、明天做二十台都長一樣。
實例：補習班平常一天兩百個瀏覽，七月一日開放暑期班報名，兩小時湧進一萬兩千人。六月底打成一份映像檔驗過，當天用同一份開 8 台容器，設定完全一致，不會出現「A 機器繳費成功、B 機器失敗」的對帳惡夢。打映像檔約 8–16 小時（NT$13,000–26,000）。
名詞 3：水平擴展與負載平衡（Horizontal Scaling／Load Balancer）
定義：水平擴展＝多開幾台機器；負載平衡＝帶位員，把人分到空的那台。
類比：美食街的櫃檯與帶位員。中午人潮爆炸，一是換更貴的收銀機（垂直擴展，有上限）；二是多開三個櫃檯，再派帶位員指人去空的那個。沒有帶位員，十個人全擠第一個櫃檯、另外三個空著。
實例：小巨蛋規模的售票案開賣瞬間每秒約 3,000 次請求，開 10 台容器加 1 台負載平衡器。但有個坑：購物車和登入狀態不能存在單台機器的記憶體裡，否則第二次點擊被分到別台，票就「不見了」。狀態外移約 16–24 小時（NT$26,000–38,000），負載平衡器 NT$600–900／月。
名詞 4：自動擴容（Auto-scaling）
定義：系統自己看人潮，忙的時候多開機器、閒的時候關掉。
類比：散場時加開的電梯。平日下午兩台就夠；週年慶散場人排到門口，管理室把備用四台全放下來，十點再關回兩台。你不會為那兩小時全年養六台電梯。AWS Auto Scaling 與 Google Cloud Run 就是這個管理室。
實例：保健食品電商平時每天 800 單，雙 11 當天 11,000 單，6,000 單擠在晚上八到九點。全年養 10 台，每台 NT$2,500／月是一年 NT$300,000；平常 2 台、尖峰長到 10 台約 NT$66,000，省下 NT$234,000。代價是設定加壓測約 16–24 小時，且新機器要 30 秒到 3 分鐘才能接客，尖峰前得先預熱。
五個名詞怎麼串在一起（概念圖描述）
在腦中畫一張由左到右的圖：
- 最左：標著「映像檔」的藍圖。
- 往右：三條箭頭各連到一樣的方塊「容器 1、2、3」，由一變多就是水平擴展。
- 方塊前面：漏斗「負載平衡器」，人先進漏斗再被平均分派。
- 上方：「自動擴容」儀表板寫著「CPU 過 60% 加一台，低於 20% 關一台」。
- 後方：共用的資料庫，購物車與登入狀態該放這裡。
看懂這張圖就能抓報價漏項：只報容器、不報負載平衡器與狀態外移，等於買了三台餐車卻沒請帶位員。
對預算、時程與風險的實際影響
| 項目 | 一次性工時／費用 | 每月 | 不做的風險 |
|---|---|---|---|
| 容器化＋映像檔 | 8–16 小時，NT$13,000–26,000 | — | 每次搬機重踩環境雷，1–3 天 |
| 狀態外移 | 16–24 小時，NT$26,000–38,000 | — | 加機器等於加客訴 |
| 負載平衡器 | 4–8 小時設定 | NT$600–900 | 流量仍全擠一台 |
| 自動擴容＋壓測 | 16–24 小時，NT$26,000–38,000 | 依用量 | 尖峰當機，或全年多花二十萬 |
時程抓現實數字：既有 Laravel 專案做完這四項，2–4 週合理；活動剩三週才開始談，通常只做得完前半段。
該問廠商的 5 個問題（可直接複製）
- 「我們的系統有容器化嗎？開賣前一天要多開 5 台，需要幾小時？」
- 「登入狀態和購物車存在哪裡？加開機器後，第二次點擊會不會掉到別台？」
- 「報價有含負載平衡器嗎？月費多少？算誰的帳單？」
- 「自動擴容的觸發條件是什麼？從決定加開到能接客，實際幾秒？」
- 「開賣前會做壓力測試嗎？測到每秒幾個請求？報告會給我們嗎？」
常見誤解：「加機器就是按一個鍵，一分鐘的事」
雲端確實能一分鐘給你一台機器，但新機器能不能接客，取決於系統有沒有被設計成可以複製。登入狀態在單機記憶體、上傳檔案在本機硬碟、排程只能跑一台，你開第二台就會出現使用者被登出、圖片時有時無、通知信寄兩封。這是程式層改造，刷卡買機器買不到。順帶一提，「用了 Docker 就會自動擴容」也是誤解，那是另一套機制（見 Kubernetes 官方文件）。
常見問題 FAQ
Q1：流量很小也需要容器化嗎？
流量小不是理由，搬遷與交接才是。只要可能換主機商或換維護廠商，容器化在第一次搬家就回本；三年不會動的形象站可以先不做。
Q2：自動擴容會不會讓雲端帳單失控？
沒設上限就會。要同時給「最少幾台、最多幾台」和帳單警示，上限設在預估尖峰的 1.5 倍。
Q3：資料庫也會跟著自動擴容嗎？
不會，這是最常被忽略的瓶頸。容器能從 2 台長到 20 台，但背後共用同一個資料庫，那才是天花板；連線數上限與慢查詢要一起檢查。
Q4：設定好之後每月還要付維護嗎？
基礎設定是一次性工程，但監控警報、每季參數校正、活動前壓測建議納入月費，中型電商通常每月 NT$8,000–15,000。
下一步
手上已經有活動日期（開賣、開課、雙 11、母親節訂位）的話，第一步不是問「要花多少錢」，而是做現況健檢：系統能不能被複製、瓶頸卡在哪層、離目標流量差多少。ScriptWalker 提供 30 分鐘免費技術諮詢，把上面那張圖畫在你的系統上，並給你一份能比價的清單。
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p