GCP帳號認證開戶 谷歌云對象存儲垃圾文件自動清理腳本

GCP帳號認證開戶 第一章：為什麼要做垃圾文件自動清理

在谷歌雲的對象存儲（如 Cloud Storage）裡，文件通常像水庫一樣被放進來、被使用、再逐漸失去價值。可問題是：失去價值並不代表它會自動消失。你可能會得到大量臨時上傳的文件、上游任務失敗後殘留的分片、重複匯入造成的舊版本、測試用的影像與報表、以及被命名規則“看起來差不多但其實早該清”的舊資料。

最常見的成本來源不是單一大文件，而是長期累積的小垃圾。幾個分區的命名不統一，就會把“以為可以清掉”的東西都留著；幾次批次上傳失敗，就會留下不完整的臨時物件；團隊更迭或流程調整後，原本有生命週期的資料卻仍然繼續存在。當你發現倉儲費用開始不受控制時，才回頭想“怎麼清”，往往已經太晚，因為清理要牽涉到風險控制與稽核。

所以，垃圾文件自動清理不是錦上添花，而是倉儲治理的一部分。它帶來三個直接收益：第一，降低存儲成本；第二，提升資料庫“乾淨度”，讓後續處理更可靠；第三，形成可追溯的管理流程。真正成熟的做法，並不是“今天刪得爽”，而是把刪除變成一個可以被審計、可以被回滾、可以逐步收緊策略的機制。

第二章：先弄清楚“能清什麼、不能清什麼”

GCP帳號認證開戶 要寫腳本，第一步不是寫程式，而是把規則說清楚。你需要面對一個現實：對象存儲的刪除通常是不可逆的（或至少回收時間與成本不同），而且資料可能被下游流程依賴。若你直接以“目錄前綴”或“最後修改時間”作為條件，很可能誤刪重要資料。

因此，先建立一張清單：

• 必須保留的資料類型：例如產品正式版、對外提供下載的資料、已被索引或已被某服務使用的索引檔、以及合規要求保留的歸檔資料。
• 允許清理的資料類型：例如臨時上傳、快取、重跑用的中間檔、標記為“staging”的物件、以及確定不再被引用的舊批次。
• 需要額外驗證的資料：例如歷史版本、可能仍被回放的影像、或含有業務邏輯的檔案。這類資料可以先“降優先級”而不是直接刪除，或採取更長的保留期。

接著，你要把“垃圾”的判定條件具體化。常見可用條件包括：

• 前綴規則：例如 tmp/、staging/、failed/。
• 檔案命名規則：例如包含 .partial、_temp、或某種批次編號後綴。
• 物件大小與型態：例如小於某閾值且符合特定副檔名的物件，通常是失敗或中斷的產物。
• 最後修改時間：例如超過 N 天的臨時物件。
• 儲存類別或自動分層：不同儲存類別可搭配不同策略。

這些條件要能組合，才能避免“單一條件誤判”。腳本要做的不是替代治理，而是把治理規則落地。

第三章：生命週期策略與腳本的取捨

谷歌云對象存儲通常支援生命週期管理（例如條件式的刪除/轉換存儲類別）。如果你的規則簡單，例如“某前綴下的所有物件保留 7 天”，生命週期配置往往是更穩定、運維成本更低的方案。

但當你需要更複雜的判定時，生命週期可能不夠，例如：

• 需要依賴物件元資料（metadata）中的某個標記。
• 需要匹配更複雜的命名模式與例外情況。
• 需要先執行“乾跑”（dry run）並把候選清單輸出成報表。
• 需要與外部系統（例如資料庫、任務系統、審計系統）做交叉驗證。
• 需要階段式收緊策略（先刪除最確定的，逐步擴展）。

這時腳本就有價值。它可以先做“預覽”，再做“執行”，並且每次執行都可以留下一份可回溯的紀錄。

因此，合理的策略通常是：能用生命週期就用生命週期，腳本用在更具彈性的治理環節。本文的重點是腳本方案，但它應該在你已有治理框架上增補，而不是替代全部生命週期。

GCP帳號認證開戶 第四章：腳本設計的核心流程

一個可靠的清理腳本通常包含六個步驟。你可以把它想成“審判流程”，而不是“刪除指令”。

