三站雲端切換彩排順利，同一天揪出 14 站環境檔外洩
這天的工作分成兩條主線：一條是三個網站搬上 Google Cloud 的正式切換測試，一條是查出同一批上傳到雲端的測試網站裡，有 14 個都外洩了本地環境設定檔案。
三站上雲彩排，測試完就切回原平台
我們讓A 站、一個服務科技業上班族的生活與工作資訊網站，以及自己的官方網站，依序把網域短暫指到新的 Google Cloud 環境，讓真實流量實際跑在新平台上做驗證，確認內容與行為都跟原本平台一致後，再把網域切回原本平台，雲端環境留到隔天繼續觀察，作為正式搬遷前的最後一次驗證。這個網站這次測試比對了 845 個網址，確認新舊平台內容一致；過程中 www 與 im 兩個子網域一度被設成空值，發現後先恢復原本設定，才分階段重新切換。A 站切換測試時也遇到一次登入逾時，一筆網域指向設定送出後沒有生效，重新登入後才補送成功。
一次讀取權限的疏漏，燒出 14 個測試網站的環境檔外洩
我們原本只是要複查C 站一個環境設定檔案外洩問題有沒有處理好——這個問題是前一天發現的，這天只是照計畫做唯讀複驗。複驗途中順著同一批上傳的線索往下查，才發現不只C 站一個：8 月 19 日一次把 18 個測試中的網站搬上 Google 雲端儲存空間的作業裡，有 14 個網站的環境設定檔案也一起被搬了上去，其中 4 個網站還留著內容更接近正式環境的版本。這些網站當時的正式網址都還停留在原本的平台，一般訪客打開網站不會碰到問題；但繞過正式網址、從背後的雲端儲存空間直接取用時，這些檔案是真的讀得到的。
往回追查上傳的原因，問題出在流程本身。原本有一套自動化流程會在上傳前先排除這類檔案，但那次搬遷是繞過這套流程、用手動方式直接上傳的；更麻煩的是，後來拿來確認那次搬遷有沒有成功的方法，是直接比對本機檔案數量與雲端物件數量是否一致——如果真的排除了這些檔案，兩邊數量就會對不上，反而會被判定為搬遷失敗。等於原本設計來把關的驗收方式，把外洩變成了「通過」的必要條件。
發現之後，我們先撤掉了讓這些檔案可以經由雲端負載平衡器讀取的權限，14 個網站的這個檔案現在全部讀不到。C 站那一份已經被判定有風險的檔案，則走了一套新建立的刪除流程正式移除——這套流程要求多重檢查與其他 AI 助手的獨立複查，正式拿來用之前，複查抓到好幾個漏洞，包括「檔案其實已經刪除了，但記錄卻卡在一半、看不出結果」這種會讓事後稽核搞不清楚發生什麼事的問題，都在正式執行刪除前修好並驗證過。刪除本身也保留了 7 天的可復原期間，作為最後一道防線。
這起事故點出一件容易被忽略的事：光在上傳端加一道過濾規則不夠，如果下游拿來驗證「搬遷有沒有成功」的方法，本來就要求兩邊檔案數量對等，那正確的過濾永遠會被判定為失敗，遲早會有人把過濾拿掉。
這天其他出錯的地方
- 修正兩個網站的網域設定紀錄時，一次用文字模式改寫設定檔，把整份 131 行檔案的換行符號全部改掉，雖然實際內容沒有錯，但這種改法會讓真正的改動被淹沒在看起來全部都變了的雜訊裡；發現後改用二進位模式重寫，只改到該改的那一行。