Phase 1：差異評估

差異評估的產出是一份 change manifest——列出所有已知的新舊差異、每項的風險等級、以及需要的應對措施。這份清單是後續所有階段的依據：平行環境要驗證清單上的每一項、切換策略要先處理高風險項、退役前要確認清單上的所有相容性問題都已解決。

差異的三個維度

第一個維度是目標本身的變化。版本升級要看 changelog、breaking changes list、deprecated features list。平台遷移要看兩個平台的功能差異（共享主機沒有的 cron 彈性、VPS 有的 SSH 存取）。資料庫升級要看 SQL 語法差異、預設行為變更（如 MySQL 8.0 的 caching_sha2_password 預設認證方式）。

第二個維度是依賴關係。升級 PHP 版本時，所有 Composer 套件都可能受影響；升級 MySQL 時，ORM 的 SQL 生成可能不相容；遷移平台時，原本靠主機面板設定的 cron job 要改用系統 crontab 或雲端排程。依賴關係沒列完整，平行環境的測試就會漏掉受影響的元件。

第三個維度是過渡期的雙版本相容性。升級不是瞬間完成的——在切換的過程中，系統的某些部分跑新版本、某些部分跑舊版本。這段期間兩個版本必須能共存：資料庫的 schema 要同時相容新舊版本的程式碼、API 的回應格式要讓新舊版本的客戶端都能處理、session 格式要能跨版本延續。

風險分級

每一項差異分級後，高風險和阻塞項決定升級的可行性與時程。阻塞項超過團隊能處理的量時，升級可能需要拆成多個階段（先升到中間版本、再升到目標版本）或延後。

時程與管理層報告

差異評估的時程通常佔整個升級的 20-30%——看起來「還沒開始做」但這段時間的產出（change manifest）決定了後面所有階段的範圍。向管理層報告時用 change manifest 的風險分級表：「共 N 項差異，其中 X 項低風險、Y 項中風險、Z 項高風險、W 項阻塞。中高風險項的處理估計 M 天，阻塞項的替代方案評估需要額外 K 天。」

Phase 2：平行環境驗證

平行環境驗證的責任是用事實證明「新版本在跟 production 相同的條件下能正常運作」。它的產出是一份驗證報告——每一項 change manifest 上的差異都標上「已驗證通過 / 有問題待修 / 不影響」。沒有這份報告就切換，等於在賭新版本會正常。

建立平行環境

平行環境跟 production 越相似，驗證結果越可信。理想狀態是完全複製 production 的架構（同規格、同設定、同網路拓撲），只差目標元件的版本不同。成本限制下的折衷是用縮小版（較小的 instance、較少的資料量），但關鍵設定（PHP 模組、MySQL 參數、安全設定）必須跟 production 一致。

資料的處理要特別注意。用 production 的資料副本驗證最可靠（能觸發真實的邊界狀況），但如果資料含 PII，需要先脫敏處理。另一個選項是用 staging 環境的資料，但要確認 staging 的 schema 跟 production 一致——schema drift 會讓驗證結果失真。

驗證清單

平行期的時間長度

平行環境跑多久才能切換？取決於業務週期。如果系統有月結、季結的批次處理，平行環境至少要跑過一次完整週期。電商系統要跑過至少一個促銷活動。沒有明顯週期的系統，一到兩週的平行驗證通常足夠發現主要問題。

Phase 3：分批切換

分批切換的核心原則是不一次切 100%——先把最低風險的流量導到新環境，觀察一段時間確認正常，再逐步增加比例。

切換策略

共享主機通常只能用維護窗口策略——沒有 load balancer 做流量分配、沒有 DNS 權重可調。維護窗口的關鍵是時間規劃：備份（15 分鐘）→ 切換（30 分鐘）→ 驗證（30 分鐘）→ 恢復或回退（15 分鐘），在窗口內必須完成全部步驟，超時就回退。

切換期間的監控

切換開始後要密切觀察的指標：

• 錯誤率：5xx / 4xx 比例相對於切換前的基線
• 回應時間：p50 和 p99 相對於基線
• 業務指標：轉換率、訂單數、付款成功率（如果適用）
• 外部整合：第三方 callback 是否正常

回退觸發條件

在切換前就定義好回退條件，避免事故發生時還要開會決定要不要退：

• 錯誤率超過基線的 2 倍持續 5 分鐘 → 回退
• 核心業務流程失敗（登入、結帳、金流） → 立刻回退
• 回應時間超過基線的 3 倍持續 10 分鐘 → 回退

回退不是失敗——它是風險控制機制的正常運作。回退後排查問題、修正、重新走 Phase 2 驗證、再嘗試切換。

切換的通知

Phase 4：退役舊環境

切換完成後不要立刻刪掉舊環境——保留 1-2 週的冷備。這段時間處理長尾問題：DNS 快取還沒更新的客戶端、排程任務還指向舊 endpoint 的外部系統、舊環境上可能還有未遷移的資料。

退役前的檢查

• 舊環境的存取 log 是否歸零？（有流量代表還有東西指向它）
• 所有 cron job 是否都已在新環境運行？
• 外部系統的 webhook / callback URL 是否都已更新？
• 舊環境上有沒有需要歸檔的資料？（log、上傳檔案、備份快照）

