網站更新還在掛「維護中」？資深工程師揭秘 WordPress 零停機部署 (Zero Downtime) 的終極魔法

嗨，我是浪花科技的 Eric。身為一個在程式碼海裡打滾多年的工程師，我最怕的場景之一，大概就是半夜三點，心驚膽顫地按下部署按鈕，然後死盯著螢幕，祈禱網站不要炸掉。更慘的是，為了部署一個小小的功能，還得先掛上「網站維護中」的牌子，把所有使用者都擋在門外，眼睜睜看著流量和訂單溜走。這種感覺，簡直比 Code Review 被挑出 Bug 還要折磨人。

你是不是也經歷過這種「部署恐懼症」？傳統的 FTP 上傳覆蓋模式，就像在高速公路上邊開車邊換輪胎，風險極高。檔案傳到一半、使用者剛好看到一個破版的畫面、資料庫更新失敗… 任何一個小環節出錯，都可能導致一場災難。但今天，我要跟你分享一個能讓你告別這種惡夢的部署魔法——零停機部署 (Zero Downtime Deployment)。

什麼是零停機部署？為什麼它對你的 WordPress 網站至關重要？

所謂的「零停機部署」，顧名思義，就是在更新網站的過程中，使用者完全感受不到任何服務中斷。網站會從舊版本無縫地切換到新版本，沒有「維護中」頁面，沒有 503 錯誤，一切都在彈指之間完成。對使用者來說，網站永遠在線上；對你來說，部署不再是壓力山大的賭注，而是一個優雅、可控的流程。

為什麼這很重要？

• 保障使用者體驗： 對於電商網站、媒體網站或任何有持續流量的平台來說，每分每秒的停機都意味著流失使用者和潛在收入。零停機部署確保了服務的連續性，讓使用者體驗絲般滑順。
• 提升商業價值： 網站永遠在線，意味著商機永遠不會中斷。尤其是在促銷活動或流量高峰期進行更新，零停機部署更是不可或缺。
• 增加開發信心： 當你知道部署是安全、可逆的，你和你的團隊就更敢於頻繁地發布新功能、修復錯誤。這能加速產品的迭代速度，提升市場競爭力。說白了，就是可以更放心地「搞事」，反正出錯了也能秒速還原。
• 降低部署風險： 傳統部署是一錘子買賣，錯了就很難回頭。零停機部署策略通常都內建了快速還原（Rollback）機制，一旦新版本有問題，可以立刻切回上一個穩定版本，將損失降到最低。

WordPress 零停機部署的核心戰術：原子部署 (Atomic Deployment)

實現零停機部署的策略有好幾種，像是藍綠部署 (Blue-Green Deployment)、金絲雀發布 (Canary Release) 等。但在大多數 WordPress 場景下，最實用、最容易上手的，莫過於基於「符號連結 (Symbolic Link)」的原子部署 (Atomic Deployment)。這也是我們今天要深入探討的主角。

「原子」這個詞聽起來很玄，其實概念很簡單：操作要嘛完全成功，要嘛完全失敗，不存在中間狀態。切換網站版本這個動作，就像原子操作一樣，瞬間完成，不會讓使用者看到一個「半新半舊」的網站。

原子部署的幕後功臣：符號連結 (Symlink)

符號連結（Symbolic Link，或稱 symlink）是 Linux 系統中的一個神奇功能，你可以把它想像成 Windows 上的「捷徑」。它是一個指向另一個檔案或目錄的特殊檔案。當你存取這個捷徑時，系統會自動將你導向它所指向的真實位置。

在我們的部署場景中，網站的根目錄（例如 Nginx 或 Apache 設定指向的 /var/www/my-site）本身不是一個真實的資料夾，而是一個指向某個「版本資料夾」的符號連結。當我們要部署新版本時，我們不是去修改這個根目錄的內容，而是讓它指向一個全新的、已經準備好的新版本資料ah夾。這個「指向」的切換動作，在系統層級是瞬間完成的，這就是「原子性」的來源。

