如果你曾经值过班，那么你肯定知道这么一种情况。凌晨两点，电话打来，你猛然惊醒，抓起笔记本电脑开始排查。你先是检查服务仪表板，接着是分析依赖关系图，然后是查看日志，最后再查看来自三个不同监控工具的指标。半小时后你发现，这不过是虚惊一场：阈值设置过严，金丝雀部署触发了可以自动恢复的告警，或是网络瞬态波动导致了短暂峰值。

但你不能就这样回去睡觉。你得等等，观察一下。你必须确保告警窗口干净利落地关闭了，而且没有任何其他告警被触发。等你确信问题已经真正解决时，你已经失去了一小时的睡眠时间，更大的问题是几乎睡意全无。

这种场景在各地运维团队中屡见不鲜。我们不断地调整告警阈值，试图找到一个完美的平衡点：过于敏感会被误报淹没，过于宽松则会错失真实事件。这种动态变化会导致告警疲劳——工程师被大量无需处理的告警淹没。随着时间推移，这会削弱人们对告警的信任度，并降低对真实问题的响应速度。关于告警疲劳的研究表明，这种响应迟滞现象普遍存在：安全监控领域的调查发现，超过半数的告警属于误报，而 IT 运维领域也呈现出类似的模式。这并非配置问题，而是监控复杂分布式系统时面临的一个根本性挑战。

为了优化告警规则，团队经常要花费无数个小时，他们应该这样做。但根本问题仍然存在：我们需要监控的范围超出了我们手动维护和解释的能力。

我们不愿谈论的监控悖论

对于现代系统，一个现实是它们会一直不停地增长。每增加一个新功能都会有更多的日志需要解析，更多的指标需要跟踪，更多的仪表板需要维护。最初简洁明了的架构与直观的监控，逐渐演变成了一个需要持续投入精力的庞大的生态系统。

随着系统的增长，维护负担也在增加。仅仅是保持可观测性基础设施的更新就需要花费团队大量的时间。新服务需要配置监控工具，仪表盘需要持续更新，流量模式变化时需要调整告警阈值。依赖关系不断变化，监控方案也必须随之调整。虽然这些工作都是例行公事，却也不可或缺，它们消耗了本可用于开发功能或提升可靠性的宝贵时间。

一个典型的微服务架构会产生巨量的遥测数据：来自数十个服务的日志，来自数百个容器的指标，跨多个系统的跟踪信息。当事件发生时，工程师会面临一个相关性问题：哪些信号至关重要？它们如何关联？近期发生的哪些变化可能解释这种行为？

AI 队友加入

初次接触可观测性 AI 代理的概念时，我是持怀疑态度的。这听起来像是供应商炒作与流行词汇的结合体。但随着技术的日趋成熟，早期应用方案的陆续出现，其潜力正变得越来越清晰。

关键转变在于将这些系统视为队友而非替代者。具体而言，这些队友擅长处理事件响应中人类厌烦的那些环节：在海量数据集中进行模式匹配，记住以往的每一个事件，并在周二凌晨两点保持警觉。

智能可观测性意味着你的监控系统不仅仅是收集指标和触发告警，还要能理解它所看到的信息。它能够：

• 留意不符合常规模式的现象：不仅仅是超出阈值，还有行为中那些微妙的变化，在情况变得严重之前发现事情不对劲。

• 串联技术栈中的各个点，将数据库延迟峰值与那些认证错误和六小时前的部署关联起来。

• 生成有实际用处的错误信息摘要。想象一下，提供这样的错误信息，“在下午 2:15 部署后，认证服务延迟增加了 200%；与新的 Redis 连接池配置相关”，而不仅仅是“错误率超过阈值”。

• 记住制度性知识。每一个事件都能教会可观测性代理一些东西。关于缓存的那个奇怪问题？代理会记住你是如何修复的，并在下次出现类似的问题时提供建议。

• 在规定的范围内采取行动。在适当的监督下，智能可观测性可以执行你基于定义好的策略预先批准的安全补救步骤。