退役步驟

1. 停止舊環境的應用服務（但不刪除）
2. 觀察 1 週——如果有問題可以快速重啟
3. 匯出需要保留的資料（log、uploaded files）
4. 刪除舊環境的運算資源（VM、容器）
5. 保留舊環境的最後一份備份 30 天，作為最後的保險
6. 清理舊環境的 DNS 記錄、SSL 憑證、IAM 角色

貫穿全程的升級紀律

一次只升一個東西

同時升級 PHP 版本 + 遷移到新主機 + 重構資料庫 schema，出問題時無法判斷是哪個變更造成的。每次升級只改一個主要元件，穩定後再升下一個。如果業務壓力要求一次完成，至少在 Phase 2 的驗證環境裡逐一引入、逐一確認。

每個階段轉換前備份

Phase 1 結束前備份 production 現況、Phase 3 切換前備份、Phase 4 退役前備份。三份備份各自獨立、各自有還原驗證。備份不只是「做了」——要實際測試過還原，確認備份的完整性。

記錄每一步

每個升級操作記錄在 repo 的 changelog 裡：什麼時間、誰做的、改了什麼、觀察到什麼結果。升級出問題時，changelog 是回溯「上一步做了什麼」的唯一依據。

在平行階段就練習回退

不要等到 Phase 3 切換時才第一次嘗試回退。在 Phase 2 的平行環境裡，刻意從新版本切回舊版本一次，確認回退路徑能走通、回退後服務能正常恢復。回退的演練跟升級的驗證同等重要。

跨分類引用

• → 接手維運：接手後穩定維運的下一步常是升級
• → 模組五：核心服務上 IaC：stateful 資源（RDS、S3）的升級涉及特殊的備份與切換策略
• → 模組八：治理好習慣：升級期間的變更紀錄對齊治理紀律
• → 模組七：infra 走 PR 流程：升級涉及的 IaC 變更走 PR review

本篇以 PHP 為主要範例（legacy 升級最常見的情境），Node.js 和 Python 的對應工具在各段併列。

相容性評估

升級前要先知道「現有程式碼跟新版本有多少不相容」。不相容的類型分四種：

PHP 相容性掃描

PHPCompatibility 是 PHP_CodeSniffer 的規則集，可以自動掃描程式碼裡哪些寫法在目標版本不相容：

1# 安裝
2composer global require phpcompatibility/php-compatibility
3
4# 掃描：目標版本 8.0
5phpcs --standard=PHPCompatibility \
6  --runtime-set testVersion 8.0 \
7  --extensions=php \
8  -p \
9  src/

掃描結果會列出每一處不相容的位置、原因和嚴重度。常見的命中包括：

1FILE: src/legacy/Database.php
2----------------------------------------------------------------------
3FOUND 3 ERRORS:
4 42 | ERROR | Function mysql_connect() is removed since PHP 7.0
5 89 | ERROR | Function each() is removed since PHP 8.0
6156 | ERROR | Curly brace access syntax is deprecated since PHP 7.4
7----------------------------------------------------------------------

php -l 可以做基本的語法檢查，但它只抓語法錯誤、抓不到 deprecated 函式和行為變更。PHPCompatibility 掃描的覆蓋面更廣。

PHP 升級的高頻修改項

Node.js 相容性掃描

1# 用 nvm 切換版本後跑測試
2nvm install 20
3nvm use 20
4npm test
5
6# 檢查 package.json 的 engines 欄位
7cat package.json | jq '.engines'

Node.js 的 breaking change 集中在 V8 引擎行為（Buffer 建構式、fs 的 callback 簽章）和原生模組的 ABI 相容性。如果專案用了原生模組（node-gyp 編譯的），版本升級後要重新 npm rebuild。

Python 相容性掃描

1# Python 2→3：用 2to3 掃描
22to3 --no-diffs -w src/
3
4# Python 3.x 小版本：用 pyupgrade
5pip install pyupgrade
6pyupgrade --py310-plus src/**/*.py

Python 2→3 的修改量通常很大（print 語法、unicode 處理、dict 方法），是接近重寫等級的升級。Python 3.x 之間的升級相對溫和，主要是 deprecation 移除和 typing 語法的演進。

本地驗證

相容性掃描找出的是靜態分析能偵測的不相容。執行期的行為變更（如字串比較規則改變、排序穩定性改變）只有跑起來才看得到。

建立目標版本的本地環境

用 Docker 建一個精確匹配目標版本的環境：

 1services:
 2  app:
 3    image: php:8.2-apache
 4    volumes:
 5      - ./src:/var/www/html
 6    ports:
 7      - "8080:80"
 8  db:
 9    image: mysql:8.0
10    environment:
11      MYSQL_ROOT_PASSWORD: localdev
12      MYSQL_DATABASE: app

如果不用 Docker，MAMP Pro 或 Laragon 可以切換 PHP 版本。關鍵是本地環境的 runtime 版本要跟升級目標完全一致——PHP 8.0 跟 8.2 之間也有差異。

驗證策略

有測試套件的專案跑測試套件。沒有測試套件的專案（legacy 專案的常態）按照這個優先序手動驗證：

