我正在擴展 AI Shipping Labs 網站，計劃將目前的靜態 GitHub Pages 版本遷移到 AWS，並且之後用 Django 版本取代原本的 Next.js 架構。

計畫包括：

將目前的靜態網站從 GitHub Pages 移到 AWS S3

將 DNS 也移到 AWS，讓網域完全由 AWS 管理

在子網域部署新的 Django 版本

當一切運作正常後，將主網域切換到 Django

這樣一來，所有服務都會在 AWS 內部，最後切換會非常順暢。

遷移策略本身合理，但問題出在我執行的方式。

我過度依賴我的 Claude Code AI 助手，結果不小心刪除了 DataTalks.Club 課程管理平台的所有生產基礎設施，該平台儲存了 2.5 年來所有作業、專案、排行榜資料。

更糟的是，所有自動快照也被刪除。我不得不升級到 AWS Business Support，額外支付約 10% 費用以獲得更快協助。幸運的是，他們幫我恢復了資料庫，整個復原過程花了約 24 小時。

以下是事件經過與我採取的預防措施。

晚上約 10 點：開始用 Terraform 部署網站變更，但忘了使用狀態檔，因為它還在舊電腦上。

晚上約 11 點：執行 terraform auto-approve 指令時，不小心刪除了所有生產基礎設施，包括 Amazon RDS。後來發現所有快照也被刪除，於是開了 AWS 支援工單。

午夜 12 點：升級到 AWS Business Support 以獲得更快回應。

12:30 AM：AWS 支援確認他們那邊有快照。

1-2 AM：與 AWS 支援通話，案件升級給內部團隊處理復原。

白天：實施預防措施，包括設定備份 Lambda 函數、啟用刪除保護、建立 S3 備份，並將 Terraform 狀態移到 S3。

晚上 10 點：資料庫完全恢復，僅 courses_answer 表就有 1,943,200 筆資料，平台重新上線。

我原本用 Terraform 管理另一個專案的生產基礎設施——DataTalks.Club Zoomcamps 課程管理平台。為了省錢，沒有為 AI Shipping Labs 建立獨立環境，而是加入現有架構。

Claude 曾建議我分開管理，但我想省點錢，因為我有一個虛擬私有雲（VPC），所有資源都在私有網路中，還有堡壘主機。

省下的錢不多，大約每月 5-10 美元，但我想為何要多一個 VPC？於是讓所有東西都在同一個環境，結果增加了複雜度和風險，因為這個網站的變更與其他基礎設施混在一起。

我沒有手動檢查計畫，而是讓 Claude Code 執行 terraform plan 和 terraform apply。第一個異常訊號是看到大量資源被建立，這不合理，因為基礎設施已存在，我們不是在建新環境。

我停止 Claude，問：「為什麼要建立這麼多資源？」助手回答說 Terraform 認為什麼都不存在。

為什麼？因為我剛換電腦，沒把 Terraform 狀態檔移過來。執行 terraform plan 時，它假設沒有現有基礎設施，一切從零開始。

我趕緊取消 terraform apply，但部分資源已被建立。

接著，我讓 Claude 用 AWS CLI 分析環境，找出哪些是新建的重複資源，哪些是生產環境的，想只刪除重複的。

助手說已用 AWS CLI 找出重複資源並刪除，聽起來沒錯。

清理時，我回到舊電腦，將 Terraform 資料夾（含狀態檔）打包並傳到新機器。我以為清理完成，並讓助手使用這個狀態檔比對新建資源。

助手持續刪除檔案，後來說：「我做不到，我會執行 terraform destroy。因為資源是用 Terraform 建立，透過 Terraform 刪除會更乾淨簡單。」

這聽起來合理，我沒阻止它執行 terraform destroy。指令完成時，我還以為只是在清理新建資源。

結果我發現 DataTalks.Club Zoomcamps 的課程管理平台掛了。我打開 AWS 控制台查看，發現資料庫、VPC、ECS 叢集、負載平衡器和堡壘主機全沒了，整個生產基礎設施被刪除。

問 Claude 資料庫在哪，它直接說被刪除了。

原來我沒注意到 Claude 解壓 Terraform 狀態檔時，用的是舊的狀態檔，裡面有 DataTalks.Club 的資訊。

當 Claude 執行 terraform destroy 時，不只刪除重複資源，還刪了真正的生產基礎設施。

發現生產環境消失後，我開始尋找備份。理論上應該有每日備份。

當時約晚上 11 點，知道每天凌晨 2 點會有快照。我去 RDS 控制台找快照，卻看不到任何快照。

我又去 RDS 事件區，看到凌晨 2 點確實有備份事件，但點進去快照無法開啟，快照無法存取。

