Q&A: How Elastic and Anyshift are bringing AI-powered context to incident response

问答：Elastic和Anyshift如何将基于AI的上下文引入事件响应 | Elastic博客

问答：Elastic和Anyshift如何将基于AI的上下文引入事件响应

作者： Sunnie Weber 2026年7月6日

• 在Twitter上分享
• 在LinkedIn上分享
• 在Facebook上分享
• 邮件分享
• 打印页面

• Anyshift的AI代理Annie现在可以在事件调查期间从Elasticsearch读取日志数据。
• SRE团队可以向Annie询问正在进行中的事件相关问题，并获得基于存储在Elastic中的日志数据的回应。
• 该集成提供对Elasticsearch数据的只读访问权限，支持API密钥认证，并可连接跨环境的多个Elasticsearch实例。Annie还能识别异常日志峰值和其他可能需要调查的信号。
• 这项集成反映了更广泛的转变趋势，即AI系统通过利用客户拥有的运营数据和上下文来改进事件响应和运营决策。

事件响应通常依赖于两种类型的上下文关联：环境发生了什么变化，以及日志中记录了后续发生了什么。通过与Elastic的新集成，Anyshift的AI代理Annie可以从客户的Elasticsearch部署中读取数据，搜索日志、识别错误和警告峰值，并将日志证据与基础设施变更历史进行关联。

我们与Anyshift的开发者倡导者兼后端工程师Louis Fradin进行了对话，探讨了该集成的工作原理、为何Elastic是自然的选择，以及这对使用AI加速事件响应的SRE和运维团队意味着什么。他与联合创始人Roxane Fischer和Stéphane Jourdan的合作，使他们能够在与Elastic共同构建故事的同时，通过技术写作和DevRel工作支持开发者。

Q：对于可能不熟悉Anyshift的读者，这家公司主要做什么？

Anyshift构建了实时基础设施的版本化资源图——包括云账户、Kubernetes、基础设施即代码，以及团队已经使用的源代码控制和工作流工具——并记录每个状态转换的历史。

我们的AI代理Annie会遍历该图，回答图结构最擅长回答的问题，例如：什么依赖于这个？什么发生了变化？影响范围有多大？如何将事件症状追溯到引入它们的变更？

Q：为何Anyshift选择与Elasticsearch集成以实现事件响应？

驱动因素是数据访问。Elasticsearch是我们在许多客户堆栈中看到的日志和可观测性后端。每当值班的SRE向Annie询问事件时，最有用的证据——实际的日志行——通常存储在Elasticsearch中，而Annie却无法访问。

在集成之前，每当客户的日志存储在Elasticsearch中时，Annie的SRE监控功能就会出现空白。通过Search API为Annie提供对客户Elasticsearch部署的只读访问权限，填补了这一空白，从而促成了此次集成。

Q：这是否是一次竞争性供应商选择？

不，这并非传统的供应商评估。Anyshift的集成是被客户驱动的，覆盖日志和可观测性来源。我们与客户使用的任意堆栈进行集成。

Elastic 被提到了优先级列表的前列，因为我们的客户群体与活跃的 Elasticsearch 部署之间存在高度重叠，而 Elastic 的 REST Search API 提供了一条无需中间层即可实现只读日志访问的清晰路径。问题的关键不是“哪家日志供应商得分最高？”而是“客户最需要我们首先落地的场景是什么？”

Q：除了技术整合之外，是什么让这次合作成为强匹配？

双方有共同的理念。客户可观测性数据属于客户，应保持开放和可查询，而不是被锁定在捕获数据的平台中。

Elastic 通过清晰的 REST Search API 暴露客户日志，这让 Anyshift 只需一个 API 密钥即可将客户的 Elasticsearch 集成到 Annie 中。在 AI 方面，理念类似：价值在于客户拥有的结构化上下文，而非数据收集格式。

Q：Anyshift 如今如何使用 Elastic？

已发布的最小可行产品（MVP）使 Annie 能够作为日志源访问客户的 Elasticsearch 部署。

有两种访问路径：

• 一组只读工具，Annie 在回答 SRE 的事件问题时按需调用，例如搜索文档、检索索引信息、检查集群健康状况和查看集群统计信息

• 一个每小时主动运行的工作者，轮询客户的索引模式以获取错误、警告和请求统计信息，并在 Annie 的 SRE 监控视图中展示异常波动

认证基于 API 密钥，方向是单向的：Annie 从 Elasticsearch 读取数据，但不会写回。

Q：Elastic 和 Anyshift 的整合如何帮助 SRE 团队处理事件？

对于使用 Elastic 的 Anyshift 客户，Annie 现在可以深入 Elasticsearch，回答依赖日志证据（如错误激增、最近异常和消息模式查找）的事件问题，而无需值班的 SRE 离开 Annie 的界面。

每小时工作者还意味着异常波动可以被主动发现，而不仅仅是按需查询。对于采用 Anyshift 的 Elastic 客户，其现有的 Elasticsearch 部署将成为 Annie 的另一个核心数据源。在调查过程中，Annie 可以将 Elastic 日志与 Anyshift 的基础设施图谱及其他集成进行联合分析。

