DevOps 遇上 AI:AIOps 摒弃炒作

多客科技

作者：微信文章






一份关于 AIOps 的务实指南——它是什么、它有哪些帮助，以及如何平稳地进行试点。本指南包含真实案例、自建与采购的视角，以及一个可运行的代码片段。


我曾经历过仪表盘时代：20 个标签页、200 张图表，以及一个从不休眠的寻呼机。随后，一场悄然的转变发生了。系统开始告诉我哪些事情是重要的——有时甚至能自行修复，而不是让我盯着图表看。这就是 AIOps (智能运维) 运行得当时的样子。它不是魔法，也不是营销噱头。它只是减少了噪音，加快了结果的产出。


01转变：从仪表盘到决策AIOps (智能运维) 利用统计学习和机器智能将遥测数据转化为实际行动：早期检测异常、关联相关事件、推荐修复方案，并在安全的情况下自动化无聊的部分。它不会取代工程师，而是增强他们的能力。说实话：一半的“事件”都是反复出现的烦恼。AIOps 的作用在于抑制这种“似曾相识”的感觉，并提升真正新颖事件的优先级。02AIOps 不是什么?

解决糟糕架构的灵丹妙药。

“让机器人运行生产环境。”

需要一个研究实验室才能运行的巨型模型。大多数成功都始于简单的统计数据和细致的反馈循环。

03它在你的技术栈中的位置把它想象成一个紧密的循环，而不是一个单体：

摄取 (Ingest)：日志、指标、追踪、事件、部署、特性标志。标准化 (Normalize)：一致的标签（服务、版本、区域）、统一的时间基准。学习 (Learn)：基线、季节性、跨信号的关联性。决策 (Decide)：抑制重复项、分组相关告警、根据影响范围确定优先级。行动 (Act)：路由到正确的待命人员、附加操作手册、或触发安全的自动化操作。改进 (Improve)：收集人工反馈（真/假阳性、修复说明）以进行再训练。

这个循环位于你的可观测性堆栈和 CICD (持续集成/持续交付) 旁边，而不是在其之上。04一个真正有效的五步试点方案

选择一个令人头痛的告警。 就是那个经常把人叫醒却很少真正重要的告警。从小处着手。集中上下文。 确保信号共享标签（服务、分片、提交）。没有一致的元数据，关联性就是空想。从统计学开始。 滚动基线、Z-score、Holt-Winters。如果这能减少噪音，你可能不需要复杂的模型。保持人工参与。 在默认开启之前，审查建议的抑制和自动修复措施。衡量影响。 跟踪告警的精确率/召回率、MTTA (平均确认时间)/MTTR (平均恢复时间)，以及——重要的是——待命人员的满意度。如果工程师没有睡得更好，那就说明它没有起作用。

05本季度可实现的快速胜利告警降噪 (Noisy alert suppression)关联服务和时间窗口内反复出现（flapping）的告警；将它们合并为一个工单，并包含统一的时间线和主要嫌疑。事件分诊和路由 (Incident triage and routing)利用近期部署、错误消息集群和所有权元数据，直接路由到能够修复它的团队，避免推诿（ping-pong）。容量（和成本）预测 (Forecasting capacity (and cost))简单的季节性模型可以预测流量高峰。你可以获得主动的扩容，并减少周一早上令人恼火的情况。小案例：午夜 CPU 风暴 (A mini case: the midnight CPU storm)我们有一个服务每晚都会发出“CPU 90%”的告警。人们学会了忽略它。一个基本的季节性基线发现，真正的异常是某种批处理作业之后的一个特定分片（shard）。我们自动暂停了该分片上的批处理，并以较低的并发度重新排队。告警量下降了 80%，平均恢复时间（MTTR）从“有人醒来”变为“90 秒内自愈”。我们是否将人类排除在外？不。我们只是将他们排除在琐碎的循环之外。06自研与采购：实用视角 (Build vs. buy: a pragmatic lens)自研：

你已经拥有强大的可观测性（observability）基础设施和清晰的标签。

你的故障模式是特定于领域的。

你需要与专有操作手册（runbooks）或基础设施（infra）紧密集成。

采购：

你希望在多个团队中快速实现降噪。

数据混乱，你需要开箱即用、带有明确判断的关联功能。

你重视受支持的自动化和合规性功能。