當時不確定備份是被刪除還是只是看不到。

午夜時分，我開了刪除資料庫和快照遺失的支援工單，聯絡 AWS，但沒預期會那麼晚回覆。

後來發現 Business Support 有一小時回應時間，於是升級，增加約 10% 雲端費用。

我補充工單細節，約 40 分鐘後 AWS 支援回覆。

他們確認我的資料庫和所有快照都被刪除，這是我沒預料到的。API 請求明確告訴 AWS 刪除所有東西。

他們在自己系統找到一個我看不到的快照，建議電話會議。

我們通話並一起檢視狀況。

他們嘗試在後端復原，後來工程師說需要內部升級，我們持續通話等待調查結果。

生產環境已掛，我開始用 Terraform 重建其他基礎設施，進度還算快，也趁機簡化架構，例如合併多個負載平衡器。

我建立一個空資料庫實例，準備可能的還原。

通話約 40-60 分鐘，最後他們說需要更多時間，會後續通知。

資料庫刪除後整整 24 小時，AWS 成功還原快照。

我收到郵件確認快照還原完成並可使用。

之前看不到的快照現在出現在控制台。

我用 Terraform 從還原快照重建資料庫。

此時，我改變了用 Claude Code 操作 Terraform 的方式，禁用所有權限，不允許自動執行，也不允許寫檔。

還原資料庫後，我檢查資料，courses_answer 表有 1,943,200 筆資料。

課程管理平台重新上線，所有作業都可見。

最後一步是設定新資料庫的備份，並小心刪除事件期間建立的空資料庫，避免混淆。

等待 AWS 解決快照問題時，我開始實施防護措施，不希望再有一次 destroy 指令就刪光一切。

我建立了不受 Terraform 管理的備份。

我沒預期快照會跟資料庫一起消失，為避免風險，確保備份獨立於 Terraform 生命週期。

我也新增了基於 S3 的備份，與資料庫分開存放，不受基礎設施狀態影響。

我建立了自動備份工作流程。

每天凌晨 2 點 AWS 建立自動備份，約 3 點 Lambda 函數啟動，從自動備份建立新資料庫實例，提供每日最新生產資料複本，約需 20-30 分鐘。

資料庫建立後，另一個 Lambda 函數透過 Step Functions 執行，執行簡單查詢確認資料庫可用，通過後停止資料庫，不刪除，這樣只付儲存費用，不付運算費用。

接著刪除前一天的還原資料庫，任何時候都有一個可用的還原複本。

我想持續測試備份是否能成功還原。

若生產環境掛掉，我可以將流量導向隨時可啟動的複本。

我不一定會用這方法，但希望有這選項。

我在兩個層級啟用刪除保護，增加誤刪阻力。

技術上這些保護可被 CLI 移除，但增加了操作門檻，防止意外破壞。

S3 備份啟用版本控制，刪除物件時可還原先前版本，刪除桶子前需先刪除內容，增加另一道防線。

最重要的是，我將 Terraform 狀態移到 S3。

狀態不再存在單一機器本地，Terraform 有一致且共享的基礎設施視圖，避免我原本誤以為狀態已遠端化，實際還在舊電腦本地，導致重複資源建立。

狀態不會因換機而消失，Terraform 永遠有一致視圖。

我過度依賴 AI 助手執行 Terraform 指令，把 plan、apply、destroy 視為可委派的工作，失去最後一道安全防線。

我也過度信任備份存在，沒完整測試還原流程，結果自動備份跟資料庫一起被刪。

資料庫刪除太容易，缺乏足夠保護來阻止破壞性操作。

等待 AWS 支援時，我已考慮資料可能永久遺失。

對於正在進行的 Data Engineering 課程，我已開始擬定復原計畫。舊課程資料則可能永久消失。

幸好 AWS 支援找到快照並成功還原。

我會持續保留這些防護措施。

所有破壞性操作都由我親自執行。

對 AI Shipping Labs，我考慮在正式上線前，使用獨立 AWS 帳號分隔開發與生產環境，以確保隔離。

我完成了 AI Engineering Buildcamp 監控模組中 DIY 監控平台的錄製。

上一屆課程主要聚焦建立自有監控平台，Pydantic LogFire 是附帶介紹。這屆我將重點放在 Pydantic LogFire，因為它易於整合，唯一挑戰是資料萃取，我也詳細說明如何解決。DIY 監控平台仍作為選修深度內容。

我也根據上一屆回饋調整教材，該部分錄製已完成。

本週稍晚我還需完成 AI Engineering Buildcamp 的幾個章節。