1. 定義範圍：明確列出要處理的 bucket、前綴、例外前綴、排除模式。
2. 拉取候選物件：只列出可能符合條件的物件，降低掃描成本。
3. 二次判定：基於時間、大小、metadata、命名等進行二次過濾。
4. 乾跑模式：先輸出將刪的清單和原因，不真正刪。
5. 執行刪除：以批次方式刪除，控制速率，並保留刪除回執。
6. 日誌與告警：把每次執行結果記錄到日誌或外部監控，失敗要可追蹤。

其中最容易被忽略的是“二次判定”和“乾跑”。如果你一開始就真刪，後面才修正規則，你會在事故中學習；而如果你把乾跑與原因輸出做得好，修正會變得很有系統。

第五章：建立可配置的規則（而不是寫死在程式裡）

清理規則通常會演進：某個前綴以前是臨時，現在變成正式；某個批次命名規則被團隊改了；某個元資料字段突然出現新值。若你把規則寫死在腳本裡，調整就會變成頻繁改程式、重新部署，風險很大。

因此，我建議使用配置化設計。配置可以用環境變數、配置檔、或參數引入（例如作業的參數）。配置至少應包含：

• bucket 名稱
• 要掃描的前綴列表
• 要排除的前綴列表（例如 keep/、prod/）
• 保留天數（例如 tmp 保留 3 天，failed 保留 14 天）
• 匹配模式（例如副檔名或特定字串）
• dry run 開關
• 最大刪除批次大小與速率限制

GCP帳號認證開戶 你還可以把“理由”做成規則輸出的欄位，例如：reason=expired_3d、reason=staging_prefix、reason=partial_suffix。這對排錯與審計非常重要。

第六章：選擇乾跑輸出格式，讓人能看懂

很多腳本在乾跑時只打印幾行結果，但一旦候選數量上來，你就會失去判斷能力。你需要一個可讀的輸出格式，最好是表格化，包含關鍵欄位：

• 物件路徑（object name）
• 大小（size）
• 最後修改時間（updated）
• 命中原因（reason）
• 是否排除（如果排除了也要有標記）

GCP帳號認證開戶 如果你把乾跑輸出成 CSV 或 JSON Lines，那後續可以很方便地拿去做人工審查或存檔。重點不是“輸出格式多漂亮”，而是“輸出能讓你放心”。當團隊看到乾跑的候選物件明細與理由，才可能把策略快速敲定並投入執行。

第七章：刪除策略的安全欄位

刪除策略要加安全欄位，避免一次把事情做過頭。以下是我常用的安全設計：

• 最大刪除上限：例如每次只刪除不超過 10,000 個物件或總大小不超過某個門檻。超出就中止並告警。
• 白名單保留：即便命中了候選條件，只要在白名單前綴或白名單物件列表，就不刪。
• 二階段刪除：先刪“確定性最高”的類型（例如副檔名為 partial），再刪“低確定性但符合過期”的類型。
• 最短保留窗口：即使符合過期，也要保證至少保留某個最低天數，避免新流程剛切換就被誤清。

這些欄位的本質是“把刪除變成可控的操作”。當你把它們做進腳本，事故就會從“整桶清掉”變成“只清掉一小部分”，而且你能快速回溯原因。

第八章：一個可落地的腳本思路（不用糾結語言細節）

下面給出的是腳本邏輯設計，你可以用你熟悉的語言（Shell、Python、Go、Node.js）來實作。關鍵是流程與安全策略，而不是語法花樣。

8.1 環境變數與參數

你可以設置：

• BUCKET
• DRY_RUN（true/false）
• SCAN_PREFIXES（逗號分隔）
• GCP帳號認證開戶 EXCLUDE_PREFIXES（逗號分隔）
• TEMP_DAYS、FAILED_DAYS 等
• MAX_DELETE_OBJECTS
• OUTPUT_CANDIDATES_PATH

8.2 物件列舉與過濾

流程上你要做兩層過濾：

• 第一層：範圍掃描。只掃描指定前綴，並排除例外前綴。
• 第二層：規則判定。對每個物件，根據 updated 時間、大小、命名模式、metadata 做判定。

判定後形成候選清單，每一行帶上 reason。候選清單同時計算總數與總大小，用來做上限檢查。

8.3 乾跑與輸出

當 DRY_RUN=true：

• 不執行刪除
• 輸出候選清單到檔案
• 打印概要：命中數量、總大小、每個 reason 命中分布