打造一個零停機部署的伺服器結構

要實現原子部署，我們得先對伺服器的目錄結構做點規劃。這點小囉嗦是必要的，地基打歪了，神仙也難救。一個典型的結構如下：

/var/www/my-site/
├── current -> /var/www/my-site/releases/20250715120000/  (這是一個符號連結)
├── releases/
│   ├── 20250715100000/  (舊的版本)
│   └── 20250715120000/  (新的、準備上線的版本)
└── shared/
    ├── .env             (共享的環境變數設定檔)
    └── wp-content/
        └── uploads/     (共享的媒體上傳目錄)

• current：這是你的網站伺服器（Nginx/Apache）設定的網站根目錄。它永遠是一個指向某個特定版本資料夾的符號連結。
• releases：這個目錄存放著你每一次部署的完整程式碼。每個子目錄都以時間戳或版本號命名，互不干擾。
• shared：這個目錄用來存放那些在不同版本之間需要「共享」的檔案或目錄。最典型的例子就是 WordPress 的 wp-content/uploads 目錄和包含資料庫連線資訊的 .env 或 wp-config.php 檔案。畢竟，你總不希望每次部署後，使用者上傳的圖片就全不見了吧？

實戰演練：一步步完成 WordPress 原子部署

理論說完了，我們來點實際的。假設你已經透過 SSH 登入了你的伺服器，讓我們來走一遍完整的部署流程。

第一步：拉取最新程式碼到新的 Release 目錄

首先，我們建立一個以當前時間戳命名的資料夾，用來存放新版本的程式碼。

# 定義一些變數，方便後續使用
RELEASE_DIR=/var/www/my-site/releases
SHARED_DIR=/var/www/my-site/shared
NEW_RELEASE_NAME=$(date +"%Y%m%d%H%M%S")

# 建立新的版本目錄
mkdir -p $RELEASE_DIR/$NEW_RELEASE_NAME

# 透過 Git 拉取最新程式碼
git clone YOUR_REPO_URL $RELEASE_DIR/$NEW_RELEASE_NAME

第二步：在新目錄中執行建置與相依性安裝

在新版本的目錄中，執行所有必要的建置步驟。這一步非常關鍵，因為所有的準備工作都在這裡完成，而不是在線上環境。這確保了在上線前，所有東西都已經是「準備就緒」的狀態。

cd $RELEASE_DIR/$NEW_RELEASE_NAME

# 如果你用 Composer 管理 PHP 相依套件
composer install --no-dev --optimize-autoloader

# 如果你有前端資源需要建置
npm install
npm run build

第三步：連結共享檔案

這是最容易出錯，也最重要的一步。我們需要將新版本目錄中需要共享的部分（例如 uploads 和設定檔）刪除，並換成指向 shared 目錄中對應檔案的符號連結。

# 刪除新版本中的 uploads 目錄和 wp-config.php (假設我們用共享的)
rm -rf $RELEASE_DIR/$NEW_RELEASE_NAME/wp-content/uploads
rm $RELEASE_DIR/$NEW_RELEASE_NAME/wp-config.php

# 建立符號連結，將 shared 目錄的檔案連結過來
ln -s $SHARED_DIR/wp-content/uploads $RELEASE_DIR/$NEW_RELEASE_NAME/wp-content/uploads
ln -s $SHARED_DIR/wp-config.php $RELEASE_DIR/$NEW_RELEASE_NAME/wp-config.php

踩過坑才知道痛，很多新手就是忘了這一步，導致網站上線後圖片全不見，或是資料庫連線錯誤。務必再三確認！

第四步：原子切換！更新 current 符號連結

萬事俱備，只欠東風。現在，我們執行最關鍵的一步：將 current 連結指向我們剛剛準備好的新版本目錄。

# 進入網站根目錄的上一層
cd /var/www/my-site

