Stop Managing Alarms: An Incident-First Blueprint for Telecom AIOps
Stop Managing Alarms: An Incident-First Blueprint for Telecom AIOps
停止管理告警：电信 AIOps 的“事件优先”蓝图
Authors: Amir Hossein Karami and Hamed Tahmooresi 作者：Amir Hossein Karami 和 Hamed Tahmooresi
At national-operator scale, the most expensive operational failure is not an outage. It is treating every symptom of an outage as a separate problem. 在国家级运营商规模下，最昂贵的运营故障并非宕机本身，而是将宕机的每一个症状都视为一个独立的问题来处理。
Consider a fiber cut. It can produce a flood of downstream alarms across routers, transport links, base stations, probes, service KPIs, and customer-care channels. A conventional NOC sees hundreds of red tiles. An effective operations system sees one evolving incident, estimates its customer and SLA impact, identifies the most plausible upstream cause, and either executes a proven low-risk repair or gets the right human on the case immediately. 以光缆中断为例。它会引发路由器、传输链路、基站、探针、服务 KPI 和客户服务渠道中海量的下游告警。传统的网络运营中心（NOC）会看到数百个红色警示块。而一个高效的运营系统则能识别出一个正在演变的事件，评估其对客户和服务等级协议（SLA）的影响，确定最可能的上游原因，并立即执行经过验证的低风险修复，或直接将问题指派给合适的专业人员处理。
That is the practical shift behind modern telecom AIOps: from alarm-centric operations to incident-centric service assurance. It is especially consequential for operators serving tens of millions of subscribers, where alert fatigue quickly becomes a quality-of-service and leadership problem. 这就是现代电信 AIOps 背后的实践转变：从“以告警为中心”的运营转向“以事件为中心”的服务保障。对于服务数千万用户的运营商而言，这一点尤为重要，因为告警疲劳会迅速演变成服务质量和管理层面的难题。
The benchmark is a direction, not a vendor shopping list
基准是一个方向，而非供应商购物清单
Public evidence from large operators points in a consistent direction, while also showing why claims need careful handling. 大型运营商的公开证据指向了一个一致的方向，同时也表明了为何对相关声明需要谨慎对待。
China Mobile has publicly described moving packet-transport operations toward incident-centric management. A TM Forum case study reports a program that compressed approximately 600,000 daily alarms into about 600 incidents in a stated scenario. China Mobile’s more recent autonomous-NOC work emphasizes intelligent agents and closed loops. 中国移动已公开描述了其将分组传输运营转向“以事件为中心”的管理模式。TM Forum 的一份案例研究报告显示，在特定场景下，某项目将每天约 60 万条告警压缩为约 600 个事件。中国移动近期在自主 NOC 方面的工作则强调了智能体和闭环控制。
Airtel has published work on AI-based predictive maintenance, while its TM Forum transformation case study describes a data-driven shift toward service outcomes, RCA-enriched work orders, and automation. The transferable point is not a headline percentage; it is joining operations data with a workflow that can act before a service issue becomes customer-visible. Airtel 发布了关于基于 AI 的预测性维护工作，其 TM Forum 转型案例研究描述了向服务成果、根因分析（RCA）增强工单及自动化驱动的数据转型。其可借鉴之处不在于头条新闻中的百分比，而在于将运营数据与工作流相结合，从而在服务问题影响到客户之前采取行动。
Jio markets its ATOM platform around ML-enabled network analytics, RAN analysis, and anomaly detection. This is useful confirmation that anomaly detection belongs inside an operational platform, rather than as an isolated dashboard experiment. Jio 将其 ATOM 平台定位为基于机器学习的网络分析、无线接入网（RAN）分析和异常检测。这有力地证明了异常检测应集成在运营平台内部，而非作为孤立的仪表盘实验存在。
AT&T is a valuable customer-impact benchmark: its public AI work spans analytics and automation for network operations. The durable design lesson is to prioritize a technical event by the service and customer harm it can cause—not by device severity alone. AT&T 是一个极具价值的客户影响基准：其公开的 AI 工作涵盖了网络运营的分析与自动化。其持久的设计经验是：根据技术事件可能造成的服务和客户损害来确定优先级，而不仅仅是依据设备告警的严重程度。
Turkcell publicly demonstrates AI-oriented 5G and network-automation work, but detailed, independently verifiable descriptions of its internal alarm-correlation and RCA process are limited. Treat it as a strategic peer, not as evidence for unverified compression or MTTR figures. Turkcell 公开展示了面向 AI 的 5G 和网络自动化工作，但关于其内部告警关联和 RCA 流程的详细、可独立验证的描述有限。应将其视为战略同行，而非未经证实的压缩率或平均修复时间（MTTR）数据的证据。
This pattern is also aligned with the 2025 ITU-T M.3390, which defines requirements for AI-enhanced telecom operations spanning network-resource assurance, network-service quality, end-to-end service-quality analysis, and service-assurance strategy generation. 这一模式也与 2025 年发布的 ITU-T M.3390 标准相一致，该标准定义了 AI 增强型电信运营的要求，涵盖网络资源保障、网络服务质量、端到端服务质量分析以及服务保障策略生成。
Build an incident factory, not a louder dashboard
构建“事件工厂”，而非更吵闹的仪表盘
A useful architecture transforms raw signals through a sequence of increasingly meaningful objects: 一个有用的架构通过一系列意义递增的对象来转换原始信号：
The ordering matters. An LLM is not a replacement for deterministic event processing. It is much more reliable when it receives a compact incident record, topology context, prior resolved incidents, change history, and runbook evidence—rather than millions of unfiltered alarms. 顺序至关重要。大语言模型（LLM）不能替代确定性的事件处理。当它接收到精简的事件记录、拓扑上下文、既往已解决的事件、变更历史和操作手册证据时，其可靠性远高于接收数百万条未经筛选的告警。
1. Normalize before you model 1. 先标准化，再建模 Start with a canonical event and incident schema. Every incoming signal needs a stable identity, timestamp, source, object type, alarm family, severity, location, and correlation identifiers. Enrich it with live topology, inventory/CMDB ownership, service dependencies, maintenance windows, active changes, and business-service mappings. 从规范的事件和事故模式开始。每个传入的信号都需要一个稳定的标识、时间戳、来源、对象类型、告警类别、严重程度、位置和关联标识符。利用实时拓扑、资产/配置管理数据库（CMDB）归属、服务依赖关系、维护窗口、活动变更和业务服务映射来丰富这些数据。
This layer is not glamorous, but it determines whether later machine learning is trustworthy. A model cannot infer a correct root cause from an outdated topology graph or an event stream that cannot distinguish a child alarm from its parent. 这一层工作虽然枯燥，但它决定了后续机器学习是否可信。如果拓扑图过时，或者事件流无法区分父子告警，模型就无法推断出正确的根因。
2. Reduce noise with four explicit controls 2. 通过四种明确的控制手段减少噪音 Noise reduction should be explainable and measurable: 噪音减少过程应当是可解释且可衡量的：
- Exact deduplication: collapse repeated copies of the same alarm within a source-appropriate time window. 精确去重： 在适合源端的时间窗口内合并同一告警的重复副本。
- Flap control: group open/clear oscillations and notify only when persistence exceeds policy. 抖动控制： 对开启/清除的震荡进行分组，仅在持续时间超过策略阈值时才发出通知。
- Maintenance-aware suppression: silence expected symptoms during approved work, while retaining an audit trail and guarding against an unexpected impact spike. 维护感知抑制： 在批准的维护期间屏蔽预期症状，同时保留审计追踪，并防范意外的影响激增。
- Topology-aware aggregation: identify a likely upstream dependency and represent downstream symptoms as evidence within a single incident. 拓扑感知聚合： 识别可能的上游依赖，并将下游症状作为单一事件内的证据进行呈现。
Never discard raw evidence. Suppression is a presentation and workflow decision; original signals must remain queryable for RCA, audit, and model training. 切勿丢弃原始证据。抑制只是呈现和工作流层面的决策；原始信号必须保持可查询状态，以供 RCA、审计和模型训练使用。
3. Rank incidents by impact, confidence, and urgency 3. 根据影响、置信度和紧迫性对事件进行排序 Device severity is only one input. A practical score is a policy-controlled combination of service criticality, affected subscribers, SLA exposure, geographic blast radius, duration, revenue or risk, technical severity, recurrence, and RCA confidence. 设备严重程度只是输入之一。一个实用的评分应是策略控制下的综合指标，包含服务关键性、受影响用户数、SLA 风险敞口、地理影响范围、持续时间、收入或风险影响、技术严重程度、复发率以及 RCA 置信度。
The result should include an explanation: which service is affected, how many subscribers may be exposed, which dependency is implicated, what changed recently, and why this incident outranks the next one. Operators need the explanation to trust automation and to improve it. 结果应包含解释：哪个服务受到影响、多少用户可能受波及、涉及哪些依赖关系、近期发生了什么变更，以及为什么该事件的优先级高于其他事件。运营商需要这些解释来信任并改进自动化系统。
4. Treat RCA as ranked hypotheses, not false certainty 4. 将 RCA 视为排序后的假设，而非虚假的确定性 Real-time RCA works best as evidence fusion. Combine temporal order, dependency direction in the topology graph, KPI anomalies, alarms, logs, configuration changes, historical incident patterns, and customer complaints. Output the top hypotheses. 实时 RCA 作为证据融合效果最佳。结合时间顺序、拓扑图中的依赖方向、KPI 异常、告警、日志、配置变更、历史事件模式和客户投诉，输出排名靠前的假设。