1. 首頁能載入：最基本的 smoke test，確認 PHP 不 fatal error
2. 登入流程：session 處理是版本升級最常出問題的區域
3. 資料庫操作：CRUD 的每一種至少各跑一次
4. 金流 / 第三方 API：callback URL 和 API 呼叫是否正常
5. 表單提交：file upload、驗證邏輯

PHP 升級時把 error_reporting 開到最大：

1// 開發環境設定（不要在 prod 開）
2error_reporting(E_ALL);
3ini_set('display_errors', '1');

所有 notice、warning、deprecation 都要修——它們在下一個版本可能升級為 error。

第三方依賴相容性

1# Composer：檢查哪些套件需要更新
2composer outdated
3
4# 檢查各套件是否支援目標 PHP 版本
5composer why-not php 8.2

composer why-not 會列出哪些套件的 require.php 限制不允許目標版本。這些套件要先升級到支援新版本的版號，才能升 PHP。

如果某個套件已經不再維護且不支援新 PHP 版本，要評估替代方案或 fork 修改。這個評估的工作量可能佔整個升級的大部分時間。

分批部署策略

有獨立環境控制的情境（VPS / 雲端）

最安全的策略是建一套平行環境跑新版本：

1. 用新 PHP 版本建一台新的 VM 或容器
2. 部署相同的程式碼
3. 匯入 prod 資料庫的副本
4. 在新環境跑完整驗證
5. DNS 或 load balancer 切換流量到新環境
6. 舊環境保留一段時間作為 rollback 目標

rollback 是把流量切回舊環境。舊環境在確認新環境穩定之前不要關——保留期至少一週。

面板管理主機（無 SSH）的情境

面板管理主機（cPanel / Plesk）的 PHP 版本切換通常是 per-domain 的設定：

• cPanel：MultiPHP Manager，選域名 → 選 PHP 版本 → Apply
• Plesk：PHP Settings → PHP version 下拉選單

切換是即時生效的，rollback 也是即時的（選回舊版本）。但沒有「平行環境驗證」的能力——除非主機商提供 staging subdomain 可以先測。

面板管理主機的升級策略：

1. 如果有 staging subdomain：先在 staging 切換版本、驗證、再切 prod
2. 如果沒有：選流量最低的時段切換（如凌晨），切換後立刻驗證關鍵流程，出問題立刻切回
3. 切換前備份（FTP mirror + DB dump），確認 rollback 路徑存在

WordPress / 框架的版本矩陣

WordPress 和主流框架有明確的 PHP 版本支援矩陣。升級 PHP 前要先確認框架版本是否支援目標 PHP 版本：

如果框架不支援目標 PHP 版本，要先升級框架。框架升級和 PHP 升級不要同時做——先升框架、驗證穩定、再升 PHP，每一步都有獨立的 rollback 點。

常見的升級陷阱

Session 序列化格式

PHP 的 session 序列化格式在某些版本之間有變更。版本切換後舊 session 檔案可能無法反序列化，使用者會被強制登出。處理方式：

• 在維護窗口切換版本（使用者預期重新登入）
• 或在切換前清除所有 session 檔案

opcache 快取

PHP 的 opcache 會快取編譯後的 bytecode。版本切換後如果 opcache 沒清，可能用舊版本編譯的 bytecode 跑在新版本上。切換後的第一件事：

1# CLI 方式清除（如果有 SSH）
2php -r "opcache_reset();"
3
4# 或重啟 PHP-FPM / Apache
5systemctl restart php8.2-fpm

Composer 的 PHP 版本鎖定

composer.lock 裡的套件版本是根據當時的 PHP 版本解析的。PHP 版本變了之後，要重新 composer update 讓 Composer 用新版本重新解析依賴。但 composer update 可能升級其他套件——較安全的做法是 composer update --lock 只更新 lock file 的 metadata、不升級套件版本。

隱性的行為變更

PHP 8.0 起，字串跟數字的比較規則改了（0 == "foo" 從 true 變 false）。這類變更不會報錯、不會拋例外，程式碼照跑但行為不同。靜態分析抓不到，只有業務邏輯測試能覆蓋。

如果沒有測試套件，至少在切換後的一週內密切監控錯誤日誌和業務指標（訂單數、登入數、API 錯誤率），用業務指標的異常作為行為變更的偵測手段。

時程與管理層溝通

向管理層溝通時要說明：「升級 runtime 版本不只是在伺服器改一個設定。程式碼裡用到的函式和行為在新版本有不同的定義，需要逐一修改和驗證。時程取決於程式碼用了多少舊版本的專屬功能。」

成本參考：PHP 版本升級本身的工具和環境不花錢（PHPCompatibility 開源、Docker 免費、cPanel 版本切換內建）。成本全在工程師時間。

跨分類引用

• → 升級的共通操作框架：四階段模型（評估 → 平行環境 → 切換 → 退役）
• → Legacy PHP 的安全盤點：PHP 版本風險評估與漏洞掃描
• → 程式碼版控與 FTP 部署紀律：升級前的 Git 基準線與 rollback 策略

遷移的核心約束是帶電施工——系統在搬遷過程中要持續服務。這決定了操作模式：在新平台建起平行環境、驗證通過後用 DNS 切換流量、確認沒問題再拆舊環境。每一步都保留回退到舊環境的能力，直到新環境穩定運行一段時間。

