這篇文章的操作順序按風險排列：先做不碰 prod 的盤點（零風險），再建本地開發環境（只動本機），然後才是碰 prod 的部署與資料庫紀律。

拍下完整現況（不動 prod）

接手後的第一個工作日只做一件事：把 prod 的完整狀態拍一份下來存到本地。這一步不改 prod 的任何東西，目的是讓自己手上有一份可對照的快照。

環境不同，拍照的工具和流程不同。先判斷自己的情境：

• 有 cPanel / Plesk 完整備份功能 → 用主機面板一次打包
• 只有 FTP 存取 → 用 FTP 逐層拍照
• 有 SSH 存取（部分 VPS 或獨立主機）→ 改讀有 SSH 但沒有 IaC 的雲端環境接管

用主機面板一次打包

如果主機有 cPanel，「備份精靈（Backup Wizard）」可以一次打包程式碼 + 資料庫 + email 設定 + cron jobs，是最快的完整快照方式。Plesk 的對應功能在「工具與設定 → 備份管理員」。

面板備份通常包含：網站檔案（含隱藏檔）、所有 MySQL 資料庫、email 帳戶與轉寄規則、cron job 設定、DNS zone 記錄。下載打包檔後解壓到本地、用 Git 初始化（見下方「初始化 Git repo」段）。

面板備份可能不包含的：SSL 憑證的私鑰（Let’s Encrypt 自動續期的通常不需要手動備份）、PHP 版本與模組設定（需要另外記錄，見環境設定的拍照）、.htaccess 以外的 Apache/LiteSpeed 自訂設定。拿到面板備份後仍然要跑「環境設定的拍照」段，因為面板備份拍的是檔案、不是環境設定。

用 FTP 逐層拍照

沒有主機面板（或面板不提供完整備份）時，要用 FTP 和 phpMyAdmin 分別拍程式碼和資料庫。

程式碼與靜態資源：用 FTP client 把整個網站目錄鏡像到本地。FileZilla 的操作路徑：站台管理員連線後，在遠端面板對根目錄按右鍵 → 「下載」，或用「伺服器 → 同步瀏覽」模式讓本地與遠端目錄結構保持對齊。WinSCP 提供「保持更新（Keep Remote Directory up to Date）」功能，但接手階段只需要一次性的完整下載，不需要持續同步。下載前確認 FTP client 的設定有勾選「顯示隱藏檔案」——.htaccess、.env、.user.ini 這類隱藏檔經常包含關鍵設定。

資料庫：用 phpMyAdmin 的「匯出」功能匯出完整資料庫（詳見下方「資料庫」段）。FTP 只拍程式碼，資料庫要另外匯出。

初始化 Git repo

不論用面板備份還是 FTP 逐層拍，拿到檔案後都初始化成 Git repo：

1mkdir project-takeover && cd project-takeover
2# FTP 下載完整站台到此目錄後
3git init
4git add -A
5git commit -m "initial snapshot from production FTP"

這個 commit 是接手的基準線。之後任何改動都能 diff 回這個起點，知道自己改了什麼。

資料庫

用 phpMyAdmin 的「匯出」功能：選「自訂」模式 → 勾選所有資料表 → 格式選 SQL → 勾選「加入 DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER 敘述」（讓匯入時能乾淨覆蓋）→ 壓縮選 gzip（大型資料庫避免瀏覽器逾時）→ 編碼選 UTF-8 → 執行。

phpMyAdmin 的匯出在資料庫超過幾百 MB 時容易因 PHP max_execution_time 或記憶體限制中斷。替代方案：如果主機有 cPanel，「phpMyAdmin → 匯出」旁邊通常有「MySQL 資料庫備份」或透過 cPanel API 的 mysqldump 介面，比 phpMyAdmin 的 PHP 層匯出更可靠。另一個選項是本地安裝 DBeaver（免費、跨平台）或 TablePlus（macOS/Windows），用主機提供的遠端 MySQL 連線（cPanel → 遠端 MySQL → 加入本機 IP 白名單）直接從本機執行 mysqldump。HeidiSQL（Windows 免費）也支援同樣的遠端連線匯出。

把匯出的 .sql 檔存進 repo：

1mkdir db-snapshots
2# 把 phpMyAdmin 匯出的檔案存到這裡
3mv ~/Downloads/production-dump.sql db-snapshots/$(date +%Y%m%d)-initial.sql
4git add db-snapshots/
5git commit -m "initial database snapshot from phpMyAdmin"

如果主機面板有提供 mysqldump 的 web 介面（部分 cPanel 有），用那個比 phpMyAdmin 的匯出更可靠——phpMyAdmin 在大資料庫上容易因為 PHP 記憶體限制而中斷。

環境資訊記錄

在 repo 根目錄建一份 ENVIRONMENT.md，記錄以下資訊：

 1## Production 環境
 2
 3- **主機商**：[名稱]、方案：[方案名稱]
 4- **PHP 版本**：cPanel/Plesk 的 PHP 設定頁直接顯示；沒有控制面板時，FTP 上傳一個 `phpinfo.php`（內容 `<?php phpinfo();`）到站台根目錄、瀏覽器開啟後記錄版本、確認後立刻刪除（phpinfo 會暴露伺服器完整設定）
 5- **MySQL 版本**：phpMyAdmin 首頁顯示
 6- **Web server**：Apache / LiteSpeed / Nginx（控制面板或 response header）
 7- **域名 / DNS**：誰管的、nameserver 指向哪裡
 8- **SSL**：Let's Encrypt 自動續期 / 主機商代管 / 手動上傳
 9- **Cron jobs**：控制面板 → Cron Jobs 頁面截圖或列表
10- **Email**：有沒有用主機的 email 服務、轉寄規則
11- **.htaccess**：已包含在 FTP 下載中（注意隱藏檔有沒有漏）

掃描 hardcoded credential

PHP 專案常見的做法是把資料庫密碼、API key 直接寫在 config.php 或 wp-config.php 裡。在本地 repo 跑一次掃描：

1grep -rn "password\|passwd\|secret\|api_key\|apikey\|api_secret" \
2  --include="*.php" --include="*.ini" --include="*.env" .

把找到的每一筆記錄下來：哪個檔案、什麼 credential、用在哪裡。這份清單是後續 credential 輪替的輸入。

第三方整合清單

翻 code 找出所有對外部服務的呼叫——金流（綠界、藍新、Stripe）、簡訊（Twilio、三竹）、Email（SendGrid、SMTP）、社群登入（Facebook、Google）、CDN、Analytics。每一個整合都有對應的 API key 或 webhook URL，這些都是接手後需要確認存取權的項目。

環境設定的拍照

程式碼和資料庫之外，伺服器的執行環境本身也要記錄。非 container 環境沒有 docker commit 可以一次打包整台機器，要逐層拍：

PHP 設定：在站台根目錄上傳一個 phpinfo.php（內容 <?php phpinfo();），用瀏覽器打開後把完整輸出另存為 HTML 檔。記錄完立刻刪掉這個檔案——phpinfo 會暴露伺服器的完整設定與路徑。需要記錄的關鍵項：PHP 版本、載入的模組（mysqli、curl、mbstring、gd、imagick）、upload_max_filesize、post_max_size、max_execution_time、memory_limit、error_reporting、session.save_handler。這些值直接影響程式碼能不能在本地環境重現相同的行為。

Cron jobs：cPanel 的 Cron Jobs 頁面或 Plesk 的排程工作清單，截圖或逐條抄到 ENVIRONMENT.md。每一條 cron 記錄三項：排程時間、執行的指令（通常是 /usr/local/bin/php /home/user/public_html/cron.php）、這條 cron 的業務用途（如果能從指令或檔案名推斷）。

SSL 憑證：記錄域名、簽發者（Let’s Encrypt / 自購 / 主機商代管）、到期日。瀏覽器的鎖頭圖示可以查看憑證詳情。從本機也可以用 CLI 確認：

1echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -issuer

如果是 Let’s Encrypt 自動續期，要確認續期機制是 cPanel 內建（AutoSSL）還是某個自訂 cron。手動購買的憑證要記錄到期日並設日曆提醒——過期後站台會直接出現瀏覽器安全警告。

.htaccess 規則：.htaccess 可能散在多個目錄（根目錄、uploads/、wp-admin/、api/）。FTP 下載時已包含在內（前提是 FTP client 有設定顯示隱藏檔案），確認一下這些檔案都在 repo 裡。

外部服務連線：除了前一節的第三方整合清單，用 grep 掃程式碼找出所有對外 URL。這些連線在未來遷移時要同步處理——搬了伺服器但 callback URL 沒改，金流通知就收不到。

1grep -rn "https\?://" --include="*.php" . \
2  | grep -v "localhost\|127\.0\.0\.1\|example\.com" \
3  | sort -u > _environment/external-urls.txt

檔案權限：FileZilla 的遠端檔案清單有權限欄。記錄 uploads/、cache/、sessions/、config 檔案的權限。777 的目錄是安全風險（任何使用者都能寫入），在多租戶的主機上尤其危險——同台主機的其他帳戶也能存取。

把以上資料存進 repo 的 _environment/ 目錄：

1_environment/
2├── phpinfo-20260626.html      # phpinfo 完整輸出
3├── cron-jobs.md               # cron 清單
4├── ssl-cert-info.txt          # 憑證資訊
5├── external-urls.txt          # 外部連線清單
6└── file-permissions.txt       # 目錄權限記錄

_environment/ 可加進 .gitignore（phpinfo 含敏感資訊），或只 ignore HTML 檔、其餘進 Git。

建立本地開發環境

本地能跑起來，才有安全的測試空間。目標是在本機重現 prod 的 PHP + MySQL 版本組合。

選型：Docker vs 本地堆疊

選型判準：如果 prod 的 PHP 版本是 5.6 或 7.0 這類已停止維護的舊版，Docker 是唯一能精確對齊的選項——MAMP/XAMPP 通常只提供仍在維護的版本。常見版本（7.4、8.0、8.1、8.2）用 MAMP/Laragon 會比 Docker 更快跑起來。

Docker 方式

Docker Compose V2（docker compose 指令）不需要 version 欄位。如果使用舊版 docker-compose CLI，在檔案開頭加 version: '3.8'。

 1# docker-compose.yml
 2services:
 3  web:
 4    image: php:8.1-apache
 5    volumes:
 6      - ./:/var/www/html
 7    ports:
 8      - "8080:80"
 9  db:
10    image: mysql:8.0
11    environment:
12      MYSQL_ROOT_PASSWORD: localdev
13      MYSQL_DATABASE: project
14    volumes:
15      - ./db-snapshots/initial.sql:/docker-entrypoint-initdb.d/init.sql
16    ports:
17      - "3306:3306"
18  phpmyadmin:
19    image: phpmyadmin/phpmyadmin
20    environment:
21      PMA_HOST: db
22    ports:
23      - "8081:80"

PHP 版本要對齊 prod。如果 prod 是 PHP 7.4，本地用 php:7.4-apache。版本差異會導致函式行為不同（str_contains 在 8.0 才有、mysql_* 系列在 7.0 移除），測試通過但 prod 壞掉。phpmyadmin service 讓本地也有跟 prod 相同的資料庫操作介面，方便驗證 phpMyAdmin 上要執行的操作。

匯入資料庫

Docker 啟動後匯入初始快照：

1docker exec -i project-db-1 mysql -uroot -plocaldev project < db-snapshots/20260626-initial.sql

MAMP/Laragon/XAMPP 的匯入方式：開啟對應的 phpMyAdmin（通常在 localhost/phpmyadmin）→ 選資料庫 → 匯入 → 選 .sql 檔案 → 執行。或用 DBeaver/TablePlus 連本地 MySQL 後執行 SQL 檔。

常見的「本地跑不起來」原因

本地能完整跑起來之後，這個環境就是所有變更的測試場。任何改動都先在這裡驗證。

資料庫變更紀律

phpMyAdmin 讓修改 prod DB 只需要幾次點擊，這正是它危險的原因——沒有 preview、沒有 undo、沒有 review。紀律要靠流程補上。

變更流程

1. 在本地 DB 寫好 SQL 並執行，確認結果正確
2. 把 SQL 存進 repo 的 migrations/ 目錄，檔名帶日期：

1# migrations/2026-06-26-add-status-column.sql
2ALTER TABLE orders ADD COLUMN status VARCHAR(20) DEFAULT 'pending';

3. 在 phpMyAdmin 上對要改的資料表做匯出（只匯出該表的結構 + 資料），存進 db-snapshots/ 作為回退依據
4. 在 phpMyAdmin 的 SQL 頁籤貼上已驗證的 SQL 執行
5. 在 repo 的 CHANGELOG.md 記錄：時間、操作者、改了什麼、為什麼

高風險操作的額外防護

修改欄位型別、刪除欄位、刪除資料表、批次更新資料——這些操作在 phpMyAdmin 上執行就生效，沒有乾淨的 undo。額外防護是在執行前先確認：

• 有沒有剛做的該資料表備份（不是上週的，是剛剛做的）
• 這張表有沒有 foreign key 或觸發器會連帶影響其他表
• 如果改錯了，回退的具體步驟是什麼（從備份 SQL 重建整張表？還是用 UPDATE 改回來？）

部署紀律

FTP 部署沒有 CI pipeline 的自動化保護，但不代表不能有流程。流程的目標是讓每次部署都可追溯、可回退。

部署步驟

11. git diff HEAD~1 --name-only          # 確認這次改了哪些檔案
22. 本地測試通過
33. FTP client 開兩個窗格：左邊本地、右邊 prod
44. 用 FileZilla 的目錄比較功能確認差異
55. 只上傳有變更的檔案（不要整站覆蓋）
66. 上傳完在瀏覽器驗證功能
77. git tag deploy-20260626 && git push   # 標記這次部署的版本

備份策略

無 SSH 的主機環境通常不提供自動快照。備份要自己做：

如果主機面板有自動備份功能（cPanel 的 Backup Wizard），確認它有開並且能還原。但不要把它當唯一備份——主機商的備份可能在主機出問題時一起不見。

備份自動化（沒 SSH 也能做）

無 SSH 的環境沒有 cron + CLI 的組合，但可以用本機排程 + FTP client 的 CLI 模式達成自動化備份。

用 lftp（macOS/Linux 可透過 Homebrew 或 apt 安裝）做定期站台鏡像：

1# backup.sh — 加入本機的 cron 或 launchd 每日執行
2lftp -e "mirror --verbose /public_html/ /local/backup/site/; quit" \
3  -u username,password ftp.example.com

rclone 是另一個選項，支援 FTP/SFTP 且有更好的增量同步（只傳有變更的檔案）：

