Kubiks 联合创始人 Alex Holovach 访谈系列

亚历克斯·霍洛瓦赫Kubiks 联合创始人是一位经验丰富的软件工程师，专注于可扩展的高性能系统。他曾在 Prove、TAG（Aspen Group）、airSlate 和 Google 领导数字化转型，构建容错微服务，并开发企业集成。如今，他正将这些专业知识运用到 Kubiks 的 AI 可观察性重塑中。

库比克斯 Kubiks 是一个 AI 原生的可观测性平台，可帮助工程团队更快地监控、诊断和解决问题。它无需手动设置即可自动捕获日志、跟踪、查询和 LLM 调用，然后利用 AI 精准定位根本原因、发送上下文警报，甚至提供修复建议。Kubiks 提供实时服务地图、历史快照以及与主流工具和云提供商的集成，从而简化事件响应并提高系统可靠性。

您曾在 airSlate、Prove 和 Google 等公司构建并扩展基础设施。这些职位中的哪些部分最能塑造您对扩展系统挑战的看法？这些经验最终是如何激励您共同创立 Kubiks 的？

我亲身体验了在每天有超过100名工程师推动变更的情况下，如何保持可靠性。在这种情况下，巴士因子（关键团队成员突然缺席的风险）很高，关键在于尽可能地自动化一切，以保持服务平稳运行。但你无法总是预测接下来会发生什么。这些经历凸显了传统方法的局限性，这就是为什么让人工智能代理持续实时监控每个环节会改变一切。它们始终在线，在出现问题时立即发出警报并进行根本原因分析。这正是促使我共同创立Kubiks.ai的动机，旨在让更多团队能够获得这种智能、始终在线的监控。

Kubiks 于 2025 年 XNUMX 月成立，并做出了一个大胆的承诺：一分钟设置和 AI 修复。您看到了哪些市场空白，让您确信现在是创办这家公司的最佳时机？

目前存在巨大的差距，因为人工智能终于可以为互联网添加一层自我修复能力。我们的使命很简单：让人工智能监控您的生产系统，自动分析故障根源，并准备安全的修复方案，以便团队能够在几秒钟内做出反应。随着人工智能承担起持续的主动监控工作，工程师们可以专注于快速响应，而不是无休止的检查。这就是我们正在实现的重大转变。

Kubiks 独具特色地捕获完整的请求和 LLM 调用，自动生成修复，并提交拉取请求以供审核。哪些技术突破实现了这种从检测到解决的顺畅流程？在全面性和简便性之间取得平衡是否很困难？

我们的突破在于端到端关联和上下文工程：我们自动从每个请求中提取关键 ID，例如付款、用户、会话、数据库、队列、模型和版本，并将它们编织成一条时间线。连接完整链条后，AI 可以精确定位第一个失败的调用、导致失败的输入以及需要修复的具体内容。这借鉴了 Facebook 的内部可观察性工具 Scuba。一旦使用了类似这样的工具，您就无法再回到仅仅依靠指标和聚合的模式了。

Kubiks 提供实时可视化、服务地图和以关系为中心的视图。将日志、跟踪、指标和映射整合到一个统一的仪表板中，如何彻底改变团队检测和解决问题的方式？

现代系统就像在高速公路上行驶的汽车。如果必须解析每个原始传感器读数，肯定会崩溃。因此，您需要一个仪表板来标记问题所在。因此，我们将日志、跟踪记录、指标和实时地图结合在一起：快速浏览即可了解全貌，单击即可找到修复方法。它将分散的调试工作转化为专注、高效的解决方案。

时间旅行和快照注释对于历史调试来说听起来很强大。实际上，有哪些用例可以发现实时视图本身无法发现的问题？

想象一下，您的核心服务宕机了，实时地图上所有地方都显示红色，系统范围内的错误，但您却无法在一片混乱中确定哪个先发生故障。例如，我们曾经有一个 Airflow 作业，其重试策略配置错误；它原定于夜间执行，却在中午高峰流量期间触发，导致数据库崩溃。实时视图只能显示大范围的故障，但时间旅行功能可以让我们回溯到事件从该作业失败开始的整个过程，从而揭示出实时运行中尚不清楚的根本原因。

你们的人工智能如何分析遥测数据来检测异常并提出修复建议？能否分享一些 Kubiks 发现传统监控系统可能遗漏的细微或隐蔽问题的例子？

一位工程师在功能开关背后部署了新的逻辑，在关闭该开关的情况下，生产在两周内保持稳定。后来，为某个用户群启用该开关，却导致该用户出现错误。在标准仪表盘中，错误看起来是随机的，很难追溯到部署。Kubiks 将每个请求与代码版本、开关状态、用户群和下游调用关联起来。当错误激增时，AI 会将其与开关激活和特定的代码路径进行匹配。它会突出显示失败的功能和触发输入。通过将可观察性与代码和开关关联起来，AI 可以快速识别原因并提出有针对性的修复建议，从而捕捉到传统工具所忽略的问题。

用户评价 Kubiks “无需任何设置” 并且“开箱即用”。从安装到日常工作流程，你们采取了哪些措施来确保用户信任度和易用性？

我们设计 Kubiks 时，从本地开发阶段开始就让人感觉熟悉，因此您可以在生产环境升温之前就建立信任。我们的 CLI 可在本地运行您的应用，自动检测 HTTP、数据库、队列和 LLM 调用，并流式传输干净的遥测数据；无需手动记录或跟踪。它通过 MCP 为您的 AI 代码编辑器提供丰富的上下文，并提供与您在预发布和生产环境中看到的完全相同的视图。您只需在构建功能时按照自然的流程学习一次，即可在关键时刻实现无缝且可靠的运行。

如今，许多 AI 初创公司在系统快速扩展的同时，都在努力提高可观察性。Kubiks 如何帮助小型团队以与数十亿美元级公司相同的可靠性标准运营？

初创公司发展迅速。你无法停止冲刺，到处添加日志和追踪信息。这就是我们强调自动化检测的原因。只需一次安装，Kubiks 即可开箱即用地捕获所有信息：HTTP 路由、数据库调用、LLM 交互。它让小型团队无需额外开销即可实现企业级可靠性。

随着人工智能系统日益复杂，您认为 Kubiks 在确保分布式人工智能工作负载的可靠性、可观察性和可操作性方面发挥什么作用？

传统的微服务虽然复杂，但可预测。您可以绘制调用图并预测流程。分布式人工智能颠覆了这一点：代理可以动态交互、启动工具、动态调整计划，并根据上下文进行路由。这很有创新性，但调试起来却非常困难。Kubiks 会自动检测整个设置（每个代理、工具、队列、Webhook 和模型调用），然后创建一个实时因果图，显示谁在何时使用了哪些数据执行了哪些操作。我们的人工智能会实时监控这些操作，在发生偏差、循环、交接失误和错误决策时及时发现，而不是事后记录在日志中。

展望未来，您如何看待人工智能驱动的云原生环境中可观察性的演变？未来几年，您为 Kubiks.ai 制定了哪些发展路线图——更高的自动化、更深的智能化，还是更广泛的集成？

很快，企业将在云端同时运行数百万个代理，需要清晰地了解哪些代理被称为什么、何时运行以及使用哪些数据。可观察性将不断发展，以提供对这些动态系统的实时洞察，并深入LLM内部以了解其决策。对于Kubiks，我们专注于代理级别的端到端跟踪：提示、参数、模式、工具、输入和输出。这将帮助工程师及早发现威胁、边缘情况和异常，使复杂的AI环境更加可靠且更具可操作性。

感谢您的精彩采访，想要了解更多信息的读者可以访问 库比克斯.