遷移路徑的常見組合

每條路徑的遷移工程量級不同：共享主機 → VPS 是最輕的（應用層搬家）、地端 → 雲端是最重的（整個基礎設施重建）。選擇遷移路徑時先確認商業目標——如果目標是「能裝自訂軟體」，共享主機 → VPS 就夠了，不需要一步跳到雲端。

共享主機 → VPS 遷移

遷移前的記錄

把共享主機的所有設定記下來，作為 VPS 上重建的 checklist。需要記錄的項目：

接手維運模組的環境設定拍照有更完整的盤點方法。

VPS 環境建立

VPS 上從零安裝 web stack：

 1# Ubuntu 22.04 為例
 2sudo apt update && sudo apt upgrade -y
 3
 4# Web server
 5sudo apt install nginx -y
 6
 7# PHP（對齊共享主機的版本）
 8sudo apt install php8.1-fpm php8.1-mysql php8.1-curl php8.1-mbstring php8.1-gd php8.1-xml -y
 9
10# MySQL
11sudo apt install mysql-server -y
12
13# SSL（Let's Encrypt）
14sudo apt install certbot python3-certbot-nginx -y
15sudo certbot --nginx -d example.com -d www.example.com

安裝完成後用 php -m 比對共享主機的 phpinfo 記錄，確認所有模組都已安裝。缺少的模組用 apt install php8.1-<module> 補上。

資料搬移

1# 程式碼：從本地 Git repo 部署（不從共享主機直接搬）
2git clone git@github.com:org/site.git /var/www/site
3
4# 資料庫：從備份匯入
5mysql -u root -p site_db < backup-latest.sql
6
7# 使用者上傳檔案：從共享主機 FTP 下載後 rsync 到 VPS
8rsync -avz /local/backup/uploads/ user@vps:/var/www/site/uploads/

.htaccess → nginx 設定轉換

共享主機用 Apache 的 .htaccess，VPS 如果改用 nginx 需要手動轉換。常見的規則對照：

 1# .htaccess: RewriteEngine On / RewriteRule ^(.*)$ index.php/$1
 2# nginx 等價：
 3location / {
 4    try_files $uri $uri/ /index.php?$query_string;
 5}
 6
 7# .htaccess: Options -Indexes
 8# nginx 等價：
 9autoindex off;
10
11# .htaccess: deny from all (某目錄)
12# nginx 等價：
13location ~ /\.env { deny all; }

轉換後在本地或 staging 驗證每條規則的行為是否一致。WordPress、Laravel 等框架有現成的 nginx 設定範例可參考。

Email 處理

共享主機通常附帶 email 服務（用主機面板建 email 帳號）。VPS 預設不含 email。三個處理方式：

• 自架 email server（Postfix + Dovecot）：維運成本高、不推薦除非有特殊需求
• 改用第三方 email 服務（Google Workspace / Zoho Mail）：設定 MX 記錄指向服務商
• 只轉發（不收信）：應用程式的寄信功能改用 SMTP relay（SendGrid / Mailgun）

DNS 的 MX 記錄要在切換前就改好指向新的 email 服務，否則切換後 email 會中斷。

SSL 自動續期

共享主機的 SSL 通常由主機商代管續期。VPS 上用 Let’s Encrypt 的 certbot 會自動設定 systemd timer 或 cron 做續期，但要驗證它確實在跑：

1# 確認 certbot 的自動續期排程存在
2sudo systemctl list-timers | grep certbot
3
4# 模擬續期測試（不實際續期）
5sudo certbot renew --dry-run

VPS → 雲端遷移

服務盤點與雲端對照

VPS 上的每個 process 都需要對應到雲端的服務：

自動化遷移工具

AWS Application Migration Service（MGN）可以自動化 VM workload 的搬遷——把現有 server 的 block-level data 持續複製到 AWS、切換時啟動 EC2 instance。適合大量 VM 的 lift-and-shift，但不處理應用層的重構（nginx config、cron 轉 EventBridge 等仍需手動）。單台 VM 的遷移用 MGN 反而比手動 dump/restore 多一層設定成本，適用場景是同時搬 5 台以上。

IaC 的導入時機

VPS → 雲端是導入 IaC 的最佳時機——新環境從零建起，沒有歷史包袱。用 Terraform 描述 VPC、subnet、RDS、ECS、ALB 等資源，讓新環境可重現（見模組一：最小可行 IaC）。遷移完成後，這套 IaC 直接成為持續維運的基礎。

資料庫遷移

小型資料庫（< 10GB）：mysqldump + 匯入 RDS，遷移期間短暫唯讀即可。

1# 從 VPS dump
2mysqldump -u user -p --single-transaction site_db | gzip > site_db.sql.gz
3
4# 匯入 RDS
5gunzip -c site_db.sql.gz | mysql -h rds-endpoint.region.rds.amazonaws.com -u admin -p site_db

大型資料庫（> 10GB 或需要零停機）：使用 AWS DMS（Database Migration Service）做持續複寫，VPS 上的 MySQL 作為 source、RDS 作為 target，DMS 做初始全量複製後持續同步增量，切換時把應用指向 RDS 端點。

網路設計