1# 設定 rclone remote（首次）
2rclone config  # 選 FTP、填入主機資訊
3
4# 同步（之後每次只傳差異）
5rclone sync myhost:/public_html/ /local/backup/site/ --progress

macOS 用 launchd plist、Windows 用工作排程器（Task Scheduler）排定每日執行這些腳本，讓備份不再依賴人工記得。

資料庫的自動備份較受限——phpMyAdmin 沒有 CLI 介面。如果主機允許遠端 MySQL 連線，可以在本機 cron 裡加一條 mysqldump：

1mysqldump -h mysql.example.com -u dbuser -p'password' dbname | gzip > /local/backup/db/$(date +%Y%m%d).sql.gz

不允許遠端連線時，退而求其次：每週手動從 phpMyAdmin 匯出一次、存進 repo。

回退方式

FTP 部署沒有 rollback 按鈕。回退的方式是：

1git checkout deploy-20260625 -- path/to/changed/file.php
2# 把特定檔案回到上一次部署的版本，再 FTP 上傳

整站回退則是 checkout 到上一個 deploy tag，再整批 FTP 上傳。這就是為什麼 deploy tag 重要——沒有 tag 就不知道要回退到哪個版本。

credential 盤點與保護

接手後要回答的問題是：有哪些 credential、誰有存取權、哪些需要輪替。

盤點清單

最高優先輪替的是前人可能仍持有存取權的 credential：主機面板密碼、資料庫密碼。如果前人的離開不是善意的（被解僱、爭端），這些應該在接手的第一天就改。

從 hardcode 到 config 分離

長期目標是把 credential 從 code 裡搬出來。即使在沒有 SSH 的環境也能做：

1// 改前：password 直接寫在 code 裡
2$db_password = 'p@ssw0rd123';
3
4// 改後：從 .env 讀取（用 vlucas/phpdotenv 或手寫 parse）
5$db_password = getenv('DB_PASSWORD') ?: parse_ini_file(__DIR__ . '/.env')['DB_PASSWORD'];

.env 放在 webroot 之外（如果主機允許）或在 .htaccess 裡禁止存取：

1<Files ".env">
2    Require all denied
3</Files>

外部監控（prod 不用裝東西）

無 SSH 的環境裝不了監控 agent，但可以用外部 HTTP 檢查服務從外面看。這類服務從多個地理位置定期對網站發送 HTTP request，回應異常時通知。

UptimeRobot 的免費方案提供 50 個 monitor、每 5 分鐘檢查一次，夠用於一個站台的首頁 + 幾個關鍵頁面（登入頁、API endpoint、金流回呼 URL）。Better Stack（原 Better Uptime）提供類似功能並附帶 status page。兩者都只需要填入 URL 和通知方式（email / Slack / webhook），不需要在 server 上裝任何東西。

設定後至少加三個 monitor：首頁（網站是否活著）、登入或後台入口（PHP 是否正常執行）、以及任何有外部依賴的頁面（金流 callback、API endpoint）。這不是完整的可觀測性，但至少讓「網站掛了」這件事從「使用者打電話來」變成「手機收到通知」。

時程參考

完整走完盤點（FTP mirror + DB dump + 環境記錄）約需半天到一天。本地環境建立與驗證約需半天到一天（取決於 PHP 版本對齊的難度）。紀律建立（changelog + 部署流程）是持續的、但框架搭建約需 2-3 小時。CI 化 FTP 部署約需半天。整體從接手到穩定維運約 2-3 個工作天。

升級路徑的切入點

接手穩定後，逐步脫離無 SSH 環境的約束。每一步都獨立且可回退。

最低成本的第一步：CI 化 FTP 部署

在 GitHub repo 設定 GitHub Actions，推到 main 時自動跑測試（如果有的話）+ 自動 FTP 部署。FTP credential 存在 GitHub Secrets 裡，不在 code 裡。

 1# .github/workflows/deploy.yml
 2name: Deploy via FTP
 3on:
 4  push:
 5    branches: [main]
 6jobs:
 7  deploy:
 8    runs-on: ubuntu-latest
 9    steps:
10      - uses: actions/checkout@v4
11      - uses: SamKirkland/FTP-Deploy-Action@v4
12        with:
13          server: ${{ secrets.FTP_HOST }}
14          username: ${{ secrets.FTP_USER }}
15          password: ${{ secrets.FTP_PASS }}
16          server-dir: /public_html/

這一步的價值是部署從「開 FileZilla 手動上傳」變成「push to main 自動部署」，人為失誤的空間顯著縮小。Prod 伺服器不需要任何改動。

下一步：遷移到有 SSH 的 VPS

當以下任一條件出現時，無 SSH 環境的約束會變成瓶頸：

• 需要 SSH 存取（裝 Git、跑 CLI 工具、設排程）
• 需要自訂 PHP extension 或 PHP 版本
• 需要更多的運算資源或記憶體
• 需要環境分離（dev / staging / prod）

遷移到 VPS（DigitalOcean、Linode、AWS Lightsail）後，SSH 存取讓所有雲端環境的工具鏈成為可用——Git on server、composer、artisan、mysqldump CLI、cron 的完整控制。這一步之後，接手維運的環境開始對齊模組負一：還沒有 infra 的環境的操作紀律，後續可以按成熟度階梯逐步往 IaC 推進。

跨分類引用

• → 有 SSH 但沒有 IaC 的雲端環境接管：搬到 VPS 或雲端後的接管流程
• → 模組負一：還沒有 infra 的環境：接手完成、環境穩定後，操作紀律對齊這裡
• → 模組零：infra 是什麼：成熟度階梯作為接手後評估現況的座標
• → 模組二：身分與憑證地基：credential 盤點與輪替的系統性設計
• → 模組八：治理好習慣：tagging、secret 管理、成本可見性

接管的操作順序是：先拍下現況（盤點）、再理解結構（依賴）、再收斂風險（credential、備份）、再建立紀律（變更紀錄）、最後才考慮 IaC 導入。每一步都在不改動 production 的前提下進行。

資源盤點：拍下雲端現況

盤點的目標是把「雲端上有什麼」轉成一份可版本控制的清單。這份清單是後續所有操作的事實基礎 — 沒有清單就無法判斷哪些資源重要、哪些可以回收、哪些的設定有風險。

盤點的工具依環境類型不同：

• VM 為主（EC2 / GCE） → 先跑 VM 快照與系統清單，再跑 CLI 資源盤點
• Managed service 為主（RDS / Lambda / S3） → 直接跑 CLI 資源盤點
• 混合（VM + managed） → 兩個都跑：先 VM 快照（拍下機器狀態），再 CLI 盤點（拍下所有雲端資源）

用 CLI 拉清單

盤點有三層工具可用，從粗到細：

全貌掃描：先用跨服務工具拿到「到底有多少資源」的量級感。AWS Resource Explorer 在 Console 開啟後可以用搜尋語法跨 region、跨 service 查資源（例如搜 resourcetype:ec2:instance 列出所有 EC2）。Steampipe 是開源的 SQL 介面雲端查詢工具，用 select * from aws_ec2_instance 這類語法查詢，對習慣 SQL 的人比 CLI flag 直覺。兩者都能在幾分鐘內拿到環境的全貌。

Tag 層掃描：AWS Resource Groups Tagging API 能跨服務撈出所有被標記的資源，但會漏掉沒有 tag 的 — 而接手環境裡沒 tag 的資源往往是風險最高的（沒人認領、不敢動）。

1aws resourcegroupstaggingapi get-resources \
2  --output json > inventory/tagged-resources.json

Per-service 細節：全貌掃描只告訴你資源存在，細節（備份設定、SG 規則、IAM policy）要用 per-service describe 拉。以下是接手時最該優先盤點的四類：

 1# EC2：哪些機器在跑、什麼規格、在哪個 subnet
 2aws ec2 describe-instances \
 3  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,SubnetId,SecurityGroups[].GroupId,Tags]' \
 4  --output json > inventory/ec2.json
 5
 6# RDS：資料庫的備份設定、刪除保護、Multi-AZ
 7aws rds describe-db-instances \
 8  --query 'DBInstances[].[DBInstanceIdentifier,Engine,DBInstanceClass,MultiAZ,BackupRetentionPeriod,DeletionProtection]' \
 9  --output json > inventory/rds.json
10
11# Security Group：哪些規則對外開放
12aws ec2 describe-security-groups \
13  --query 'SecurityGroups[].[GroupId,GroupName,IpPermissions]' \
14  --output json > inventory/security-groups.json
15
16# S3：哪些 bucket、versioning 是否開啟
17for bucket in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
18  echo "$bucket: $(aws s3api get-bucket-versioning --bucket $bucket --query 'Status' --output text)"
19done > inventory/s3-versioning.txt

把所有輸出存進一個 Git repo 的 inventory/ 目錄。這份快照的價值在於：一週後再跑一次比對差異，就能看出環境在背景長出了什麼新資源。

優先查三件事

盤點不需要一次做完所有服務，但三件事要第一天就查：

對外暴露面：security group 裡有沒有 0.0.0.0/0 入站規則指向非 HTTP/HTTPS 的 port（22、3306、5432、6379）。手動逐條查很慢 — 用安全掃描工具一次跑完更可靠。Prowler 是開源的 AWS 安全掃描工具，一次執行就能產出「哪些 SG 對外開放、哪些 S3 public、哪些 IAM 過寬」的分類報告：

1# 安裝後執行，針對最相關的服務掃描
2prowler aws --services ec2 iam s3 rds -M json-ocsf -o inventory/
3
4# 如果只想快速查 SG 暴露面，用 CLI：
5aws ec2 describe-security-groups \
6  --query 'SecurityGroups[].IpPermissions[?contains(IpRanges[].CidrIp, `0.0.0.0/0`)]' \
7  --output json | jq '[.[][] | select(.FromPort != 80 and .FromPort != 443)]'

ScoutSuite 是類似工具、支援多雲（AWS / GCP / Azure）。AWS Trusted Advisor 的免費 tier 也有基本安全檢查（S3 public access、SG 開放埠），但覆蓋面比 Prowler 窄。接手時三者選一跑一次，比手動翻 Console 快且不會漏。

備份狀態：RDS 的 BackupRetentionPeriod 是不是 0（代表沒有自動備份）。S3 的 versioning 是不是關的。如果是，這是接手後第一個要改的設定 — 改備份設定不影響服務運作，但沒有備份時任何資料操作失誤都不可逆。

誰最近在動環境：CloudTrail 記錄了所有 API 呼叫。查最近 30 天的變更事件，能看出哪些資源被頻繁修改、被誰修改。這比逐一問前團隊成員可靠——CloudTrail 不會漏記。

1aws cloudtrail lookup-events \
2  --lookup-attributes AttributeKey=ReadOnly,AttributeValue=false \
3  --start-time $(date -v-30d +%Y-%m-%dT%H:%M:%S) \
4  --max-items 50 \
5  --query 'Events[].[EventTime,Username,EventName,Resources[0].ResourceName]' \
6  --output table

VM 層級的快照

如果接手的環境包含 EC2 或 GCE 等 VM，在做任何改動之前先對每台 VM 建一個 AMI（AWS）或 machine image（GCP）。這是最粗粒度但最完整的「拍照」——整台機器的 OS、安裝的軟體、設定檔、磁碟內容全部打包成一個可重建的映像。

 1# AWS: 對 EC2 建 AMI（--no-reboot 避免服務中斷）
 2aws ec2 create-image \
 3  --instance-id i-0abc123 \
 4  --name "takeover-baseline-$(date +%Y%m%d)" \
 5  --no-reboot
 6
 7# 確認 AMI 建立完成
 8aws ec2 describe-images \
 9  --owners self \
10  --filters "Name=name,Values=takeover-baseline-*" \
11  --query 'Images[].[ImageId,Name,State]' \
12  --output table

--no-reboot 讓快照過程中服務不中斷，代價是檔案系統快照的一致性不如有 reboot 的版本（記憶體中的寫入可能還沒 flush 到磁碟），但對接手基線已經足夠。AMI 的費用是底層 EBS 快照的儲存費用（按 GB 計費、差異儲存），作為接手保險措施這筆成本值得。

除了 VM 快照，有 SSH 存取時也要拍 VM 內部的軟體環境——AMI 可以還原整台機器，但看不到「裡面裝了什麼、跑了什麼」的摘要：

 1# 作業系統與版本
 2cat /etc/os-release
 3
 4# 已安裝的套件清單
 5dpkg -l > ~/takeover/packages-$(date +%Y%m%d).txt   # Debian/Ubuntu
 6rpm -qa > ~/takeover/packages-$(date +%Y%m%d).txt    # RHEL/CentOS/Amazon Linux
 7
 8# 執行中的服務
 9systemctl list-units --type=service --state=running > ~/takeover/services.txt
10
11# 所有使用者的 cron jobs
12for user in $(cut -f1 -d: /etc/passwd); do
13  echo "=== $user ===" >> ~/takeover/crontabs.txt
14  crontab -u "$user" -l 2>/dev/null >> ~/takeover/crontabs.txt
15done
16
17# 網路監聽的 port（哪個 process 在聽哪個 port）
18ss -tlnp > ~/takeover/listening-ports.txt

把這些輸出存進盤點 repo，跟 CLI 資源盤點（describe 指令的輸出）放在一起。listening-ports.txt 跟 security group 規則對照，可以看出「哪些 port 有服務在聽但 SG 沒開」（可能是內部服務）和「哪些 port SG 開了但沒有服務在聽」（可能是殘留規則）。

依賴關係推導

盤點回答「有什麼」，依賴推導回答「改一個會連帶影響什麼」。手動環境沒有 Terraform 的依賴圖可以看，需要從資源的引用關係反推。

從 security group 開始

Security group 是依賴推導的最佳起點，因為它的引用關係最密集 — 幾乎每個資源都掛著至少一個 SG，而 SG 之間可以互相引用（app SG 的入站來源是 LB SG、DB SG 的入站來源是 app SG）。

1# 列出每個 SG 被哪些 ENI（網卡）使用
2aws ec2 describe-network-interfaces \
3  --query 'NetworkInterfaces[].[NetworkInterfaceId,Description,Groups[].GroupId]' \
4  --output json > inventory/sg-usage.json

AWS Console 的 VPC 頁面有 Resource Map 功能，可以視覺化 subnet → instance → SG 的對應關係，接手時第一次瀏覽依賴用它比 CLI 直覺。要產出可存檔的依賴圖，draw.io（有 AWS icon set）或 Lucidchart 都能畫，重點是圖要存進 repo、不是畫完就丟。

如果後續打算導入 Terraform，Former2 可以掃描現有 AWS 資源、自動產出 Terraform / CloudFormation / CDK 程式碼。產出的程式碼不會完美（屬性常漏、命名要改），但作為反推依賴關係的起點比從零寫快。Inframap 則是從 Terraform state 產出依賴關係圖（在 import 階段才用得到）。

