這次我們不看本地模型也不看生成工具看一個最近在開源社區(qū)里引發(fā)討論的事件Gentoo 的 Bugzilla 因?yàn)?AI bot 和 scraper 流量過載被迫關(guān)閉。這個事件本身不長但暴露出來的問題很典型當(dāng)大量 AI 訓(xùn)練爬蟲、數(shù)據(jù)采集腳本開始對舊式 Web 應(yīng)用發(fā)起高頻請求時一個正常維護(hù)的 Bugzilla 實(shí)例可以毫無預(yù)兆地被“打癱”。Gentoo 不是第一個遇到這類問題的開源項(xiàng)目也不太可能是最后一個。這篇文章會圍繞三件事展開一是把事件鏈路拆開看AI bot 流量到底是怎么壓垮 Bugzilla 的二是為什么傳統(tǒng) Web 應(yīng)用對這種流量幾乎沒有招架能力三是作為開源維護(hù)者或運(yùn)維工程師可以用哪些低成本的工程手段給這類系統(tǒng)加防護(hù)。涉及限流、UA 管理、robots.txt、CDN/WAF、日志監(jiān)控和恢復(fù)流程都會給出可落地的思路和配置模板。1. 事件核心速覽先把這個事件的關(guān)鍵信息整理成一張表方便快速判斷它和你有沒有關(guān)系。項(xiàng)目/事件說明事件主體Gentoo Linux 項(xiàng)目的 BugzillaBug 跟蹤系統(tǒng)事件類型AI bot / scraper 流量過載導(dǎo)致服務(wù)關(guān)閉根本原因自動化爬蟲對公開頁面高頻請求超出系統(tǒng)承載能力直接影響B(tài)ug 提交、評論、搜索、開發(fā)者協(xié)作等功能中斷受影響人群Gentoo 開發(fā)者、維護(hù)者、普通用戶恢復(fù)方式先關(guān)閉系統(tǒng)保護(hù)數(shù)據(jù)再封禁異常流量并恢復(fù)服務(wù)行業(yè)背景AI 大模型訓(xùn)練爬蟲、數(shù)據(jù)采集工具大量抓取公開網(wǎng)頁已對開源基礎(chǔ)設(shè)施構(gòu)成現(xiàn)實(shí)壓力本文目標(biāo)拆解事件成因給出可復(fù)用的防護(hù)、處置、恢復(fù)方案需要說明的一點(diǎn)是目前公開信息主要集中在事件結(jié)論層面具體請求量、響應(yīng)延遲這些參數(shù)沒有完整披露。所以下文凡是涉及數(shù)字和性能指標(biāo)的都會以通用工程經(jīng)驗(yàn)作為參照不會冒充官方數(shù)據(jù)。實(shí)際操作時請以你自己的監(jiān)控平臺和日志統(tǒng)計(jì)為準(zhǔn)。2. 事件復(fù)盤一條 AI 爬蟲流量是怎么壓垮 Bugzilla 的Bugzilla 是一個老牌的 Bug 跟蹤系統(tǒng)Gentoo 長期把它作為核心協(xié)作工具。它的流量模型是典型的“低基數(shù)、高信任”平時主要是開發(fā)者提交 bug、維護(hù)者評論、用戶搜索歷史問題單頁面體積不大整體請求量不算高但頁面之間關(guān)聯(lián)復(fù)雜每次頁面渲染通常都要訪問數(shù)據(jù)庫。這種系統(tǒng)放在十年前完全沒問題。但放到現(xiàn)在AI 爬蟲的抓取模式和人類訪問有本質(zhì)區(qū)別。人類訪問 Bugzilla 的行為是片段式的查一個 bug、翻一兩頁、或者提交一個補(bǔ)丁一次會話可能只有幾個請求。AI 爬蟲不是這樣。它會從首頁、搜索頁、bug 列表頁開始沿著所有鏈接遞歸遍歷把每一條 bug 詳情、每一個評論歷史、每一次附件變更全部抓走。單條數(shù)據(jù)本身不大但 Gentoo 這種重度使用 Bugzilla 的項(xiàng)目歷史 bug 數(shù)量級是以數(shù)十萬甚至百萬計(jì)的。爬蟲要做的就是把這一整棵頁面樹完整爬一遍。這個行為會導(dǎo)致兩個直接后果。第一個是數(shù)據(jù)庫壓力。Bugzilla 每個詳情頁都對應(yīng)若干條 SQL 查詢包括 bug 主表、評論表、附件表、關(guān)鍵字表、依賴關(guān)系表。爬蟲每請求一個頁面都會觸發(fā)這些查詢。普通用戶的并發(fā)量可能是幾十AI 爬蟲跑起來并發(fā)是幾百甚至上千。數(shù)據(jù)庫連接池先被打滿然后請求開始排隊(duì)排隊(duì)時間變長后面的人類用戶打開頁面也會變慢最終整體不可用。第二個是 CPU 和內(nèi)存壓力。Bugzilla 這類傳統(tǒng)應(yīng)用頁面渲染依賴服務(wù)器端模板每次請求都要重新執(zhí)行認(rèn)證邏輯、權(quán)限判斷、模板渲染、甚至發(fā)送郵件通知。無狀態(tài)爬蟲請求沒有會話緩存每個請求都是全然的開銷。當(dāng)系統(tǒng) CPU 長時間打滿進(jìn)程會開始堆積磁盤 IO 和內(nèi)存交換跟著惡化最后只能靠外部干預(yù)恢復(fù)。從“請求量上升”到“服務(wù)不可用”中間往往沒有明顯的前兆。這正是 AI bot 流量最棘手的地方它不像 DDoS 攻擊那樣短時間脈沖式爆發(fā)而是像溫水煮青蛙一樣持續(xù)爬行。運(yùn)維可能前幾個小時看負(fù)載曲線還只是緩慢上升等到發(fā)現(xiàn)時數(shù)據(jù)庫連接已經(jīng)全部耗盡。這個事件的關(guān)閉動作從運(yùn)維角度看是合理的。寧可先關(guān)掉服務(wù)也不能讓異常流繼續(xù)寫壞數(shù)據(jù)庫或把日志目錄打滿。關(guān)鍵是關(guān)閉之后要有一套快速止血和定位的流程而不是關(guān)了就完事。3. 為什么 Bugzilla 這類傳統(tǒng)系統(tǒng)特別容易被爬蟲擊穿不是所有 Web 應(yīng)用都會被爬蟲輕易打癱?，F(xiàn)代 Web 應(yīng)用大多有緩存層、限流組件、靜態(tài)資源 CDN 和 API 網(wǎng)關(guān)爬蟲在到達(dá)業(yè)務(wù)邏輯之前就被擋掉大半。但 Bugzilla 這類系統(tǒng)有幾個先天弱點(diǎn)。第一個弱點(diǎn)是架構(gòu)太“直”。瀏覽器直接請求動態(tài)頁面應(yīng)用直接查數(shù)據(jù)庫模塊之間沒有像樣的緩沖。靜態(tài)資源和動態(tài)接口沒有分離CDN 的緩存收益很低因?yàn)榕老x訪問的 URL 幾乎全是需要實(shí)時渲染的動態(tài)路徑。第二個弱點(diǎn)是應(yīng)用層沒有內(nèi)置限流。Bugzilla 的歷史設(shè)計(jì)目標(biāo)是讓匿名用戶也能方便地瀏覽和檢索 bug所以默認(rèn)不強(qiáng)制登錄。這讓爬蟲可以用最簡單的 GET 請求遍歷全部公開頁面不需要 session、不需要 cookie、不需要處理表單。第三個弱點(diǎn)是頁面語義結(jié)構(gòu)化程度太低。Bugzilla 的頁面是上世紀(jì)風(fēng)格的 HTML 表格布局正文內(nèi)容散落在多個td和div里。爬蟲為了提取標(biāo)題、狀態(tài)、評論內(nèi)容會重復(fù)請求多個相關(guān)頁面或者反復(fù)嘗試不同的 URL 參數(shù)。比如一個 bug 列表頁可能帶bug_status、resolution、product、component等多個 query 參數(shù)爬蟲為了完整抓取會把參數(shù)組合全部請求一遍。這會讓請求量再放大一個數(shù)量級。第四個弱點(diǎn)也是最重要的一點(diǎn)舊系統(tǒng)往往缺乏觀測能力。沒有按 UA 維度做的請求量統(tǒng)計(jì)沒有頁面級響應(yīng)延遲監(jiān)控沒有數(shù)據(jù)庫連接池水位告警。結(jié)果就是流量異常時運(yùn)維只能看到“系統(tǒng)變慢”而很難快速定位到“某個具體爬蟲類型正在掃描哪個路徑”。所以這次 Gentoo 關(guān)閉 Bugzilla本質(zhì)上不是一次應(yīng)急失誤而是傳統(tǒng) Web 應(yīng)用面對新時代自動化流量的一次結(jié)構(gòu)性碰撞。要解決它不能只靠重啟。4. 同類事件不是孤例AI 爬蟲對開源社區(qū)的普遍沖擊很多人會以為這是 Gentoo 自己的個例實(shí)際上 AI 爬蟲沖擊公開 Web 服務(wù)已經(jīng)是一個行業(yè)級問題。大模型訓(xùn)練需要數(shù)據(jù)而訓(xùn)練數(shù)據(jù)的很大一部分來自公開網(wǎng)頁。GPTBot、ClaudeBot、Amazonbot、Grokbot、PerplexityBot 等公開的 AI 爬蟲會把整個站點(diǎn)內(nèi)容抓走。除了這些帶明確標(biāo)識的爬蟲還有大量不帶標(biāo)識的 scraper偽裝成普通瀏覽器 UA或者使用“通用爬蟲”的 UA專門批量采集內(nèi)容用于搜索索引、內(nèi)容聚合、競品分析等場景。對商業(yè)網(wǎng)站來說這類流量更多是帶寬成本和內(nèi)容版權(quán)問題。但對開源基礎(chǔ)設(shè)施來說風(fēng)險完全不同。開源項(xiàng)目的基礎(chǔ)設(shè)施大多依靠捐贈、志愿者和有限的硬件資源。Bugzilla、GitLab、Wiki 這類系統(tǒng)本身跑在公共服務(wù)器上帶寬和 CPU 都不寬裕。AI 爬蟲的全站抓取會讓流量成本、存儲成本、數(shù)據(jù)庫負(fù)載都顯著上升而開源社區(qū)沒有商業(yè)公司那樣的 SLA 預(yù)算和專人值班去應(yīng)對。流量過載到影響正常開發(fā)者提交代碼修復(fù) bug 的時候問題就從“成本”變成了“可用性”。更麻煩的是很多爬蟲并不理會 robots.txt。robots.txt 在語義上是一個君子協(xié)議靠爬蟲方自覺遵守并沒有強(qiáng)制執(zhí)行力。技術(shù)上它解決不了無標(biāo)識爬蟲、偽裝 UA 爬蟲和已經(jīng)提前抓取過的緩存數(shù)據(jù)。從信息收集的角度看開源項(xiàng)目的 Bugzilla 里包含大量技術(shù)討論、補(bǔ)丁信息、版本漏洞修復(fù)歷史。這些內(nèi)容對 AI 訓(xùn)練有數(shù)據(jù)價值但同時對社區(qū)來說它們是協(xié)作資產(chǎn)不是開放給任意爬蟲隨意采集的免費(fèi)接口。是否允許爬取、以什么頻率爬取、抓走之后怎么使用這些問題在開源基礎(chǔ)設(shè)施上一直沒有清晰的技術(shù)方案。這次事件給開源維護(hù)者們提了個醒如果你的項(xiàng)目還在用裸奔的 Web 應(yīng)用對外提供服務(wù)那么 AI 爬蟲過載不是“會不會發(fā)生”的問題而是“什么時候發(fā)生”的問題。提前加防護(hù)比事后恢復(fù)成本低得多。5. 開源社區(qū)應(yīng)對 AI Bot 的工程化方案下面這套方案按“先低成本、再高成本”的順序來設(shè)計(jì)。開源項(xiàng)目可以先從 robots.txt 和網(wǎng)關(guān)限流開始成本幾乎為零但能擋住絕大多數(shù)有標(biāo)識的 AI 爬蟲。如果還不行再考慮 CDN/WAF 和應(yīng)用層改造。5.1 第一道防線robots.txtrobots.txt 解決不了惡意爬蟲但它能防住遵守協(xié)議的公開爬蟲。對開源項(xiàng)目來說這一步仍然值得做因?yàn)橹髁鞔竽Ｐ陀?xùn)練爬蟲大多會先讀取 robots.txt。這是一個可供參考的配置模板User-agent: * Disallow: /admin/ Disallow: /bugzilla/show_bug.cgi Disallow: /bugzilla/buglist.cgi Disallow: /bugzilla/long_list.cgi Disallow: /bugzilla/attachment.cgi # 明確禁止 AI 訓(xùn)練爬蟲 User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: Amazonbot Disallow: / User-agent: PerplexityBot Disallow: / User-agent: Grokbot Disallow: /需要說明的是robots.txt 對同一個站點(diǎn)只能全局維護(hù)一份如果你的 Bugzilla 不是部署在根路徑路徑前綴需要按實(shí)際部署情況調(diào)整。另外robots.txt 的修改生效不是即時的已經(jīng)拿到舊 robots.txt 的爬蟲可能還會繼續(xù)抓一段時間。5.2 第二道防線網(wǎng)關(guān)層限流與 UA 管理如果應(yīng)用前面有 nginx 或 Caddy 這類反向代理可以在網(wǎng)關(guān)層做兩件事一是按 UA 屏蔽已知 AI 爬蟲二是對動態(tài)路徑做單位時間請求數(shù)限流。nginx 的封禁 UA 配置示例# 禁止已知 AI 爬蟲 UA map $http_user_agent $ai_bot { default 0; ~*GPTBot 1; ~*ClaudeBot 1; ~*Amazonbot 1; ~*PerplexityBot 1; ~*Grokbot 1; ~*Bytespider 1; ~*CCBot 1; } server { listen 80; server_name bugs.example.org; if ($ai_bot) { return 403; } location /bugzilla/ { # 對動態(tài) bug 路徑限流比如 30 秒 10 個請求 limit_req zonebugzilla burst10 nodelay; proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } # 在 http 塊中定義限流區(qū)域 limit_req_zone $binary_remote_addr zonebugzilla:10m rate20r/m;這里的limit_req_zone把每個 IP 的請求頻率限制為每分鐘 20 個請求。burst允許短時突發(fā)nodelay表示突發(fā)請求不延遲直接放行。實(shí)際參數(shù)需要根據(jù)你的正常用戶量來調(diào)整不能設(shè)置得太死否則會影響正常開發(fā)者的批量操作。需要注意單純按 UA 封禁并不能擋住偽裝 UA 的爬蟲。所以限流是更關(guān)鍵的一層它不關(guān)心你是誰只關(guān)心你有沒有在短時間內(nèi)發(fā)起異常數(shù)量的請求。5.3 第三道防線CDN / WAF 托管層如果你的項(xiàng)目能接受把 DNS 接入 Cloudflare 這類服務(wù)可以開啟安全防護(hù)讓異常流量的過濾發(fā)生在前端而不是打到你自己的服務(wù)器上。這類托管層能做的幾件事開啟“爬蟲管理”或“機(jī)器人過濾”模式自動識別已知的 AI 爬蟲并進(jìn)行質(zhì)詢或攔截。配置速率限制規(guī)則例如某個路徑下單個 IP 每分鐘超過 50 次請求就觸發(fā)挑戰(zhàn)頁。開啟緩存規(guī)則把不經(jīng)常變化的公開頁面設(shè)置為緩存資源讓動態(tài)請求量降下來。通過防火墻規(guī)則按 UA 或 ASN 屏蔽特定來源。這里引出一個技術(shù)術(shù)語需要解釋下Cloudflare 的“挑戰(zhàn)頁”并不是一個簡單的驗(yàn)證碼而會綜合判斷訪問者的瀏覽器環(huán)境、行為特征和 IP 信譽(yù)。對正常用戶幾乎無感但對無頭瀏覽器爬蟲來說有很高的攔截率。5.4 第四道防線應(yīng)用層改造與登錄墻如果前幾層都擋不住那就要考慮應(yīng)用層改造了。對于 Bugzilla最有效的改造是給“寫操作”加登錄墻給“讀操作”加緩存。Bugzilla 的show_bug.cgi這類動態(tài)頁面可以被設(shè)置成只允許登錄用戶查看爬蟲在未登錄狀態(tài)下拿不到有價值的頁面內(nèi)容也就沒有動機(jī)繼續(xù)抓。代價是犧牲了一部分公開瀏覽的便利性但對以協(xié)作為主的開源項(xiàng)目來說這個取舍是合理的。更輕量的做法是給最消耗資源的頁面加一層 SQL 查詢緩存或頁面級緩存。以 Bugzilla 為例一個 bug 詳情頁在 X 分鐘內(nèi)的輸出內(nèi)容基本是一致的可以對匿名用戶緩存完整 HTML。請求落到緩存層數(shù)據(jù)庫壓力會顯著降低。如果你用的是 nginx可以配一段簡單的緩存location /bugzilla/show_bug.cgi { proxy_cache bugzilla_cache; proxy_cache_key $request_uri; proxy_cache_valid 200 302 5m; proxy_pass http://127.0.0.1:8080; }這個配置只緩存匿名用戶返回的 200 和 302 響應(yīng)緩存時間 5 分鐘。登錄用戶的響應(yīng)因?yàn)橛蠸et-Cookie通常會繞過緩存能保持?jǐn)?shù)據(jù)實(shí)時性。這里的核心思路是把爬蟲最常訪問的“靜態(tài)化頁面”緩存住讓它們不會每次都打到數(shù)據(jù)庫。5.5 日志監(jiān)控與告警防護(hù)做完了沒有監(jiān)控等于白做。你需要知道自己的系統(tǒng)正在被誰訪問、訪問哪些路徑、響應(yīng)速度如何。以下是一組可以直接在 Linux 服務(wù)器上執(zhí)行的日志分析命令用來做快速流量畫像# 統(tǒng)計(jì)訪問量前 10 的 UA awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 # 統(tǒng)計(jì)訪問量前 10 的 IP awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 # 查看某個具體 IP 最近訪問了哪些頁面 grep 1.2.3.4 /var/log/nginx/access.log | awk {print $7} | sort | uniq -c | sort -nr | head -30 # 統(tǒng)計(jì)響應(yīng)碼分布 awk {print $9} /var/log/nginx/access.log | sort | uniq -c | sort -nr # 篩選出 5xx 錯誤出現(xiàn)最多的路徑 awk $9 500 {print $7} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20在這些命令的基礎(chǔ)上可以再做自動化用定時任務(wù)定期統(tǒng)計(jì) UA 分布如果發(fā)現(xiàn)某個 UA 在 5 分鐘內(nèi)的請求量超過閾值就自動通過防火墻封禁該 IP。也可以用更成熟的監(jiān)控方案比如 Prometheus 收集 nginx 指標(biāo)配合 Grafana 做可視化。對開源社區(qū)來說先用日志命令手動分析再逐步加自動告警是比較務(wù)實(shí)的路徑。6. 系統(tǒng)恢復(fù)與運(yùn)維處置流程如果事件已經(jīng)發(fā)生服務(wù)已經(jīng)不可用可以參考下面的處置流程。這套流程適用于 Bugzilla 這類傳統(tǒng) Web 應(yīng)用也能遷移到其他類似的舊系統(tǒng)。第一步是止血。果斷關(guān)閉對外的 Web 訪問可以通過防火墻規(guī)則只放行維護(hù)者的 IP或者在 nginx 層直接返回維護(hù)頁面。關(guān)閉服務(wù)可能影響正常用戶但總比讓異常流量繼續(xù)把數(shù)據(jù)庫寫壞、把磁盤日志打滿要好。第二步是備份。在服務(wù)關(guān)閉后立即備份數(shù)據(jù)庫和關(guān)鍵配置文件。故障恢復(fù)的最終目標(biāo)是讓業(yè)務(wù)數(shù)據(jù)完好無損備份必須在清理異常流量之前完成否則一旦誤刪數(shù)據(jù)就麻煩了。第三步是定位異常流量來源。登錄服務(wù)器查看負(fù)載曲線確認(rèn)磁盤、CPU、內(nèi)存、數(shù)據(jù)庫連接池各自的狀態(tài)。然后按日志分析命令統(tǒng)計(jì) UA、IP 和請求路徑。重點(diǎn)看三個信號是否有單一 UA 請求量異常高、是否有單一 IP 的請求頻率異常高、是否有某個動態(tài)路徑比如show_bug.cgi的請求量占絕對大頭。第四步是封禁與限流。將確認(rèn)的惡意 IP 加入防火墻黑名單在 nginx 層封禁已知 AI 爬蟲 UA對動態(tài)路徑開啟限流規(guī)則。如果你的站點(diǎn)有 CDN配置相應(yīng)的安全規(guī)則讓流量在前端就被過濾掉。第五步是恢復(fù)服務(wù)并觀察?；謴?fù)訪問后不要立刻把限流規(guī)則全部放開先保持一個嚴(yán)格閾值運(yùn)行 30 分鐘左右持續(xù)觀察負(fù)載和請求量。如果負(fù)載曲線明顯回落再逐步放寬規(guī)則。如果放寬后流量又反彈說明異常流量還在需要調(diào)整封禁策略。第六步是復(fù)盤和補(bǔ)丁。確認(rèn)服務(wù)穩(wěn)定后要把這次的修復(fù)措施固化下來模板化為腳本或配置防止下次復(fù)發(fā)。同時復(fù)盤系統(tǒng)本身有沒有需要改造的短板比如數(shù)據(jù)庫是否需要加索引、緩存是否需要開啟、部分公開頁面是否需要加登錄墻。這套流程的核心原則是“先恢復(fù)數(shù)據(jù)安全再恢復(fù)業(yè)務(wù)可用最后恢復(fù)訪問便利性”。順序不能反。7. 常見問題與排查方法結(jié)合這類 AI bot 過載事件常見的臨床表現(xiàn)整理成一個排查表方便運(yùn)維時快速對照。問題現(xiàn)象可能原因排查方式解決方案服務(wù)器 CPU 長時間打滿爬蟲高頻請求動態(tài)頁面top查看進(jìn)程awk統(tǒng)計(jì)請求量最高 UA封禁對應(yīng) UA限流動態(tài)路徑數(shù)據(jù)庫連接池耗盡大量匿名請求觸發(fā) SQL 查詢查看數(shù)據(jù)庫慢查詢?nèi)罩竞瓦B接數(shù)開啟頁面緩存限制匿名訪問負(fù)載正常但頁面打開很慢數(shù)據(jù)庫響應(yīng)或網(wǎng)絡(luò)帶寬瓶頸檢查網(wǎng)絡(luò)出入流量、數(shù)據(jù)庫慢日志增加帶寬限制優(yōu)化 SQL 查詢啟用緩存封了 UA 依然有高流量爬蟲偽裝 UA 或無標(biāo)識抓取按 IP 統(tǒng)計(jì)請求量、訪問路徑按 IP 限流啟用 CDN 機(jī)器人過濾robots.txt 設(shè)置了卻仍被請求部分爬蟲不遵守 robots.txt觀察日志中的爬蟲請求網(wǎng)關(guān)層硬封禁使用 CDN/WAF恢復(fù)服務(wù)后流量再次反彈限流閾值過寬或封禁 IP 不完全觀察恢復(fù)后的請求量曲線先保持嚴(yán)格限流逐步放寬正常用戶也被限流誤傷限流閾值設(shè)置過低對比正常用戶 IP 的請求模型按路徑分開限流為登錄用戶放開限制5xx 錯誤突然增多后端服務(wù)或數(shù)據(jù)庫過載按狀態(tài)碼統(tǒng)計(jì)錯誤、查看應(yīng)用日志優(yōu)先恢復(fù)后端服務(wù)再排查異常流量這個表里的方案都偏向“快速止血”。等系統(tǒng)穩(wěn)定之后應(yīng)該把其中一部分固化為自動化規(guī)則而不是每次都靠人工介入。8. 給開源維護(hù)者的最佳實(shí)踐這次事件值得所有開源項(xiàng)目維護(hù)者對照檢查。下面這些實(shí)踐不一定全都要做但至少應(yīng)該挑出幾項(xiàng)盡快落地。第一給公開動態(tài)頁面做好緩存。很多舊應(yīng)用的瓶頸不在“數(shù)據(jù)體積”而在“每個請求都實(shí)時渲染”。哪怕是靜態(tài)化 5 分鐘都能把數(shù)據(jù)庫壓力降下來一個數(shù)量級。這是成本最低、收益最明顯的優(yōu)化。第二一定要按 UA 和 IP 兩個維度做流量觀測。你可以先不做自動告警但至少保留 nginx access log并且能隨時用日志命令統(tǒng)計(jì)出“誰在請求什么”。很多 AI 爬蟲第一次訪問時會暴露真實(shí)的 UA發(fā)現(xiàn)得越早處理成本越低。第三限流規(guī)則要分路徑。不要對整個站點(diǎn)一刀切限流否則容易誤傷正常用戶的批量操作。把最消耗資源的動態(tài)路徑比如show_bug.cgi、buglist.cgi、attachment.cgi單獨(dú)拆出來設(shè)置更嚴(yán)格的閾值。第四不要過度依賴 robots.txt。它只是一個聲明不是一個強(qiáng)制執(zhí)行機(jī)制。合理的定位是“給遵守協(xié)議的爬蟲一個快速低成本的退出按鈕”而不是“所有爬蟲都會看到并遵守”。第五安全層面要考慮隱私和版權(quán)。Bugzilla 里可能包含未公開的安全漏洞信息、開發(fā)者個人信息、討論內(nèi)容和補(bǔ)丁細(xì)節(jié)。開放給 AI 爬蟲采集不只是負(fù)載問題還涉及這些內(nèi)容被第三方收集、加工和再傳播的合規(guī)風(fēng)險。在部署任何爬蟲防護(hù)時都應(yīng)該明確哪些數(shù)據(jù)允許公開抓取哪些必須走認(rèn)證流程。第六長期來看給開源基礎(chǔ)設(shè)施排優(yōu)先級。如果你的項(xiàng)目已經(jīng)進(jìn)入了維護(hù)成本高、流量增長的階段可以考慮把 Bugzilla 這類傳統(tǒng)系統(tǒng)遷移到更現(xiàn)代的協(xié)作平臺或者用容器化部署配合自動化防護(hù)鏈。這類遷移成本較高但比每次遇到流量過載都應(yīng)急恢復(fù)要劃算。9. 總結(jié)與后續(xù)觀察Gentoo Bugzilla 這次的關(guān)閉不是一次孤立的運(yùn)維事故它是 AI 自動化流量開始改變開源基礎(chǔ)設(shè)施運(yùn)行環(huán)境的一個信號。過去我們防的是搜索引擎爬蟲它們頻率可控、遵守協(xié)議、目的單一現(xiàn)在我們要防的是訓(xùn)練數(shù)據(jù)采集器、內(nèi)容聚合器、無標(biāo)識瀏覽腳本它們的請求模式更激進(jìn)目標(biāo)也更不透明。對普通用戶來說這件事的啟示是當(dāng)你在一個開源社區(qū)提交 bug 或搜索問題時后臺可能正有一批自動化程序在不同地點(diǎn)瘋狂請求同一個頁面。對維護(hù)者來說正確的應(yīng)對不是等系統(tǒng)掛掉再重啟而是提前在網(wǎng)關(guān)層、緩存層、應(yīng)用層都做好準(zhǔn)備。如果你也在維護(hù)一個基于 Bugzilla、MediaWiki、GitLab 或類似的公開 Web 服務(wù)建議從今天開始做三件事查一下最近 24 小時的 access log 里請求量最高的 UA 是誰確認(rèn)你的動態(tài)頁面有沒有開緩存再給最關(guān)鍵的動態(tài)路徑加上限流規(guī)則。占用不了多少時間但你會在下一次 AI bot 流量高峰到來之前感謝自己在當(dāng)天做了這些配置。后續(xù)值得繼續(xù)觀察的是 Gentoo 恢復(fù)之后是否會公開更多技術(shù)細(xì)節(jié)比如異常流量的規(guī)模、具體是哪些爬蟲類型、恢復(fù)策略是否有效。這些數(shù)據(jù)對其他社區(qū)都有參考價值。真遇到了類似情況按這篇文章里的處置流程走一遍能讓你少走不少彎路。