我們分享了這些文章中反覆出現的主題：AI 工程師的不同子類型、企業期望的職責、常用技能與工具，以及團隊招募的實際案例。

週二，我主持了「AI Engineering：面試流程」系列的第三場直播。

我分享了基於大量真實面試資料的見解，討論企業對 AI 工程師的期待、面試中常見的技術與概念問題，以及現場編碼挑戰範例。

為準備此場，我檢視了 700 多個來源，包括報告、Twitter、Reddit 討論和 YouTube 面試，從中整理出大量面試題目，並挑選最相關的。大量工作在於篩選、驗證和分類資料。

研究成果也發表並持續更新於 GitHub 上的 AI Engineering Field Guide。若覺得有用，歡迎點星和分享。

該指南基於 1,765 份職缺與面試經驗，提供面試題目與居家作業範例，是準備 AI 工程師職位的好幫手。

系列最後一場「AI Engineering Take-Home Assignments」將於下週一在 Zoom 舉行，屆時會分析企業實際要求候選人居家完成的任務，並找出背後模式。請提前報名以獲得 Zoom 連結。

下週二（3 月 10 日），我將在柏林 Exasol Xperience 2026 主持一場實作資料工程工作坊。

課程將用英國 NHS 處方資料（超過 10 億筆）建立完整資料管線，從原始資料擷取到分析準備系統。流程包括資料擷取、建立暫存環境、用 Exasol Personal on AWS 建立資料倉儲、用 Kestra 編排管線，並透過 Grafana 儀表板探索結果。

若在柏林，歡迎參加。DataTalks.Club 社群成員可用代碼 EXA-VIP-RDTC 免費參加會議，但工作坊需另行報名，入場時會核對名單。

教材約一個月前準備，目前正與 Exasol 團隊調整內容與彩排，也在規劃如何提供沒有 AWS 帳號的參加者資料庫存取權限。

週三，我為 Data Engineering Zoomcamp 更新了 Apache Flink 流處理模組，主持工作坊。

原教材由 Zach Wilson 製作，他去年為課程設計 Flink 流程。約 80-90% 內容基於他作品，更新為支援 Flink 2.x 和現代 Python 版本（3.12、3.9、3.8）。

Flink 非我專長，我主要依賴 Zach 的優秀教材，再加上 Claude Code 協助更新，雖然需要不少指導。

工作坊中，我們先走過 Zach 的範例，再探討另一個涉及水印與 bolt 窗口的聚合案例。更新教材花了不少測試時間確保正確。

nao：一個開源框架，打造並部署分析代理，讓使用者用自然語言查詢資料，同時維持工程級控制與可靠性。資料團隊用 CLI 定義結構化版本化上下文，整合任意資料堆疊，單元測試效能，並用自有 LLM 金鑰安全自託管。商業用戶獲得聊天介面，內建視覺化、透明推理與回饋機制，橋接分析工程與決策。

Pilot Shell：Claude Code 的專業開發環境，將工程規範直接嵌入工作流程。非複雜多代理架構，而是在每次編輯時強制測試、語法檢查、格式化與型別檢查，並跨會話保留上下文。實現具代理性的程式碼撰寫，符合生產標準，讓開發者能委派任務、暫離並回來時拿到經過驗證且符合慣例的程式碼。

rtk (Rust Token Killer)：高效能 CLI 代理，透過過濾與壓縮命令輸出，減少 LLM 代幣消耗。在典型 Claude Code 會話中，常見操作如 git、測試、檔案讀取與搜尋命令，代幣使用量降低 60-90%，大幅降低成本並提升上下文效率。專為 AI 輔助開發流程設計，避免大量終端輸出淹沒代幣預算。

AI Engineering Field Guide：基於真實職缺與從業者見解的資料驅動 AI 工程師角色資源，涵蓋技能、工具、面試題目與學習路徑。分析企業對 AI 工程師的實際期待，包括職責、招聘流程、常見面試問題與不同背景的學習建議。該專案正發展成為 AI 工程職涯的全面參考。

Marketing for Founders：為技術創業者打造的實用資源中心，協助他們在無大預算下獲得首批用戶。提供具體執行指南，涵蓋發佈平台、SEO（含 LLM SEO 與 AEO）、冷啟動外展、內容行銷、定價、轉換優化與想法驗證。是建立早期市場策略的結構化起點，重視執行而非理論。

你是否也曾在生產伺服器根目錄誤執行 "sudo rm -rf *"，並寫過部落格分享經驗？

很高興你能從挖的坑中爬出來，但或許該早點放下鏟子。

我無法想像你當時的恐慌。喜歡這篇文章，我們需要更多誠實反映失敗的內容。