從 SG 的引用鏈可以畫出一張粗略的依賴圖：

這張圖不需要精確到每個 port — 它的用途是在改動任何資源前，快速判斷影響範圍。例如要改 app SG 的規則時，先查它被哪些 EC2 和 ECS 引用、它的入站來源 ALB SG 是否受影響。

其他依賴面向

除了 SG，以下幾個引用關係也要記錄：

• EC2 → IAM role：instance profile 決定這台機器能存取什麼（S3 bucket、Secrets Manager、其他 AWS 服務）
• RDS → subnet group：決定資料庫在哪些 subnet 裡，改 VPC 或 subnet 時會受影響
• ALB → target group → EC2/ECS：流量路徑，改 target group 的 health check 或移除成員會影響服務可用性
• Lambda → VPC 設定：如果 Lambda 被放進 VPC，它的出站走 NAT，改 NAT 或 route table 會影響它
• Route 53 → ALB/EC2：DNS 指向哪個資源，改資源 IP 或 ALB 時要同步更新

credential 盤點與收斂

接手環境時，credential 是風險最高的一類 — 前團隊建立的 IAM user 和 access key 可能還在活躍狀態，而那些人已經不在團隊裡了。

接手後第一件事是用 aws-vault 管理自己的 credential。aws-vault 把 AWS access key 存在 OS keychain（macOS Keychain / Windows Credential Manager），而非明文放在 ~/.aws/credentials。執行 AWS 指令時由 aws-vault 注入臨時 session，本地磁碟上不留長期 key 的明文。不要沿用前人留下的 AWS CLI profile — 那些 profile 的權限範圍和用途都不確定。

1# 安裝後設定新的 profile
2aws-vault add takeover-admin
3# 用臨時 session 執行指令
4aws-vault exec takeover-admin -- aws sts get-caller-identity

產出 credential 報告

1aws iam generate-credential-report
2aws iam get-credential-report \
3  --query 'Content' --output text | base64 -d > inventory/credential-report.csv

這份 CSV 列出所有 IAM user、每把 access key 的建立時間、上次使用時間、MFA 是否啟用。從中篩出三類需要處理的：

停用（deactivate）而非直接刪除是關鍵 — 停用後如果某個自動化腳本依賴這把 key 會立刻報錯，這時候可以快速重新啟用；直接刪除就回不去了。觀察期設 7 天，涵蓋一個完整的業務週期（含週末的 cron job）。

檢查 key 散落的位置

Access key 可能被寫在不只一個地方：

 1# EC2 user data 裡是否有 hardcode 的 key
 2aws ec2 describe-instance-attribute \
 3  --instance-id i-xxx --attribute userData \
 4  --query 'UserData.Value' --output text | base64 -d | grep -i "aws_access_key\|aws_secret"
 5
 6# Lambda 環境變數
 7aws lambda list-functions --query 'Functions[].FunctionName' --output text | \
 8  xargs -I{} aws lambda get-function-configuration --function-name {} \
 9  --query 'Environment.Variables' --output json | grep -i "key\|secret\|password"
10
11# SSM Parameter Store
12aws ssm describe-parameters --query 'Parameters[].Name' --output text

找到 hardcode 的 key 後，替換路徑是改用 IAM role（EC2 用 instance profile、Lambda 用 execution role）。替換前先確認 role 的 policy 涵蓋這把 key 原本在做的操作。

備份驗證

盤點出的每個 stateful 資源（RDS、S3、EBS）都要確認備份狀態。接手環境時不能假設「前團隊應該有設定備份」— 要親自驗證。

RDS 備份

1# 檢查每個 RDS instance 的備份設定
2aws rds describe-db-instances \
3  --query 'DBInstances[].[DBInstanceIdentifier,BackupRetentionPeriod,LatestRestorableTime,DeletionProtection]' \
4  --output table

BackupRetentionPeriod 為 0 代表沒有自動備份 — 立刻改成至少 7 天。DeletionProtection 為 false 代表一個誤操作就能刪掉資料庫 — 立刻開啟。這兩項設定的修改不需要重啟、不影響服務。

備份存在不等於備份可用。接手後的第一週內，從最近的 snapshot 還原一台測試 RDS、連進去確認資料完整。這個步驟的成本是一台 RDS 跑幾小時的費用，換到的是「備份確定能用」的確認 — 等到要用備份的時候才發現不能還原，代價是另一個量級。

S3 versioning

沒有開 versioning 的 bucket，物件被覆寫或刪除後不可回復。對承載業務資料的 bucket（上傳的檔案、匯出的報表、設定檔），開啟 versioning：

1aws s3api put-bucket-versioning \
2  --bucket my-business-data \
3  --versioning-configuration Status=Enabled

開啟 versioning 不影響既有物件，但會讓後續的每次覆寫都保留舊版本。儲存成本會因為保留歷史版本而增加 — 配一條 lifecycle rule 設定 noncurrent version 的過期天數來控制。

建立變更紀律

盤點、依賴推導、credential 收斂做完後，環境的現況已經有一份可查的記錄。下一步是確保從現在開始的每一次變更都留下痕跡。

變更日誌

在 inventory repo 裡建一份 CHANGELOG.md，每次改動 production 就追加一筆：

1## 2026-06-26
2
3- **操作者**：alice
4- **資源**：rds/payments-prod
5- **變更**：BackupRetentionPeriod 0 → 14, DeletionProtection false → true
6- **原因**：接手盤點發現備份未開啟
7- **回退方式**：BackupRetentionPeriod 改回 0（不建議）

CloudTrail 確認

確認 CloudTrail 正在記錄 management events。如果沒有 trail 存在，建一個指向 S3 bucket 的 trail — 這是事後追溯「誰動了什麼」的最後防線。

1aws cloudtrail describe-trails --query 'trailList[].{Name:Name,S3:S3BucketName,IsLogging:IsLogging}'

開始標 tag

盤點過程中辨識出的每個資源，標上 env、owner、service 三個 tag。接手階段的 owner 通常標「待確認」或新接手的團隊名稱。tag 的價值在於讓後續的盤點和清理可以用查詢系統性地進行 — 沒有 tag 的資源無法被 filter 找到。

往 IaC 的銜接

盤點和紀律建立完成後，環境已經從「不知道有什麼」推進到「知道有什麼、知道誰在動、改了有紀錄」。這個狀態對應成熟度階梯的第零階到第一階之間。

成本現況

接手環境通常伴隨「這個月帳單多少」的問題。AWS Cost Explorer（免費）能看過去幾個月的花費分布，按服務類型、帳號、tag 維度拆。接手時先拉一次 Cost Explorer 的月度趨勢，看有沒有異常成長或不預期的高額服務。後續導入 IaC 後，Infracost 可以在 terraform plan 階段預估變更的成本影響（例如「升 RDS 規格會多花多少」），讓成本決策在 apply 之前就被看見。

往 IaC 的銜接不需要一次做完。按穩定度和改動風險排序：

每批 import 的操作流程是：terraform import → terraform plan 確認零變更 → 寫 HCL 補齊差異 → 再跑 plan 直到零變更。具體的 import 步驟和工具選型在模組一：最小可行 IaC。

時程參考：10-20 個資源的環境，完成盤點 + credential 收斂 + 備份驗證約需 3-5 天；往 IaC 的 import 約需 1-2 週。兩者可以平行進行但建議先完成盤點 — 沒有完整的資源清單就開始 import，容易漏掉關鍵的依賴關係。

跨分類引用

• → 有半套 IaC 但文件缺失的環境接管：如果盤點過程中發現環境裡已有部分 Terraform code
• → 模組負一：還沒有 infra 的環境：盤點完成後的操作紀律對齊
• → 模組零：infra 是什麼：成熟度階梯作為接手後現況評估的座標
• → 模組一：最小可行 IaC：盤點完成後的第一步 IaC 導入
• → 模組二：身分與憑證：credential 收斂的完整設計
• → 團隊權限分級與存取管理：接手後重新建立權限分級

本篇的操作流程從盤點差距開始，經過 state 健康檢查、drift 收斂、文件重建，到最後排出收斂的優先序。每一步都在不影響線上服務的前提下進行。

state 與現實的差距盤點

盤點的第一步是跑 terraform plan 但不 apply — plan 的輸出就是程式碼描述的狀態與雲端現實之間的完整差距清單。

1terraform plan -no-color > plan-baseline-$(date +%Y%m%d).txt

把這份輸出存進 repo，它是接手時的基線快照。之後每一次收斂動作的效果都用「跟這份基線比少了幾項 diff」來衡量。

三類 diff 的判讀

plan 輸出的每一項 diff 歸屬三類，各自的風險等級與處理方式不同：

「要刪」是最危險的一類。常見成因是：前人在 Console 手動刪了某個資源但沒同步從程式碼移除（state 裡還有紀錄），或者前人在程式碼裡移除了某段 HCL 但沒跑 apply（雲端資源還在、state 記得它）。兩種情況都需要先確認該資源在雲端是否存在、是否仍被服務依賴，再決定是從 state 移除（terraform state rm）還是補回 HCL。

另一個需要留意的標記是 -/+（forces replacement）— 它代表 Terraform 判定這個屬性的變更無法原地更新，必須先刪除再重建。對 stateful 資源（RDS、EBS volume）來說這等於資料遺失，在接手階段看到這個標記要先暫停、查清楚是哪個屬性觸發了 replacement。

哪些資源在 state 裡、哪些不在

terraform state list 列出所有被 IaC 管理的資源。配合 terraform show -json 可以取得更結構化的 managed resource 摘要：

1# state 裡有什麼（清單）
2terraform state list > managed-resources.txt
3
4# state 裡有什麼（結構化摘要：type + name + provider）
5terraform show -json | jq '.values.root_module.resources[] | {type, name, provider}' > managed-summary.json

但 state 只是一份已知的清單 — 雲端上可能還有大量不在這份清單裡的資源。用 CLI 列舉雲端資源跟 state 做比對：

1
2# 雲端上有什麼（以 EC2 + RDS + SG 為例）
3aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId' --output text > cloud-ec2.txt
4aws rds describe-db-instances --query 'DBInstances[].DBInstanceIdentifier' --output text > cloud-rds.txt
5aws ec2 describe-security-groups --query 'SecurityGroups[].GroupId' --output text > cloud-sg.txt

用這兩份清單做比對，分成三類：

未管理的資源需要逐一判斷：這個資源是前人刻意排除在 IaC 外的（例如一個還在實驗的測試機），還是應該納管但漏了？判斷依據是它的角色 — security group、IAM role、VPC 這類地基資源應該優先 import；一台跑完就該關的測試 EC2 可以暫時留在手動。

手動比對 state list 與 CLI 輸出的效率有限，driftctl（現由 Snyk 維護、開源）可以自動掃描雲端資源與 Terraform state 的差異，一次列出所有 unmanaged resource。它跟 terraform plan 的差別在於 plan 只看已管理資源的 drift，driftctl 同時涵蓋根本不在 state 裡的資源。兩者互補：先用 driftctl 產出完整的 unmanaged 清單，再用 plan 處理已管理資源的 drift。

state 的健康檢查

state 本身的存放方式決定了後續所有操作的安全性。接手後第一件事是確認 state 的健康狀態。

存放位置

1# 查看 backend 設定
2grep -A 10 'backend' *.tf

如果 backend 是 local（或沒有 backend 設定），state 檔只存在某台機器的磁碟上。這代表如果有第二個人從自己的機器跑 apply，兩人會用不同版本的 state 互相覆蓋。把 state 搬到 remote backend（S3 + DynamoDB lock）是接手後的第一優先事項，做法見IaC 工具選型與 state 地基。

加密與版本控制

如果 state 已經在 S3，確認三件事：

1# bucket 有沒有 versioning
2aws s3api get-bucket-versioning --bucket <state-bucket>
3
4# bucket 有沒有加密
5aws s3api get-bucket-encryption --bucket <state-bucket>
6
7# 有沒有 lock table
8aws dynamodb describe-table --table-name <lock-table> 2>/dev/null

versioning 沒開的話，一次壞掉的 apply 寫壞 state 就回不去了。加密沒開的話，state 裡的敏感值（資料庫密碼、private key 輸出）以明文存在 S3。

state 裡的敏感值

state 檔經常包含不該暴露的值。確認 state 有沒有在 Git 歷史裡：

1git log --all --diff-filter=A -- '*.tfstate' '*.tfstate.backup'

如果命中，代表 state 曾經被推進 repo。此時 Git 歷史裡的敏感值已經無法徹底清除（git filter-branch 或 git filter-repo 可以嘗試，但無法保證所有 clone 都更新）。務實的處理是：列出 state 裡的敏感值，全部輪替。

1# 用 jq 從 state JSON 撈敏感值候選
2terraform show -json | jq -r '
3  [.. | objects | to_entries[] |
4   select(.key | test("password|secret|key|token"; "i"))] |
5  unique_by(.key) | .[] | "\(.key): \(.value)"
6' 2>/dev/null

這個 jq 查詢會遞迴掃描 state JSON 裡所有欄位名稱含 password / secret / key / token 的值。命中的每一筆都要確認是否為真實密鑰、是否需要輪替。

drift 收斂策略

盤點完差距、確認 state 健康之後，逐項收斂 drift。對 plan 輸出的每一項 diff 做一個二選一的決定：採納手動變更（改 HCL 去符合現實），或回退到程式碼版本（讓下一次 apply 把現實改回來）。

採納 vs 回退的判斷

多數 drift 應該採納。前人在 Console 手動改設定通常有一個操作理由（即使沒有記錄下來）— 加了一條 security group 規則可能是為了讓某個新服務連進來，改了 RDS 的 max_connections 可能是為了解決連線數不足。在沒有充分理解這些改動的背景之前，回退它們等於撤銷一個可能正在支撐服務運作的設定。

回退適用的情境是：drift 明顯是誤操作（例如 0.0.0.0/0 打開了不該打開的埠）、或 drift 的屬性是有標準答案的（例如 S3 的 block_public_access 被關掉了）。

操作步驟

1# 1. 刷新 state 到最新雲端狀態（不改資源、只更新 state 的快照）
2terraform apply -refresh-only
3
4# 2. 再跑一次 plan — 刷新後 diff 會減少（純 state 過期的 diff 消失）
5terraform plan -no-color > plan-after-refresh.txt
6
7# 3. 對剩餘的 diff 逐項處理
8#    採納：改 HCL 讓程式碼跟現實一致 → plan 確認該項 diff 消失
9#    回退：不改 HCL、讓 apply 把現實改回程式碼版本 → 先確認影響

