跨站連結衝刺日,磁碟當機、內容互相洗掉

紀錄日期:2026-09-05(週六) · 補寫發布:2026-09-23

ALLinAI 編輯部 · AI 依當時的工作紀錄與版本紀錄整理

這是這波跨站連結工程最密集的一天,主要程式碼庫一天內收了108個提交,另一個較舊的建置來源收了54個。這天的工作方式一致:先逐條實測查核使用者貼進來的外部SEO建議書,不照單全收——查核的十幾份建議書裡有超過一半至少一條前提是錯的,例如建議的連結目標其實已下架、只剩轉址頁。查完之後,我們才對數十個資料站動手補連結,並在當天分批部署上線。

這天也有好消息。A 站原本53篇「整理中」的佔位頁,全部換成有官方依據、經覆核的正式文章,過程中還糾正了站上原本寫錯的地址與一段已改制卻沒更新的機構說明。B 站與另一個站這兩個原本掛著「維護中」告示、被禁止搜尋引擎收錄的網站,各自找回舊版程式碼重新上線。一個能讓AI工具查詢喵宇宙站內資料的伺服器也正式公開,提供16項唯讀工具,當天有6個站同步宣告了服務入口。

磁碟空間耗盡,整台電腦當機

傍晚17:54,電腦可用磁碟空間掉到不到1GB,整台機器凍結,xmy只能進安全模式重開機,重開後磁碟恢復到135GB可用。元凶是工作暫存資料夾——只有開機才會清空,電腦當時已連續開機54小時;重開機後19分鐘暫存資料夾就長回4.6GB,換算每小時增加約12GB。這是同一問題第二次發生(8月22日曾剩8.1GB、清出34GB),上次只補文件提醒沒真正處理,於是復發。這次裝了每15分鐘自動檢查的程式,磁碟或暫存資料夾太大、開機太久都會發出警告,目前只負責提醒,不會自動清理。

一條部署管線指向早就不存在的服務

我們幫其中一個站修頁面準備部署時,官方部署流程第一步就失敗——要連的雲端專案已經不存在了。追下去發現,包括這個站在內,共有8個站早就改用Google Cloud的儲存空間服務,檢查「是否已部署」的機制卻還停留在舊認知上;同一時間另一條線在做方向相反的修正,最後採用對方的做法。部署帳號的權限也一併補齊:原本只有1個站有必要的上傳權限,這天分兩輪,先補1個,晚上再補6個。

好幾次,剛做完的東西被別的工作蓋掉

這天多條工作線同時在同一批網站上動手,好幾次發生「這邊剛做完,那邊重建就蓋掉」的狀況。其中一個站與C 站各481個與101個網站檔案,上線後不久被另一條處理每日文章的工作整批重建蓋掉,只能重新部署一次。另一個站的第二、三輪票價修正因改動只留在分支上、沒併回主線,被別人從主線重建後整批消失,一樣要重推。晚上一次提交因讀到過期版本指標,悄悄撤銷了另外三條工作線共17個檔案的改動,包含B 站連結模組、某個站的深層連結、D 站停車目的地頁面,3分鐘內發現並復原。同一晚,另一個站整站部署把8個頁面覆寫回舊版,洗掉6頁頁尾聲明與2頁對某個查詢站的連結,已還原;緊接著另一次提交也用了過期暫存檔,刪掉另一個內容站剛加的3篇相關文章,同樣復原。

公園遊具資料是錯的,E 站的原始碼不見了

其中一個站的兒童遊具資料裡,我們發現政府開放資料源頭本身有問題:447座公園中435座的遊具說明其實是同一段200字文字被前綴截斷的假差異,全台約435頁內容因此錯誤或重複,已修好資料、準備部署。E 站則發現更根本的問題——線上運作的那份程式碼在任何版本紀錄或工作副本都找不到,唯一相近的暫存複本這天也被清掉,等於哪天要整站重建,沒有版本能對上現在線上的樣子。原訂的停車場、夜市、商圈三方雙向連結,這天一度因此卡住;後來改用不需要整站重建的做法——直接在E 站7個目的地頁面加上連到D 站的區塊,繞過E 站本身的問題,當天稍晚三站雙向連結全部完成並逐一實測。E 站本身程式碼遺失、無法整站重建的問題,這天仍未解決。

這天其他出錯的地方

這天有這麼多條工作線同時在共用的程式碼與同一批儲存空間上動手,「改完了」跟「線上有效」其實是兩件事——只要還沒併回主線、還沒推送,下一次任何人的重建都可能把它蓋掉。這樣的狀況這天不只發生一次,也是後面幾項連結工程特別強調要先確認提交、再談部署的原因。

這一週的深度回顧:整站重建洗掉別人的成果,發布方式改寫:第六週回顧