雲端環境的網路要在遷移前規劃好。VPC、subnet、security group 的設計見模組三：網路地基。VPS 上的 iptables 規則要映射成 security group 規則——iptables 的每條 accept 對應一條 SG ingress rule，但 SG 不支援 deny（用「不開就是 deny」的白名單模式）。

資料同步策略

選擇策略時先問兩個問題：資料量多大（決定 dump 時間）、業務能接受多長的唯讀或停機窗口（決定要不要持續複寫）。

對於上傳檔案（圖片、文件），遷移到雲端時通常從本地檔案系統搬到 S3：

1# 從 VPS 同步上傳目錄到 S3
2aws s3 sync /var/www/site/uploads/ s3://site-uploads/ --delete

應用程式碼裡的檔案路徑要改成 S3 URL 或用 CDN 代理。

DNS 切換與驗證

切換前準備

遷移前 48 小時，降低 DNS TTL 到 300 秒（5 分鐘）。正常的 TTL 通常是 3600 秒（1 小時）或更長——如果切換出問題需要回退，短 TTL 讓 DNS 傳播更快。

1# 確認當前 TTL
2dig example.com +short +ttlid

切換操作

1# 更新 A record 指向新平台的 IP / ALB endpoint
2# 如果用 Route 53：
3aws route53 change-resource-record-sets --hosted-zone-id Z123 --change-batch '{
4  "Changes": [{"Action": "UPSERT", "ResourceRecordSet": {
5    "Name": "example.com", "Type": "A",
6    "AliasTarget": {"HostedZoneId": "Z456", "DNSName": "alb-xxx.region.elb.amazonaws.com", "EvaluateTargetHealth": true}
7  }}]
8}'

切換後監控

切換後的驗證窗口至少等 2 倍 TTL（短 TTL 設 300 秒的話，至少等 10 分鐘）。在這段時間內：

• 新平台：監控 HTTP 狀態碼、回應時間、錯誤率
• 舊平台：觀察流量是否遞減到零（仍有流量代表 DNS 還沒完全傳播）
• 功能驗證：跑一次關鍵流程（登入、查詢、交易）

回退

如果新平台出問題，回退方式是把 DNS 切回舊平台的 IP。回退的生效時間等於當前的 TTL——這正是切換前降低 TTL 的理由。舊平台在 DNS 切換後要保留至少 72 小時（全球 DNS 快取最慢的清除時間），確認完全沒有流量後再退役。

切換後收尾

穩定運行 1-2 週後：

• 把 DNS TTL 恢復到正常值（3600 秒）
• 退役舊平台（關機 → 保留快照 → 一個月後刪除）
• 更新文件：新環境的存取方式、部署流程、監控端點

時程與管理層溝通

向管理層溝通時的關鍵訊息：「應用程式碼不變、改的是運行環境。風險集中在資料搬移和 DNS 切換這兩個步驟，兩者都有回退路徑。」

成本變化也要提前說明：共享主機 → VPS 的月費通常持平或略增（$5-30/月）；VPS → 雲端的月費取決於資源用量，初期可能增加 50-200%（換到的是彈性和 managed 服務），但可以透過 reserved instance 和 rightsizing 後續優化。

跨分類引用

• → 升級的共通操作框架：評估差異 → 平行環境 → 切換 → 退役的四階段模型
• → 接手維運：無 SSH 的 FTP 環境：遷移前的環境盤點方法
• → 模組一：最小可行 IaC：雲端遷移是導入 IaC 的最佳時機
• → 模組三：網路地基：雲端環境的 VPC / subnet 設計

升級前的相容性評估

大版本升級不只是換一個二進位檔——新版本可能改變 SQL 行為、儲存格式、認證方式與預設值。在動任何生產資源之前，先在本地或測試環境把相容性問題找出來。

MySQL 5.7 → 8.0 的常見破壞性變更

PostgreSQL 大版本升級的檢查點

PostgreSQL 的大版本升級相對穩定，但仍有需要確認的項目：extension 版本是否跟新 PostgreSQL 版本相容（特別是 PostGIS、pg_partman、timescaledb 這類複雜 extension）、pg_upgrade 的 --check 模式可以在不實際升級的前提下驗證相容性。

1# PostgreSQL: 升級前 dry-run 檢查
2pg_upgrade --old-datadir /var/lib/postgresql/13/main \
3           --new-datadir /var/lib/postgresql/16/main \
4           --old-bindir /usr/lib/postgresql/13/bin \
5           --new-bindir /usr/lib/postgresql/16/bin \
6           --check

應用程式層的查詢相容性

把應用程式的所有 SQL 查詢（ORM 產生的也算）對新版本跑一遍。重點是行為變更而非語法錯誤——語法錯誤會立刻報錯、容易抓；行為變更（排序結果不同、型別轉換規則不同）不會報錯、但結果錯誤。

1# MySQL 升級前檢查工具
2mysqlcheck --all-databases --check-upgrade
3mysql_upgrade --upgrade-system-tables --dry-run

ORM 和 database driver 也要確認版本支援。PHP 的 mysqli 在 PHP 7.4+ 預設支援 caching_sha2_password、但舊版不支援。Node.js 的 mysql2 原生支援、但 mysql（舊套件）不支援。Python 的 mysqlclient 1.4+ 支援。