传统监控与这种方法的区别在于：一个只发出告警，而另一个会分析告警的含义。传统监控告诉你有东西越过了阈值。代理辅助的可观测性会帮助解释发生了什么变化，可能与什么相关，以及接下来应该查看什么。

生产环境中究竟发生了什么

向智能可观测性的转变改变了工程工作开展的方式。在每次处理事件时，工程师不用首先花二十分钟手动在仪表板上关联日志和指标，而是可以审查 AI 生成的事件摘要，其中链接了部署时间、错误模式和基础设施变化。事件工单自动填充了上下文信息。根因分析现在从一个清晰的假设开始，而不像以前那样需要先进行广泛的调查。工程师仍然需要做出决定，但他们是基于分析数据而不是原始信号。

这节省了时间，减少了认知负荷，让你最好的工程师们可以把更多的时间投入到功能建设上，而不是用在救火上。

实际路径

如果你正在考虑采用智能可观测性，下面是一个分阶段采用的步骤。

第一阶段：只读学习

首先，将现有的遥测数据（日志、追踪信息、指标等）输入到一个处于观察模式的智能代理中，它会分析实时和历史数据，学习模式并标记异常，但不触发告警或执行操作。

这个阶段的目标是建立信任。团队看到智能代理提供了合理的建议。你捕捉到了本来可能会错过的异常。工程师们开始在深入分析日志之前查看智能代理生成的摘要信息。

第二阶段：启用上下文感知分析

这个阶段关乎让智能代理理解你特有的环境，并利用这些知识进行智能调查。它有两个协同运作的关键组件。

添加操作上下文

向智能代理提供专有知识：运行手册、服务所有权文档、架构图、依赖关系图和过往事件报告。这些信息将智能代理从一个通用的模式匹配器转变为一个理解特定系统的工具。

现在，当它检测到异常时，它有一个上下文。它不再简单地显示“检测到高错误率”，而是能具体说明：“（通信团队负责的）通知服务出现高错误率。该服务依赖于邮件网关和消息队列。最近部署记录：v1.8.2 版本于 3 小时前部署”。

启用智能关联

有了这个上下文，智能代理现在可以关联日志、指标和追踪信息中的相关信号。它将模式与过去的事件做匹配，并根据系统的实际拓扑和历史信息提出调查路径。

下面这个例子是一个成熟的智能代理生成的分析结果：

智能代理不做决定。相反，它正在做工程师手工操作通常需要 20 分钟才能完成的仪表板跳转、日志搜索及其他相关工作。它提供了一个连贯的叙事和可操作的调查步骤。

第三阶段：根据运营经验定义自动化

在观察和咨询模式下运行智能代理几周后，你会发现某些规律。有些事件会重复发生。特定的诊断步骤会反复出现。有些补救措施简单直接且风险低。这时，你就可以定义哪些工作流程在什么条件下可以自动化。

关键是从实际的操作经验出发，而不是理论。查看事件历史并问这样的问题：我们反复采取了哪些行动？哪些是安全且可预测的？哪些可以在低风险时段自动运行？

常见的自动化选项包括：

• 重启不健康的 Pod 或容器，它们未能通过健康检查

• 运行标准诊断脚本，收集分析数据

• 流量高峰时段，在预设的边界内扩展资源

• 在发生异常时触发日志收集或性能分析

但自动化需要有所限制。在启用任何自动化操作之前都应定义清晰的策略：

• 何时可以自动运行？也许只在非高峰时段，或者最初只针对非关键服务，或者从不在部署窗口或主版本发布期间运行。

• 什么需要升级？高严重性事件、面向客户的服务或代理的置信度低于某个阈值时，必须始终由人工介入处理。

• 什么需要审计？每个自动化操作都应该记录其背后的逻辑依据、触发操作的上下文和操作结果。这有助于建立责任机制，并随着时间推移不断完善自动化规则。

• 谁可以控制或暂停自动化？需要有一个简单的方法，让工程师可以在需要时（如维护、测试或敏感时期）禁用自动化。