-refresh-only 是安全的操作 — 它只更新 state 裡的屬性快照，不會改動任何雲端資源。但它會把手動變更「記進」state，讓後續 plan 的 diff 只剩程式碼與 state 的差異（而非程式碼與雲端的差異）。刷新後 plan 的 diff 更精確、更少、更容易逐項處理。

import 未管理的資源

對未管理的資源，用 import 區塊一次處理一個，每次 import 後都跑 plan 確認零新增 diff：

1import {
2  to = aws_security_group.legacy_app
3  id = "sg-0abc123def456"
4}

1# 生成對應的 HCL
2terraform plan -generate-config-out=generated_legacy_app.tf
3
4# 確認生成的 HCL 跟現實一致
5terraform plan
6# 預期：只有 import 動作、沒有 change/destroy

生成的 HCL 需要人工確認 — 有些屬性是雲端自動設的預設值，Terraform 會把它們全部列出來，造成 HCL 冗長。移除純預設值的屬性、只保留有意義的設定，讓 HCL 反映設計意圖而非雲端預設。

對於大量未管理資源需要一次性反推 HCL 的情境，Former2 可以從現有 AWS 資源批量生成 Terraform code。它掃描帳號裡的資源、產出對應的 HCL，品質不完美（命名會用資源 ID 而非有意義的名稱、屬性可能包含大量預設值），但作為起點比從零手寫每個資源快得多。產出後仍需逐檔清理命名與移除預設值。

文件重建

接手的環境通常沒有文件、或者文件已經過時到比沒有更糟（記載的是兩個版本前的架構）。文件重建的目標是讓下一個接手者不需要重複同樣的盤點過程，而非追求一份完美的架構文件。

來源

能重建的資訊來源有限，但每個都有價值：

terraform-docs 用一條指令就能從現有 HCL 產出每個 module 的 inputs、outputs 和 resources 清單，省去手動整理 module 介面的時間。Inframap 從 state 或 HCL 產出依賴關係圖，比 terraform graph | dot 好用的地方在於它自動過濾掉 provider 和 data source 的噪音，大型 state 也能產出可讀的圖。

最小可行文件

寫一份 INFRA-STATE.md 放在 repo 根目錄，包含：

• 管理範圍：哪些資源由 IaC 管理、哪些是手動的、為什麼手動的沒有 import（例：還在實驗、不穩定、計畫廢棄）
• 已知 drift：目前 plan 輸出裡還有哪些未處理的 diff、每個 diff 的處理方向（採納/回退/待調查）
• state 存放位置：backend 設定、bucket 名稱、lock table 名稱
• credential 狀態：有幾把 access key、哪些還在用、上次輪替時間
• 接手日期與盤點結果：盤點時的資源數量、覆蓋率（managed / total）

這份文件不需要精美，需要的是準確且持續更新。每次收斂一項 drift 或 import 一個資源，就更新對應的段落。前任團隊的知識已經不在了，這份文件取代它成為環境的記憶。

收斂到完整 IaC 的優先序

把整個收斂過程排成四個階段，每個階段都能獨立交付價值：

每個階段的驗證方式相同：terraform plan 的輸出是否比上一階段乾淨。階段一完成後，plan 的可信度才成立；階段二和三是把 plan 的 diff 清到零；階段四是擴大 plan 的管轄範圍。

每一步操作之前都先備份 state：

1# 手動備份 state（不論 bucket 有沒有 versioning 都先拉一份）
2terraform state pull > state-backup-$(date +%Y%m%d).json

state 操作失敗時的回退路徑是 terraform state push state-backup.json 從備份還原 — 資源本身不受影響，只是工具對現實的記憶回到上一個正確的版本。state push 是覆寫操作，只在確認備份版本正確時使用。

需要搬移資源在 state 裡的位址時（例如重構 module 結構），優先用 moved {} 區塊而非 terraform state mv。moved 是宣告式的、寫在 HCL 裡、可以被 PR review、plan 時會顯示搬移動作。state mv 是指令式的、直接改 state、沒有 review 機制、操作紀錄只在 CLI 歷史裡。

1moved {
2  from = aws_security_group.old_name
3  to   = module.network.aws_security_group.app
4}

跨分類引用

• → IaC 工具選型與 state 地基：state 怎麼從 local 搬到 remote backend
• → Console 唯讀鐵律：drift 的來源與偵測
• → 環境分離與模組化：收斂完成後怎麼把單環境拆成 per-env module
• → infra 走 PR 流程：收斂完成後的變更怎麼走 review
• → State 修復與清理：state 損壞的操作修復步驟
• → Drift 分類處理：逐項判斷 adopt vs revert
• → 批次 Import 工作流：unmanaged resource 的 import 操作
• → 過渡期操作：兩套真相並存時的安全操作規則

本篇是無 SSH 的 FTP / 面板管理環境接管的延伸，聚焦在資料庫層面。程式碼與部署紀律見主文。

phpMyAdmin 的限制與對策

phpMyAdmin 是多數無 SSH 環境預裝的資料庫管理介面，匯出功能涵蓋完整 SQL dump，但它跑在 PHP 執行環境裡，受限於 max_execution_time 和記憶體上限。資料庫超過 50MB 時，匯出經常在執行到一半就因 timeout 中斷，產出不完整的 SQL 檔案——而不完整的 dump 在還原時只會匯入前半段的表、後面的表靜靜消失。

大資料庫的匯出對策

第一個選項是分表匯出。phpMyAdmin 的匯出頁面允許選擇要匯出的資料表，把一次完整匯出拆成 3-5 批，每批在 timeout 之前完成。缺點是匯出不是原子操作——不同批次之間如果有寫入，表之間的參照關係可能不一致（例如訂單表引用的商品 ID 在商品表的那一批裡還沒匯出）。對多數讀取為主的站台，這個不一致窗口可接受；對交易密集的站台，需要在低流量時段操作。

第二個選項是調整 phpMyAdmin 的 timeout。部分主機允許在 phpMyAdmin 的設定目錄放自訂的 config.inc.php：

1$cfg['ExecTimeLimit'] = 600; // 從預設 300 秒增加到 600 秒

cPanel 主機通常在「軟體」區塊的 phpMyAdmin 設定裡有對應的 UI 選項。Plesk 的路徑是「資料庫」→「phpMyAdmin 設定」。能不能改取決於主機商的權限政策，改之前先確認。

第三個選項是繞過 phpMyAdmin。如果主機允許遠端 MySQL 連線（在 cPanel 的「遠端 MySQL」頁面加白名單 IP），就能用桌面工具直連資料庫匯出：

桌面工具直連 MySQL 比 phpMyAdmin 穩定，因為匯出跑在本機、不受主機的 PHP timeout 限制。mysqldump 是最可靠的選項：

1mysqldump -h db-host.example.com -u dbuser -p \
2  --single-transaction --routines --triggers \
3  dbname > backup_$(date +%Y%m%d_%H%M).sql

--single-transaction 對 InnoDB 表做一致性快照，不需要鎖表。--routines 和 --triggers 確保 stored procedure 和觸發器也被包含在 dump 裡——phpMyAdmin 匯出預設也包含，但容易在手動選項時漏勾。

匯出後的驗證

匯出完成後檢查 SQL 檔案的結尾。完整的 mysqldump 結尾會有 -- Dump completed on YYYY-MM-DD HH:MM:SS。phpMyAdmin 匯出的結尾會有 -- phpMyAdmin SQL Dump 的對應結尾標記。如果檔案在某個 INSERT INTO 語句中間斷掉，這份 dump 就是不完整的，還原時會靜靜丟失後面的資料。

1tail -5 backup_20260626_1430.sql
2# 預期看到 "Dump completed" 或完整的結尾註解

備份策略：頻率與保留

備份頻率由資料的變更速率決定。一個每天只有幾筆訂單的小型電商，每週備份加上每次變更前備份就夠用。一個每天有數百筆交易的服務，需要每日備份。判斷依據是：如果最新的備份丟了、要用上一份還原，能接受丟失多少資料？這個時間差就是實際的 RPO（Recovery Point Objective）。

保留策略

命名用時間戳避免覆蓋：dbname_20260626_1430.sql.gz。壓縮用 gzip（gzip backup.sql），50MB 的 SQL dump 通常壓到 5-10MB。

儲存位置

本機是第一份副本，但本機磁碟故障時備份也跟著消失。至少再推一份到雲端儲存：

1# rclone 同步到 Google Drive（事先用 rclone config 設定 remote）
2rclone copy /local/backups/db/ gdrive:project-backups/db/ --max-age 7d
3
4# 或推到 S3
5aws s3 sync /local/backups/db/ s3://my-project-backups/db/ --storage-class STANDARD_IA

備份驗證

備份存在不等於備份可用。每月至少做一次驗證：把最新的 dump 匯入本地 MySQL，檢查關鍵表的 row count 跟 prod 一致、應用程式能正常啟動。如果匯入報錯或 row count 差異超過預期，備份流程有問題要立刻排查。

1mysql -u root -p local_testdb < backup_20260626_1430.sql
2mysql -u root -p -e "SELECT COUNT(*) FROM orders;" local_testdb

自動化備份（無 SSH 環境的限制下）

無 SSH 環境的自動化受限程度取決於主機提供的能力。三個層級由好到差：

主機有 cron + mysqldump 路徑：部分主機在 cPanel 的「cron 工作」裡允許設定排程指令。mysqldump 通常安裝在 /usr/bin/mysqldump，可以直接用：

1# cPanel cron job（每天凌晨 3 點）
20 3 * * * /usr/bin/mysqldump -u dbuser -p'password' dbname | gzip > /home/user/backups/db_$(date +\%Y\%m\%d).sql.gz

密碼寫在 cron 指令裡不理想但在無 SSH 環境選擇有限。用 .my.cnf 檔案存密碼（chmod 600）較安全，但不是所有主機都支援。

主機有遠端 MySQL 但沒 cron：用本機排程（macOS launchd / Windows Task Scheduler / Linux cron）跑 mysqldump 遠端連線：

 1#!/bin/bash
 2# local-backup.sh — 本機排程每天跑
 3BACKUP_DIR="$HOME/backups/myproject/db"
 4mkdir -p "$BACKUP_DIR"
 5mysqldump -h db-host.example.com -u dbuser -p'password' \
 6  --single-transaction dbname \
 7  | gzip > "$BACKUP_DIR/db_$(date +%Y%m%d_%H%M).sql.gz"
 8
 9# 推到雲端
10rclone copy "$BACKUP_DIR" gdrive:project-backups/db/ --max-age 7d
11
12# 清理超過 30 天的本地備份
13find "$BACKUP_DIR" -name "*.sql.gz" -mtime +30 -delete

沒有 cron 也沒有遠端 MySQL：只能靠手動的 phpMyAdmin 匯出，加上 cPanel 的「備份精靈」（如果主機方案包含）。cPanel 備份精靈可以設定每日或每週的完整備份（含資料庫 + 檔案），但免費方案通常不支援排程。這是最受限的情境——如果連手動匯出都嫌麻煩，最高優先的升級路徑是開通遠端 MySQL 存取。

資料庫變更的 migration 紀律

Schema 變更（加欄位、改索引、拆表）在沒有 migration 工具的 legacy PHP 專案裡，全靠手動在 phpMyAdmin 執行 SQL。migration 紀律的目標是讓每一次 schema 變更有紀錄、可重播、可回退。

Migration 檔案格式

每次 schema 變更寫成一個獨立的 SQL 檔案，存在 repo 的 migrations/ 目錄：

 1-- migrations/2026-06-26-001-add-users-email-verified.sql
 2-- 目的：新增 email 驗證欄位，支援 email 驗證流程
 3-- 回退：ALTER TABLE users DROP COLUMN email_verified;
 4
 5-- UP
 6ALTER TABLE users ADD COLUMN email_verified TINYINT(1) NOT NULL DEFAULT 0 AFTER email;
 7CREATE INDEX idx_users_email_verified ON users (email_verified);
 8
 9-- DOWN（回退用，不自動執行）
10-- DROP INDEX idx_users_email_verified ON users;
11-- ALTER TABLE users DROP COLUMN email_verified;

檔名的結構是 日期-序號-描述，序號處理同一天多次變更的排序。UP 段是要執行的 SQL，DOWN 段是回退 SQL（註解掉，手動需要時才用）。

追蹤哪些 migration 已執行

在資料庫建一張追蹤表：

1CREATE TABLE IF NOT EXISTS migrations_log (
2    id INT AUTO_INCREMENT PRIMARY KEY,
3    filename VARCHAR(255) NOT NULL,
4    applied_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
5    applied_by VARCHAR(100)
6);

每次在 prod 執行完一個 migration，手動插入一筆紀錄：

1INSERT INTO migrations_log (filename, applied_by) VALUES ('2026-06-26-001-add-users-email-verified.sql', 'alice');

查哪些 migration 還沒跑：比對 migrations/ 目錄的檔案清單跟 migrations_log 表的 filename 欄。這不是自動化的 migration runner（像 Laravel 的 artisan migrate），但在沒有框架支援的 legacy 專案裡，一張表加一個目錄就能達到可追蹤的最低標準。

執行流程

高風險的 migration（改大表結構、刪欄位、改資料類型）在步驟 2 要做完整的資料庫 dump 而非只備份受影響的表，因為外鍵和觸發器可能讓影響範圍超出目標表。

還原演練

備份的價值在還原成功的那一刻才被驗證。沒有演練過的備份等同於不存在——匯出可能不完整、SQL 版本可能不相容、匯入順序可能因為外鍵而失敗。

演練流程

在本地用最新的備份還原一次完整的資料庫：

1# 建一個測試用的空資料庫
2mysql -u root -p -e "CREATE DATABASE restore_test;"
3
4# 匯入備份
5mysql -u root -p restore_test < backup_20260626_1430.sql
6
7# 驗證
8mysql -u root -p -e "SHOW TABLES;" restore_test
9mysql -u root -p -e "SELECT COUNT(*) FROM orders;" restore_test

驗證三件事：表結構完整（SHOW TABLES 的表數量跟 prod 一致）、資料完整（關鍵表的 row count 一致）、應用程式能跑（把本地應用指向 restore_test 資料庫、打開首頁和幾個關鍵流程）。

還原時間的量測

記錄從開始匯入到驗證完成的時間。這個數字就是事故時的最快恢復時間。如果一個 500MB 的資料庫匯入需要 40 分鐘，加上排查原因和決策的時間，實際恢復可能超過一小時。知道這個數字，才能在事故時給管理層一個實際的時間預期。

無 SSH 環境沒有 PITR

