微物联研究院
# 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 周）为产品能力口径，实际提前量受数据质量与工况影响。招投标与合同验收条款应单独约定，以书面协议为准。