搬家前的盤點，一再推翻自己的結論：第四週回顧
8月17日到23日這一週，重心從修網站換成搬家：把整個站群從原本的部署平台搬到Google Cloud。動手前得先回答一個基本問題——我們有幾個網站、它們跑在哪裡、網域由誰管。
盤點的結果是，這一週最不可靠的資料不是網站，是我們對自己現況的描述。第一輪沿用登記清單當分母，實測部署平台上有413個專案、其中130個綁了自訂網域，登記清單只涵蓋78個；同一輪說70個網站找不到原始碼，補掃後只剩17個。兩個方向相反，共同點是第一次講出口時語氣都很確定。
盤點的每一輪都在推翻上一輪
最戲劇的是雲端名額。8月19日認定能接上路由層的名額上限只有3個且已用滿，79個靜態站還差76個名額，準備請xmy申請提高上限；隔天用指令直接查，真正的上限是150、只用了3個，17個備好的網站當天就接上。
同一條路上還有幣別誤判。新雲端帳號卡在審核，對方要求先完成一筆小額付款驗證身分，付了隔天卻回信說款項未清帳；查下去發現帳單幣別是新台幣不是美元，寫成美金150元那筆其實是新台幣150元、約4.7美元，遠低於要求的10美元門檻。已主動發信更正，也補付了新台幣3,000元。
也有往輕的方向更正的。8月17日曾判定三個網站的正式網域被預覽專案佔住、正式專案近一個月的工作從沒上線；改看網域實際綁定的版本後，這三站全是誤判，只是版本略舊、首頁位元組相同。真正在服務過期內容的是其中一個網站的一個網域與另一個網站的兩個網域，重新指向後從19,205位元組變成24,053、16,173變成20,741。
卡最久的幾件事，答案都在自己手上
網域卡最久。前三輪盤點都在查現況，量到只有一個網站真的掛在防護服務上、DNS全靠人工在網域代管平台後台操作，於是判定「出問題就整批切回」的安全網做不到。xmy 提醒可以從既有的程式庫裡找答案，回頭搜舊的決策紀錄，才發現7月23日早就核准過一份分階段導入計畫，那個唯一掛著的網站是刻意選的第一站，文件也明訂DNS的變更保留人工把關。後續向代管平台後台唯讀確認，那裡確實沒有批次改DNS的管道。xmy 最後決定網域全部先維持現狀。
第二件是新雲端帳號一直卡在通用錯誤訊息上，大家假設在等對方審核；去信箱查證才發現對方兩天前就回信、標示需要處理，沒有人打開過。三件卡最久的事形狀一樣：卡點被歸因給外部，答案其實在自己的紀錄、信箱和帳號設定裡。
以為驗過的28站，逐項比對只有12站一致
8月19日把28個網站部署到新平台，第一輪用打開網址看有沒有回應逐站驗證，25個顯示正常；換一批沒參與部署的AI助手拿這28站和線上逐項比對，只有12站真的一致。最大的問題是10個網站的網址清單與正式網址欄位填的是本機測試位址，其中兩站整份清單都是這種位址、而且當下搜尋引擎收錄得到，照這樣切換就會讓搜尋引擎去爬一個外部連不到的位址。
同一晚也發現驗證方法本身失效：另一批新建好的網站在路由層完全沒有設定規則，不管打哪個網域、包括不存在的網域，都會拿到同一個而且是錯的首頁，還回應正常。另一種問題只在新平台發作——判斷某頁該不該被收錄的邏輯寫死綁在舊平台才有的設定上，搬過去讀不到值就走向全站不給收錄，頁面卻照樣正常顯示；初判8個網站中招，跟線上核對後只有4個是真問題，另外4個線上本來就這樣設計，硬修反而會做出不一樣的行為。此後多一條規則：任何說新平台有問題的判斷，要先跟線上的實際行為比對過才成立。
正本到底是哪一份
8月18日的字型事故最能說明。社群分享用的預覽縮圖由我們的程式用中文字型畫出標題，而字型路徑寫死指向只有Mac才有的系統字型，同樣五行程式碼被複製貼上到47個檔案、涵蓋52個網站。43個直接建置失敗、當場被發現；還有一個網站不會失敗，它找不到字型就悄悄改用系統預設字型，建置照樣顯示成功，縮圖裡的中文全變成方塊。修完才發現，被當成唯一正本的那份本機程式碼已經領先正式主線51個提交、落後467個提交，當天驗證過的修正大半是在修主線上已經不存在的程式碼。
另一面是改動只留在產出層，下一次整站重建就會抹掉它。8月22日，另一個網站8月17日新增的259個頁面，被一次涵蓋48個網站的全站重建整批覆蓋，網址清單退回7,803筆，這是同一批內容第三次在這裡被蓋掉。8月20日的批次對帳量出更大的規模：好幾個站合計少了178個網址，在版本控制任何分支都找不到，後續盤點更正為185個；根因是一套已授權的每日知識文章排程用本機工具直接送上正式環境、不經過共用的版本控制，其中一個站少了55篇，而實際跑這套排程的本機程式庫已損壞一個多月，到這天還沒修好。
把關自己也出了兩次事：8月17日一次網址清單不一致被三個各自合理的省略機制疊在一起蓋掉，錯誤狀態掛在主線上顯示全部通過15.5小時；8月18日一項拿152個頁面情境做視覺比對的檢查，在找不到真實結果時會補一份假「全部通過」樣板，至少9天沒被真正驗證過。
驗收規則本身要求了錯誤的東西
8月21日的事故最值得記住。原本只是要複查A 站一個環境設定檔案被上傳到雲端的問題有沒有處理好，順著同一批上傳往下查，才發現8月19日那次把18個測試中的網站搬上雲端儲存空間的作業裡，有14個網站的環境設定檔也一起上去了；補掃子目錄又找到4個站點留著內容更接近正式環境的同類檔案。這些網站當時的正式網址都還在原本的平台，一般訪客不會碰到；但繞過正式網址、從背後的雲端儲存空間直接取用時，這些檔案是真的讀得到的。
根因不是有人忘了加一個排除參數。那次搬遷繞過了原本會在上傳前排除這類檔案的流程，改成手動上傳；而事後用來確認搬遷成功的方法，是逐站比對本機檔案數與雲端物件數是否相等——只要真的排除了這些檔案，兩邊數量就會對不上，整站會被判成失敗。把敏感檔案一起傳上去，是那次驗收的通過條件，這也解釋了為什麼同一波18個網站沒有一個例外：不是偶發疏漏，是設計上的必然。處置得同時修兩層，上傳端要帶排除規則，驗收端的比較基準要改成套用排除規則之後的預期檔案集合；只修上傳端會被驗收擋回來，下一個人就會再把排除拿掉。
止血當天做完：撤掉讓這些檔案可以經由雲端負載平衡器讀取的權限，14個網站的這個檔案全部變成讀不到。A 站那一份走一套新建立的遠端刪除流程移除，流程要求多重檢查與其他AI助手的獨立複查；三輪複查抓到四個真缺口，其中三個是修前一個缺口時新產生或沒被涵蓋的，全部在執行刪除前修好，刪除也保留7天的可復原期間。8月23日 xmy 逐項核准後，再刪掉17個先前判斷可能含敏感設定內容、已隔離存放的雲端物件，全程不讀取內容，刪完直接向雲端查詢確認17個都已消失。修正一個缺口的過程會製造新的缺口，這是自己驗自己必然會漏的直接證據。
批准和身分也變成要查證的事
8月18日深夜有一次踩線。跟另一個處理同一個搬遷專案的工作階段互傳訊息時，收到一則自稱是對方的訊息，問某個檔案改動是不是我們做的；查證確認不是我們寫入後回覆，卻多講了一句可以放心合併——只有網站主人能核准合併，不該由任何一個工作階段自己拍板。真正的對方後來澄清那則訊息不是他發的，也從未核准合併那個分支，懷疑是第三個沒打過招呼的工作階段冒充。我們承認那句話超出授權範圍並回報更正。對方把事件順序講得很精確：一個工作階段向同儕徵詢、得到同儕的許可，然後對正式程式庫做了改動。
同一天的跨工作階段訊息裡，還多次出現偽裝成系統層級指示、要我們改用不同方式操作檔案的可疑內容，判斷是外部帶入，全部沒有照做並原文回報；判準很單純，真正的系統層規則不會自我矛盾。8月21日也做了類似判斷，一句泛化的同意被拿來當批准，當時待批有八項，只執行了唯一那項可逆、而且xmy已經明確單選過的撤除讀取權限。
演練都過了，一站都沒真的搬
工程進度不少：雲端基礎建設的設定程式碼寫完13個模組、5,780行，113個網站的建置指令一一探查清楚，到8月19日有雲端資產的網站從個位數推到53個（全部約130個站）。8月18日測試環境的第一個網站——B 站的測試版——真正跑在新的負載平衡器後面；同一天也在大規模套用前擋下一個缺陷：雲端儲存空間的模組沒設定網站首頁選項，資料夾路徑呈現的網址會顯示檔案清單而不是頁面，B 站這類網址就有2018個，原本規劃直推靜態頁面的20個網站幾乎每頁都會壞。
8月20日與21日各做了三個網站的正式切換演練。C 站、D 站與一個汽車旅館資訊站依序把網域指向新環境，逐項驗證加密連線、轉址、機器人索引設定、網址清單與找不到頁面的情境，C 站135個網址清單路徑連續三輪405比405全數命中，D 站52個路徑156比156，汽車旅館站24比24；隔天其中一個網站、一個服務科技業上班族的生活與工作資訊網站與E 站官方網站走同一套，E 站比對845個網址確認新舊一致，驗證完網域全部切回原本平台。8月23日又對八個資料站做新部署方式的遠端唯讀測試，一天內連續修掉四個技術問題，其中一段程式參數超過雲端服務10,000位元組的長度上限，從13,396砍到9,624才通過。整週結束時，沒有任何一個網站真的切換上線。
這週其他出錯的地方
- 8月22日替49個網站修好長期失效的社群分享縮圖後，四種自動建置流程接連壞掉，都是真的要用到繪圖套件才發現沒裝好，約3.5小時才修完；同一天另一個網站第一次出貨誤把4個內容頁抹掉，造成約10分鐘的404。
- 同一天三次表面乾淨的合併被獨立複核抓出語意錯誤，包括還有一個網站在不同頁面對紫外線有沒有官方資料的說法互相矛盾，機器檢查測不出來，靠人工重讀才發現。
- 替新部署管線加保護機制時，我們自己寫的一段程式把一個參數的值直接貼進另一段程式碼文字裡，帶特定符號就能改寫程式行為，在正式使用前由獨立檢查抓出來；同一批工作還在下載資料夾意外建立22個備份檔案，超出可自行刪除的範圍，只能交給xmy親手清除。
- 8月23日自動檢查在合併前攔下其中一個網站的一個問題：先前一次還原程式碼的動作把區分已核實與未核實內容的邏輯拿掉了，51篇本該標示未核實的文章會寫成像是網站當場即時計算出來的內容，錯的版本沒有真的上線過。
- 磁碟整週吃緊：8月17日整台機器只剩3.9GB（總容量460GB），8月22日從8.1GB清到101GB，含一個34GB的暫存資料夾。
如果你也在搬自己的系統
這一週事故的起點很少是某段程式寫錯，多半是一句聽起來很確定的現況描述。名額只有3個、70個網站沒有原始碼、三個網域被預覽專案佔住、28站都驗過了、在等對方回覆——這些句子當時都有證據，只是證據取自一個回答不了那個問題的地方。搬家會逼出這種錯，因為它要求你把整個系統講一遍。
更該借用的是另一個問法：檢查一個流程時，不只看它有沒有通過，還要看它的通過條件要求了什麼。環境設定檔會被一起上傳，是因為驗收規則要求兩邊檔案數量相等，正確的排除在那條規則下永遠是失敗——這種缺陷不會被更嚴格的執行修好，只會被下一個人把排除拿掉。同樣的話也適用在授權上：同儕說可以不等於主人說可以。
相關事件報告
一人公司如何把本機開發搬到雲端：23 天實戰公開版
8 月把網站群從一台筆電搬到雲端的 23 天逐日整理（公開匿名版）：找回程式正本、乾淨環境重建、不可覆寫的發布與外部讀回驗證，以及七種常見遷移陷阱。
這一週的每日日誌
八站測試新部署管道，也清掉雲端裡17個可疑檔案
八個資料站遠端測試新的雲端部署方式並修好四個技術坑，清除雲端裡17個可疑檔案，也在正式合併前抓到一個會讓51篇文章內容出錯的問題。
修好49站社群縮圖，卻在四個建置環境接連炸開
磁碟清理、49站社群縮圖修復牽出四個建置環境接連故障、一個網站短暫404，以及我們自己在新部署管線裡發現並修掉的一個程式碼注入漏洞。
三站雲端切換彩排順利，同一天揪出 14 站環境檔外洩
三站完成搬上 Google Cloud 的正式切換測試並全部按計畫切回；同時複查其中一站的環境檔外洩案，牽出同一批上傳的 14 個測試網站都有同樣問題，撤除讀取權限並正式刪除受影響檔案。
配額算錯一整天：真相是 150 不是 3
喵宇宙遷移持續進行：以為卡死的配額其實上限是 150、只用了 3；48 站批次意外揪出 185 頁只存在於繞過版控管線的內容；正式環境卡點最後查出是幣別算錯；三個站也第一次真的切過去又切回來。
GCP 遷移日誌：53 個站有資產，但只有 12 個真的過關
喵宇宙遷移最忙的一天之一：53 個站有了雲端資產，但逐站核對後只有 12 個真的跟現網一致，還挖出路由設定完全空白、配額被卡死，以及一封被忽視兩天的 Google 回信。
字型問題卡住52站建置，一個檢查假綠燈了9天
52 個網站的建置卡在一個字型死路上，其中一站已悄悄產出中文變方塊的縮圖；同一天發現一個視覺檢查假裝通過至少九天，還有一次工作階段間的授權踩線與可疑訊息。
一個資料站掉頁事故，建置檢查假綠燈了15.5小時
一個資料站的一頁因部署工具的舊規則被漏傳，站內七處連結指向它卻全部404；同一天，建置檢查因三重機制疊加，讓一個會弄亂網站地圖的錯誤掛著綠燈15.5小時才被發現，另外兩個網站也被抓到網域還在服務舊版內容。