民眾檢舉平台在連假被塞爆，多半不是運算能力不夠，而是上傳頻寬吃滿、長連線佔住、儲存空間用完這三件事之一。科技執法的後端系統裡，這個平台是最容易被低估的一塊——路口設備、AI 辨識、入案流程都寫進規格書了，對外收件的那個網頁卻常常只寫一句「應具備足夠承載能力」。等到四天連假一次湧進平日五倍的件數，民眾按下送出鍵等了十分鐘、回一個逾時錯誤，機關才發現「足夠」兩個字沒有人定義過。
這篇文章把承載量從一句形容詞變成四個可以算出來的數字，說明為什麼檢舉平台的瓶頸和一般網站不同，四種擴充機制各自要付什麼代價，高可用架構要寫進規格的量測點有哪些，以及連假前的壓力測試該怎麼測才有意義。
民眾檢舉平台的尖峰到底有多尖？四步算出四個數字
先講結論：承載量估算要從「月案件量」一路推到「尖峰時段的每秒進件數與同時上傳連線數」，中間有四個步驟，少算一步就會低估一個量級。直接問廠商「你們的平台可以撐多少人同時上線」是問不到答案的，因為對方也不知道你的案件長什麼樣。
以單一交通隊每月 1,000～20,000 件的實際落差來看，中間值大約落在每月 6,000 件。以這個數字往下推：
第一步｜日均：6,000 件 ÷ 30 天 = 每日約 200 件
第二步｜尖峰日：200 件 × 尖峰倍數 4 = 連假單日約 800 件
第三步｜尖峰時段：800 件 × 集中率 40% = 320 件，落在 4 小時內 → 每小時 80 件 ≈ 每 45 秒一件
第四步｜資料量：320 件 × 每件 2 支影片 × 每支 120 MB ≈ 76.8 GB／4 小時 ≈ 進站 44 Mbps（持續值）
四個步驟裡，第二步的尖峰倍數不要抄別人的。每個單位的檢舉來源結構不同——以路口違停為主、以行車紀錄器影片為主、或以特定專案活動為主，尖峰形狀完全不一樣。正確做法是把自己單位過去兩年的每日收件數拉出來，找出前十名的高峰日，除以同期日均，得到屬於自己的倍數。實務上案件量在連假後會出現數倍的跳升，但「數倍」到底是三倍還是八倍，只有自己的歷史資料答得出來。
第三步的集中率也一樣。民眾上傳檢舉的時間分布通常不是平均的，而是集中在晚間與收假前後。若手上沒有資料，先用 40% 落在 4 小時當保守起點，上線後再用實際資料修正。
為什麼瓶頸不是 CPU，而是上傳頻寬與長連線？
上面算出來的「每 45 秒一件」看起來低到不需要討論——任何一台入門主機每秒處理幾十個請求都不成問題。但檢舉平台的請求和一般網頁完全不同：它不是幾十毫秒就結束的短請求，而是一條會佔住好幾分鐘的長連線。
接續前面的例子。一件檢舉帶 2 支影片、合計約 240 MB，民眾家用或行動網路的上傳速率若以 5 Mbps 計算：
單件上傳耗時：240 MB × 8 = 1,920 Mb ÷ 5 Mbps ≈ 384 秒（約 6.4 分鐘）
同時上傳連線數：384 秒 ÷ 45 秒（進件間隔）≈ 8.5 條長連線
若尖峰再集中 3 倍：同時約 26 條長連線，每條佔住一個處理程序與一份暫存空間
這就是「每秒不到一件卻塞住」的成因：衡量檢舉平台的單位不是每秒請求數，而是同時在線的長連線數，以及每條連線佔住的頻寬、處理程序與暫存磁碟。共用型的網頁環境通常會限制單一帳號的並行處理程序數與單檔上傳大小，這兩個限制值往往在承載評估時被完全忽略。
四個實際會先撞到的限制值
- 單檔上傳上限：PHP 的
upload_max_filesize與post_max_size、網頁伺服器的LimitRequestBody，三者取最小值。任何一個沒調，民眾傳到 99% 才會被拒絕。 - 執行時間上限：
max_execution_time與max_input_time。上傳 6 分鐘的請求會被預設值直接中斷，而且錯誤訊息對民眾毫無意義。 - 暫存空間：上傳中的檔案先落在暫存目錄，26 條連線同時進行就是 6 GB 的瞬時佔用，暫存分割區滿了會連帶影響其他服務。
- 對外頻寬：44 Mbps 是持續值，瞬時尖峰可能到 130 Mbps。若機房頻寬沒有保證值，尖峰時就是和鄰居搶。
儲存成長是另一個常被漏掉的數字，而且它不會自己停下來。每月 6,000 件 × 240 MB ≈ 1.4 TB，一年約 16.5 TB。案件影像的保存年限一旦依規定訂為數年，儲存規劃就必須從第一天開始算，不能等到空間快滿了再處理——因為到那時要搬的已經是幾十 TB。
尖峰擴充有哪四種做法？各自的代價是什麼
知道瓶頸在哪之後，擴充的選項其實只有四種，差別在於「花錢」「花時間」還是「花架構改寫成本」。
| 做法 | 解決什麼 | 代價與限制 |
|---|---|---|
| 垂直擴充 升規格 |
CPU、記憶體、暫存空間不足 | 最快，但有上限，且升級通常要重啟。對「頻寬吃滿」型的瓶頸幫助有限。 |
| 水平擴充 加機器＋負載平衡 |
長連線數、對外頻寬 | 需要應用程式本身無狀態化（session 與上傳暫存要外置），舊系統改寫成本高。 |
| 佇列削峰 收件與處理解耦 |
後段辨識、比對、入案的處理積壓 | 要改流程與介面（民眾拿到的是受理編號而非即時結果），但改完之後尖峰只影響等待時間，不影響收件。 |
| 前端減量 分塊上傳與提前驗證 |
逾時中斷、無效檔案佔頻寬 | 需要前端開發工時；對已經寫死的舊表單要重做上傳元件。 |
四種裡面，佇列削峰對檢舉平台的效益通常最直接。原因是收件和處理的耗時差了一個量級：收件只要把檔案落地、寫一筆案件紀錄、回一個受理編號，幾秒內就能結束；而影像檢核、車牌辨識、車籍查詢、案件比對這些步驟，即使全自動也要數十秒到數分鐘。把兩者綁在同一個請求裡，等於讓民眾的瀏覽器等待整條流水線跑完——尖峰時必定逾時。解開之後，尖峰帶來的只是佇列變長、案件晚幾小時處理完，收件端不會掉件。這條流水線後段實際有哪些關卡，可參考科技執法一條龍全流程解析；把人工入案改成自動化之後的處理量差異，則整理在民眾檢舉爆量與自動化入案。
前端減量的三個具體做法
- 先驗再傳：在瀏覽器端先檢查副檔名、檔案大小與影片長度，超過上限當場擋下並說明原因，不要讓民眾傳完才被伺服器拒絕。
- 分塊上傳與續傳：把大檔切成數 MB 的區塊逐塊送出，單塊失敗只需重送該塊。行動網路切換基地台造成的中斷，靠這一項就能救回大半。
- 即時進度與明確錯誤：沒有進度條的上傳，民眾會以為當掉而重複送出，反而製造更多重複案件與更多頻寬消耗。
高可用架構要寫進規格的四個量測點
「高可用」在規格書裡若只寫成一個百分比，驗收時雙方一定各自解讀。要能認定，至少得補上四件事。
一、稼動率要換算成分鐘，並寫清楚量測方式。以三十天一個月計算，各級距的可中斷時間差距是這樣的：
| 稼動率 | 每月可中斷 | 每年可中斷 |
|---|---|---|
| 99% | 約 7.2 小時 | 約 3.65 天 |
| 99.5% | 約 3.6 小時 | 約 1.83 天 |
| 99.9% | 約 43.2 分鐘 | 約 8.76 小時 |
| 99.95% | 約 21.6 分鐘 | 約 4.38 小時 |
百分比後面多一個 9，成本可能翻倍。真正要寫進規格的是配套條件：量測週期是月還是年、計畫性維護時段是否計入、以及以哪一方的監測資料為準。三項沒寫清楚，99.9% 只是一個數字。
二、單點故障要逐層盤點。對外網路、負載平衡器、應用層、資料庫、檔案儲存，五層各問一句「這一層壞掉會怎樣」。實務上最常見的疏漏是：應用層做了兩台，資料庫卻只有一台；或負載平衡器本身沒有備援，結果它成了新的單點。
三、RPO 與 RTO 要分開寫。RPO 是「可以接受掉多少資料」，RTO 是「多久要復原」。只做每日備份，代表最壞情況下會掉掉將近一整天份的案件——對民眾檢舉平台來說通常不可接受，需要再加上資料庫交易日誌或近即時複寫。而 RTO 要能成立，必須做過還原演練並留下紀錄；沒演練過的備份，只能算是一份還沒驗證的檔案。
四、降級策略要事先定義。尖峰扛不住時，系統該保住什麼、可以先關什麼，應該在規格階段就講好。檢舉平台的優先序通常很清楚：收件優先於查詢，查詢優先於統計報表。把耗資源的全文查詢與報表產製在尖峰時段暫時停用，讓收件端維持可用，比整個平台一起倒下要好得多。這類主機層的可用性設計與資安要求如何一併寫進採購文件，另可參考警政系統上雲與資安規範解讀，以及智慧警政採購指南裡的評選標準。
連假前壓測什麼？上線後盯哪五個數字
壓力測試最常見的錯誤，是拿空白的 GET 請求去打首頁，然後宣稱「每秒可承受三千次請求」。那個數字和檢舉平台的實際負載沒有關係。有意義的壓測要滿足三個條件：
- 要帶真實附件。模擬的請求必須包含與實際案件相同量級的影片檔上傳，否則測到的只是網頁伺服器的靜態回應能力。
- 要在同規格環境跑。在開發機上測出來的數字不能外推到正式環境，兩者的磁碟、頻寬與並行限制值都不同。若無法在正式環境測，至少要用同規格的複本。
- 要持續足夠長的時間。測一分鐘的瞬時峰值沒有意義，因為暫存空間、佇列積壓、資料庫連線數這些問題都是累積出來的。至少要模擬完整的尖峰時段長度。
上線之後，把監看收斂成五個數字就夠用了：
檢舉平台上線後要盯的五個數字
- 收件成功率：以「檔案已落地且已回覆受理編號」為成功的定義，不是伺服器回了 200 就算。
- 上傳中斷率：開始上傳卻沒有完成的比例。這個數字上升，通常是逾時設定或行動網路品質問題，不是主機負載。
- 佇列積壓件數與最久等待時間：只看件數會誤判，要同時看最久的那一件等了多久，才知道是暫時性尖峰還是處理能力真的不足。
- 儲存剩餘天數：用「剩餘空間 ÷ 近 7 日平均日增量」換算成天數，比看剩餘百分比有用得多——剩 20% 可能只代表還剩四天。
- 回應時間的 95 百分位：平均值會被大量快速的靜態請求稀釋，看 95 百分位才看得到真正在痛的那一群使用者。
告警門檻要設在「還來得及反應」的位置，而不是「已經出事」的位置。儲存剩餘天數低於 30 天就該告警，等到剩 3 天才通知，採購與擴充根本來不及。
案件量會隨著取締點位增加、宣導活動、以及民眾使用習慣改變而持續變動，一次估算撐不了三年。務實的做法是把上面五個數字納入每月維運報表，每季用實際資料回頭校正尖峰倍數與集中率，並在每次新增點位或推動專案活動前，重算一次尖峰承載。承載規劃的價值不在算得多精準，而在於它讓「不夠用」這件事提前幾個月被看見。
瑪尼國際深耕資訊服務 20 年、服務逾 500 家企業，並以協力廠商身分參與全台多個縣市警察局交通隊的入案系統建置與維運。從對外檢舉平台的收件層、佇列與辨識後段，到主機規格、保證頻寬與長期網站代管，都在同一個技術體系內完成——出問題時只有一個窗口要找，這是一條龍服務對機關最實際的價值。對外的成效公開頁面與宣導網站網頁設計也可納入同一案處理。系統的完整技術規格與資安設計，請見智慧警政科技執法系統方案頁；主機採用中華電信光纖機房、不鎖頻寬，尖峰時段的進站頻寬不會被隔壁的流量吃掉。
常見問題
Q：民眾檢舉平台的尖峰承載該怎麼估算？
用四個步驟往下推，不要直接問廠商「你們可以撐多少人」。第一步，把月案件量除以三十得到日均件數；第二步，用自己單位過去連假的實際件數回推尖峰倍數，不要套別人的係數；第三步，估算當日案件集中在幾個小時內送出，換算成每小時與每秒進件；第四步，把每件的附件大小乘進去，得到進站頻寬與每月儲存成長。四個數字算完，才有辦法判斷規格夠不夠。
Q：民眾檢舉平台連假爆量，主機該用雲端還是自建機房？
先問架構、再問機房。如果收件與辨識沒有解耦，尖峰時放在哪裡都會塞；如果已經用佇列把收件和後續處理拆開，收件層需要的是可快速增減的運算資源，後段的辨識與入案則可以維持固定規格慢慢消化。實務上常見的做法是混合：對外收件層放在可水平擴充的環境，資料庫與案件儲存放在規格固定、頻寬有保證的機房，兩者之間用佇列銜接。
Q：科技執法的檢舉平台要求 99.9% 稼動率，實際代表什麼？
以三十天一個月計算，99.9% 代表每月允許中斷約 43.2 分鐘，99.5% 是 3.6 小時，99% 則放寬到 7.2 小時。差別看起來只有小數點，換算成分鐘就是十倍差距。規格書要一併寫清楚三件事：量測週期是月還是年、計畫性維護時段算不算進去、以及由誰的監測資料為準，否則同一個百分比雙方各自解讀，驗收時無從認定。