備份：升級前的保險

升級前的備份不是日常備份——它是一份明確的、經過驗證的、標記為「升級前保險點」的快照。

備份操作

1# MySQL: 完整 dump（InnoDB 用 --single-transaction 避免鎖表）
2mysqldump --all-databases --single-transaction --routines --triggers \
3  --set-gtid-purged=OFF > pre-upgrade-$(date +%Y%m%d-%H%M).sql
4
5# PostgreSQL: 完整 dump
6pg_dumpall > pre-upgrade-$(date +%Y%m%d-%H%M).sql

RDS 環境：在升級操作前手動建立 snapshot，而非依賴自動備份。自動備份在升級過程中可能被新的快照覆蓋，手動 snapshot 不會被自動清除。

1aws rds create-db-snapshot \
2  --db-instance-identifier mydb-prod \
3  --db-snapshot-identifier pre-upgrade-$(date +%Y%m%d)

備份驗證

備份存在不等於備份可用。驗證方式是把備份還原到一台獨立的測試實例、確認資料完整：

1# 還原到測試實例
2mysql -h test-instance -u admin -p < pre-upgrade-20260626-1400.sql
3
4# 驗證關鍵表的 row count
5mysql -h test-instance -e "SELECT COUNT(*) FROM orders; SELECT COUNT(*) FROM users;"

記錄還原時間：「從這份備份還原到可服務狀態需要 N 分鐘/小時」。這個數字是升級失敗時的停機時間下限——管理層需要這個數字來評估升級的風險。

平行驗證策略

在生產環境切換之前，先在新版本的平行環境上跑完所有驗證。平行驗證的目標是讓切換那一刻的風險降到最低——切換時已經知道新版本在相同資料和相同負載下的行為。

建立平行環境

驗證項目

平行驗證至少跑一週。時間越長、覆蓋到的邊界情境越多——月結批次、週期性報表、低頻排程任務都可能觸發只在特定條件下才出現的相容性問題。

切換策略

切換策略的選擇取決於三個變數的取捨：操作複雜度、停機時間、回退速度。

In-place 升級

直接在原實例上升級版本。RDS 的操作是修改 engine version、等待升級完成。

• 停機：升級期間實例不可用（MySQL 5.7→8.0 在 RDS 上約 10-30 分鐘，視資料量而定）
• 回退：從 pre-upgrade snapshot 還原，需要 snapshot restore 時間（分鐘到小時級）
• 適用：可接受計畫性停機的環境、資料量不大

Blue-green 切換

在新版本上建立獨立實例、透過 replication 同步資料、切換應用程式的連線端點。

• 停機：接近零（DNS TTL 或 endpoint 切換的傳播時間）
• 回退：把連線端點切回舊實例，舊實例持續運行
• 複雜度：需要維護兩個實例的同步、切換時要處理複寫延遲
• 適用：不能接受停機的 production 環境

RDS 從 2022 年開始提供原生的 Blue/Green Deployments 功能，簡化了同步與切換的操作：

1aws rds create-blue-green-deployment \
2  --blue-green-deployment-name mydb-upgrade \
3  --source arn:aws:rds:ap-northeast-1:123456789012:db:mydb-prod \
4  --target-engine-version 8.0.35

Read replica 升級後提升

建立指定新版本的 read replica，replica 同步完成後提升為獨立實例，應用程式切換連線。

• 停機：提升 replica 的幾秒 + 連線切換
• 回退：舊 primary 仍在，切回即可
• 限制：不是所有版本組合都支援跨版本 replica

選型判準

升級後的驗證與監控

切換完成後的 48-72 小時是觀察期。這段時間舊實例保持可用狀態，直到確認新版本穩定才退役。

切換後立即驗證

1. 應用程式的所有關鍵路徑可正常操作（登入、查詢、寫入、交易）
2. 連線池行為正常（沒有持續的 authentication failure 或 connection reset）
3. 排程任務（cron job、背景 worker）正常連線並執行

效能監控

比較升級前後的關鍵指標：

1# 觀察升級後的 slow query 數量
2mysql -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"
3
4# 比較 p99 延遲（需要 application-level metrics）
5# CloudWatch: DBInstanceIdentifier → ReadLatency, WriteLatency

升級後效能退化的常見原因：optimizer 行為改變（新版本選了不同的執行計畫）、buffer pool 冷啟動（升級後快取是空的、前幾小時延遲偏高是正常的）。如果 48 小時後延遲仍未回到基線，檢查 slow query log 找出退化的具體查詢。

舊實例退役

觀察期結束、新版本確認穩定後：

1. 停止舊實例的 replication（如果仍在同步）
2. 保留舊實例的 final snapshot
3. 刪除舊實例（先確認 deletion protection 關閉是刻意的、不是誤操作）
4. 更新文件：記錄升級日期、版本號、升級過程中遇到的問題

時程與管理層溝通

向管理層說明時的關鍵框架：資料是不可重建的，升級策略是「在旁邊建一個新版本的資料庫、驗證它在相同資料和相同負載下行為正確、然後切過去」。多出來的時間買的是「切換那一刻的信心」和「出問題時能快速回退」——兩者對生產服務都是必要的保險。

跨分類引用