# -f (force) 會強制覆蓋，-n (no-dereference) 確保我們是修改連結本身而不是它指向的內容，-s (symbolic) 建立符號連結
ln -Tfs $RELEASE_DIR/$NEW_RELEASE_NAME current

執行這行指令的瞬間，所有新的網路請求就會被導向新版本的程式碼。整個切換過程不到一秒，使用者完全無感。這就是原子部署的魔力！

第五步：清理舊版本（與保留還原的彈性）

部署成功後，releases 目錄會堆積越來越多的舊版本。我們可以寫個腳本，只保留最近的 3-5 個版本，以便在需要時可以快速還原。

還原操作其實非常簡單，就是把 current 再指回上一個版本的目錄而已：

# 假設上一個版本是 20250715100000
ln -Tfs /var/www/my-site/releases/20250715100000 /var/www/my-site/current

這就是為什麼我們要保留幾個舊版本的原因，它給了我們一顆強大的「後悔藥」。

工程師的小囉嗦：資料庫變更與快取問題

零停機部署聽起來很美好，但有幾個坑是純靠符號連結無法解決的，這也是新手和老手間的差距所在。

資料庫遷移 (Database Migration)

如果你的新版本包含了資料庫結構的變更（例如新增一個資料表或欄位），事情就變得複雜了。在切換程式碼的短暫瞬間，可能會出現新程式碼存取舊資料庫結構，或舊程式碼存取新資料庫結構的狀況，這很容易導致錯誤。
處理這個問題的原則是：永遠保持向後相容。

• 新增欄位： 盡量讓新欄位有預設值，或允許 NULL，這樣舊程式碼寫入資料時不會出錯。
• 刪除或修改欄位： 這最危險。通常需要分兩次部署。第一次部署，讓程式碼不再讀寫舊欄位；第二次部署，確認沒有程式碼使用後，才真正從資料庫中刪除它。

這個主題水很深，但核心思想就是：確保在過渡期間，新舊版本的程式碼都能在同一個資料庫結構下正常運作。

清除快取 (Cache Busting)

部署完新版本後，別忘了清除各種快取！

• WordPress 物件快取： 如果你用了 Redis 或 Memcached，記得在部署腳本的最後加上清除快取的指令，例如 wp cache flush。
• 頁面快取： 如果你用了 Nginx FastCGI Cache 或 Varnish，也需要清除對應的快取。
• CDN 快取： 如果你使用了 Cloudflare 這類的 CDN 服務，最好也透過 API 觸發一次快取清除，確保使用者能看到最新的前端資源。

忘記清快取，就像換了新引擎卻還在用舊的機油，效果大打折扣，甚至會引發各種靈異事件。

結論：讓部署成為一種享受，而非惡夢

從傳統的 FTP 覆蓋，到優雅的零停機部署，這不僅是技術上的升級，更是思維上的轉變。它讓我們能夠更自信、更頻繁、更安全地交付價值。雖然初期設定會比單純的 FTP 上傳複雜一些，但一旦建立了這套自動化流程（例如整合到 GitHub Actions CI/CD 流水線），你將會徹底從半夜部署的惡夢中解放出來。

部署應該是一個按下按鈕、喝杯咖啡、看著流程自動跑完的愉快過程。希望今天的分享，能幫助你向這個目標邁進一大步。

延伸閱讀

• 不只是上傳！打造 WordPress『零停機』CI/CD 部署流水線：GitHub Actions 進階實戰
• FTP部署還在手忙腳亂？GitHub Actions 進階戰術，打造 WordPress 企業級自動化部署流水線！
• 網站慢到想哭？解鎖 WordPress 終極加速密技：Redis 物件快取實戰教學

如果你對於如何為你的 WordPress 網站導入零停機部署、或是建立更穩固的網站架構感到頭痛，別擔心，這正是浪花科技的專業所在。我們協助過許多企業客戶打造高效能、高可用性的網站架構。歡迎與我們聯繫，讓我們的專業團隊為你評估並規劃最適合你的解決方案！