這一步你要拿去讓管理者或資料負責人確認。確認後再切到正式模式。

8.4 批次刪除與回執

當 DRY_RUN=false：

• 檢查候選總數是否超過 MAX_DELETE_OBJECTS，超了就中止並告警
• 以批次方式刪除（例如每次 500 或 1000 個，視 API 限制而定）
• 每批刪除要記錄成功與失敗的 object name
• 如果刪除失敗，記錄錯誤類型（權限、不存在、網路等）

批次處理的好處是：你不會因為單個錯誤讓整體失敗，也能清楚知道哪些物件沒刪成。

第九章：如何把腳本放進日常運維（排程與告警）

自動清理不等於你把腳本丟上去就完事。它需要運維化：何時執行、失敗怎麼處理、成功怎麼驗證、刪除怎麼審計。

常見排程方式：

• 定時觸發：例如每天凌晨執行一次，掃描前一天或過去 N 天的物件。
• 事件觸發：例如某些任務完成或失敗後觸發清理（但要小心延遲與一致性問題）。
• 人工手動觸發：當規則更新、或要對某個前綴做緊急清理時。

告警與驗證可以這樣做：

• 成功指標：例如本次刪除數量是否在預期範圍（太少可能是規則沒命中，太多可能是誤判）。
• 失敗指標：例如刪除批次失敗率、權限錯誤次數、API 呼叫失敗次數。
• 人工審計檔案：每天保存乾跑候選和正式刪除清單（至少保存 N 天）。

這些機制會讓你從“靠感覺運維”變成“靠數據運維”。你會更快發現規則漂移或資料命名變了。

第十章：常見坑位與排錯方法

GCP帳號認證開戶 很多人第一次做清理腳本會踩幾個典型坑。提前知道，能少走彎路。

10.1 刪除條件寫太寬

例如只用 updated <= now-7d，但你的桶裡也可能有正式檔剛好滿足時間條件。解決方法是：一定要加前綴、加命名模式、加 metadata 或至少加副檔名。

10.2 前綴排除沒生效

常見原因是排除條件沒有匹配到實際 object name 格式，例如多了一個斜線、或前綴拼寫不同。解法是：在乾跑輸出中把“被排除的物件”記錄原因，並抽樣檢查。

10.3 分段上傳留下的 multipart 殘留

有些上傳流程可能會留下中間檔或暫存物件。你以為它們是可清理垃圾，但又可能被後續流程依賴。解法是：對這些物件用明確的副檔名或 metadata 標記，且在保留期上不要太激進。

10.4 刪除速率或配額問題

一次刪太多可能觸發限流或性能問題。解法是：批次刪除 + 控制并发 + 重試策略（只對可重試錯誤重試）。

10.5 乾跑與正式模式差異

有些腳本在 dry run 時列舉邏輯與正式模式不同，導致你乾跑看到的候選跟真正刪的不是同一批。解法是：乾跑與正式模式共用同一段“候選生成邏輯”，只把“刪除動作”替換成“不刪”。

第十一章：把“治理”做得更像產品，而不是一次性工具

GCP帳號認證開戶 當腳本開始穩定運作後，你會遇到下一個問題：規則如何迭代？誰能改？改了怎麼回滾？

比較實用的做法是把規則變成版本化配置：

• 每次修改規則，生成一個配置版本號
• 乾跑輸出包含配置版本號
• 正式執行也記錄使用的配置版本
• 出問題時可以回到上一版本配置重跑（仍需確保刪除操作風險被控制）

另外，角色分離也很重要：資料所有者負責規則與例外，工程或運維負責腳本可靠性與可觀測性。這樣你不會把所有決策都塞進程式裡，最後變成難以審計。

第十二章：結語——讓倉儲乾淨，是可以持續的

“谷歌云對象存儲垃圾文件自動清理腳本”真正要解決的，不只是把文件刪掉，而是把資料生命週期變成可管理、可驗證、可追蹤的流程。當你用清晰的規則界定範圍、用乾跑模式建立信任、用上限與二階段策略控制風險、用日誌與告警把運維標準化，你就能在成本上升之前，把問題扼殺在日常流程裡。

最好的清理系統不是刪得最多，而是刪得正確。從“小範圍高確定性”開始，逐步擴大治理範圍；每次變更都先乾跑、留痕、再執行。當你這樣做，倉儲衛生會越來越好，而你的團隊也會越來越省心。