• → 升級的共通操作框架：四階段模型的通用說明
• → Stateful 資源保護與依賴表達：multi-AZ、備份、deletion protection 的 IaC 描述
• → 無 SSH 環境的資料庫備份與變更管理：接手環境的資料庫備份策略

EOL 風險評估

EOL 在操作層面的意義是三件事同時停止：安全修補（CVE 不再被回填到該版本的 patch release）、核心更新（kernel 的錯誤修正與硬體支援停止）、套件庫維護（官方 repository 凍結或下架，新裝套件或更新依賴都做不到）。

風險時間軸

EOL 是一段逐漸惡化的過程，而非單一時間點：

常見的 EOL 情境

CentOS 7 在 2024 年 6 月結束支援，但仍有大量 production 環境在使用。CentOS 8 在 2021 年 12 月被轉向 CentOS Stream，打破了原本預期到 2029 年的支援承諾，迫使使用者重新選型。Ubuntu 18.04 的標準支援在 2023 年 4 月結束，Canonical 提供 ESM（Extended Security Maintenance）付費延長到 2028 年，但 ESM 只涵蓋 main 套件庫。

ESM 或類似的付費延長支援（RHEL 的 ELS、CentOS 的第三方 TuxCare）是「買時間做遷移」的合理策略——付月費取得額外 2-5 年的安全修補，讓團隊有餘裕規劃平行建置而非被迫緊急遷移。Ubuntu Pro 免費涵蓋 5 台 instance 的 ESM，超過才需要付費。ESM 是給遷移專案爭取時間的保險，而非長期方案——延長支援的套件覆蓋範圍通常比標準期窄。

合規的影響很直接：PCI DSS 要求所有面對持卡人資料的系統都執行在有安全修補支援的軟體上；SOC 2 和 ISO 27001 的定期稽核會檢查作業系統的支援狀態。在 EOL OS 上跑的 production 環境會讓稽核結果出現 finding，需要額外的補償控制（compensating control）才能通過——而補償控制的維護成本通常高於遷移本身。

目標 OS 選型

選型看四個維度：LTS 發布週期（支援年限多長）、社群與商業支援（問題能不能查到答案、能不能買付費支援）、套件可用性（應用層需要的 runtime 和 library 在官方 repo 裡有沒有）、團隊熟悉度（操作指令和設定路徑的學習成本）。

常見選擇

同家族 vs 跨家族

CentOS → Rocky Linux / AlmaLinux 是同家族遷移：套件名稱、設定路徑、init 系統（systemd）幾乎不變，應用層的改動最少。CentOS → Ubuntu 是跨家族遷移：套件管理從 yum/dnf 換成 apt、設定路徑從 /etc/httpd/ 變成 /etc/apache2/、某些服務名稱不同。

同家族遷移的優勢是應用層風險低——多數設定檔可以直接搬過去。跨家族遷移的優勢是可以借機切到更活躍的生態（Ubuntu 的社群回答量和第三方套件支援在多數指標上領先），代價是設定檔要全面調整。

選型判準：如果團隊已經有 Ubuntu 經驗、或其他系統已經跑 Ubuntu，統一到 Ubuntu 的長期維護成本較低。如果團隊對 RHEL 系操作更熟、或有 RHEL 付費支援合約，Rocky/Alma 是阻力最小的路。

遷移策略：原地升級 vs 平行建置

原地升級

在現有伺服器上直接換 OS 版本。做法是用 OS 提供的升級工具（如 do-release-upgrade、leapp）在跑著的系統上切換。

風險集中在升級過程中系統處於不確定狀態——kernel 換了但 userland 還沒、init 系統切了但服務設定還指向舊路徑。如果中途失敗、伺服器可能開不了機，而 rollback 意味著從備份還原整台機器。原地升級只在同 OS 家族的小版本升級（如 Ubuntu 20.04 → 22.04）且有完整 VM 快照保底時才值得考慮。

平行建置

在旁邊建一台新 OS 的伺服器、安裝應用層、遷移資料、用 DNS 或 load balancer 切換流量。舊伺服器保留作為 rollback 目標，確認新環境穩定後再退役。

平行建置的成本是短期多付一台伺服器的費用（通常是幾天到幾週）。收益是：升級失敗時舊伺服器完好無損、切回去只需要改 DNS 或 LB 的 target；新伺服器可以在切換前充分測試、不影響線上服務；整個過程可以在非尖峰時段進行。

對多數環境來說平行建置是預設策略。原地升級只在無法多開一台伺服器（預算極度受限、或裸機硬體無備品）時才退而求其次。

應用層的遷移清單

新 OS 上要重建整個應用執行環境。以下是逐項需要確認的面向：

Web 伺服器

如果新舊 OS 都用 Apache，設定檔的路徑可能不同（RHEL 系 /etc/httpd/conf.d/、Debian 系 /etc/apache2/sites-available/），模組載入方式也不同（LoadModule 指令 vs a2enmod 工具）。逐一比對現有的 VirtualHost 設定、rewrite 規則、SSL 設定。

如果同時換成 nginx，見下一節。

Runtime 版本對齊