無 SSH 的主機環境的 MySQL 通常不提供 binlog 層級的 point-in-time recovery。能還原到的最近時間點就是最新備份的時間點——備份是每天凌晨做的、下午三點出事，那就是丟失當天的所有寫入。這是備份頻率需要跟資料變更速率對齊的根本原因。交易密集的站台如果無法接受一天的資料丟失，升級到有 binlog / PITR 的環境（VPS 或 managed MySQL）是必要的投資。

大資料庫的特殊處理

資料庫超過 500MB 時，備份和還原的操作時間和失敗風險都會上升。需要針對大表做特殊處理。

超過 1GB 的單表通常是 log 表、歷史紀錄表、或含有二進位大物件（BLOB）的表。對這類表的備份策略跟業務表不同：

• log / 歷史表：備份時可以加 --where="created_at > DATE_SUB(NOW(), INTERVAL 90 DAY)" 只匯出近期資料，歷史資料另做一次性歸檔
• BLOB 欄位（圖片、PDF）：用 --no-data 單獨匯出 schema，BLOB 內容如果已經搬到檔案系統或 CDN，資料庫裡只需要保留路徑參考
• InnoDB 大表：--single-transaction 避免鎖表，但匯出期間的記憶體消耗跟表大小成正比，本機如果記憶體不足可以加 --quick（逐行讀取、不緩衝整張表）

1# 大表匯出：逐行讀取 + 一致性快照 + 壓縮
2mysqldump -h db-host.example.com -u dbuser -p \
3  --single-transaction --quick \
4  dbname large_table | gzip > large_table_$(date +%Y%m%d).sql.gz

資料庫規模成長到備份時間超過維護視窗（例如匯出要兩小時但只有一小時的低流量時段），代表這類環境的備份能力已經到頂，需要評估升級到有 automated snapshot 的 managed MySQL 或 VPS。

跨分類引用

• → 無 SSH 的 FTP / 面板管理環境接管：主文，涵蓋程式碼備份、部署紀律與整體接管流程
• → 程式碼版控與 FTP 部署紀律：DB migration 跟 code deploy 要同步——schema 改了但 code 沒跟上會讓服務壞掉
• → Legacy PHP 的安全盤點：DB credential 的掃描與保護、SQL injection 風險評估
• → Stateful 資源保護與跨服務依賴：IaC 環境裡的備份、deletion protection 與 PITR 設計
• → 治理好習慣：tagging、secret 管理與成本可見性的長期治理

從 FTP 拉下來建立 Git repo

用 FTP client 把整個站台完整下載到本地目錄，這份下載就是 production 的快照。下載完成後在該目錄初始化 Git：

1cd /path/to/downloaded-site
2git init

在第一次 commit 之前先處理 .gitignore。PHP 專案需要排除的檔案分三類：套件依賴（由 Composer 或 npm 管理、可重建）、執行期產物（快取、session、上傳檔案）、以及含有機密值的設定檔。

 1# 套件依賴
 2vendor/
 3node_modules/
 4
 5# 執行期產物
 6cache/
 7tmp/
 8sessions/
 9*.log
10
11# 使用者上傳內容（通常很大、且屬於資料不屬於程式碼）
12uploads/
13media/
14wp-content/uploads/
15
16# 機密設定（下一節處理）
17.env
18config.local.php
19wp-config.php

使用者上傳的內容（uploads/、media/）不進 Git 的理由是它屬於資料層：檔案數量可能成千上萬、總容量可能數 GB，Git 不適合管理這類大量二進位檔案。這些檔案的備份策略跟程式碼不同——用 FTP mirror 或 rclone 定期同步到本地即可。

設好 .gitignore 後做第一次 commit：

1git add -A
2git commit -m "production snapshot $(date +%Y-%m-%d)"

這個 commit 就是「接手時 production 長什麼樣」的基準線。後續所有改動都從這裡開始有版本歷史。

Config 分離：讓 Git repo 不含機密值

無 SSH 環境的 PHP 專案常把資料庫密碼、API key、SMTP 憑證直接寫在 config.php 或 wp-config.php 裡。這些檔案如果進了 Git，機密值就跟著 repo 走——推到 GitHub 就等於公開。

分離的模式是把設定拆成兩份：一份進 Git（結構與預設值）、一份不進 Git（實際機密值）。

模式一：.env 檔案

使用 vlucas/phpdotenv 套件或手動解析，讓程式碼從 .env 檔案讀取環境變數：

1// config.php — 進 Git
2$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
3$dotenv->load();
4
5$db_host = $_ENV['DB_HOST'];
6$db_name = $_ENV['DB_NAME'];
7$db_user = $_ENV['DB_USER'];
8$db_pass = $_ENV['DB_PASS'];

1# .env — 不進 Git（.gitignore 已排除）
2DB_HOST=localhost
3DB_NAME=mysite_prod
4DB_USER=mysite_user
5DB_PASS=actual-password-here

同時在 repo 裡放一份 .env.example（進 Git），列出所有需要的環境變數但不填實際值：

1# .env.example — 進 Git，作為範本
2DB_HOST=
3DB_NAME=
4DB_USER=
5DB_PASS=
6SMTP_HOST=
7SMTP_USER=
8SMTP_PASS=

模式二：config.local.php

如果專案不使用 Composer、引入 phpdotenv 成本太高，用 PHP include 分離：

1// config.php — 進 Git
2if (file_exists(__DIR__ . '/config.local.php')) {
3    require __DIR__ . '/config.local.php';
4} else {
5    die('config.local.php not found. Copy config.local.example.php and fill in values.');
6}

1// config.local.php — 不進 Git
2$db_host = 'localhost';
3$db_name = 'mysite_prod';
4$db_user = 'mysite_user';
5$db_pass = 'actual-password-here';

WordPress 的處理

WordPress 的 wp-config.php 同時包含機密值和非機密設定。把整份排除再 include 一份 local 版是最簡單的做法，但也可以只把機密值抽到 .env、wp-config.php 本身保留在 Git 裡：

1// wp-config.php — 進 Git（機密值從 .env 讀）
2$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
3$dotenv->load();
4
5define('DB_NAME', $_ENV['DB_NAME']);
6define('DB_USER', $_ENV['DB_USER']);
7define('DB_PASSWORD', $_ENV['DB_PASSWORD']);
8define('DB_HOST', $_ENV['DB_HOST'] ?? 'localhost');

分離完成後，用 grep 確認 repo 裡沒有殘留的明文密碼：

1git grep -in "password\|passwd\|secret\|api_key\|smtp" -- '*.php' ':!*.example*'

任何命中都要評估：是真的機密值（要移到 .env）還是變數名稱（可以保留）。

FTP 部署的風險控制

FTP 上傳是逐檔覆寫，沒有交易性——上傳到一半斷線、或上傳了有語法錯誤的 PHP 檔案，站台會立刻出問題。風險控制的核心是「每次上傳前知道在改什麼、上傳後知道改了什麼」。

上傳前的比對

FileZilla 的目錄比較功能（「檢視 → 目錄比較 → 啟用」）可以在上傳前看到本地與遠端的差異：哪些檔案是本地較新、哪些是遠端較新、哪些只存在於一邊。上傳前先跑比較、確認差異清單符合預期——如果出現預期外的「遠端較新」檔案，代表有人在伺服器上直接改了東西，要先下載回來合併再上傳。

只上傳改過的檔案

一次上傳整個站台目錄既慢又危險。只上傳 Git diff 顯示的改動檔案：

1# 列出相對於上次部署 tag 改了哪些檔案
2git diff --name-only deploy-2026-06-25 HEAD

把這份清單對照 FileZilla 的比較結果，逐一上傳。量大時用 lftp 的 mirror 指令加 --only-newer flag 只傳新檔。

關鍵檔案的額外保護

index.php、.htaccess、設定檔這類檔案壞掉會讓整個站台無法存取。上傳這些檔案之前，先從伺服器下載一份當前版本存到本地的 _backup/ 目錄（gitignored）。如果上傳後站台出問題，可以立刻把備份版本傳回去。

部署前後的驗證

部署前檢查

部署後驗證

上傳完成後立刻驗證：

1. 首頁能正常載入（HTTP 200、頁面內容正確）
2. 本次改動涉及的功能可正常操作
3. 如果是電商站：結帳流程、金流 callback 測試
4. 檢查 PHP error log（cPanel → 錯誤日誌、或 FTP 下載 error_log 檔案）

如果驗證失敗，回退方式是從 Git 歷史取出上一個版本的受影響檔案重新上傳：

1# 取出上一個部署 tag 的特定檔案
2git show deploy-2026-06-25:path/to/file.php > _rollback/file.php
3# 用 FTP 上傳 _rollback/file.php 覆蓋 prod

CI 化 FTP 部署

手動 FTP 部署的問題是它依賴特定人的 FTP client 和操作紀律。用 GitHub Actions 把 FTP 上傳自動化，可以讓部署變成「push 到 main → CI 跑測試 → CI 上傳到伺服器」的流程，不依賴任何人的本地環境。

 1name: Deploy via FTP
 2on:
 3  push:
 4    branches: [main]
 5
 6jobs:
 7  deploy:
 8    runs-on: ubuntu-latest
 9    steps:
10      - uses: actions/checkout@v4
11        with:
12          fetch-depth: 2
13
14      - name: Deploy to FTP
15        uses: SamKirkland/FTP-Deploy-Action@v4
16        with:
17          server: ${{ secrets.FTP_HOST }}
18          username: ${{ secrets.FTP_USER }}
19          password: ${{ secrets.FTP_PASS }}
20          server-dir: /public_html/
21          exclude: |
22            **/.git*
23            **/.git*/**
24            **/node_modules/**
25            **/.env
26            **/config.local.php

FTP 憑證存在 GitHub repo 的 Secrets 裡（Settings → Secrets and variables → Actions），不寫在 workflow 檔案裡。

CI 化後的改變

限制

FTP 部署沒有原子性（atomic deployment）——檔案逐一上傳的過程中，伺服器上同時存在新舊版本的檔案混合狀態。如果上傳的檔案之間有依賴關係（新的 A.php 引用新的 B.php，但 B.php 還沒上傳完），短暫的錯誤窗口無法避免。流量高的站台如果需要零停機部署，需要升級到 SSH + symlink 切換的部署方式，那屬於 VPS 遷移之後的能力。

Git tagging 部署紀錄

每次部署前在 Git 打一個 tag，讓「這次部署的是哪個版本」有明確的錨點：

1git tag deploy-$(date +%Y-%m-%d-%H%M)
2git push origin --tags

tag 的命名用日期時間戳而非版號，因為這類專案通常沒有語意化版號的概念。tag 的作用是：

• 回退時知道要退到哪個版本（git diff deploy-previous deploy-current 看這次改了什麼）
• 多次部署之間的差異可追蹤
• CI 化後可以用 tag 觸發部署而非每次 push 都部署

資料庫變更的回退跟程式碼獨立處理——程式碼可以靠 Git 回退，資料庫要靠 SQL dump 回退，兩者的回退點要對齊但機制不同。資料庫的備份策略見資料庫備份與變更管理。

跨分類引用

• → 無 SSH 的 FTP / 面板管理環境接管：本篇的母文章，涵蓋接手的完整流程
• → 資料庫備份與變更管理：資料庫端的備份、migration 紀律與回退策略
• → Legacy PHP 的安全盤點：credential 分離之後的存取控制與安全掃描
• → 無 SSH 環境的監控與告警：部署後用外部監控驗證服務正常
• → 模組七：infra 走 PR 流程：從 FTP CI 化進一步演進到完整的 PR review 流程

Credential 掃描與處理

寫死在程式碼裡的 credential 是接手後最先要掌握的風險面。資料庫密碼、API key、SMTP 帳號這些值如果散落在多個 PHP 檔案裡，每一個都是外洩路徑。

掃描方式

用 grep 對整個 codebase 搜尋常見的 credential 關鍵字：

1grep -rn "password\|passwd\|secret\|api_key\|app_key\|mysql_connect\|mysqli_connect\|PDO(" \
2  --include="*.php" .

常見的集中位置是 config.php、wp-config.php、database.php、settings.php，以及專案根目錄的 .env。但 legacy 專案的 credential 經常散落在意想不到的地方——寫在某個 helper function 的預設參數裡、硬編碼在 cron job 的 PHP 檔案裡、或藏在某個很久沒改的 email 發送模組裡。grep 的涵蓋範圍應該是整個專案目錄，不只是已知的 config 檔案。

如果專案已經在本地 Git repo（見主文的快照步驟），檢查 Git 歷史裡有沒有曾經存在但後來被刪除的 credential：

1git log --all -p -- '*.php' | grep -i "password\|secret\|api_key" | head -30

歷史裡的 credential 無法從 Git 裡真正移除（rewrite history 可以但成本高），所以找到的 credential 都要列入輪替清單。

處理方式

掃描結果彙整成一張清單，每筆記錄：credential 類型、所在檔案、用途、是否可輪替。處理優先序：

把 credential 從 code 移到 .env 後，用 getenv('DB_PASSWORD') 或框架的 config 機制讀取。.env 加進 .gitignore，prod 的 .env 透過 FTP 單獨上傳、不進版本控制。

PHP 版本與已知漏洞

PHP 版本決定了這個專案暴露在什麼層級的平台風險下。已結束安全支援（EOL）的 PHP 版本不代表「馬上會被攻擊」，但代表任何未來被發現的漏洞都不會得到官方修補。

版本確認

在站台放一個 phpinfo.php，瀏覽後記錄版本號，完成後立刻刪除（phpinfo() 輸出含伺服器路徑與配置細節，留在 prod 上是資訊外洩）：

1<?php phpinfo(); ?>

或在 cPanel / Plesk 的 PHP 設定頁面直接查看。

版本風險對照

版本升級是獨立的工程專案——可能會觸發函式棄用警告、行為變更、甚至語法不相容。盤點階段的任務是記錄版本和風險等級，升級規劃放在穩定維運之後。

常見的 PHP 安全漏洞模式

Legacy PHP 專案最常見的四類漏洞都可以用 grep 做初步掃描。掃描結果是候選清單、不是確認的漏洞——每個命中都需要讀上下文確認是否有防護。

SQL injection

任何把使用者輸入直接拼接到 SQL 查詢裡的寫法都是 SQL injection 的候選：

1# 找使用 mysql_query / mysqli_query 但沒有 prepare/bind 的查詢
2grep -rn "mysql_query\|mysqli_query" --include="*.php" . | grep -v "prepare\|bind_param"
3
4# 找字串拼接的 SQL 查詢
5grep -rn "query.*\\\$_GET\|query.*\\\$_POST\|query.*\\\$_REQUEST" --include="*.php" .

修法是改用 prepared statement（PDO 或 mysqli 的 prepare + bind_param）。如果 codebase 大量使用 mysql_* 函式（PHP 7.0 已移除），這本身就是版本升級的阻礙——需要同時處理。