Q：在整合过程中是否遇到任何有意义的技术障碍？

是的，有三个领域需要真正迭代。

• 多实例 Elasticsearch 支持：真实客户通常运行多个 Elasticsearch 部署，无论是不同区域的生产环境还是独立的生产与测试环境。最初的单实例 MVP 需要重新设计，以支持每个项目下的多个部署。

• 客户端网络访问：客户 Elasticsearch 集群通常位于 IP 白名单或 VPC 后面，因此入职流程包含一个协调步骤，客户需允许 Anyshift 的出站 IP。

• 多样化的客户日志模式：Elasticsearch 部署在字段类型和结构上存在差异，这会影响每小时工作者的聚合逻辑。我们通过改进服务字段检测、聚合前的验证以及优雅的回退行为来解决这一问题。

Q：这次整合是否影响了 Anyshift 内部产品构建的方式？

确实有影响。Elasticsearch 整合的多实例工作成为我们如今在集成层更广泛使用的架构模式。这帮助我们从默认单实例的模式转向了默认多实例的架构，为后续路线图的其他部分奠定了基础。

Q: 现在客户能够做哪些以前无法做到的事情？

有几个显著的改进。

• Annie 可以在事件发生时按需搜索客户的 Elasticsearch 日志，因此无需 SRE 离开 Annie 界面即可获取日志证据答案。

• Elasticsearch 中的错误和警告峰值可通过每小时工作流程在 Annie 的 SRE 监控视图中主动呈现。

• 当回答 SRE 问题时，Elasticsearch 成为 Annie 对比的数据源之一，与 Anyshift 已经整合的基础设施和工作流上下文信息共同参与关联分析。

Q: 这项合作对 AI 在运维领域未来的发展意味着什么？

核心观点是：生产环境中的 AI 瓶颈在于上下文信息，而非模型本身。

版本化资源图越快成为 AI 原生可观测性的基础设施上下文层，我们的优势就越稳固。Elastic 是这一进程中的天然合作伙伴，因为可观测性数据是 AI 在生产环境中发挥作用所需的关键上下文信息。

Q: 是否有早期迹象表明这项合作产生了影响？

目前 Anyshift 的客户如果在生产环境中使用 Elastic，已经开始使用该集成。由于客户尚未公开具体案例，因此命名的联合案例研究仍需等待。

从更广泛的 Anyshift 角度来看，我们已经看到 Annie 在可从图状态恢复的事件中显著减少了根本原因分析时间。例如，MotherDuck 基础设施负责人 Hilary Brennan-Marquez 描述了一个原本需要人类花费 20 分钟到 2 小时的过程，Annie 在 30 秒内就完成了。这种 MTTR（平均故障恢复时间）模式正是我们未来联合客户案例中预期看到的。

Q: Elastic 和 Anyshift 的合作下一步会聚焦哪些方向？

目前有三个短期重点方向。

第一是围绕如何使用 Anyshift 探索运行 Elastic 产品的基础设施的联合博客文章。第二是当有共享客户准备好公开时，发布首个命名的联合案例研究。第三是将集成扩展到 Elastic 知识库和 Streams，使客户基础设施上下文和 AI 分区的重要事件能够与我们已消费的日志数据一同流入 Annie 界面。

Q: 你个人最兴奋的路线图部分是什么？

坦率地说，是 Streams。从非结构化日志中提取 AI 解析、AI 分区的重要事件叙事——与基础设施变更事件在相同时间线上并行展示——这是我见过的最具吸引力的实时运维理解方向。这将彻底改变值班人员的工作方式。

Q: 对于其他希望与 Elastic 合作的组织，你有什么建议？

以技术讨论为主导，而非法律条款。一旦工程和产品方向达成一致，商业结构通常会随之跟进。

此外，选择一个能立即让非技术人员理解的集成场景作为切入点。对我们来说，这很简单：值班 SRE 向 Annie 询问错误，Annie 在同一对话中从客户的 Elasticsearch 部署中提取匹配的日志行。

Q: 如果用三个词来描述 Elastic 和 Anyshift 的合作，你会选择哪些词？

开放。互补。原生 AI。

本文中描述的任何功能或功能的发布时机均完全由Elastic自主决定。任何当前不可用的功能或功能可能无法按时或根本不会提供。

在本博客文章中，我们可能已使用或引用了第三方生成式AI工具，这些工具由其各自的所有者拥有和运营。Elastic对第三方工具没有任何控制权，我们对其内容、操作或使用方式不承担任何责任或义务，也不对因使用此类工具可能导致的任何损失或损害负责。在使用AI工具处理个人、敏感或机密信息时请保持谨慎。您提交的任何数据可能用于AI训练或其他用途。无法保证您提供的信息将被安全或保密保存。在使用任何生成式AI工具之前，请熟悉其隐私政策和使用条款。

Elastic、Elasticsearch及相关标识是elasticsearch B.V.在美国和其他国家的商标、标志或注册商标。所有其他公司和产品名称均为其各自所有者的商标、标志或注册商标。

分享