再見了，半夜三點的更新惡夢！資深工程師帶你實現 WordPress 真正的「零停機部署」

嗨，我是浪花科技的 Eric。身為一個在程式碼海裡打滾多年的工程師，我敢說，沒有什麼比半夜三點，盯著 FTP 上傳進度條，心裡默念「拜託不要出錯」更讓人心跳加速的了。每更新一個檔案，就像在拆一顆未爆彈。客戶在睡覺，使用者可能還在逛網站，而你，只能祈禱那個「網站維護中，請稍後再試」的頁面不要掛太久。

這種「祈禱式」的部署方式，不僅壓力山大，而且充滿風險。只要一個檔案傳錯、一個資料庫欄位沒改對，整個網站可能就直接「白畫面」給你看。今天，我就要來跟大家聊聊，如何告別這種原始人般的部署方式，進入專業開發的殿堂：零停機部署（Zero Downtime Deployment）。

為什麼「FTP 上傳大法」是工程師的惡夢？

我知道，很多剛接觸 WordPress 的朋友，甚至一些老手，都還習慣用 FTP（File Transfer Protocol）來更新網站檔案。它很直觀，拖拉放就好，但這背後隱藏的風險，就像海面下的冰山。讓我這個囉嗦的工程師來細數一下它的幾大罪狀：

• 非原子性操作： FTP 是一個一個檔案傳輸的。在你上傳數百個檔案的過程中，使用者訪問網站時，可能會讀到一個「半成品」——有些檔案是新的，有些是舊的。這很容易導致 PHP Fatal Error，也就是俗稱的「死亡白畫面」。
• 缺乏版本控制： 如果更新後發現網站炸了，你該怎麼辦？手忙腳亂地把舊檔案再一個個傳回去嗎？萬一你忘了備份哪個檔案呢？沒有版本控制，回滾（Rollback）就成了一場災難。
• 設定檔外洩風險： 很多人會不小心把本地的 wp-config.php（包含資料庫帳密）也一起上傳，覆蓋了正式站的設定，後果不堪設想。
• 純粹的手動苦力： 每次部署都要重複一樣的步驟，不僅浪費時間，也大幅增加了人為失誤的機率。

總之，依賴 FTP 部署，就像是開著一輛沒有煞車和安全氣囊的車上高速公路。或許幾次沒事，但只要出一次意外，就是車毀人亡等級的。專業的團隊，絕不允許這種賭博式的操作。

什麼是零停機部署 (Zero Downtime Deployment)？

好了，抱怨完了，我們來談正事。零停機部署（Zero Downtime Deployment，簡稱 ZDD），顧名思義，就是一套讓你在更新網站版本時，對前端使用者完全透明、毫無中斷的部署策略與技術。它的核心精神只有一個字：快。不是指上傳速度快，而是指「新舊版本切換」的過程必須是瞬時完成的，也就是所謂的「原子操作」。

想像一下，你不是在原地一磚一瓦地修改房子，而是在旁邊蓋好一棟全新的、裝潢完美的房子，然後在某個瞬間，直接把大門的門牌換過去。你的家人（使用者）走出門，再走進門，發現房子已經煥然一新，但他們從未察覺到「施工中」的過程。這就是 ZDD 的魅力。

實現 ZDD 的三大主流戰術

概念很美好，但要怎麼實現呢？業界有幾種主流的戰術，各有優劣，適用於不同規模的專案。身為工程師，我們當然要懂這些酷東西。

戰術一：藍綠部署 (Blue-Green Deployment)

這是最經典的 ZDD 策略。你需要準備兩套完全一樣的生產環境，我們稱之為「藍色」環境和「綠色」環境。

• 假設目前線上提供服務的是藍色環境。
• 當你要上新版本時，你會將新版程式碼部署到綠色環境。
• 在綠色環境上進行完整的測試，確保一切功能正常。
• 測試通過後，你只需要在最前端的負載平衡器（Load Balancer）或路由器上動個手腳，將所有流量瞬間從藍色環境指向綠色環境。
• 此時，綠色環境就成為了新的線上版本。如果發現問題， rollback 也超簡單，再把流量切回藍色環境就好。

優點： 概念簡單，回滾極快且安全。
缺點： 成本高，因為你需要維護兩套一模一樣的硬體資源。

戰術二：金絲雀部署 (Canary Deployment)

這個名字來自以前礦工會帶金絲雀下礦坑，用來預警瓦斯外洩。在部署上，它的意思是先讓一小部分使用者（金絲雀）去體驗新版本。

• 先將新版本部署到少數幾台伺服器上。
• 透過流量控制，只將 1%、5% 的使用者流量導向新版本。
• 密切監控這群「金絲雀」使用者的回饋和系統錯誤日誌。
• 如果一切穩定，再逐步擴大流量比例，直到 100% 的使用者都轉移到新版本上。

優點： 風險極小化，可以在真實環境中驗證新版本的穩定性。
缺點： 部署策略複雜，需要精密的流量控制與監控系統。

戰術三：原子部署 (Atomic Deployment) – 最適合 WordPress 的單兵利器

對於大多數單一主機的 WordPress 網站來說，藍綠部署太奢侈，金絲雀部署又太複雜。這時候，「原子部署」就是我們的最佳選擇。它的核心武器是 Linux 系統中的一個神奇工具：符號連結（Symbolic Link，或稱 symlink）。

