開場：一家餐廳不會讓客人吃到試菜
一間中式餐廳，後場有一個試菜間。新菜色在那裡調整鹹淡、試擺盤、算成本，確定沒問題才進正式廚房出餐。沒有人會把還在調味的菜直接端給客人。但在軟體世界，「直接改正式站」這件事天天在發生——某餐飲客戶的訂位系統，工程師晚上八點直接在正式主機改了一行程式，結果隔天早上所有訂位表單送不出去，兩小時內流失 37 筆訂位。
這五個名詞——測試站（Staging）、正式站（Production）、部署（Deploy）、回滾（Rollback）、CI/CD——講的其實就是「試菜間怎麼運作」。搞懂它們，你就能分辨為什麼有的廠商修一個 bug 要三天、有的三十分鐘，也能在報價單上看出對方到底有沒有把安全網算進去。
一、正式站（Production）：客人真正吃到的那一份
日常類比：正式廚房。出去的每一道菜都會被客人吃到、被評價、被結帳。
白話定義：使用者真正在用的那一套系統，資料是真的、錢是真的、出錯是真的會賠。
業務情境：補習班的線上報名頁面。家長在上面填資料、刷卡繳學費。這裡出一次錯，不只是「網頁壞了」，是收不到錢、家長打電話罵人、櫃檯要花整天手動補資料。
跟錢的關係：正式站的每一分鐘停機都可以換算。以一家月營收 300 萬的電商為例，平均每小時營收約 4,100 元，一次 3 小時的當機就是 1.2 萬元的直接損失，還不含客服成本與退貨率上升。
二、測試站（Staging）：那間試菜間
日常類比：試菜間。設備、食材、流程都跟正式廚房一樣，但客人吃不到。
白話定義：一套跟正式站環境幾乎相同、但用假資料的系統，專門用來驗收新功能。網址通常長得像 staging.yoursite.com。
業務情境：醫美診所要換首頁版型。廠商先做在測試站，老闆用手機打開連結看過、行銷確認文案、櫃檯試填一次諮詢表單，全部沒問題才上正式站。整個過程正式站的客人完全不受影響。
常被省略的原因與代價：測試站要多一份主機費用，每月約 300–1,500 元，加上初次建置約 8–16 工時。很多報價單為了壓低數字會把它拿掉。省下的是一年一萬多元，換來的是「每次改東西都在賭」。
關鍵細節：測試站的資料必須是去識別化的假資料。直接把正式站的客戶名單複製過去是常見錯誤，等於在防護較弱的環境放真實個資。
三、部署（Deploy）：把菜從試菜間送進正式廚房
日常類比：把確認過的食譜、備料流程正式搬進主廚房，並確保今天所有廚師都照新版本做。
白話定義：把測試好的程式碼與設定，搬到正式站並讓它生效的整個動作。
業務情境：製造業客戶的 B2B 詢價系統要加一個「多幣別報價」功能。部署不只是複製檔案，還包含：更新資料庫結構、清除快取、重啟服務、確認舊的報價單不會壞掉。任何一步漏掉，畫面看起來正常但報價金額可能算錯。
跟時程的關係：手動部署一次通常 20–60 分鐘且容易漏步驟；自動化部署通常 2–5 分鐘且每次一致。差別不在快，在不會忘。以每月部署 4 次計算，一年省下約 30 工時，但真正的價值是消掉「人為漏步驟」這個風險來源。可參考 Laravel 官方部署文件對正式環境設定的建議。
四、回滾（Rollback）：發現不對，三分鐘內換回舊菜單
日常類比：新菜出了兩桌，客人反應不對，主廚立刻宣布「回用舊食譜」，五分鐘內恢復。
白話定義：新版本上線後發現有問題，把系統快速切回上一個正常版本的能力。
業務情境：電商在雙十一前一天上了新的購物車。上線 20 分鐘後發現運費算錯。有回滾機制的團隊：3 分鐘切回舊版，損失 3 筆訂單。沒有回滾機制的團隊：現場除錯 2 小時，期間所有訂單運費都是錯的，事後要一筆一筆退補。
跟風險的關係：回滾能力是把「出錯的成本」從不可預測變成可預測。它不會讓你不出錯，但會把最壞情況鎖定在「幾分鐘」而不是「幾小時」。一個容易被忽略的重點是：程式碼可以回滾，資料庫的變更通常不能。所以真正的回滾計畫必須包含「資料庫變更要設計成可回復」，這是專業與業餘的分水嶺。
五、CI/CD：把試菜到出餐的流程自動化
日常類比：一條有品管關卡的輸送帶。食材進來自動秤重、自動檢查溫度，任何一關不合格就停下來，全部通過才自動送到出餐口。
白話定義：CI（持續整合）是「每次改程式都自動跑一次檢查與測試」；CD（持續部署）是「檢查都過了就自動送上線」。合起來就是一條自動化的品管到上線流水線。
業務情境：一家有 5 家分店的連鎖品牌，官網加訂位系統由兩位工程師維護。導入 CI/CD 後，任何一次修改都會自動跑 120 個測試（訂位不能重複、時段不能超賣、金額計算正確等），有一項不過就擋下來不准上線。上線頻率從「每月一次、每次都緊張」變成「每週三次、沒人加班」。
成本與門檻：GitHub Actions 對私有專案有免費額度，中小型專案通常每月成本在 0–500 元之間。真正的成本是建置：初次設定約 16–40 工時，約 24,000–60,000 元。回本點通常在第 8–12 個月，但如果你的系統一年出過兩次以上的上線事故，回本會更快。
常見誤解
- 誤解一：「有測試站就不會出錯。」 測試站只能降低機率。測試站的資料量、流量、第三方金流的正式環境都跟正式站不同，有些問題只在正式站才會出現。測試站的價值是擋掉「顯而易見的錯」，剩下的靠回滾接住。
- 誤解二：「CI/CD 是大公司才需要的。」 恰恰相反。大公司有專職維運人員可以人工把關，小團隊沒有，才更需要自動化當那個永遠不會忘記檢查的人。
- 誤解三：「回滾就是把備份還原。」 不一樣。還原備份通常會把這段時間的新資料一起蓋掉——訂單、留言、註冊全部消失。回滾只換程式版本、保留資料。把這兩件事講混的廠商，通常沒真正做過。
- 誤解四：「這些是技術細節，我不用管。」 這些直接決定你的報價與風險。沒有測試站與回滾的專案，報價會比較便宜，但把風險轉嫁給了你。
你該問廠商的 6 個問題
- 「這個專案有沒有獨立的測試站？費用包含在報價裡嗎？」 如果沒有，請對方報一個含測試站的版本，比較兩者差價再決定。
- 「上線出問題，多久可以回到上一個正常版本？」 合理答案是 5–15 分鐘。答「要看情況」或「重新部署一次舊版本大概一兩小時」的，等於沒有回滾能力。
- 「資料庫結構變更怎麼回復？」 這題是專業度的照妖鏡。好的答案會提到「每個 migration 都有對應的 down 方法」或「變更前自動快照」。
- 「部署是手動還是自動？步驟寫在哪裡？」 手動不是罪，但必須有一份書面的部署清單，而且不能只存在某一位工程師的腦袋裡。
- 「有沒有自動化測試？涵蓋哪些關鍵流程？」 不用要求全面覆蓋，但金流、訂單、庫存、權限這四類一定要有。
- 「上線時段怎麼安排？會不會停機？」 電商與訂位系統應該安排在流量最低時段，並事先公告。
決策清單：你的專案需要幾層防護
- ☐ 網站每天有超過 100 位訪客嗎？
- ☐ 網站上有金流或訂單功能嗎？
- ☐ 停機一小時會直接造成營收損失嗎？
- ☐ 每個月會改動兩次以上嗎？
- ☐ 有兩位以上的人會改到同一套程式嗎？
- ☐ 系統裡有客戶個資嗎？
- ☐ 曾經發生過上線後才發現壞掉的狀況嗎？
- ☐ 需要在特定檔期（雙十一、開學季）保證穩定嗎？
勾 1–2 項：正式站加定期備份即可。勾 3–5 項：一定要有測試站與明確的回滾流程。勾 6 項以上：建議完整導入 CI/CD 與自動化測試。
常見問題 FAQ
測試站會不會被 Google 收錄，影響 SEO？
會，而且是常見事故。測試站必須加上密碼保護或 IP 限制，並在回應標頭加 X-Robots-Tag: noindex。只靠 robots.txt 不夠保險。
導入 CI/CD 要多久、多少錢？
中小型專案初次設定約 16–40 工時，費用 24,000–60,000 元，含測試環境建置、部署腳本與基本自動化測試。之後每月維護成本接近零。
我的網站是 WordPress，也需要這些嗎？
需要，但做法不同。WordPress 的風險主要在外掛更新，建議至少做到：更新前自動快照、有一個測試站先更新看看、以及能在 10 分鐘內還原。這三件事用主機商提供的工具通常就能完成，成本很低。
可以先做測試站，之後再做 CI/CD 嗎？
可以，而且這是最務實的順序。測試站的投報率最高、門檻最低；有了測試站與明確的部署清單之後，再把清單自動化就是 CI/CD。不用一次到位。
行動呼籲
如果你不確定現有的網站或系統有沒有這幾層防護，我們提供一次性的「上線流程健檢」：檢查你的測試站、部署方式、回滾能力與備份策略，給你一份具體的補強清單與報價。
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p