honghulabs 內部策略文件 · 由本地大模型 Qwen3-235B-A22B 生成(8×RTX PRO 6000 @ SGLang)· 草稿待校
機隊韌性與風險管理策略
鴻虎科技（honghulabs）內部策略文件
負責人：蔡長明
擬定日期：2025年4月5日
擬定人：首席策略顧問
一、礦池單點故障（Stratum 中斷）
1. 偵測
- 自動監控：每台挖礦機部署
vastai-monitor + 自定義腳本，每 30 秒檢查： - 是否收到 Stratum
mining.notify； - 最近 2 分鐘有無有效 share 上報；
- 網路連線至礦池端口（
nc -z 測試）。 - 集中告警：異常觸發後，立即透過 Webhook 通知 Slack + 手機 Dashboard（gpu.earth）。
目標：90 秒內發現中斷，誤報率 < 1%。
2. 處置
- 自動切換流程（LuckyPool 優先）：
- 檢測到中斷 → 觸發切換腳本；
- 停止當前挖礦進程（
kill -15）； - 切換至預設備援礦池（LuckyPool / HeroMiners）；
- 重啟挖礦進程，使用機器唯一識別碼（MAC/IP）自動載入對應帳號；
- 發送切換成功通知。
- 備援順序：LuckyPool（主）→ HeroMiners（備）→ A20 自建 stratum（未來規劃，見下）。
目標：切換時間 ≤ 3 分鐘，損失挖礦時間 < 5 分鐘。
3. 預防
- 多礦池註冊：所有機器預先在 LuckyPool、HeroMiners 完成註冊與驗證。
- 未來建設：2025 Q3 前，於 A20 Research 內部部署 自建 stratum proxy（基於
stratum_proxy 或 eth-proxy），統一對接多個上游礦池，實現「虛擬多活」。 - 監控強化：每週模擬一次 stratum 中斷演練。
二、GSP 韌體卡死（Xid 154: Node Reboot Required）
1. 偵測
- NVIDIA DCGM 監控：
- 部署
dcgmi + Prometheus，監控 Xid Errors（特別是 Xid 154）； - 每 15 秒採集一次 GPU 狀態。
- 異常指標：
- GPU Util = 0% 但功耗 > 50W（疑似卡死）；
nvidia-smi 無回應或 timeout；- DCGM 持續報告 Xid 154 ≥ 1 次。
目標：120 秒內偵測卡死，誤報率 < 2%。
2. 處置
| 等級 | 判定條件 | 處置方式 | 負責人 |
|---|
| L1（軟卡死） | nvidia-smi timeout，但 IPMI 可 ping | 自動觸發 IPMI 冷重啟（ipmitool chassis power cycle） | 系統自動 |
| L2（硬卡死） | IPMI 無回應，BMC 可訪問 | 手動登入 BMC 強制 power off → on | 維運團隊 |
| L3（硬體死亡） | 重啟後 GPU 不識別、Xid 持續報錯 | 標記 RMA，隔離機台 | 蔡長明決策 |
- 遠端冷重啟工具鏈：
- 使用
Redfish API（AMI MegaRAC BMC）自動執行； - 腳本驗證 MAC 與 BMC 對應關係，避免誤操作。
目標：L1 問題 5 分鐘內自動恢復，L2/L3 30 分鐘內人工介入。
3. 預防
- 韌體管理：
- 所有機器 GSP firmware 升級至最新穩定版（≥ 555.44）；
- 每月執行一次「預防性重啟」（非高峰時段）。
- 負載調控：
- 挖礦時限制 GPU P0 功率（如 90% TDP），避免 GSP 過載；
- AI 推理時啟用
--disable-cuda-graph（已驗證有效）。 - 硬體篩選：新購機優先選擇 GSP firmware 穩定批次（如 Dell/HP 出廠卡）。
三、硬體折舊與 RMA 流程
1. 偵測
- 折舊追蹤系統：
- 每台機器建立「硬體生命週期表」，包含：
- 購入日期、成本、預期壽命（5090: 24 個月；Pro 6000: 36 個月）；
- 累計運轉小時、溫度曲線、Xid 錯誤次數。
- RMA 觸發條件：
- 同一 GPU 出現 ≥ 3 次 Xid 154 / 60 天內；
- GPU 修復成本 > 新購 30%；
- 效能下降 ≥ 15%（對比基準）。
2. 處置
- RMA 標準流程：
- 標記故障機，從負載排程中移除；
- 備份 BMC 設定與網路配置；
- 執行「非破壞性資料清除」（
dd if=/dev/zero of=/home/user，保留系統）； - 送修或更換；
- 新機上線前執行 burn-in 測試（72 小時 stress test）。
目標：RMA 停機時間 ≤ 7 天（含物流）。
3. 預防
- 折舊預算：
- 每季提列「硬體更新基金」，金額 = 當前機隊總成本 × 8% ÷ 4；
- 專戶儲存，不得挪用。
- 延壽策略：
- Pro 6000 機組維持機房溫度 ≤ 22°C；
- 挖礦機組每週清灰一次（自動提醒）；
- 所有機器使用模組化電源（易更換）。
四、租戶資料保全
1. 偵測
- 存取監控：
- 所有租用機部署
auditd + fail2ban，監控： - 非授權 SSH 登入；
sudo 使用記錄；- 檔案系統異常寫入（特別是
/home）。 - 資料完整性：
- 每次回收前，自動執行
rsync --dry-run 比對租戶資料快照。
2. 處置
- 回收流程標準化：
- 停止租戶容器/服務；
- 自動備份至
s3://honghulabs-tenants/（加密，保留 90 天）； - 發送備份完成通知給租戶；
- 本地資料標記「待清除」，不立即刪除；
- 7 天後執行
shred -n 3 -z 安全擦除。
目標：資料誤刪率 = 0，租戶滿意度 ≥ 95%。
3. 預防
- 租戶隔離：
- 使用 Docker + cgroups 限制資源；
- 每租戶獨立 UID，禁止 root access；
- 網路隔離（VLAN 或 firewall rule）。
- 合約條款：
- 明訂「資料備份非義務」，但提供付費長期儲存選項。
五、公開連結與遠端管理資安
1. 偵測
- 暴露面監控：
- 使用
nmap 每日掃描對外 IP，確認僅開放必要 port（22, 443, 8443）； cloudflared tunnel 日誌分析，偵測異常連線（如非蔡總常用 IP）。- 入侵偵測：
- 部署
OSSEC，監控： - 多次登入失敗；
- 異常 process（如
minerd 在非挖礦機）； - cron job 變更。
2. 處置
- 自動阻斷：
fail2ban 自動封鎖異常 IP（15 分鐘 → 永久，依次數）；- 發現 reverse shell 立即斷網 + BMC power off。
- 應變流程：
- 切斷 cloudflared tunnel；
- 啟用備用管理通道（4G USB modem + Tailscale）；
- 從乾淨備份重建系統。
目標：入侵平均發現時間（MTTD）< 10 分鐘，平均修復時間（MTTR）< 60 分鐘。
3. 預防
- 最小權限原則：
- SSH 僅允許 key login，禁用密碼；
sudo 使用需雙因素（TOTP）；- BMC 設定獨立帳號，不與 OS 共用。
- Tunnel 安全：
cloudflared 僅暴露 Dashboard 與 Open WebUI；- Open WebUI 啟用帳號密碼（bcrypt）+ rate limit。
- 定期滲透測試：每季委外執行一次。
最該優先補強的三個缺口（Gap Closure Priority）
| 優先序 | 缺口描述 | 影響 | 解決方案 | 預計完成