概念是這樣的，我們重新規劃一下伺服器上的目錄結構：

/var/www/my-site/
├── current -> /var/www/my-site/releases/20250915120000
├── releases/
│   ├── 20250915113000/
│   └── 20250915120000/
└── shared/
    ├── wp-config.php
    └── web/app/uploads/

• releases 目錄：存放每一個版本的完整程式碼，通常用時間戳命名。
• shared 目錄：存放跨版本共享的檔案，例如包含資料庫連線資訊的 wp-config.php 和使用者上傳的 uploads 目錄。
• current 目錄：這不是一個真實的目錄，而是一個指向某個特定 release 目錄的「捷徑」。你的 Nginx 或 Apache 網站根目錄（Document Root）就設定為這個 current 目錄。

部署流程就變成了一套標準SOP：

1. 透過自動化腳本，在伺服器上拉取最新的 Git 程式碼，並存放到一個新的時間戳目錄，例如 releases/20250915130000。
2. 在這個新目錄裡執行編譯、安裝相依套件等任務（例如 composer install）。
3. 在新目錄裡，建立指向 shared 目錄中 wp-config.php 和 uploads 的 symlink。
4. 見證奇蹟的時刻：執行一條指令，將 current 這個 symlink「原子性地」指向新的 release 目錄。

那個神奇的指令長這樣：

ln -sfn /var/www/my-site/releases/20250915130000 /var/www/my-site/current

這個操作對作業系統來說是瞬時完成的。上一秒使用者讀的還是舊版的程式碼，下一秒就無縫切換到新版。如果出錯了呢？只要把 current 指回上一個版本的目錄，就完成了秒級回滾！

最大的魔王：處理資料庫變更

講到這裡，你可能會覺得 ZDD 簡直完美。但別忘了，我們還有一個大魔王：資料庫。程式碼可以輕易地替換，但資料庫是「有狀態的（stateful）」，裡面的資料不能說丟就丟。

這也是 ZDD 中最棘手的部分。想像一下，新版程式碼需要一個新的資料表欄位，但舊版程式碼不認識它。如果在切換的瞬間，還有舊版程式碼在執行，它可能會因為不認識新的資料庫結構而報錯。更糟的是，如果資料庫的變更無法回滾，那就算你的程式碼秒級回滾了，網站一樣是壞的。

處理資料庫變更的黃金準則就是：所有資料庫變更都必須是向後相容的。

這通常需要一個多步驟的發布流程：

1. 第一階段（新增）：先上一個版本，這個版本只做「加法」的資料庫變更。例如新增資料表、新增欄位。此時，舊的程式碼還在線上跑，它會完全忽略這些新增的結構，所以不會出錯。
2. 第二階段（啟用）：部署新的程式碼，開始讀寫這些新的資料庫結構。
3. 第三階段（清理）：在好幾個版本之後，確認舊的結構已經完全沒在用了，再部署一個版本來移除它們。

這需要非常嚴謹的規劃。通常我們會使用資料庫遷移（Database Migration）工具，並搭配 WP-CLI 來執行這些腳本，確保每次變更都是可追蹤、可重複執行的。處理不當，很容易引發像資料庫死結 (Deadlock) 這樣更深層的問題。

整合一切：你的 ZDD 自動化工作流

看到這裡，你可能會覺得「天啊，好複雜」。沒錯，手動執行這些步驟依然很繁瑣。所以 ZDD 的最後一塊拼圖，就是「自動化」。

一個現代化的 WordPress 零停機部署流程看起來會是這樣：

本地開發 -> `git push` 到 GitHub -> GitHub Actions 自動觸發 -> 執行部署腳本（SSH連線到主機 -> 原子部署 -> 執行資料庫遷移 -> 清除快取）-> Slack 通知部署成功！

從你按下 `push` 的那一刻起，到網站更新完畢，整個過程全自動化，你只需要泡杯咖啡，等著收通知。這就是 CI/CD (持續整合/持續部署) 的威力。

零停機部署，不僅僅是一項技術，更是一種專業的開發思維。它強迫我們思考版本控制、思考向下相容、思考自動化。它將部署從一場充滿不確定性的豪賭，變成了一個穩定、可靠、甚至有點無聊的日常流程。而對工程師來說，「無聊」通常意味著「穩定」，這是最棒的讚美。

延伸閱讀

• 告別FTP手動上傳惡夢！資深工程師手把手搞定 WordPress CI/CD，從 GitHub Actions 到資料庫遷移全攻略
• 結帳又失敗？庫存又超賣？資深工程師帶你拆解 WordPress 資料庫死結 (Deadlock) 與競爭條件 (Race Condition) 的隱形殺手
• 網站半夜炸掉也不怕！資深工程師的 WordPress 資料庫備份與災難復原終極策略 (Dump vs. HA 全解析)

如果你也厭倦了半夜三點的部署惡夢，希望為你的重要網站建立一套穩固、可靠的自動化部署流程，卻不知從何下手？這正是浪花科技的專業所在。我們協助企業導入現代化的開發與維運流程，讓你的團隊能專注於打造卓越的產品，而不是在半夜救火。

立即聯繫浪花科技，讓我們為你規劃專屬的零停機部署解決方案，讓你的網站更新從此優雅又從容。