关键要点
- 随着系统复杂性的增加，监控和维护的工作负担也会随之加重。当系统中新增服务或出现依赖关系时，团队需要花费大量时间来维护观测基础设施，并在出现问题时分析各种数据之间的关联。
- 使用代理式观测机制并不需要彻底替换现有的监控工具栈——这些代理可以与现有的监控平台无缝集成。
- 最初应选择只读模式开始使用，逐步建立信任机制，先从异常检测和汇总功能入手，然后再添加操作背景信息，以便实现智能化的关联分析和问题排查，最后再考虑是否引入自动化流程。
- 在观察了实际发生的问题后，可以找出那些重复出现、风险较低的任务作为自动化的候选对象，并明确规定自动化规则何时以及如何执行。
- 人工智能代理可以将工程师的工作重点从手动调试转移到分析与验证上，从而提高运营效率，而非取代人类的判断能力。
如果你曾经有过值班经历，就应该了解这种情景：凌晨2点，警报通知突然出现，你被惊醒后立刻拿起笔记本电脑开始调查。你会先查看服务面板，然后是依赖关系图，接着是日志记录，最后还会参考三种不同的监控工具提供的数据。30分钟后，你才会发现其实这是虚惊一场——可能是阈值设置得过于严格，某个部署测试触发了警报，但问题很快就被解决了；也可能是网络暂时出现异常，导致数据出现了短暂波动。
但你不能就此继续睡觉，你必须继续观察，确保所有警报都真正被处理完毕。等到你确定问题真的得到解决时，你已经损失了一个小时的睡眠时间，而且也很难再重新入睡了。
这种情景在各个运维团队中都很常见。我们不断调整警报设置，试图找到那个完美的平衡点：如果警报设置得过于敏感，就会收到大量误报；而如果设置得过于宽松，就会错过真正的问题。这种动态会导致“警报疲劳”现象——工程师们会被大量无需采取任何行动的警报所困扰，久而久之，他们对警报的信任度会下降，对真正问题的响应速度也会变慢。关于警报疲劳的研究表明，这种反应迟缓的现象普遍存在：在安全监控领域，有调查发现超过一半的警报都是误报；在IT运维领域也是如此。这不是配置问题，而是监控复杂分布式系统时所面临的一个根本性挑战。
各团队花费了大量时间来优化他们的警报规则，这也是理所应当的。但根本问题依然存在：我们需要监控的范围已经超出了我们手动维护和解读这些数据的能力。
那个我们从未讨论过的监控悖论
现代系统的现实是，它们总是在不断发展。每一个新功能的加入都会带来更多需要分析的日志、更多需要追踪的指标、以及更多需要维护的仪表盘。原本设计简洁、监控机制直接的系统，最终会发展成一个需要持续关注的庞大生态系统。
随着系统规模的扩大，维护工作也变得越来越繁重。各团队要花费大量时间来确保自身的监控基础设施始终处于最新状态。新服务需要添加相应的监控工具，仪表盘需要更新，当流量模式发生变化时，警报阈值也需要进行调整。这些虽然是常规且必要的工作，但却会占用本可用于开发新功能或提升系统可靠性的时间。
典型的微服务架构会产生海量的遥测数据：来自数十个服务的日志、来自数百个容器的指标信息，以及跨越多个系统的追踪数据。当发生故障时，工程师们就会面临如何判断这些数据之间关联性的问题——哪些信号才是真正重要的？它们之间是如何相互关联的？最近又发生了什么变化，从而导致这种异常现象的出现呢？
人工智能助手的到来
当我第一次接触到利用人工智能技术进行监控这一概念时，我持怀疑态度。这听起来就像是供应商们为了吸引关注而使用的宣传话术罢了。但随着这项技术逐渐成熟，一些早期应用案例也陆续出现，其实际潜力也就变得越来越清晰了。
关键在于，我们应该将这些系统视为合作伙伴，而不是替代品。具体来说，它们在那些人类觉得繁琐的任务上表现得非常出色：比如在庞大的数据集中进行模式匹配分析、记住之前发生的所有故障情况，甚至在周二凌晨两点依然保持高度警惕。
具有智能功能的监控系统不仅仅能够收集数据并触发警报，它真正能够理解所观察到的现象。它可以：
- 发现那些不符合常规模式的变化：不仅仅是超过预设阈值的异常情况，还包括那些暗示问题出现的细微行为变化，从而在问题变得严重之前就及时发出警告。
- 梳理整个系统中的各种关联信息，将数据库延迟的增加与认证错误、以及六小时前进行的部署操作联系起来进行分析。
- 生成真正有用的总结报告。比如，不要只是简单地显示“错误率超过了阈值”，而应该说明“在下午2:15进行部署后，认证服务的延迟增加了200%，这一现象与新的Redis连接池配置有关”。
- 记住各种系统知识。每一次故障都会让监控系统学到一些东西。比如那些与缓存相关的异常问题，系统会记住你之前采取的解决方法，并在下次遇到类似情况时再次提出建议。
- 在规定的范围内采取行动。在适当的监管机制下，具有智能功能的监控系统可以根据预先设定的规则，执行安全可靠的补救措施。
这种方法与传统监控方式的区别，就如同一个只会发出警报的系统与一个能够分析这些警报含义的系统之间的区别。传统监控只是告诉你某些指标已经超出了预设的阈值，而基于智能代理的监控系统则能帮助你理解究竟发生了什么变化、这些变化可能与哪些因素有关，以及接下来应该关注哪些方面。
生产环境中实际发生的情况
向智能监控方式的转变改变了工程工作的开展方式。工程师们不再需要在每次出现问题时，首先花费二十分钟的时间手动对比各个仪表板上的日志数据和指标数值，现在他们可以直接查看由人工智能生成的总结报告，这些报告会将部署时间、错误模式以及基础设施的变化联系起来。事故处理工单也会自动附带相关的背景信息。过去需要进行深入调查才能进行的根本原因分析，现在也可以在有了明确的假设之后就开始进行。虽然最终还是工程师来做出决策，但他们所依据的已经是经过分析的数据，而不是原始信号。
这样一来，不仅节省了时间，也减轻了工程师们的认知负担，让他们有更多时间去从事那些真正重要的工作，而不是忙于处理各种紧急问题。
实际可行的实施路径（因为理论在凌晨3点是不会来指导你的行动的……）
如果你正在考虑采用智能监控技术，以下是一个分阶段实施的实用方案。
第一阶段：仅用于学习用途
首先，将你现有的所有监测数据（包括日志、跟踪信息、各项指标等）输入到处于观察模式的智能代理系统中，让该系统分析实时数据及历史记录，从而识别出其中的规律并标记异常情况，但不会触发警报或自动执行任何操作。
这个阶段的主要目的是建立信任——你的团队会发现，智能代理给出的建议确实是有意义的，而且它还能帮助你发现那些原本可能会被忽略的异常现象。工程师们也会逐渐养成在查看原始日志之前先参考智能代理生成的报告的习惯。
| 所需时间 | 2至4周 |
| 风险等级 | 基本为零 |
| 能学到的内容 | 智能代理是否能够理解你的系统运行规律 |
第二阶段：启用基于上下文的分析功能
这一阶段的重点是让智能代理学会了解你特定的环境，并利用这些信息来进行智能化的故障排查。这一过程包含两个关键环节，它们需要协同工作才能发挥作用。
添加运营相关背景信息
你需要向智能代理提供各种运营相关的资料，比如操作流程手册、服务责任文档、架构图、依赖关系图表以及以往发生的事故报告等。这些信息会让智能代理从一个仅仅能够识别通用规律的工具，变成一个真正了解你特定系统的工具。
这样一来，当它检测到异常情况时，就能提供具体的上下文信息。例如，它不会只是简单地说“检测到高错误率”，而是会具体说明“通知服务出现了高错误率，该服务由通信团队负责维护，而这个服务又依赖于邮件网关和消息队列系统，最近的一次部署版本是v1.8.2，是在3小时前进行的”。
启用智能关联功能
在具备了这一功能后，代理就能够主动地在日志、指标和跟踪数据之间进行关联分析。它会将当前出现的模式与过去的事件进行比对，并根据您系统的实际架构及历史数据来提出相应的调查方向。
以下是一个由代理生成的成熟分析示例：
代理并不会自行做出决策，而是会执行工程师通常需要花费二十分钟来完成的那些工作——包括在仪表板上查看数据、搜索日志以及进行关联分析。最终，它会呈现出一个条理清晰的分析结果，并提供可行的调查步骤。
| 所需时间 | 2至8周（最初需要1至2周来建立分析基础，之后随着关联分析能力的提升会持续优化） |
| 风险等级 | 低（仅提供建议性功能） |
| 你能从中获得什么 |
你的系统文档记录得是否完善？代理对你们环境中的因果关系理解得如何？ |
第三阶段：根据实际运营经验定义自动化规则
在让代理以观察或建议模式运行了几周之后，你一定会发现一些规律：某些事件会反复发生，特定的诊断步骤也会频繁出现，而有些补救措施则简单且风险较低。这时，你就需要确定哪些工作流程可以自动化，以及在什么条件下才能自动化。
关键在于要基于实际的运营经验来制定规则，而不是仅仅依靠理论。回顾一下过去发生的事件，问问自己：我们有哪些操作是反复进行的？哪些操作是安全且可预测的？在风险较低的情况下，哪些操作可以无人值守地自动执行呢？
适合自动化的常见任务包括：
- 重启那些健康检查未通过的不健康的容器或Pod
- 运行标准的诊断脚本以收集数据进行分析
- 在流量激增时，在预设的范围内调整资源分配
- 当出现异常情况时，触发日志采集或性能分析功能
不过，自动化也需要相应的约束机制。在启用任何自动化操作之前，必须明确制定相关政策：
- 何时可以自动执行这些操作？也许只在非高峰时段执行，或者最初只针对非关键服务，而在部署期间或重大项目启动时则绝对禁止自动化。
- 哪些情况需要人工干预？严重级别较高的事件、面向客户的服务，或者代理的分析结果低于某个阈值的情况，都应由人类来处理。
- 哪些操作需要被记录下来进行审计？每一个自动化的操作都应该被详细记录下来，包括其执行原因、触发它的具体情境以及最终的结果。这样才能确保责任得到落实，并有助于逐步完善自动化规则。
- 谁有权取消或暂停自动化操作？
工程师应该能够方便地在中断自动化操作，无论是为了进行维护、测试，还是因为在敏感时期需要如此操作。
首先从一两个低风险的自动化任务开始尝试。观察它们在一两周内的运行情况，然后随着信心的增加和规则的不断完善，逐步增加更多的自动化任务。目标并不是实现完全自动化的操作流程，而是消除重复性劳动，让团队能够专注于那些需要人类判断的复杂问题。
| 所需时间 | 根据实际运行情况持续进行优化 |
| 风险等级 | 风险中等，但可以通过制定策略并逐步推进来实现控制 |
| 能带来的收获 | 哪些事件处理环节真正适合自动化，哪些仍需要人工干预 |
集成的现实情况
你很可能不需要替换现有的任何系统。大多数智能观测平台都能与现有的监控工具集成使用。无论你是使用开源解决方案还是商业平台，这些智能组件通常都可以与你当前的系统架构一起正常运行。
可以把这看作是在现有基础设施之上添加一层智能功能，而不是彻底推翻原有的体系。
当系统运行顺利时
在实践中，我们可以观察到一些明显的成效：随着各组织开始使用智能观测系统，通常会出现以下改进：
- 事件处理速度加快（例如：“三个月内，平均处理时间从45分钟缩短到了18分钟”）。
- 值班人员的工作体验得到改善（例如：“现在我可以安心睡觉了，智能系统会处理那些常规性任务，只有真正需要人工判断的情况才会通知我”）。
-
学习效果提升 （例如：“每次处理事件都能积累宝贵的经验。新成员可以直接向系统查询：‘请告诉我最近发生的五次数据库故障以及解决方法’”）。 - 问题能被更主动地发现并解决（例如：“我们能够在问题真正引发故障之前就将其发现并解决。这种转变可能会让人感到不习惯，因为团队从被动应对事件转向了主动预防”）。
- 工程师的工作重点从调试转向分析（例如：“工程师们花费在查看日志上的时间减少了，而用于分析问题趋势和验证解决方案的时间却增加了。运营效率确实得到了提升，团队也真正开始致力于系统的优化工作”）。
存在的不足
在实际应用中，也会遇到一些常见的挑战：
- AI并不会在第一天就立刻理解你的系统运行机制。该智能助手需要时间来学习你系统的正常运行模式，因此在初期提供的建议可能会偏离目标。你可能会得到一些无关紧要的关联信息，或者一些毫无帮助的显而易见的建议。只有经过数周的学习，这些智能助手所提供的分析结果才会真正变得有价值。
- 建立所需的环境背景信息其实比你想象中更耗时。将你的操作手册、系统架构文档以及那些仅存在于人们记忆中或过时的文档资料提供给智能助手，这个过程看似简单，但实际上其中包含了许多关键信息。你需要花实际的时间来整理并上传这些资料。
- 学习曲线确实存在。你的团队需要了解如何配置、使用以及验证该智能助手的行为，因此为此预留足够的时间是必要的。
- <>文化上的抵触情绪也是不可避免的。有些工程师对AI缺乏信任，有些人则担心自己的工作会因此受到影响。对于这些问题，你需要通过坦诚地解释AI的作用——它是用来辅助人类工作，而不是取代人类——来加以解决。
- <>调试智能助手本身往往比调试整个系统更加困难。当智能助手做出错误的判断时，问题通常出在信号、环境背景信息以及学习到的模式之间的结合方式上，而并非某个具体的指标或日志数据。这种复杂性降低了系统的透明度，因此解释性就显得尤为重要了。
一种简单的检测机制，用于评估“代理可观测性”的效果
不确定“代理可观测性”是否适合您吗？请向您的团队提出以下问题：
- 在处理故障时，我们是否会反复执行相同的诊断命令？
- 我们是否花费了大量时间来对比不同工具中收集到的数据？
- 虚假警报是否会让我们忽略真正存在的问题？
- 如果初级工程师能够即时获取高级工程师掌握的故障处理经验，他们的响应速度是否会更快，出现错误的风险也会更低吗？
- 我们是花了更多时间去“扑灭火灾”，还是在预防故障方面投入了更多精力？
如果您对其中两个或更多问题给出了肯定的回答，那么这种机制肯定会带来帮助。
展望未来
系统正变得越来越复杂，数据量也在不断增加，而停机带来的损失也日益严重。然而，人类的大脑并不会变得更大或更快。
“代理可观测性”的目的并不是取代工程师，而是为他们提供实际的帮助——使他们能够在大规模的数据中识别出规律，回顾以往的故障处理经验，并能在几毫秒而不是几分钟内根据信息采取行动。
从小处着手，逐步建立信任，让系统本身来证明它的价值。可靠性的未来并不在于人类或人工智能，而在于将人工智能应用于人类的工作中，从而帮助人们更好地完成工作。
也许，就这样，我们都能多睡一会儿吧……
免责声明：本文所表达的观点仅代表作者个人立场，并不代表其雇主的观点、政策或实践方式。所有示例与建议均基于行业通用惯例及个人经验提出。