第一層：官方 API 取數
以 UniFi 官方 API 讀取裝置活動記錄、告警及狀態，不需要在客戶網絡安裝 agent，也不需要開放入站端口。
技術白皮書
以 UniFi 官方 API 與 GNS AI 數據分析建立託管服務
本文說明 GNS CARE 的運作方式：透過 UniFi 官方 API 讀取裝置活動記錄，經加密通道送到我們的雲端平台，再以 SIEM 及異常偵測持續比對設備基線，在硬件故障前介入。內容涵蓋技術架構、與香港傳統 IT 保養服務的分別、實際好處，以及外國市場的公開做法。
監控的目的不是事後記錄故障，而是在故障發生前發現它。
- 傳統保養在故障後才回應；我們以 API 遙測持續比對基線，於故障前安排維修或更換
- 不需要在客戶網絡安裝 agent，也不需要開放入站端口
- 記錄加密傳送，只有獲授權的工程師可以查看
- 同一套做法覆蓋 UniFi 網絡、CCTV、門禁及對講
摘要
傳統的 IT 保養服務以回應為本：客戶報修，服務商上門，而問題已經發生。這種模式在硬件密度低、系統互不相關的年代仍然可行；但當一間公司同時依賴 Wi-Fi、CCTV、門禁及對講運作，一次故障就足以令營運停頓。
本文說明的託管模式改用另一個起點：先取得設備的活動記錄，再比對基線。我們透過 UniFi 官方 API 讀取裝置記錄，經加密通道送到自家雲端平台，先由 SIEM（security information and event management）作 24/7 事件關聯，再交由我們自行開發的 AI 平台接手分析。AI 平台把關聯結果與每部裝置的長期基線一併運算，自動指出哪些裝置即將故障、建議可以怎樣改善設定或擺位，並在硬件真正失效之前排出更換次序。當硬碟、供電、連線或無線覆蓋開始偏離正常，我們在客戶察覺之前已經收到訊號，並主動安排維修或更換。
本文涵蓋：
- 香港傳統 IT 保養模式的三個結構性限制
- 傳統上門保養、一般遙距監控與 GNS CARE 的比較
- 我們的五層技術架構
- 每一類裝置經官方 API 實際讀到的欄位
- 客戶如何把裝置加入 GNS 託管名單
- 由簽約到恆常託管的工作流程
- 對企業的六項實際好處
- 外國市場的公開做法
- 常見問題
問題所在
傳統 IT 保養模式的三個結構性限制
以下三點與服務商的技術水平無關，而是「回應式」模式本身的限制。
-
只會在故障後才開始
回應式保養的觸發點是客戶的報修電話。在電話之前，服務商對設備狀態一無所知；在電話之後，時間已經用在復原，而不是預防。
-
只看得到「這一刻」
上門檢查是一張快照：當時能開機、能連線，就算通過。硬碟的讀寫錯誤、供電的電壓波動、無線裝置的漫遊失敗，都不會出現在這張快照裡。
-
保養與工程分家
硬件由一家供應商保養，網絡由另一家維護，紀錄分散在各處。當問題跨過兩個介面，時間就花在協調，而不是修復。
模式比較
傳統上門保養、一般遙距監控、GNS CARE
三種模式的分別不在價錢，而在「何時發現問題」，以及「憑甚麼決定更換」。
| 服務內容 | 傳統上門保養 按次收費 | 一般遙距監控 只看即時告警 | GNS CARE API 遙測 ＋ SIEM |
|---|---|---|---|
| 取數方式 | |||
| 資料來源 | 傳統上門保養 只靠現場檢查 | 一般遙距監控 裝置即時狀態 | GNS CARE 官方 API 讀取裝置活動記錄 |
| 要在客戶網絡安裝 agent | 傳統上門保養 不需要 | 一般遙距監控 通常需要 | GNS CARE 不需要（以官方 API 直讀） |
| 資料保留 | 傳統上門保養 只有工單紀錄 | 一般遙距監控 短期 | GNS CARE 長期保留，可作趨勢比對 |
| 發現問題的時機 | |||
| 觸發點 | 傳統上門保養 客戶報修 | 一般遙距監控 即時數值超出門檻 | GNS CARE 基線偏移 |
| 硬碟健康 | 傳統上門保養 故障後才知道 | 一般遙距監控 只看即時數值 | GNS CARE 追蹤趨勢，提早安排更換 |
| 跨裝置事件關聯 | 傳統上門保養 不包括 | 一般遙距監控 不包括 | GNS CARE 已包括 |
| 檢查頻率 | 傳統上門保養 每年或每次報修 | 一般遙距監控 24/7 告警 | GNS CARE 24/7 關聯分析及每月報告 |
| 處理及紀錄 | |||
| 更換決定 | 傳統上門保養 故障後更換 | 一般遙距監控 收到告警後安排 | GNS CARE 故障前安排（全面級 24 小時內換機） |
| 每月書面報告 | 傳統上門保養 不包括 | 一般遙距監控 部分提供 | GNS CARE 已包括 |
| 可供稽核的事件紀錄 | 傳統上門保養 不包括 | 一般遙距監控 不包括 | GNS CARE 已包括 |
技術架構
五層架構：由裝置記錄到預判換機
每一層都刻意避開「在客戶網絡放入第三方軟件」這個做法。
第二層：加密傳輸
記錄經加密通道傳送到我們的雲端平台，傳輸及儲存均以加密處理，只有獲授權的工程師可以查看。
第三層：自家雲端平台
由我們自己營運的雲端平台集中存放遙測資料，客戶之間互相隔離，並保留趨勢比對所需的歷史資料。
第四層：SIEM 及異常偵測
SIEM 把不同裝置的事件關聯起來，異常偵測則比對每部裝置的長期基線；兩者同時命中，才會成為一個待處理的訊號。
第五層：自家 AI 平台
由我們自行開發的 AI 平台接手分析：把 SIEM 的關聯結果與每部裝置的長期基線一併運算，自動指出即將故障的裝置、排出更換先後，並提出可以改善的設定或擺位建議。
官方 API 取數範圍
每一類裝置，我們實際讀到甚麼
以下欄位全部取自 Ubiquiti 官方開發者文件（Network API v10.4.57、Protect API v7.3.60、Site Manager API v1.0.0），不是自建 agent，也不是推測。前五類每類至少十項；官方未公開的類別，我們如實列在最後一項。
-
無線存取點（Wi-Fi）— Network API
裝置身份及狀態：id、name、model、macAddress、ipAddress、state（ONLINE、OFFLINE、UPDATING、CONNECTION_INTERRUPTED 等）、firmwareVersion、firmwareUpdatable、supported、interfaces（ports／radios）。無線電：channel、channelWidthMHz、frequencyGHz、wlanStandard。即時統計：cpuUtilizationPct、memoryUtilizationPct、uptimeSec、loadAverage1Min／5Min／15Min、lastHeartbeatAt、nextHeartbeatAt、uplink。
-
閘道器及防火牆 — Network API 加 Site Manager API
裝置：id、name、model、macAddress、ipAddress、state、firmwareVersion、firmwareUpdatable、supported、adoptedAt、configurationId、provisionedAt、uplink。即時統計：cpuUtilizationPct、memoryUtilizationPct、uptimeSec、loadAverage1Min／5Min／15Min、lastHeartbeatAt、nextHeartbeatAt。防火牆規則：action、source、destination、ipProtocolScope、connectionStateFilter、ipsecFilter、loggingEnabled、schedule、enabled、index。Site Manager 主機：hardwareId、type、owner、isBlocked、registrationTime、lastConnectionStateChange、latestBackupTime、reportedState。ISP 線路：avgLatency、maxLatency、packetLoss、uptime、downtime、download_kbps、upload_kbps、ispName、ispAsn。
-
交換機 — Network API
裝置：id、name、model、macAddress、ipAddress、state、firmwareVersion、firmwareUpdatable、supported、interfaces。端口：idx、connector、state、speedMbps、maxSpeedMbps。PoE：enabled、standard、state、type（並可發出 POWER_CYCLE 指令為單一端口重新供電）。堆疊及聚合：switching/lags、switching/switch-stacks、switching/mc-lag-domains。即時統計：cpuUtilizationPct、memoryUtilizationPct、uptimeSec、loadAverage1Min／5Min／15Min。
-
監控鏡頭 — Protect API
身份及狀態：id、name、modelKey、type、guid、mac、state。影像：videoMode、hdrType、activePatrolSlot。畫面文字：osdSettings（isNameEnabled、isDateEnabled、isLogoEnabled、isDebugEnabled、overlayLocation）。指示燈：ledSettings（isEnabled、welcomeLed、floodLed）。收音：isMicEnabled、micVolume。智能偵測：smartDetectSettings（objectTypes、audioTypes）。能力旗標：featureFlags（hasHdr、hasMic、hasSpeaker、hasLedStatus、supportFullHdSnapshot、videoModes）。另有 lcdMessage 及 hasPackageCamera。可執行：snapshot 截圖、rtsps-stream 串流、ptz/goto 預設位、talkback-session 對講。
-
錄影主機（NVR）— Protect API
身份及狀態：id、name、modelKey、type、guid、mac、state。佈防：armMode（status、armProfileId、armedAt、willBeArmedAt、breachDetectedAt、breachEventCount、breachTriggerEventId、breachEventId）。門鈴設定：doorbellSettings（defaultMessageText、defaultMessageResetTimeoutMs、customMessages、customImages）。事件推送：/v1/subscribe/events 逐條推送（motion、smartDetectZone、smartDetectLine、smartDetectLoiter、smartDetectAudio、nfcCardScanned、fingerprintIdentified 等）；/v1/subscribe/devices 推送裝置新增、修改及移除。同一套 API 亦覆蓋 sensor、light、chime、siren、speaker、fob、relay、bridge、alarm-hub 及 link-station。
-
官方未公開的類別：門禁及對講、NAS、線材配件
Ubiquiti 開發者平台目前只發布 Network、Protect、Site Manager（另有 mobility、innerspace、carrier-fabric），門禁及對講（Access／Talk）沒有公開 API。所以讀卡機及對講機在我們的遙測裡，只會以「已連接客戶端」及「交換機 PoE 端口」的形式出現：macAddress、ipAddress、type、connectedAt、uplinkDeviceId、port state、speedMbps、maxSpeedMbps，以及 PoE 的 enabled／standard／state／type。
你的裝置如何加入 GNS 託管名單
託管由一次授權開始，過程約十分鐘，不需要在你的網絡安裝任何第三方軟件，也不需要開放對外入站端口。
- 你在 UniFi Site Manager 以「加入管理團隊」方式邀請 GNS 的帳戶。
- 你在 UniFi 介面確認邀請。
- GNS 帳戶隨即出現在你的組織成員名單，權限由你設定。
- 我們的平台以官方 API 讀取裝置清單及活動記錄，記錄第一次基線。
- 讀到的資料只經加密通道送到我們的雲端平台，與其他客戶互相隔離。
- 你隨時可以在同一個畫面移除 GNS；移除之後，我們即刻失去讀取權。
六個步驟的實際介面畫面，見託管服務中心「讓 GNS 加入你的 UniFi 管理團隊」：看六步流程。
實施流程
由簽約到恆常託管
首月是建立基線的關鍵期；基線未穩定之前，告警門檻仍在調整。
-
現場評估及基線記錄
檢視場地、設備清單及現有設定，記錄每部裝置的初始狀態，作為日後比對的基線。
-
接管及設定遙測
接管 UniFi 管理權限，開啟官方 API 取數及加密傳輸，設定告警門檻及通知路徑。
-
首月觀察期
密集檢視告警並調整門檻，減少誤報；同時處理積壓的韌體及設定問題。
-
恆常託管
每月提交報告，並按級別跟進硬件健康、事件處理及需要上門的更換安排。
實際好處
對企業的六項實際好處
好處不在於「有監控」，而在於問題被發現的時間點。
減少非計劃停機
問題在變成故障前已被安排處理；即使硬件最終失效，更換亦已預先安排，而不是等到收銀或門禁停頓才開始。
延長硬件壽命
硬碟、風扇及供電的損耗可以在趨勢中看到，更換時機由狀態決定，而不是由故障決定。
保安事件更早浮現
裝置記錄被關聯分析，異常登入、非預期設定變更及新裝置上線都會留下紀錄。
預算可預測
月費固定、按裝置端點計算；硬件故障的處理費用不會突然出現在某一季的帳目上。
可供稽核的紀錄
設備、事件及處理過程均有紀錄；加購安全加固另設每月安全審核報告，方便回覆管理層、審計、合規或客戶查詢。
AI 指出成因，並建議改善做法
AI 平台不只用來告警：它會同時指出成因與可行的改善做法（例如調整擺位、把高流量裝置分開、更換損耗中的硬碟），令每次介入都同時降低下一次故障的機會。
外國市場
外國市場的公開做法
以下幾點是公開資料可以查證的行業做法，並非客戶個案；本地項目參考可在現場評估時提供。
-
以 RMM 平台作為託管核心
北美及歐洲的託管服務商（MSP）以 RMM（remote monitoring and management）平台作為服務核心，集中讀取客戶設備的狀態與告警，公開的供應商包括 Datto、N-able、Kaseya 及 Auvik。這種做法在當地屬於標準配置，而不是增值選項。
-
官方 API 取數逐漸取代 agent
近年設備供應商陸續提供官方 API，讓服務商直接讀取遙測資料，減少在客戶網絡安裝常駐軟件。我們採用的 UniFi 官方 API 屬於同一方向。
-
「每裝置每月」定價
澳洲、英國及美國的託管服務普遍以每裝置每月（per-device per-month）定價，把預防性維護、更新及支援包在一個固定月費內，而不是逐次上門收費。GNS CARE 的計價方式與此一致。
-
停機成本與預防性維護的差距
多份公開的行業研究（例如 Uptime Institute 的年度停機分析）都指出，非計劃停機的每小時成本遠高於預防性維護的支出。這是託管模式在歐美普及的主要原因。
資料來源及說明
本文引用的第三方資料均為公開資料，只作行業背景說明。
- Ubiquiti 官方開發者平台及 API 文件：Network API v10.4.57（developer.ui.com/network/v10.4.57）、Protect API v7.3.60（developer.ui.com/protect/v7.3.60）、Site Manager API v1.0.0（developer.ui.com/site-manager/v1.0.0）；本文所列欄位以 2026 年 9 月版本為準
- Ubiquiti 官方支援文件：help.ui.com
- Uptime Institute：年度停機分析
- RMM 供應商公開產品文件：Datto、N-able、Kaseya、Auvik
- CompTIA：MSP 行業社群及公開報告
本文所載的服務範圍、月費及 SLA，以正式報價單為準。
常見問題
關於託管模式及這份白皮書
以下是客戶在評估託管服務時最常提出的問題。
GNS CARE 託管與一般 IT 保養服務有何分別？
傳統保養在故障後才開始，我們在故障前介入。我們以 UniFi 官方 API 持續讀取裝置活動記錄，送到自家雲端平台，由 SIEM 作 24/7 關聯分析並比對每部裝置的長期基線；當硬碟、供電或連線開始偏離正常，我們會主動安排維修或更換，而不是等收到報修電話。
SIEM 是甚麼？為何需要它？
SIEM 是 security information and event management，用來把來自不同裝置的事件集中起來並找出關聯。單一告警可能只是雜訊，但當同一時間出現多次登入失敗、設定變更及新裝置上線，關聯分析就會顯示這是一個需要處理的事件，而不是三件獨立小事。
你們以 API 取數，會讀到我們的業務資料嗎？
API 只讀取 UniFi 管理層面的資料：裝置狀態、活動記錄、告警及設定。託管服務無需接觸檔案、電郵或業務系統，亦不會讀取 CCTV 畫面內容；我們取得的是設備健康及事件紀錄。記錄經加密傳送，只有獲授權的工程師可以查看。
需要在我們的網絡安裝軟件或開放端口嗎？
不需要。我們以 UniFi 官方 API 直接讀取資料，所以不需要在客戶網絡安裝 agent，也不需要開放入站端口；這亦減少了託管服務本身帶來的攻擊面。
如果一直沒有異常，月費是否白付？
月費購買的是「持續比對」及「已經準備好的處理能力」：裝置基線、告警門檻、更新排程、事件紀錄及 1 小時內回應的承諾，都在沒有故障的日子累積。沒有故障的月份，正是這套機制在運作的結果。
異常偵測會不會經常誤報？
首月觀察期的作用正是調整門檻。我們以每部裝置的長期基線作比對，而不是單一固定數值，並由工程師確認後才安排上門；兩者同時命中才會成為一個待處理的訊號。
為何最少要簽 12 個月？
趨勢比對需要歷史資料：硬碟、供電及無線覆蓋的偏移，通常要數個月才看得出方向。首月建立基線、其後累積趨勢，12 個月是能夠真正比較「有託管」與「無託管」的最短週期。月費固定，合約期滿後按月續期。