微物联研究院
# 99.9%、警報壓縮 80%、MTTR 縮短 60%：太一文件指標的實用讀法
直接回答
結論：99.9% 資料接入成功率對應「資料不中斷」，警報壓縮 80% 對應「值班人員不再被無效警報淹沒」，MTTR 縮短 60% 對應「故障修復週期大幅下降」——這一組指標共同回答的不是「系統多先進」，而是「落地後你能省多少人力、少停多少電」。 它們是平台的企業揭露口徑，應結合現場基線來評估，而不是當作絕對承諾。
對專案業主和運維管理人員，這篇文章回答三個問題：第一，每個指標在業務上到底意味著什麼；第二，怎麼把指標換算成自己專案裡的人力與停電損失；第三，如何建立自己專案的基線，驗證這些指標是否兌現。文中以「某園區配電系統」的脫敏場景為例說明。
一、一組指標，三種承諾
太一平台對外揭露的系統指標可以歸成三類承諾：
| 指標 | 數值 | 對應承諾 |
|---|---|---|
| 資料接入成功率 | 99.9% | 資料連續性：採得上、傳得到、不中斷 |
| 警報壓縮比 | 80% | 資訊有效性：值班看到的是去重後的有效警報 |
| 端到端時延 | < 2 秒 | 響應速度：從現場到平台的延遲 |
| MTTR 縮短 | 60% | 處置效率：故障平均修復時間大幅下降 |
| 根因準確率 | 85%+ | 判斷品質：大部分警報能直接給出根因 |
| 場景定位精度 | L17-L18 | 定位能力：警報能定位到具體場景位置 |
| 級聯風險覆蓋 | 100% | 覆蓋面：已知級聯風險全部納入監控 |
業主在評估時最容易犯的錯是「逐個數好不好看」，但正確的讀法是：先想清楚自己專案最大的痛點是什麼，再找對應的指標——怕停電損失看 MTTR 與預警提前量，怕值班疲於奔命看警報壓縮，怕資料斷檔看接入成功率。
二、99.9% 資料接入成功率：對應「資料不中斷」
99.9% 意味著平均來看，1000 個資料點裡約 999 個能成功接入平台。對業務的意義在於監測的連續性：
- 分析有據：趨勢預測、壽命折算都依賴連續資料。接入成功率高，意味著 CUSUM 等演算法有足夠的資料點建立基準、識別漂移；接入中斷頻繁，任何預測都會退化成猜測。
- 警報不丟：漏報往往是因為模型漏判，而是資料根本沒上來。接入成功率高是從源頭降低漏報機率。
- 對運維的含義：平台介面上「採集正常率」這個數字長期穩定在 99.9% 量級，說明現場鏈路（感測器、閘道、網路）健康；一旦開始下滑，第一反應應是檢查鏈路，而不是懷疑演算法。
這個指標的正確用法是當「系統健康度儀表板」看，而不是當「承諾書」看。
三、警報壓縮 80%：對應「值班不被淹沒」
未做警報治理的系統有個典型症狀：一個隱患引發幾十條相似警報（同迴路多參數、同事件多測點重複上報），值班員的注意力被刷屏消耗，真正重要的警報反而被淹沒。警報壓縮 80% 的意思是：系統把相似、重複、可歸併的警報聚合處理，值班員最終看到的是原始警報量的約 20%。
它落到業務上有兩個直接價值：
- 人力可算：假設原來每天 1000 條原始警報需要盯，壓縮後約 200 條有效警報，值班人力與關注成本同比例下降。
- 重要警報顯形：聚合後，同源警報歸併成一條帶數量統計的警報（如「迴路 A 溫度警報×23」），值班員一眼看到的是問題而不是數字。
值得注意：警報壓縮不是為了「少報」，而是為了「報得準」。壓縮後該響應的仍然響應，區別在於響應的是歸併後的有效警報，而不是幾十條重複訊息。
四、MTTR 縮短 60%：對應「故障修復週期大幅下降」
MTTR（Mean Time To Repair，平均修復時間）衡量的是從故障發生到恢復的週期。縮短 60% 的意思是：同樣的故障，平均修復時間降為原來的約 40%。
MTTR 由幾個環節構成，平台在每一環都能起作用：
| MTTR 環節 | 平台作用 | 效果 |
|---|---|---|
| 發現 | 秒級警報+預警提前量 | 故障第一時間被發現，甚至提前發現 |
| 定位 | 場景標籤 L17-L18 + 根因準確率 85%+ | 直接指向哪個櫃、哪個迴路、什麼原因 |
| 處置 | 處置建議+分級時限 | 值班員按流程執行，不靠經驗猜 |
| 驗證 | 檢修後趨勢回驗 | 確認問題真正解決，不留尾巴 |
對業主最直觀的換算：假設一次故障跳閘平均造成 8 小時生產損失，修復時間縮短 60% 後，若故障間隔不變，年度非計劃停機損失大約也降為原來的 40%。 這個換算是方案彙報裡最有說服力的數字。
五、預警提前量：檢修窗口是最大槓桿
指標表裡沒有單列「預警提前量」，但它是整個平台最值錢的能力之一。天衍的 CUSUM 趨勢預警（S-02）能在漏電仍在安全範圍時提前 4-12 週預警；SAR 紅線在危險發生前直接攔截。這兩者共同改變的是處置方式的屬性：
- 沒有提前量：故障 = 非計劃停機 = 搶修 = 最大損失。
- 有提前量：故障 = 計劃性檢修 = 安排在負荷低谷 = 損失大幅縮小。
所以在向主管彙報時，不要只講「MTTR 縮短 60%」，要講「從搶修變計劃檢修」這件事本身的價值——計劃檢修的停電窗口可以選在生產低谷，單次損失可能差一個數量級。
六、企業揭露口徑：怎麼理解才不算過度承諾
這一組指標（99.9%、80%、60%、85%+、L17-L18、100%）是平台的企業揭露口徑，理解時把握三條原則：
- 用於理解量級，不用於合約承諾：它們描述的是平台在典型工況下的能力水準，不是針對某個具體專案驗收的保證值。招投標與合約中的驗收條款應單獨約定。
- 受現場條件影響：接入成功率取決於現場鏈路品質與維護，警報壓縮效果取決於警報源數量與相似度，MTTR 縮短還取決於運維制度與人員執行。
- 需要基線對照：判斷「縮沒縮短、壓沒壓住」，必須與自己專案改造前的基線比，而不是與數字本身比。
一句話：這些指標告訴你「好的平台能做到什麼水準」，但「你專案裡能兌現多少」要用你自己的資料去驗證。
七、在自己專案裡建立基線對照
要驗證指標是否兌現，建議在專案初期就建立三類基線：
| 基線 | 內容 | 作用 |
|---|---|---|
| 警報基線 | 改造前日均警報量、重複率、有效警報佔比 | 驗證警報壓縮是否成立 |
| 停機基線 | 改造前年度非計劃停機次數、平均時長、損失估算 | 驗證 MTTR 與提前量價值 |
| 資料基線 | 改造前資料完整率、鏈路故障頻率 | 驗證接入成功率提升 |
基線資料最好在改造前就採集一個月以上，形成「改造前 vs 改造後」的同口徑對比。有了基線，彙報時就不是「平台說 80%」而是「我們專案從日均 1200 條警報降到 260 條，壓縮 78%」，可信度完全不同。
八、指標怎麼用進方案彙報
把指標翻譯成業務語言，彙報層次建議是：
- 先講痛點：現在值班疲於奔命、停機損失大、資料斷檔——用自己專案的基線數字說話。
- 再講指標對應：警報壓縮 80% → 值班人力釋放；MTTR 縮短 60% → 停機損失下降；99.9% → 資料連續。
- 最後講機制：為什麼能做到——警報聚合、根因定位、趨勢預警這些機制，而不是指標本身。
記住一條彙報原則：指標是結果，機制才是原因。 講清楚「為什麼能做到 80%」，比反覆強調「我們有 80%」更有說服力，也更容易讓業主相信指標會兌現。
適用範圍與限制
本頁為 KD-0014 閱讀版。99.9%、警報壓縮 80%、端到端<2 秒、MTTR 縮短 60%、根因準確率 85%+、場景定位 L17-L18、級聯風險覆蓋 100% 等指標為微物聯全產品知識庫揭露的企業口徑，用於理解平台能力量級，不構成對具體專案的性能保證；實際效果受現場鏈路、警報源構成、運維制度與人員執行影響，需結合專案基線驗證。文中「某園區配電系統」與「日均 1200 條警報降到 260 條」為脫敏示例。預警提前量（如 CUSUM 提前 4-12 週）為產品能力口徑，實際提前量受資料品質與工況影響。招投標與合約驗收條款應單獨約定，以書面協議為準。