XSS（跨站腳本）

把使用者輸入直接輸出到 HTML 而沒有跳脫：

1# 找直接 echo/print 使用者輸入的地方
2grep -rn "echo.*\\\$_GET\|echo.*\\\$_POST\|echo.*\\\$_REQUEST\|echo.*\\\$_COOKIE" --include="*.php" .
3
4# 找 PHP 短標籤輸出
5grep -rn "<?=.*\\\$_" --include="*.php" .

修法是所有輸出都經過 htmlspecialchars($var, ENT_QUOTES, 'UTF-8')。模板引擎（如 Twig、Blade）預設會做跳脫，使用模板引擎的專案 XSS 風險較低。

檔案包含（File Inclusion）

把使用者輸入當作 include 或 require 的路徑：

1grep -rn "include.*\\\$_\|require.*\\\$_\|include_once.*\\\$_\|require_once.*\\\$_" --include="*.php" .

這類寫法讓攻擊者可以指定載入任意檔案（本地或遠端）。修法是用白名單限制可載入的檔案路徑。

檔案上傳

檢查上傳處理的三個面向：副檔名驗證（只允許白名單）、上傳目錄是否可執行 PHP（不應該）、檔案大小限制。

1# 找上傳處理程式碼
2grep -rn "move_uploaded_file\|\\\$_FILES" --include="*.php" .

每個命中的上傳處理都要確認：有沒有驗證副檔名（黑名單不夠、要白名單）、上傳目錄有沒有 .htaccess 禁止 PHP 執行（見下節）、有沒有重新命名上傳的檔案（避免覆寫攻擊）。

Session 管理

1# 找 session 相關設定
2grep -rn "session_start\|session_regenerate_id\|session\.cookie_httponly\|session\.cookie_secure" --include="*.php" .

確認：登入成功後有沒有呼叫 session_regenerate_id(true) 防止 session fixation、session.cookie_httponly 是否為 on（防止 JavaScript 讀取 session cookie）、session.cookie_secure 在 HTTPS 站台是否為 on。

.htaccess 安全設定

無 SSH 的 Apache 環境中 .htaccess 是可用的伺服器端安全防線。盤點時確認這些設定是否存在，缺少的補上。

基礎安全設定

 1# 禁止目錄列表 — 防止瀏覽上傳目錄的檔案清單
 2Options -Indexes
 3
 4# 阻擋敏感檔案的 HTTP 存取
 5<FilesMatch "\.(env|local|bak|sql|log|ini|conf|yml|json|lock|md)$">
 6    Require all denied
 7</FilesMatch>
 8
 9# 阻擋隱藏檔案與目錄（.git、.env 等）
10<IfModule mod_rewrite.c>
11    RewriteEngine On
12    RewriteRule (^\.|/\.) - [F]
13</IfModule>
14
15# 強制 HTTPS
16<IfModule mod_rewrite.c>
17    RewriteCond %{HTTPS} off
18    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
19</IfModule>

上傳目錄的 PHP 執行禁令

在上傳目錄（如 uploads/、wp-content/uploads/）放一個獨立的 .htaccess：

1# 禁止此目錄下的 PHP 執行
2php_flag engine off
3
4# 只允許靜態檔案類型
5<FilesMatch "\.(?!jpg|jpeg|png|gif|pdf|webp|svg|css|js)">
6    Require all denied
7</FilesMatch>

這條設定讓即使攻擊者成功上傳了 .php 檔案，也無法透過 HTTP 請求觸發執行。

安全 header

 1# 防止 MIME type sniffing
 2Header set X-Content-Type-Options "nosniff"
 3
 4# 防止 clickjacking
 5Header set X-Frame-Options "SAMEORIGIN"
 6
 7# XSS 防護（現代瀏覽器多已內建、但舊站加上無害）
 8Header set X-XSS-Protection "1; mode=block"
 9
10# Referrer 資訊控制
11Header set Referrer-Policy "strict-origin-when-cross-origin"

檔案權限

無 SSH 環境的權限控制能力有限——多數情況下透過 FTP client 檢查和調整。

777 權限（所有人可讀寫執行）在多租戶主機上等於同一台伺服器的其他租戶也能讀寫這些檔案。如果發現任何目錄或檔案是 777，立刻改回 755/644。FileZilla 在檔案上按右鍵 → 「File permissions」可以查看和修改。

外部依賴的安全性

Composer 管理的依賴

如果專案使用 Composer，在本地跑一次已知漏洞檢查：

1composer audit

這條指令比對 composer.lock 裡的每個套件版本與 Packagist 的安全公告資料庫，列出有已知 CVE 的套件。

手動管理的依賴

沒有 Composer 的 legacy 專案可能直接把第三方程式碼複製進專案目錄。常見的高風險依賴：

JavaScript CDN 引用

檢查 HTML 裡引用的外部 JavaScript CDN 連結，確認：使用 integrity 屬性（Subresource Integrity）防止 CDN 被竄改、引用的 CDN 是否仍在維護。

掃描工具

除了手動 grep，可以用工具做自動化掃描。這些工具都從本地或外部執行，不需要在 prod 伺服器上安裝任何東西。

WordPress 站台的掃描指令：

1# WPScan 掃描（從本地執行、掃描遠端站台）
2wpscan --url https://example.com --enumerate vp,vt,u
3# vp = vulnerable plugins, vt = vulnerable themes, u = users

所有掃描結果存進 repo 的 security-audit/ 目錄，標上日期。這份報告是後續修補計畫的輸入，也是向管理層說明安全狀態的依據。

跨分類引用

• → 無 SSH 的 FTP / 面板管理環境接管：本文的前置步驟（程式碼與資料庫快照）
• → 資料庫備份與變更管理：SQL injection 修復前先備份，避免修補過程造成資料遺失
• → 無 SSH 環境的監控與告警：安全事件的持續偵測與錯誤追蹤
• → 模組二：身分與憑證地基：credential 管理的系統性設計
• → Backend 模組七：資安與資料保護：應用層安全的完整討論

可用性監控（外部 HTTP check）

外部 HTTP check 的運作方式是從第三方伺服器定期對目標 URL 發 HTTP 請求，驗證回應狀態碼、回應時間、以及頁面內容是否包含預期的文字。服務掛了或回應異常時觸發告警。

工具選型

UptimeRobot 的免費方案對多數無 SSH 環境的站台足夠——50 個 monitor 可以覆蓋一個站台的主要入口。

該監控哪些 URL

選監控目標的判準是「這個 URL 掛了代表哪一層出問題」：

每個 monitor 設兩層閾值：回應時間 >3 秒為警告（效能劣化的早期訊號）、>10 秒或非 200 狀態碼為嚴重（服務已不可用）。

告警通道

免費方案通常支援 email 與 webhook（可串 Slack）。付費方案加 SMS 和電話。接手初期用 email + Slack 即可，等確認告警不會誤報後再決定要不要升級到 SMS。頻繁誤報會讓團隊學會忽略通知——閾值要設在「真的有問題才響」的水位。

錯誤追蹤（不需要 server agent）

PHP 的錯誤追蹤在無 SSH 環境有兩條路徑：server 端用 PHP 內建的 error_log、client 端用不需要安裝的 SaaS 服務。

PHP error_log（server 端、不需 SSH）

PHP 可以把錯誤寫進檔案，設定方式是在 .htaccess 或 php.ini（如果主機允許）加入：

1# .htaccess — 啟用錯誤記錄、關閉畫面顯示
2php_flag display_errors off
3php_flag log_errors on
4php_value error_log /home/user/logs/php_errors.log

error_log 的路徑要指向 web root 之外的目錄，避免錯誤訊息被外部存取。設定後透過 FTP 定期下載這個檔案、用 grep 篩選嚴重等級：

1# 篩選 Fatal 和 Warning（過濾掉 Notice / Deprecated）
2grep -E "Fatal|Warning" php_errors.log | tail -50

Sentry（PHP + JavaScript、不需 server agent）

Sentry 的 PHP SDK 不需要系統層 agent，只需要在應用程式碼裡初始化：

1composer require sentry/sentry

1// 在應用程式進入點（如 index.php 最前面）加入
2\Sentry\init([
3    'dsn' => 'https://examplekey@o0.ingest.sentry.io/0',
4    'traces_sample_rate' => 0.1,
5]);

這段程式碼會在 PHP 拋出未捕捉的例外或觸發 error 時，把錯誤資訊（stack trace、request context、使用者資訊）透過 HTTP 送到 Sentry 的 SaaS 平台。免費方案每月 5,000 個事件，對流量不大的流量不大的站台通常足夠。

前端的 JavaScript 錯誤追蹤更簡單——在 HTML 的 <head> 加一行 Sentry 的 CDN script，不需要修改 server 設定：

1<script
2  src="https://browser.sentry-cdn.com/8.x/bundle.tracing.min.js"
3  crossorigin="anonymous"
4></script>
5<script>
6  Sentry.init({ dsn: "https://examplekey@o0.ingest.sentry.io/0" });
7</script>

JavaScript SDK 捕捉的是瀏覽器端的錯誤——DOM 操作失敗、AJAX 請求異常、未處理的 Promise rejection。跟 PHP 端的 SDK 各抓不同層的問題。

error_log vs Sentry 的分工

error_log 是 server 端的文字紀錄，需要手動下載和篩選；Sentry 有搜尋、聚合、告警和 stack trace 視覺化。兩者互補：error_log 保留完整紀錄作為備份、Sentry 提供可操作的告警和分析介面。error_log 在 PHP 嚴重到 Sentry SDK 自己也掛掉的情況下仍然有紀錄。

效能基線

效能基線的責任是回答「正常狀態下回應時間是多少」，讓異常浮現時有比對的參考。沒有基線時，回應時間從 200ms 劣化到 2 秒、但因為「好像一直都這麼慢」而沒人察覺。

量測方式

最簡單的量測是從本機或 CI 環境定期 curl：

1# 量測回應時間（秒），只看 time_total
2curl -o /dev/null -s -w "%{time_total}\n" https://example.com

把這段做成 GitHub Actions 的 scheduled workflow，每小時跑一次、把結果追加到 repo 的 CSV 檔案，就有了一條回應時間的趨勢線：

 1on:
 2  schedule:
 3    - cron: '0 * * * *'
 4jobs:
 5  perf-check:
 6    runs-on: ubuntu-latest
 7    steps:
 8      - uses: actions/checkout@v4
 9      - run: |