从一两个低风险的自动化开始，观察它们在一周或两周内的表现。随着信心的建立和规则的完善，逐渐增加更多的自动化操作。我们的目标不是无人操作，而是要消除重复的劳动，使团队可以专注于需要人类判断的复杂问题。

集成的真实情形

你可能不需要替换任何东西。大多数智能可观测性平台都集成了现有的监控和可观测性工具。无论是使用开源解决方案还是商业平台，智能代理通常都可以与你当前的技术栈协同工作。

可以将其视为是在现有基础设施之上增加一个智能层，而不是推倒重来。

当它正常工作时

在管理平台可靠性和观察团队如何应对监控挑战时，你会发现某些特定的模式。随着组织尝试使用智能可观测性系统，往往会出现类似下面这样的改进：

• 事件解决速度更快（例如，“我们的事件解决时间从平均 45 分钟减少到 18 分钟，而这仅用了三个月”）。

• 提升值班生活质量（例如，“我现在可以一觉睡到天亮。智能代理处理日常事务，只有在遇到需要人类判断的事情时才会叫醒我”）。

• 提升学习便利性（例如，“每个事件都会增加制度性知识。团队的新成员可以要求智能代理：‘告诉我过去的五次数据库事件是什么以及如何解决的’”）。

• 提高主动捕获能力（例如，“在问题变成事件之前就发现并修复了它们。这种转变可能令人感到陌生，因为团队正从被动地响应事件转向主动地预防。”）。

• 工程时间从调试转移到分析（例如，“工程师花在浏览日志上的时间减少了，花在分析模式和验证修复上的时间增加了。这切实提升了运维效率。团队从救火模式转变为真正地改善系统”）。

缺点

以下是实践中通常会遇到的几个挑战：

• AI 不会在第一天就神奇地理解了你的整个系统。智能代理需要时间来学习正常的模式应该是什么样子，所以早期的建议可能会偏离目标。它可能会做出不相关的关联，或提供明显没用的建议。经过数周的学习之后，洞察力才会真正变得有价值。

• 设置上下文比你想象的更耗时。听起来，向智能代理提供运行手册、架构文档和专有知识很简单，但从中可以看出有多少关键信息只存在于人们的头脑中或过时的文档里。预计要实实在在花些时间来组织和上传这些上下文。

• 真实存在的学习曲线。团队需要了解如何配置、信任和验证智能代理的行为，并为此预留时间。

• 文化阻碍。会有一些工程师不信任 AI，也会有一些人担心工作保障。直面这个问题，明确说明增强团队能力与人员替代之间的区别。

• 调试调试器比调试系统本身更难。当智能代理判断错误时，问题可能出在信号、上下文和学习模式的组合方式上，而不是任何单一的指标或日志文件中。这会降低透明度，因此可解释性很重要。

一种用于评估智能可观测性的简单检查方法

如果不确定智能可观测性是否适合你，那么可以问下你的团队下面这些问题：

• 在事件处理期间，我们是否反复运行相同的诊断命令？

• 我们是否花费了大量的时间来关联多个工具之间的信号？

• 误报是否导致我们错过了真正的问题？

• 如果我们的初级工程师能够即时访问高级工程师积累的事件知识，他们是否能更快地响应事件，降低风险并减少混乱？

• 我们是否花费了更多的时间灭火而不是预防？

如果有两个或更多问题的答案是“是”，你将从中获益。

未来展望

系统变得越来越复杂，数据量在不断增加，停机成本变得越来越高，而人脑并没有变得更大或更快。

智能可观测性的目标不是要取代工程师，而是为他们赋能：大规模地识别模式，保留以往事件的知识，并在毫秒（而非分钟）内对信息作出反应。

从小处开始，逐步建立信任。让系统自己证明自己。可靠性的未来不是人类也不是 AI，而是拥有 AI 的人类，使他们在工作中的表现更好。

也许，只是也许，我们都可以多睡一会。

免责声明：本文所表达的观点和意见仅代表作者个人立场，不代表其雇主机构的观点、政策或实践。所有示例和建议均基于行业普遍做法及个人经验。

原文链接：

https://www.infoq.com/articles/agent-assisted-intelligent-observability/