大多数团队会选择混合方案：商业降噪产品 + 针对“最后一公里”的内部自动化。一个微型工作示例：无戏剧性的异常检测 (A tiny working sample: anomaly detection without the drama)下面是一个最小的 Python 代码片段，它使用滚动 Z 值（rolling z-score）标记 p95 延迟（latency）峰值。这不是生产代码，但它反映了许多 AIOps 成功案例的前 80%。# Rolling anomaly detection for p95 latency (milliseconds)import numpy as npdef rolling_z_anomalies(series, window=60, z=3.0):    """    series: list/array of numeric values ordered by time (1-min buckets, e.g.)    window: number of points for baseline    z: sensitivity; higher = fewer alerts    returns: list of (idx, value, zscore) for anomalies    """    series = np.array(series, dtype=float)    anomalies = []    for i in range(window, len(series)):        baseline = series[i-window:i]        mu, sigma = baseline.mean(), baseline.std() or 1e-6        zscore = (series - mu) / sigma        if zscore > z:            anomalies.append((i, float(series), float(zscore)))    return anomalies# Example usage: anomalies = rolling_z_anomalies(p95_latency, window=60, z=3.2)

如何安全使用它：

首先在影子模式（shadow mode）下运行；将标记的点与人工判断进行比较。

根据你的季节性（例如，一小时或一天）调整 `window`。

切勿在首次通过时直接发出告警——将异常作为上下文附加到现有告警中。

07风险、陷阱及如何避免 ？

垃圾进，垃圾出 (Garbage in, garbage out)。 没有一致的标签和时间戳，关联分析就会变成迷信。

自动化循环。 一项引发更多告警的补救措施可能会失控。使用熔断器（例如，每小时最大 N 次操作）。

历史事件中的偏差。 如果你的事件历史记录对某些故障的代表性不足，那么模型也会如此。每次事件后，主动征求值班人员的明确反馈。

凭证蔓延 (Secret sprawl)。 模型和管道需要凭证 (creds)。像对待任何生产服务一样对待它们：轮换密钥、审计访问、记录读取。

过度宣传 (Overselling)。 AIOps 在优先级排序和加速方面表现出色，但在弥补糟糕的架构或缺失的测试方面则不那么擅长。

08如何证明其有效性？选择一小组稳定的指标，每周跟踪它们：

告警精度 (Precision of alerts) （导致实际行动的告警百分比）。

关键事件的召回率 (Recall) （我们是否发现了真正的火灾？）。

试点前/后的 MTTA/MTTR （平均确认时间/平均解决时间）趋势线。

值班人员减少的 繁重工作时长 (Toil hours) （询问你的同事）。

部署后的变更失败率 (Change failure rate) （AIOps 应该通过更快的检测来提供帮助，而不是让情况变得更糟）。

如果至少有三项指标无法显示出改进，请暂停并重新评估。09人为因素（供应商常常忽略的部分）当运维文化健康时，AIOps 才能成功：无责事后复盘 (blameless reviews)、清晰的职责归属 (clean ownership)，以及记录人类所学经验的习惯。最优秀的团队将 AI 建议视为一位聪明的实习生：快速、不知疲倦，偶尔会犯错——所以你需要审查、教导，然后让他们处理更多事情。你可能想知道，“这会减少人员编制吗？” 以我的经验来看，它减少的是浪费的人员编制。人们不再忙于救火，而是开始投入工程建设：修复不稳定的部署、偿还服务等级目标 (SLO) 债务，以及构建保障措施，让下一次事件变得……平淡无奇。10总结AIOps 并非要取代 DevOps。它旨在用信号取代猜测——并将你的遥测数据转化为及时且重要的决策。从小处着手，让人工参与其中，衡量一切，并且只在数据表明你应该扩展的地方进行扩展。如果这引起了你的共鸣，请在评论区留下你最大的告警疲劳来源——或者关注我，获取下一篇关于如何在不付出巨大努力的情况下衡量 AIOps 投资回报率 (ROI) 的文章。面向构建者的下世代工程——快速、清晰、可衡量。你今天即可交付的系统、数据和 AI。



往期推荐

为什么很多 DevOps 工程师在面试中失败（以及你该如何避免）

2025-09-17

Kubernetes 中的 CPU 限制：为什么 Pod 明明空闲却依然被限流 ？

2025-09-18

我为什么要从 Kubernetes Ingress 迁移到 Gateway API

2025-09-25



点赞



分享



收藏



留言