新 OS 的官方 repo 裡的 PHP / Node / Python 版本可能跟舊 OS 不同。Ubuntu 22.04 預設 PHP 8.1、如果應用需要 PHP 7.4 要加第三方 PPA（如 ondrej/php）。確認所有 PHP extension（mysqli、curl、gd、mbstring、redis）在新 OS 上都有對應的套件名稱且已安裝。

1# 舊伺服器：列出所有已載入的 PHP module
2php -m > old-php-modules.txt
3
4# 新伺服器：比對缺了什麼
5php -m > new-php-modules.txt
6diff old-php-modules.txt new-php-modules.txt

資料庫客戶端程式庫

應用連接 MySQL / PostgreSQL 用的 client library（libmysqlclient、libpq）版本要跟資料庫伺服器相容。跨大版本（MySQL 5.7 client → MySQL 8.0 server）通常向前相容，但反過來可能有驗證方式不匹配的問題（如 MySQL 8.0 的 caching_sha2_password 預設驗證方式）。

Cron jobs

從舊伺服器匯出 crontab（crontab -l），在新伺服器重建。如果舊 OS 使用 /etc/cron.d/ 的檔案式 cron，確認新 OS 的 cron daemon 支援同樣的格式。Cron 的環境變數（PATH、MAILTO）在不同 OS 可能有不同預設。

日誌路徑

Apache 的預設 log 路徑在 RHEL 系是 /var/log/httpd/、Debian 系是 /var/log/apache2/。應用程式如果 hardcode 了日誌路徑，要在新 OS 上對齊。同時確認 logrotate 的設定在新 OS 上存在且正確。

檔案權限與使用者

不同 OS 的 web server 執行使用者不同（RHEL 的 apache、Debian 的 www-data）。如果應用依賴特定使用者名稱的檔案權限（如 upload 目錄的 owner），遷移後要調整 chown。

服務管理

現代 OS 都使用 systemd。但如果舊 OS 還有 sysvinit 腳本（/etc/init.d/），遷移時要轉換成 systemd unit file。轉換的核心是把 init 腳本的 start/stop/restart 邏輯對應到 systemd 的 ExecStart、ExecStop、Restart 欄位。

 1# /etc/systemd/system/myapp.service
 2[Unit]
 3Description=My Application
 4After=network.target mysql.service
 5
 6[Service]
 7Type=simple
 8User=www-data
 9ExecStart=/usr/bin/php /var/www/myapp/worker.php
10Restart=on-failure
11RestartSec=5
12
13[Install]
14WantedBy=multi-user.target

基礎軟體切換（Apache → nginx）

如果已經在為 OS 遷移建新伺服器，同時切換 web server 是成本最低的時機——反正設定檔要重寫、不如一次到位。分開做的話要拆兩次遷移、測兩次、承受兩次風險。

.htaccess → nginx 設定轉換

Apache 的 .htaccess 是分散式設定——每個目錄可以有自己的 .htaccess，Apache 在每次請求時逐層讀取。nginx 沒有這個機制，所有設定集中在 /etc/nginx/ 的設定檔裡。

轉換的第一步是找出所有 .htaccess 檔案：

1find /var/www/ -name ".htaccess" -exec echo "=== {} ===" \; -exec cat {} \;

常見的轉換對應：

平行測試

在新伺服器上同時安裝 nginx（port 80）和 Apache（port 8080）。用 curl 比對兩者的回應：

1# 比對首頁
2diff <(curl -s http://new-server/) <(curl -s http://new-server:8080/)
3
4# 比對一個有 rewrite 規則的 URL
5diff <(curl -sI http://new-server/old-path) <(curl -sI http://new-server:8080/old-path)

回應一致後再把 Apache 移除。重點比對項：HTTP status code（rewrite 的 301/302）、response body（PHP 輸出）、response header（cache control、security header）。

常見陷阱

.htaccess 的分散式設定在 WordPress 或其他 CMS 中常被用來動態控制 URL rewrite。WordPress 的 permalink 功能依賴根目錄的 .htaccess，切到 nginx 需要在設定檔裡加 try_files $uri $uri/ /index.php?$args; 才能讓 permalink 運作。其他 CMS（Drupal、Laravel）也有各自的 nginx 設定範例，通常在官方文件裡可以找到。

時程與管理層溝通

OS 遷移（平行建置）的時程取決於應用層的複雜度：

跟管理層溝通時用三個框架：

為什麼現在做：「目前的 OS 已經停止安全修補，每個月不遷移等於多一個月的曝險窗口。如果有合規要求（PCI DSS / SOC 2），下次稽核會被標記。」

做什麼：「在旁邊建一台新 OS 的伺服器，把應用搬過去、驗證通過後切換。舊伺服器保留一到兩週作為 rollback。」

花多久和多少錢：「工程師時間 1-3 週（依複雜度）。多一台伺服器的費用只有切換期間的短期成本。不做的隱藏成本是安全事故的潛在損失和合規罰款。」

跨分類引用

• → 升級的共通操作框架：四階段模型（評估差異 → 平行環境 → 分批切換 → 退役）
• → 平台遷移：如果 OS 遷移同時伴隨平台搬遷（地端 → 雲端）
• → Runtime 版本升級：PHP / Node 版本升級常伴隨 OS 遷移
• → 接手維運：接手一個 EOL OS 的環境後的下一步