用 Telegram 機器人處理本站監控與日常操作
96
2026年3月23日
Daniel Lu全端工程師 | 內容創作者
為了處理本站的一部分監控和管理任務,我選擇接入 Telegram 機器人。相比另做一套後台介面,這是一個更小的操作入口。
為了處理本站的一部分監控和管理任務,我選擇接入 Telegram 機器人。相比另做一套後台介面,這是一個更小的操作入口。
摒棄輪詢,基於 Webhook 的安全通信
在數據同步上,我沒有採用低效的定時輪詢去拉取伺服器狀態,而是全面擁抱了事件驅動的 Webhook 機制。
當我在 Telegram 對話框下發指令時,請求會直接推送到源站的專用接口。請求到達伺服器後,程式碼層面會進行嚴格的二次 Token 驗證。
由於 Telegram 機器人接口有嚴格的超時限制,Next.js 接收到指令後會立即返回 HTTP 200 確認。隨後,利用 Next.js 15 的
after 特性,把耗時的資料庫查詢或打包任務掛載到後台靜默執行,任務完成後再由機器人主動把結果推送到我的手機上。核心業務:快捷查詢與自動化維運
目前這套系統已經接管了本站絕大部分的日常維運工作,主要涵蓋以下三大塊功能:
1. 流量與點擊轉化監控
不需要再去登入雲服務商複雜的統計面板。透過簡單的指令,後端會即時查詢 SQLite 業務主庫,並在 SQL 層面過濾掉爬蟲和機器人的 User-Agent。機器人會直接把今日、昨日和近 7 天的去重 PV 與 UV 數據推送給我,並附帶最新真實訪客的脫敏地理位置。同時,我還可以一鍵提取埋點日誌,隨時掌握頁面內特定元件的點擊轉化率。
2. 快取清理與停機維護
每次更新靜態配置或發布新文章後,我可以直接在聊天框下發指令。系統會觸發 Next.js 的 layout 級別快取刷新並更新站點地圖,隨後自動清理邊緣快取,並順手將資料庫裡過期的無用數據清理乾淨。如果遇到突發情況需要停機,也可以透過指令一鍵激活邊緣節點的 Workers 路由,瞬間將全站流量安全攔截。
3. 無感知的 SQLite 資料庫熱備份
這是我最依賴的功能。觸發備份後,伺服器會使用 SQLite 的 VACUUM INTO 命令對所有核心資料庫進行物理打包。這種方式完全不阻塞線上的高頻讀寫,能生成極致安全的數據快照。隨後,系統會為快照生成隨機密碼並進行 zip 壓縮,自動切分成符合 Telegram 體積限制的獨立分卷,最後逐一發送到聊天界面。整個過程完全免去了配置第三方雲端儲存的繁瑣,數據物理文件直接掌握在自己手裡。
為什麼強烈推薦串聯 Cloudflare?
這套極簡維運方案之所以能安全且高效地運轉,很大程度上得益於 Cloudflare 在邊緣層提供的支援。強烈建議獨立開發者在構建類似系統時接入 CF,主要是因為本站實際用到了以下幾點核心能力:
1. WAF 規則徹底保護 Webhook 接口
把 Webhook 暴露在公網是非常危險的,每天都會面臨大量的惡意掃描。利用 Cloudflare 的 WAF 防火牆,我只需配置一條攔截規則,就能把所有非 Telegram 官方 IP 段的請求在邊緣節點直接丟棄。源伺服器根本不需要處理這些垃圾流量,極大地降低了被攻擊的風險。
2. 邊緣快取與 API 深度聯動
本站依賴全站快取來提高訪問速度。每次更新內容,單靠刷新 Next.js 自身的快取並不夠。Cloudflare 提供了完善的 API 服務,所以當我在 Telegram 執行
/revalidate 指令時,後端腳本會同步調用 CF 的接口,瞬間清空全球邊緣節點上的舊快取,確保用戶立刻看到最新內容。3. 基於 Workers 的邊緣流量攔截與維護頁渲染
當我透過機器人下發
/maintenance on 指令時,後端實際上是調用 Cloudflare API,動態激活了一條攔截全站請求的 Workers 路由。維護期間,所有的訪客都會由這個運行在邊緣節點的 Worker 直接接管,並由它渲染出維護提示頁。流量根本不會打到我的源伺服器上,確保了資料庫和底層程式碼升級時的絕對安全與從容。展望:將完整的控制台裝進聊天框
目前這套系統主要依賴人為下發指令來獲取資訊,在面對複雜的數據修改或突發狀況時,依然有進化的空間。在未來的規劃中,我準備將系統的能力進一步延伸:
1. 引入 Telegram Web Apps (Mini Apps)
Telegram 最新的生態允許在聊天界面內直接喚起 H5 應用。我計畫針對一些低頻但結構複雜的系統配置(例如調整顯卡跑分映射規則、多語言翻譯微調),開發一個基於 MUI v7 的前端微面板。點擊機器人菜單後,直接在聊天框內彈出一個原生的 UI 界面進行可視化修改,改完即關,用完即走。
2. 異常主動報警與 AI 日誌分析
我希望未來賦予系統主動巡檢的能力。當系統檢測到突發的流量異常,或者伺服器拋出高頻的嚴重錯誤日誌時,不再需要我主動去查,而是由機器人第一時間推送報警。更進一步,我考慮在後台任務中接入大模型 API,讓機器人在推送錯誤堆疊的同時,直接附帶一份由 AI 生成的故障根因分析和修復建議,讓自動化維運變得更具前瞻性和「生命感」。
執行前檢查傳送者和指令權限。收到指令與完成任務是兩種狀態;快速確認不能讓人誤以為備份或查詢已成功。