10          TIME=$(curl -o /dev/null -s -w "%{time_total}" https://example.com)
11          echo "$(date -u +%Y-%m-%dT%H:%M:%SZ),$TIME" >> perf-log.csv
12      - run: git add perf-log.csv && git commit -m "perf check" && git push

這條趨勢線本身就是監控：回應時間連續幾個小時上升，代表某個東西在劣化（DB 查詢變慢、磁碟快滿、PHP process 卡住）。

頁面效能

Google PageSpeed Insights（免費、不需安裝）分析前端載入效能，包含 LCP、CLS、FID 等 Core Web Vitals。對 legacy PHP 站台有用的是它會指出渲染阻塞的 CSS/JS、未壓縮的圖片、缺少快取 header 這類不需要動後端就能改善的問題。

資料庫效能（需改 code）

如果能修改 PHP 程式碼，在資料庫查詢前後加計時、超過閾值就寫 error_log：

1$start = microtime(true);
2$result = $pdo->query($sql);
3$elapsed = microtime(true) - $start;
4if ($elapsed > 1.0) {
5    error_log(sprintf("Slow query (%.2fs): %s", $elapsed, substr($sql, 0, 200)));
6}

累積一段時間後，從 error_log 裡 grep Slow query 就能看出哪些查詢是效能瓶頸。這不是完整的 APM，但在沒有 agent 的環境裡是最接近 slow query log 的替代方案。

帳單與流量異常偵測

這類主機通常按流量或磁碟空間計費，異常流量（bot 掃描、DDoS、爬蟲）會讓帳單飆高或觸發主機商的流量限制。

流量監控

主機控制面板（cPanel 的 AWStats 或 Webalizer）提供基本的流量分析——top referrer、top page、bot 流量佔比。每月檢查一次，重點看：

• bot 流量佔比是否異常高（>50% 通常代表有爬蟲）
• 單一 IP 的請求量是否異常集中
• 帶寬使用量的趨勢（月增超過 20% 且沒有對應的業務成長要查原因）

客戶端分析（不需 server 安裝）

Google Analytics 或 Plausible（隱私友善替代品）只需要在頁面加一段 JavaScript。它們追蹤的是真實使用者的瀏覽行為（page view、session、referrer），跟 server 端的 access log 互補：server log 看所有請求（含 bot），GA/Plausible 只看真實瀏覽器。

Cloudflare 免費方案

如果 DNS 可以切換，把 domain 接上 Cloudflare（免費方案）提供三個能力而不需要動 server：

• 流量分析：比 AWStats 更即時、有地理分佈和 bot 過濾
• DDoS 保護：基本的 Layer 3/4 防護免費
• CDN 快取：靜態資源（CSS/JS/圖片）由 Cloudflare 快取、減輕 origin 負擔

設定只需要把 domain 的 nameserver 改成 Cloudflare 提供的 NS、原始 DNS record 在 Cloudflare 重建。對無 SSH 環境的站台來說這是投資報酬率最高的單一改善動作——不動 server、不改 code、但同時拿到流量可見性和基本防護。

整合成最低成本監控方案

按投入程度分三層，每一層都包含上一層：

Tier 1 在接手當天就能建好（30 分鐘設定 UptimeRobot + Sentry + GA），零成本提供基本的「服務掛了會知道、程式碼出錯會收到、流量異常看得到」的覆蓋。Tier 2 適合站台有營收或合約 SLA 要求時。Tier 3 是離開無 SSH 環境後的正規化路徑，監控從外部觀測升級為 server 端全面可觀測性，見模組六：可觀測性與 log。

跨分類引用

• → 無 SSH 的 FTP / 面板管理環境接管：本篇的母篇，監控建立在盤點與本地環境之後
• → 程式碼版控與 FTP 部署紀律：部署後的驗證用監控確認服務正常
• → Legacy PHP 的安全盤點：錯誤追蹤可能暴露安全問題（未捕捉的 SQL error、路徑洩漏）
• → 模組六：可觀測性與 log：Tier 3 升級路徑的目標——有 server 存取後的 IaC 監控
• → Monitoring 監控體系：客戶端行為訊號（SDK / Collector）的完整討論

診斷 state 的健康狀態

terraform plan 的輸出是診斷 state 健康度的主要工具。在不做任何 code 變更的前提下跑 plan，輸出的每一行差異都代表 state 與現實的落差：

1terraform plan -detailed-exitcode -no-color > plan-diagnosis.txt 2>&1
2# exit code: 0=無差異, 1=錯誤, 2=有差異

Plan 的差異分三類，每一類的處理方式不同：

Plan 跑到一半報錯（exit code 1）而非產出差異，通常代表更嚴重的問題：provider 版本不相容、state 格式損壞、或 state 引用的資源 ID 在雲端已經不存在。錯誤訊息裡的 resource address 指向問題所在。

Orphaned entry 的辨認

State 裡有一筆資源記錄，但雲端已經沒有對應的資源（手動刪除、帳號切換、或 region 不對），plan 會顯示 - destroy 或直接報 Error: reading ... NotFound。這種 orphaned entry 需要從 state 移除，否則每次 plan 都會嘗試操作一個不存在的目標。

1# 列出 state 裡所有資源，逐一確認是否還存在
2terraform state list | while read addr; do
3  echo "Checking: $addr"
4  terraform state show "$addr" > /dev/null 2>&1 || echo "  POSSIBLY ORPHANED: $addr"
5done

這個腳本不連雲端驗證（只檢查 state 內部一致性），真正的驗證要靠 plan 輸出。如果 plan 對某個資源報 NotFound，那就是 orphaned。

State 操作前的備份

所有 state 操作（rm、mv、push、import）都是直接改寫 state 檔的破壞性操作。操作前的備份是唯一的回退路徑。

1# 從遠端 backend 拉一份完整的 state 到本地
2terraform state pull > state-backup-$(date +%Y%m%d-%H%M).json
3
4# 確認備份可用：檢查 JSON 格式和 resource 數量
5jq '.resources | length' state-backup-*.json

如果 state 存在 S3 且 bucket 有開 versioning（應該有，見模組一），S3 的版本歷史是第二道保險。但 state pull 的本地備份更可控——S3 versioning 的回復要操作 bucket、權限要對、而且版本 ID 需要另外查。

移除 orphaned entry：state rm

terraform state rm 把一筆資源從 state 裡移除，但不觸碰雲端的實際資源。用途是清理 state 裡對應不到雲端的記錄，讓 plan 不再嘗試操作不存在的目標。

1# 移除單一 orphaned resource
2terraform state rm 'aws_instance.old_bastion'
3
4# 移除整個 module 的記錄（module 被拆掉但資源還在雲端、要重新 import）
5terraform state rm 'module.legacy_network'

移除後立刻跑 plan 驗證：原本針對這個資源的 destroy / error 應該消失。如果移除後 plan 反而出現 + create（想重建這個資源），代表 code 裡還有對應的 resource block——要麼也刪 code，要麼這個資源需要 import 而不是 rm。

判斷「該 rm 還是該 import」的依據：資源在雲端還存在嗎？存在就 import（讓 state 重新追蹤它），不存在就 rm（清掉過時的記錄）。

搬移資源：state mv 與 moved block

重構 Terraform code（把資源搬進 module、改 resource name、改 module 結構）時，state 裡的 resource address 會跟著變。如果不處理，plan 會判定「舊 address 要 destroy、新 address 要 create」——對 stateless 資源只是多等一次重建，對 RDS 這類 stateful 資源是資料遺失。

Terraform 1.1+ 的 moved block 是宣告式的搬遷，寫在 HCL 裡、可 review、可回滾：

1moved {
2  from = aws_security_group.web
3  to   = module.network.aws_security_group.web
4}

跑 plan 時 Terraform 會把 state 裡的舊 address 自動對應到新 address，plan 顯示 (moved) 而非 destroy + create。驗證 plan 為零變更後 apply，moved block 生效後可以從 code 裡刪掉。

terraform state mv 是指令式的搬遷，直接操作 state 檔。它比 moved block 靈活（可以跨 state 搬）、但不可 review、不進版本控制、操作錯了只能靠備份回退。

優先用 moved block，state mv 留給 moved 做不到的場景。

手動編輯 state：pull → 改 → push

極少數情況需要直接編輯 state JSON——例如修正一個 resource 的 ID（某次 import 用了錯的 ID）、或手動修改一個 attribute 讓 plan 不再觸發不必要的變更。

1# 拉到本地
2terraform state pull > state-edit.json
3
4# 編輯（用 jq 或文字編輯器，改目標 resource 的 attributes）
5# 極度小心：改錯任何欄位都可能讓 plan 產生破壞性差異
6
7# 推回遠端
8terraform state push state-edit.json

state push 有 lineage 和 serial 檢查——如果本地的 state 跟遠端的 lineage 不同（來自不同的 init），push 會被拒絕。加 -force 可以繞過，但這意味著覆蓋遠端、丟棄遠端從你 pull 之後的所有變更。

手動編輯 state 的操作規則：備份 → 改一個欄位 → push → plan 驗證 → 確認只有預期的變化。批次改多個欄位時，每改一個就走一輪 push + plan，不要累積修改。

從錯誤的 state push 回復

如果 state push 推了一個錯誤的 state，回復路徑取決於 backend 有沒有版本歷史。

S3 backend 有 versioning

 1# 列出 state 檔的所有版本
 2aws s3api list-object-versions \
 3  --bucket acme-tf-state \
 4  --prefix prod/network/terraform.tfstate \
 5  --query 'Versions[].{VersionId:VersionId,LastModified:LastModified,Size:Size}' \
 6  --output table
 7
 8# 下載上一個正確的版本
 9aws s3api get-object \
10  --bucket acme-tf-state \
11  --key prod/network/terraform.tfstate \
12  --version-id "correct-version-id" \
13  state-recovered.json
14
15# 用 terraform state push 推回
16terraform state push state-recovered.json

沒有 versioning

如果 bucket 沒開 versioning、又沒有本地備份，state 的上一個版本就沒了。這時候的選項：

1. 從 plan 的輸出反推哪些 resource 的 state 記錄是錯的，逐一用 state rm + import 修正
2. 作為最後手段，刪掉整份 state、從零 import 所有資源——這等於重做一次完整的 IaC 導入

這正是模組一要求 state bucket 開 versioning 的理由——沒有版本歷史的 state backend，一次 push 錯誤就沒有回退路徑。

State backend 搬遷

接手的環境可能用本地 state（.terraform/terraform.tfstate）或者 state 放在不符合安全要求的位置（沒加密的 S3、沒有鎖表、甚至存在某個人的桌機上）。搬遷到正規的遠端 backend 是接手後的優先工作。

本地 → S3 + DynamoDB

 1# 在 backend.tf 加上遠端 backend 設定
 2terraform {
 3  backend "s3" {
 4    bucket         = "acme-tf-state"
 5    key            = "prod/network/terraform.tfstate"
 6    region         = "ap-northeast-1"
 7    encrypt        = true
 8    dynamodb_table = "acme-tf-lock"
 9  }
10}

1# 重新初始化，Terraform 會偵測到 backend 變更並提示搬遷
2terraform init -migrate-state
3
4# 確認搬遷成功
5terraform plan  # 應該顯示零變更

-migrate-state 會把本地 state 的內容寫入新的遠端 backend。搬遷後本地的 .terraform/terraform.tfstate 變成一個指向遠端 backend 的指標，不再存放實際 state 內容。

舊 S3 → 新 S3

跟本地搬遷流程相同——改 backend.tf 的 bucket/key/region，跑 terraform init -migrate-state。Terraform 會從舊 backend 讀 state、寫入新 backend。

搬遷後驗證：plan 為零變更、新 bucket 裡有 state 檔、舊 bucket 的 state 檔可以保留一段時間作為備份。搬遷過程中 DynamoDB 的 lock 會確保沒有人同時 apply。

搬遷期間的風險：如果有人在你改 backend.tf 之後、跑 init 之前，用舊 backend 跑了 apply，新 backend 的 state 會缺少那次變更。搬遷時通知團隊暫停所有 Terraform 操作，搬遷完成後再恢復。

時程參考：單一 orphaned entry 的 rm 操作約 15-30 分鐘（含備份和驗證）。Backend migration 約 1-2 小時。5-10 個問題項的完整 state 整理約半天到一天。

跨分類引用

• → 有半套 IaC 但文件缺失的環境接管：本篇的上層操作流程
• → Drift 分類處理：state 修復完成後，下一步是處理 managed resource 的 drift
• → 模組一：最小可行 IaC：state backend 的設計與 versioning 要求
• → 模組四：環境分離與模組化：moved block 在環境拆分 retrofit 裡的角色

讀 plan 輸出：三種變更類型

terraform plan 的輸出用符號標示每個資源的預期變更。三種類型的風險等級不同，處理方式也不同：

 1# in-place update（~）：修改屬性，資源本身不動
 2~ resource "aws_security_group_rule" "api_ingress" {
 3    ~ cidr_blocks = ["10.0.0.0/16"] -> ["10.0.1.0/24"]
 4  }
 5
 6# forces replacement（-/+）：刪除後重建，新資源取得新 ID
 7-/+ resource "aws_db_instance" "primary" {
 8    ~ identifier = "app-prod" -> "app-prod-v2" # forces replacement
 9  }
10
11# destroy（-）：刪除資源
12- resource "aws_security_group" "legacy_api" {
13  }

-（destroy）是最危險的類型。它代表某個資源存在於雲端但不在 Terraform code 裡——可能是手動建的、可能是從 state 被 state rm 移除過、也可能是前任維護者刪了 code 但沒跑 apply。不論原因，直接 apply 會把這個資源從雲端刪除。

-/+（forces replacement）的危險在於它看起來像修改但實際是先刪後建。對 stateless 資源（security group rule、IAM policy）影響有限，對 stateful 資源（RDS、EBS volume）意味著資料遺失。

故意的 drift vs 意外的 drift

不是所有 drift 都是問題。接手的環境裡，手動改動可能有兩種來源：

故意的改動是前任維護者為了解決特定問題而做的。常見形態：臨時開了一條 security group 規則讓外部監控系統連進來、調高了 RDS 的 max_connections 參數來應對流量成長、手動把 instance type 從 t3.small 升到 t3.medium 因為記憶體不夠。這類改動通常是正確的操作決策，只是沒有同步回 code。

意外的漂移是無意中造成的。常見形態：在 Console 測試時改了某個設定但忘了改回來、另一個 Terraform workspace 的 apply 動到了共用的資源、AWS 自動更新了某些屬性（如 default security group 的描述）。

區分兩者的方法是查 CloudTrail——看這個改動是誰做的、什麼時候、有沒有對應的 ticket 或 changelog 記錄。如果 CloudTrail 顯示改動發生在一次事故期間、由當時的值班工程師執行，大概率是故意的。如果改動來自一個不認識的 IAM user、或時間點跟任何已知事件對不上，可能是意外。

1aws cloudtrail lookup-events \
2  --lookup-attributes AttributeKey=ResourceName,AttributeValue=sg-0abc123 \
3  --start-time 2026-01-01 \
4  --query 'Events[].[EventTime,Username,EventName]' \
5  --output table

每條 drift 的處理決策

每條 plan 差異都需要一個明確的決定：保留手動改動（更新 HCL）、回退到 code 的版本（apply）、還是暫時擱置（不動）。

保留（adopt into HCL）

適用條件：手動改動是正確的操作決策，雲端的現況是期望狀態。處理方式是把 HCL 改成跟雲端一致，讓下次 plan 對這項顯示零差異。

多數 drift 應該走這條路。前任維護者調大了 instance type、加了一條 security group 規則、改了 RDS parameter——這些改動通常有操作上的理由。把 code 對齊現實，比把現實改回 code 安全。

回退（apply to revert）

適用條件：手動改動是錯誤的、或已經不再需要（如臨時開的除錯 port）。確認回退不會影響運行中的服務後，讓 Terraform apply 把設定改回 code 描述的版本。

回退前要確認的事：這條規則還有沒有服務在用？這個參數改回去會不會讓連線斷開？如果不確定，先 adopt 再說——adopt 的成本是改一行 HCL，回退錯誤的成本可能是服務中斷。

擱置（defer）

適用條件：目前無法判斷該保留還是回退（缺乏 context），或改動涉及 stateful 資源的 forces replacement 需要更多準備。擱置的做法是在 code 裡加 lifecycle { ignore_changes = [...] } 暫時跳過這項差異，並留下註解說明為什麼擱置、預計什麼時候處理。

1resource "aws_db_instance" "primary" {
2  # drift: identifier 被手動改過，forces replacement
3  # 擱置原因：直接 apply 會觸發 RDS 重建、資料遺失
4  # 預計處理：確認新 identifier 後更新 HCL + 用 moved block
5  lifecycle {
6    ignore_changes = [identifier]
7  }
8}

擱置不是永久解法。ignore_changes 會讓這個屬性脫離 IaC 管理，累積越多就越接近「回到手動」。定期回顧擱置清單，逐項決定保留或回退。

Stateful 資源的高風險 drift

stateful 資源（RDS、EBS volume、DynamoDB table）的 drift 需要特別處理，因為 forces replacement 意味著資料遺失。以下屬性的改動在 plan 裡會顯示 -/+（forces replacement），直接 apply 會先刪除再重建：

發現 stateful 資源的 forces replacement 時，處理步驟：

1. 在 lifecycle 加 ignore_changes 暫時跳過
2. 備份資源（RDS snapshot、EBS snapshot）
3. 確認正確的目標狀態後，用 moved block 或 terraform state mv 處理 identity 變更
4. 用 terraform plan 驗證變更類型從 -/+ 變成 ~（in-place）或零差異
5. 移除 ignore_changes

refresh-only：安全的 state 同步

terraform apply -refresh-only 只更新 state 來反映雲端現況，不改變任何雲端資源。它適用於「雲端被手動改了、想讓 state 跟上現實但還沒準備好改 HCL」的情境。

1terraform apply -refresh-only

refresh-only 之後，state 跟雲端一致了，但 state 跟 HCL 之間的差異仍然存在——下次跑 plan 仍會看到 drift。它解的是「state 過時」的問題，不是「code 跟現實不一致」的問題。兩者要分開處理：先 refresh-only 讓 state 乾淨，再逐項決定 HCL 要不要對齊。

使用 refresh-only 的前提是確認 state backend 有 versioning——如果 refresh-only 把 state 改壞了（例如併發操作導致 state 衝突），需要能回捲到上一個版本。

批次 drift 收斂工作流

接手環境的 drift 通常不是一兩條，可能有幾十條。逐條處理可以但效率低，按類型批次處理比較實際：

第一批：安全類。security group 規則、IAM policy 的 drift 優先處理，因為它們直接影響存取邊界。全開的規則該關就關（回退），故意開的規則 adopt 進 code。

第二批：stateless 資源的 in-place drift。tag 不一致、description 不一致、非關鍵屬性的變更。這類 drift 風險低，可以批次 adopt（把 HCL 改成跟雲端一致）然後一次 apply 驗證。

第三批：stateful 資源。RDS parameter、backup retention、instance class 的變更。逐個處理，每個都要確認是 in-place update 而非 forces replacement。

第四批：擱置項。forces replacement、無法判斷的改動。加 ignore_changes 暫緩，排進 backlog 定期回顧。

每一批處理完後跑一次 plan，確認該批的 drift 消失、其他批次的 drift 沒被影響。不要一次 apply 所有批次——分批的目的是控制每次 apply 的影響範圍。

整個 drift 收斂流程的時程取決於 drift 數量和 stateful 資源的比例。20 條以內的 drift、多數是 stateless 的 in-place 變更，2-3 天可以收完。50 條以上、含多個 stateful 資源的 forces replacement，需要 1-2 週分階段處理。

跨分類引用

• → 有半套 IaC 但文件缺失的環境接管：本文的上層總覽
• → State 修復與清理：drift 處理前先確認 state 本身是健康的
• → Unmanaged resource 批次 import：drift 收斂完成後，開始 import unmanaged resource
• → Console 唯讀鐵律：drift 的根本防線
• → 模組四：環境分離與模組化：drift 收斂後的環境拆分路徑

優先序：先 import 什麼

不是所有 unmanaged resource 都值得立刻 import。判斷依據是「這個資源不在 IaC 裡的風險有多高」和「import 的操作複雜度有多低」的交集。

優先級 1-2 的資源是地基層，import 後能讓後續的 IaC 引用鏈從 hardcode ID 換成資源屬性引用，這是 import 的結構性收益。優先級 5 的資源如果生命週期短（隨部署替換），用 IaC 重新定義再 apply 比逆向 import 划算。

import block 語法（Terraform 1.5+）

Terraform 1.5 引入了宣告式 import block，取代舊版的 terraform import CLI 指令。宣告式的優勢是 import 本身進版本控制、可 review、可回滾。

1import {
2  to = aws_security_group.api
3  id = "sg-0abc123def456"
4}
5
6import {
7  to = aws_db_instance.primary
8  id = "app-prod-primary"
9}

to 是 Terraform 裡的資源地址（resource type + name），id 是雲端的資源識別碼。每種資源的 id 格式不同：security group 用 sg-xxx、RDS 用 DB identifier、S3 用 bucket name、IAM role 用 role name。格式查 Terraform provider 文件的 Import 段。

多個 import block 可以寫在同一個檔案裡（如 imports.tf），一次 plan/apply 處理整批。apply 完成後這些 import block 可以刪除——它們的作用是觸發 import 動作，import 完成後 state 已經記住了對應關係。

generate-config-out 工作流

import block 只把資源綁進 state，不會自動產生對應的 HCL 定義。Terraform 1.5+ 提供 -generate-config-out flag 自動反推 HCL：

1terraform plan -generate-config-out=generated_resources.tf

這個指令會：

1. 讀取所有 import block
2. 查詢每個資源在雲端的真實屬性
3. 把屬性寫成 HCL 資源定義，輸出到指定檔案
4. 在 plan 輸出中標示每個資源為 import（不是 create/change/destroy）

生成的 HCL 是起點，需要人工 review 後才能正式使用。

生成 HCL 的 review 要點

自動生成的 code 有幾個常見問題需要修正：

缺少 lifecycle 設定

生成的 code 不會包含 lifecycle block。有狀態資源（RDS、S3）需要手動加上保護：

1resource "aws_db_instance" "primary" {
2  # ... generated attributes ...
3
4  lifecycle {
5    prevent_destroy = true
6  }
7}

沒加 prevent_destroy 的 stateful 資源，未來某次 plan 如果判定需要 replace，apply 會先刪除再重建——資料跟著消失。

預設值與隱含屬性

雲端資源有些屬性是由平台自動設定的（如 RDS 的 ca_cert_identifier、EC2 的 credit_specification），生成的 code 會把這些都寫出來。下次平台更新預設值時，plan 會顯示 drift。review 時判斷：這個屬性是刻意設定的（保留），還是平台預設的（刪掉、讓 Terraform 接受平台預設）。

判斷方法：如果一個屬性的值跟 provider 文件裡的 default 一致，通常可以刪掉。如果不確定，先保留——保留多餘的屬性只是 code 冗長，刪錯屬性可能在下次 apply 時改變資源行為。

provider 特有的 quirk

不同 provider 有各自的 import 陷阱：

security group 的 inline vs 獨立規則問題最常見：如果生成的 code 用 inline ingress block，但環境裡同時有獨立的 aws_security_group_rule 指向同一個 SG，兩者會互相打架。統一選一種寫法——多數情況用獨立 rule 更彈性。

批次策略

一次 import 太多資源會讓 plan 輸出太長、review 不了。按服務類型分批，每批 5-15 個資源：

1批次 1: security groups (所有 SG + 對應的 rules)
2批次 2: VPC + subnets + route tables + NAT
3批次 3: IAM roles + policies
4批次 4: RDS instances + subnet groups + parameter groups
5批次 5: S3 buckets + bucket policies
6批次 6: ALB + listeners + target groups

每批的操作流程固定：

1. 寫 import block → imports-batch-N.tf
2. terraform plan -generate-config-out=generated-batch-N.tf → 檢查 plan 輸出全部是 import、沒有 create/destroy
3. review generated code → 修正 lifecycle、刪除平台預設屬性、處理 provider quirk
4. terraform plan → 確認零非預期變更（import 完後的 plan 應該只有 import 標記、沒有 change）
5. terraform apply → 執行 import
6. terraform plan → 再跑一次確認零 drift（import 後的 state 與雲端一致）
7. 刪除 imports-batch-N.tf（import block 已完成使命）、把 generated-batch-N.tf rename 成正式檔名

批次之間要按依賴順序：先 import 被依賴的資源（VPC → subnet → SG），再 import 依賴它們的資源（RDS → EC2）。這樣後面批次的 generated code 可以引用前面批次已經在 state 裡的資源，而非 hardcode ID。

驗證：plan 必須是零非預期變更

import 完成的判準是 terraform plan 輸出只有兩種結果之一：

• 完全零變更（“No changes”）— 最理想，代表 HCL 和雲端現實完全匹配
• 只有已知且可接受的差異 — 某些屬性在 HCL 裡省略了（用平台預設）、或 provider 的 plan 行為跟雲端有已知的格式差異（如 JSON 排序不同）

出現 change（要修改屬性）代表 HCL 跟雲端有落差，apply 會把雲端改成 HCL 的版本。在確認這個修改是安全的之前，不要 apply。

出現 replace（先刪後建）代表某個屬性的修改會觸發資源重建。對 stateful 資源這等於資料遺失，必須在 apply 之前解決——通常是 HCL 裡漏寫了某個 force-new 屬性。

常見 import 失敗與處理

import 操作本身不改變雲端資源——它只修改 state 檔。失敗時的回退方式是 terraform state rm <resource_address>，把 state 裡的對應記錄移除，資源本身不受影響。

時程參考

主要時間花在 generated HCL 的 review——生成是秒級的，確認每個屬性正確與否是人工判斷。第一批（security group）通常最慢，因為要建立 review 的肌肉記憶；後面的批次會加速。

跨分類引用

• → 有半套 IaC 但文件缺失的環境接管：import 前的盤點與 state 健康檢查
• → 兩套真相並存的過渡期操作：import 期間就是 dual-truth 狀態，操作規則見此篇
• → 模組一：IaC 工具選型與 state 地基：state backend 的設定與保護
• → 模組五：Stateful 資源保護：import stateful 資源後的 lifecycle 設定

為什麼半套比全手動更危險

兩個方向的風險同時存在，而且互相放大。

apply 可能摧毀未納管的資源

Terraform apply 只知道 state 裡有什麼。一個存在於雲端但不在 state 裡的資源，對 Terraform 來說「不存在」。如果某個 managed resource 引用了一個 unmanaged resource 的 ID（例如一個 security group 引用了一個手動建的 security group 作為 source），apply 不會主動碰那個 unmanaged resource——但如果有人重構了 HCL 並把那個引用移除或改掉，apply 會改動 managed 的那一端，可能讓依賴它的 unmanaged 資源失去連線。

更直接的風險是 terraform destroy 或 terraform apply 配合 count = 0 這類邏輯刪除：如果有人誤判某個資源已經不用了、但它其實只是不在 state 裡（被前人 state rm 過），destroy 不會碰它——但如果有人重新 import 它再 destroy，資源就真的被刪了。

手動改動讓 managed 資源 drift

有人在 Console 手動改了一個已經由 Terraform 管理的資源（例如加了一條 security group 規則），state 不知道這個改動。下一次任何人跑 apply，Terraform 會把手動加的規則判定為「不該存在」並刪除。手動改動的人以為規則已經加好了，直到某次不相關的 apply 把它默默清掉。

這兩個風險的交叉效應是：團隊對「能不能跑 apply」和「能不能手動改」都缺乏信心，結果是兩邊都不敢動，變更停滯，技術債累積速度比全手動還快。

過渡期操作規則

過渡期的操作紀律核心是一句話：每個資源在任何時刻都只有一個合法的變更路徑。managed 資源走 IaC，unmanaged 資源走 Console + 變更日誌。混用就是 drift 的來源。

規則一：apply 前必讀 plan

過渡期的每一次 terraform apply 之前，都要完整讀 terraform plan 的輸出，逐行確認每一項變更是預期內的。特別警惕以下訊號：

• will be destroyed：確認這個資源是否有其他依賴（即使它在 state 裡）
• will be updated in-place 且變更的屬性不是這次修改的：代表有人手動改了這個屬性，apply 會覆蓋回去
• must be replaced：資源會被先刪後建，stateful 資源（RDS、EBS）在這裡要暫停確認

過渡期禁止 terraform apply -auto-approve。即使 CI pipeline 也要把 apply 設為手動觸發（GitHub Actions 的 environment protection rule），確保有人看過 plan。

規則二：不手動改 managed 資源

一個資源一旦進了 Terraform state，所有對它的變更都走 HCL → plan → apply。在 Console 改它會製造 drift，而 drift 在過渡期特別危險——因為下一次 apply 可能已經隔了好幾天，中間的手動改動已經忘了。

如果遇到緊急情況必須手動改 managed 資源（例如安全事件需要立即封鎖某個 port），操作流程是：

1. 在 Console 做緊急變更
2. 立刻在變更日誌記錄：時間、資源、改了什麼、為什麼
3. 在 HCL 裡同步這個變更，提 PR
4. PR 裡的 plan 應該顯示零變更（因為 HCL 已經對齊了手動改動）
5. 合併 PR，state 透過下一次 apply 或 refresh 更新

規則三：記錄哪些資源歸誰管

維護一份「管理歸屬清單」——哪些資源在 Terraform state 裡、哪些還在手動管理。格式可以是 repo 裡的一個 markdown 表格：

 1## 資源管理歸屬
 2
 3| 資源類型       | 資源名稱/ID         | 管理方式   | 備註             |
 4| -------------- | -------------------- | ---------- | ---------------- |
 5| VPC            | vpc-0abc123          | Terraform  |                  |
 6| Subnet (×4)   | subnet-0def...       | Terraform  |                  |
 7| RDS            | app-prod-primary     | Terraform  | stateful、謹慎操作 |
 8| SG web         | sg-0web456           | Terraform  |                  |
 9| SG legacy-api  | sg-0legacy789        | 手動       | 待 import        |
10| EC2 worker     | i-0worker123         | 手動       | 待 import        |
11| Lambda cron    | cleanup-job          | 手動       | 待評估是否納管   |

這份清單的維護者是跑 apply 的人——每次 import 一個新資源後更新清單。清單同時是 team communication 的基礎：team member 要改某個資源前，先查清單確認管理方式。

團隊溝通

過渡期最重要的溝通是讓所有會碰 Console 的人知道哪些資源「不能手動改」。溝通的形式是直接的操作指令：

在 team channel 發一則釘選訊息：

 1[Infra 過渡期操作規則]
 2
 3以下資源已由 Terraform 管理，變更請走 PR：
 4- VPC 和所有 subnet
 5- Security group: sg-0web456, sg-0app789
 6- RDS: app-prod-primary
 7- ALB: app-prod-alb
 8
 9以下資源仍為手動管理，變更請在 Console 操作後寫 changelog：
10- EC2: i-0worker123
11- Lambda: cleanup-job
12- SG: sg-0legacy789
13
14不確定的資源：先問再動。

隨著 import 進展更新這則訊息。如果團隊用的是 Slack，可以把這則訊息設成 channel bookmark。

縮短過渡期

過渡期越長、兩套真相並存越久、操作事故的機率越高。縮短的方式是用 import sprint 集中處理。

Import sprint 的排程

一個 import sprint 是 1-2 天的集中工作，目標是把一批相關的 unmanaged 資源納入 Terraform。按風險從低到高排序：

每批的操作流程：

1. 用 import block + terraform plan -generate-config-out 產生 HCL
2. 審查生成的 HCL，修正屬性差異
3. plan 確認零變更
4. 合併 PR
5. 更新管理歸屬清單

縮短期間不要追求完美

import sprint 的目標是「納管」，不是「重構」。一個手動建的資源 import 進來後，它的 HCL 可能很醜（自動生成的 code 有大量冗餘屬性），但只要 plan 顯示零變更，它就已經是 managed 的了。重構 HCL 是 import 完成之後的事。

同樣，import sprint 期間不要同時做 module 化或環境分離。先把所有資源納管到同一份 state，之後再拆——拆的前提是所有資源都在 state 裡。

過渡期結束的判準

過渡期結束的定義是兩個條件同時滿足：

1. terraform plan 在無 code 變更時顯示零差異：代表 state 與雲端現實一致，沒有 drift
2. 管理歸屬清單上的「手動」欄位清空：所有生產資源都進了 Terraform state

第一個條件用定期排程驗證（每天跑一次 plan，非零就告警）。第二個條件用資源盤點比對——雲端的 resource inventory 減去 terraform state list 的輸出，差集為空就完成。

過渡期結束後，操作規則簡化為：所有變更走 IaC + PR，Console 只用來觀察和排查。這就是模組一的 Console 唯讀鐵律。

跨分類引用

• → 有半套 IaC 但文件缺失的環境接管：本篇的前置操作（盤點、state 健康檢查、drift 收斂）
• → State 修復與清理：過渡期出問題時可能需要 state surgery
• → 模組一：Console 唯讀鐵律：過渡期結束後的操作紀律
• → 模組四：環境分離 retrofit：所有資源納管後的下一步
• → 模組七：infra 走 PR 流程：過渡期結束後的完整 PR 護欄