From production problem to proposed fix: Implement autonomous operations with Grafana AI

你刚刚完成了一次部署，尽管服务已上线，但你开始注意到一些请求变慢了。为了解决延迟问题，需要有人（更可能是团队中的某几个人）监控仪表板，判断变更是否重要，调查发生了什么，并将发现的结果转化为修复方案。

在每个步骤中你都在收集上下文信息——通常还需要反复向下一个人员或工具解释这些上下文。对于负责服务的团队来说，这些工作会妨碍他们完成其他需要构建的内容，情况更加糟糕。

通过 Grafana Cloud 中的 Grafana Assistant，你可以将这些任务集中在一个地方，帮助你更快地解决问题，重新专注于构建工作。你使用的是能够自动化大量重复性繁重工作的 AI 功能，同时仍然保持你的控制权。

Assistant Watchers（作为 ObservabilityCON 2026 的一部分今天正式发布）持续关注你关心的条件。Assistant Investigations（已正式发布）收集关于发生了什么的证据。而 Grafana Managed Sandboxes（今天进入公开预览版）则利用这些上下文在受控的云环境中准备变更，为团队提供具体的审查内容。在本文中，我将向你展示如何利用这些功能共同实现更好的可观测性结果。

持续关注服务状态

考虑一次发布后的结账服务。你希望了解客户是否遇到持续的错误或响应变慢，同时也要考虑到部署期间预期的短暂中断。

通过 Watchers，我们的常驻代理，你可以描述这种担忧并选择相关数据源。Assistant 会分析你的历史遥测数据以建立基线并校准检查。从那里开始，监视器会定期评估这些信号，并提供报告以及其发现背后的证据。

%3Aquality(90)%2F&w=3840&q=75)

如果监视器发现严重问题，它可以自动启动调查，使用 Investigations，我们的代理专门帮助你深入分析事件。这样，你可以将重复的健康检查委托给 Assistant，让团队专注于其他任务。现有的警报继续覆盖需要可靠通知的已知条件，而监视器则为服务添加上下文评估。

最佳之处在于：通过支持 Google BigQuery 和操作性遥测数据源，您的监控系统不再局限于传统的可观测性场景。还可以监控业务信号，帮助整个组织关注可能影响利润的关键变化。

[附带证据启动调查](https://grafana.com/blog/grafana-ai-autonomous-operations/#start-investigating-with-the-evidence-attached)

当然，通知只是响应的开始。接下来的问题很熟悉：哪些请求受到影响？行为变化发生在何时？数据库是否涉及，还是其他依赖项导致了延迟？

调查可以探索指标、日志、追踪和分析数据，测试假设，并通过支持性源查询整理发现。从那里，响应人员可以检查证据，并随着了解更多信息而引导调查。

在我们的结账示例中，假设证据指向请求路径中重复的数据库调用。现在传递给开发人员的有用信息包括受影响的服务、症状以及支持该假设的证据。用户现在有了检查代码的起点。

[将发现结果转化为拟议更改](https://grafana.com/blog/grafana-ai-autonomous-operations/#turn-the-findings-into-a-proposed-change)

托管沙箱 为 Assistant 提供了一个受控的云环境，可以使用仓库代码和实时遥测数据开发拟议的修复方案，将调查上下文带入您的代码库。在连接相关仓库并启用编码后，代理可以检查代码、准备更改，并在 Grafana 沙箱中运行可用的检查。

%3Aquality(90)%2F&w=3840&q=75)

以我们的示例为例，任务可能是检查数据库访问模式，准备有针对性的更改，并添加回归测试。托管沙箱的特定于仓库的环境可以提供构建和测试项目所需的工具和依赖项。

目标应是让 Assistant 提交一个团队可以评估的拟议拉取请求：更改了什么，为什么它解决了疑似原因，运行了哪些检查，以及仍需要验证的内容。因此，当您响应时，调查已经启动，附带支持性遥测数据，并随着工作流程的推进，提供一个待审查的拟议修复方案。

[保持决策可见并保持控制](https://grafana.com/blog/grafana-ai-autonomous-operations/#keep-the-decisions-visible-and-stay-in-control)

通过的测试是有用的证据，但您的团队仍需要在发布流程中确认生产环境中的恢复情况。您的审核人员需要决定诊断是否适用，拟议的更改是否合适，以及如何部署。发布后，他们可以使用生产遥测数据检查结果，并继续监控是否再次发生。

这使自主性变得切实可行：将重复的观察、证据收集和变更准备工作委托出去，同时保留对哪些内容能够进入生产环境的明确决策权。你可以决定要检查哪些部分，无论是通过Managed Sandboxes（托管沙箱）、Assistant Automations（助理自动化）（用于执行重复任务）还是 Watchers（监视器）。对于某些任务，你可能会选择完全交给 Assistant（助理）处理。

这也为评估工作流程提供了一种有效的方式。你的响应者是否花费更少的时间收集上下文信息？开发人员是否获得了足够的证据来采取行动？提出的变更是否更容易审查？

从一个服务开始，然后扩展

你今天就可以使用 Assistant 实现类似程度的自动化。要开始，选择一个团队已经在发布后手动监控的服务。定义对你重要的行为，校准监视器，并审查其发现的结果。在适当的位置配置调查升级机制。

然后，在启用 Managed Sandboxes 的情况下，连接一个相关仓库，并尝试一个有明确审查结果的有限任务。从团队已经理解的问题开始。利用每次运行来改进检查、上下文和验证。随着结果逐渐赢得你的信任，逐步扩大委托的工作范围。

在你积累了一些经验并找到想要的工作模式后，就可以按自己的需求进行扩展。Assistant 的所有功能都可以互操作；你可以使用 Automations（自动化）来设置 Managed Sandboxes（托管沙箱）或 Investigations（调查），在 Slack 中讨论最新事件的结果，并定期分析过去30天的所有警报，以改进效果不佳的警报。

我们很期待看到你能自动化哪些内容，以帮助改进你的运维工作。

Tags