斯特鲁德尔的Kristin Isaac，CEO兼联合创始人 – 采访系列

Kristin Isaac，斯特鲁德尔的CEO和联合创始人，是一位拥有丰富企业技术领导经验的资深专业人士，她曾在LinkedIn、Udemy、ESPN和迪士尼等公司担任过高级职务。在斯特鲁德尔，她专注于解决软件组织中最大的摩擦点之一：客户支持和工程之间的差距。斯特鲁德尔正在建设一个由AI驱动的平台，帮助技术支持团队通过将支持请求直接连接到工程智能来更快地解决复杂问题。她的背景在扩展团队、构建市场策略和推动全球组织的增长方面有所体现，这些经验帮助斯特鲁德尔在企业AI和开发者工具市场中获得了快速的发展势头和强大的竞争地位。

斯特鲁德尔是一个旨在通过分析日志、生产数据、代码仓库和过去的支持历史来识别根本原因和推荐解决方案的AI平台。其目标是减少解决困难支持案例所需的时间和工程努力，特别是那些通常消耗高级技术资源的升级案例。通过直接将支持连接到潜在的技术问题，斯特鲁德尔将自己定位为一种可以使企业支持运营更快、更高效和更可扩展的工具。

您曾在LinkedIn、Udemy和迪士尼等公司担任过领导职务，然后在2025年创立了斯特鲁德尔。在这些职位中，您获得了哪些经验，最终使您相信工程团队需要一种新的AI驱动的“工程智能”平台？这些见解如何影响了斯特鲁德尔的创立?

每家公司都有同一个问题的不同版本。在迪士尼，风险非常高——如果在主要发布期间流媒体平台崩溃，不仅仅是收入损失，也是品牌形象受损。在LinkedIn，规模是无情的——成千上万的服务都在产生噪音，即使是最好的团队也难以跟上。在Udemy，我看到一个精简的团队用有限的工具做着英雄般的工作。

连接所有这些的，是工程师们花更多时间重建上下文，而不是实际解决问题。有人在凌晨2点被叫醒，然后在开始诊断之前，他们必须搜索Slack线程、仪表盘、Jira票、部署日志——只是为了了解发生了什么变化以及何时发生。他们基本上是在做侦探工作，而不是做他们的实际工作。这是一种对非常有才华的人力的浪费。

我一直在想：一定有更聪明的方法来呈现真正重要的信息，当它重要时。斯特鲁德尔的种子就是这样。

许多公司通过失去收入或SLA罚款来衡量停机的财务影响。在您的经验中，停机的隐性成本是什么，组织通常会低估这些成本?

收入数字进入董事会议室，但停机的直接财务影响只是冰山一角。组织经常忽略的成本可以分为几个类别。

第一个是客户信任。SLA罚款是法律构造——它们不能捕捉到那些在错误时刻看到状态页面并选择竞争对手的客户的损失。这种损害是缓慢的、不可见的，并且在某种意义上是永久的，以一种简单的退款支票无法弥补的方式。

第二是工程师离职和倦怠。值班疲劳是真实存在的。当您的最佳工程师反复被拉入高压力事件中——尤其是那些本可以预防的事件时，他们开始质疑是否这是他们职业生涯的正确位置。用一年到两年的年薪来计算，替换一名高级工程师的成本非常高，因为您需要考虑招聘、入职和失去机构知识的成本。没有人在事后总结中提到这些成本。

第三是机会成本。工程团队每花一个小时在扑灭火灾上，就意味着他们没有花时间在构建产品上。这种成本很难在电子表格上量化，但在几个月内，它会悄悄地破坏您的路线图。

工程师经常被拉离构建新功能的工作来响应生产事件。这种持续的扑灭火灾如何影响产品创新和长期开发路线图?

它对工程团队的带宽构成了税收。每个团队都有有限的带宽，当大量带宽被持续重定向到事件时，产品开发的复合效应非常严重。路线图承诺被错过。技术债务没有被偿还。由于时间压力，功能以较少的严谨性发布。

特别有害的是这种不可预测性。团队可以用良好的意图计划他们的冲刺，但然后在星期二发生一个重大事件，其他一切都变得次要。这种持续的不可预测性使得建立深度工作文化几乎不可能——而这最终是驱动最佳工程成果的因素。

这也会产生一个自我强化的循环。延迟投资意味着更多的事件，这意味着更多的扑灭火灾，这意味着更少的时间来投资于潜在的问题。在斯特鲁德尔，我们正在专门为每天生活在这种现实中的SRE团队构建解决方案。

斯特鲁德尔通过连接客户支持数据、日志、生产系统和代码仓库来更快地识别根本原因。AI如何以传统监控工具无法做到的方式将这些不同的技术信号整合在一起?

传统的监控工具基本上是警报系统。它们非常擅长告诉您某些东西已经超过了阈值——延迟峰值、错误率上升、Pod崩溃。然而，它们无法跨领域进行推理。

它们不知道支付服务中的错误率峰值发生在对依赖项的部署四分钟后，并且大约在同一时间，客户支持票中提到了结账失败，并且六个月前在数据库迁移期间，日志中出现了类似的模式。

这种跨领域的关联正是AI使其成为可能的。我们可以将Zendesk票、GitHub提交、Datadog跟踪和CloudWatch日志视为一个统一的故事，而不是孤立的数据点。AI不仅仅呈现出什么是破碎的，还呈现出可能的原因和位置——并以人类工程师可以验证和采取行动的证据为基础。我们不会要求团队相信一个黑盒子。我们给他们一个经过深思熟虑的假设和一个领先的机会。

您将斯特鲁德尔描述为提供“工程智能”。在实践中，这个概念是什么意思，它与传统的可观察性或AIOps平台有什么不同?

可观察性基本上是关于仪器和可见性——确保遥测存在并且团队可以查询它。AIOps在其大多数当前实现中是关于通过基于机器学习的关联和异常检测来减少警报噪音。两者都非常有价值，我们与它们集成。

但是工程智能是一个更高层次的东西。我们正在扩展AIOps所做的事情。AIOps告诉你出了什么问题，工程智能帮助你了解为什么出了问题，问题从哪里开始，以及如何解决它——从整个技术栈中提取信号，包括传统AIOps工具不看的来源，例如客户支持票或代码更改。目标不仅仅是减少噪音。它是给你的团队一个完整的、可行的图景，以便他们可以更快地解决问题并回到构建中。

可以把它想象成烟雾探测器和火灾调查员之间的区别。可观察性和AIOps是烟雾探测器——必不可少的，但它们在警报处停止。工程智能是之后发生的事情：这里发生了什么，为什么，哪里开始。

AI代理越来越多地被部署来自动化复杂的技术工作流程。在未来五年内，您认为AI代理在诊断和解决软件事件方面将扮演什么角色?

我认为更有趣的问题不是代理会做什么——而是工程师会停止做什么。最好的工程师我曾经合作过的人，并没有进入这个领域来花费他们的夜晚来处理警报或在日志中搜索配置更改的内容。那不是他们擅长的工作。但那却是他们时间的巨大消耗。

在接下来的五年里，我认为代理将承担很多这种琐碎的工作——重复的、模式匹配的、上下文组装工作，这些工作很重要，但不是高级工程人才应该花费时间的工作。这样就可以让人们专注于复杂的问题、架构决策和真正需要人类判断的事情。

令人兴奋的是，这不仅仅是一个未来状态——我们现在就能看到这一点，包括在斯特鲁德尔。我们的整个路线图都围绕着从工程师的盘子上清除行政和维护工作。我们发现，这改变了团队可以做什么。你可以构建更多、移动更快、用更少的人来完成——因为你拥有的那些人专注于战略和复杂性，而不是重复性工作。这感觉像是一个有意义的团队建设和结构的转变。

当AI系统开始分析生产数据、代码库和操作日志时，工程团队在部署这些工具时应该考虑哪些治理或安全问题?

我在这里最坚持的一件事是：人类仍然应该审查进入生产的代码。

我与许多工程师讨论过这个问题，一个我反复听到的观点是：AI高效地编写bug，非常聪明地编写bug。真的很聪明。以一种真正很难被发现的方式，即使是仔细审查代码的高级工程师也很难发现。bug并不总是显而易见的。它们可能看起来在一瞥之间完全合理。

因此，当AI编写更多进入生产的代码时，我认为我们将看到更多这种微妙、难以检测的bug悄悄进入生产——不是因为有人粗心大意，而是因为AI生成的bug的性质不同。更难被审查发现，更难被测试捕捉到。

老实说，这也是为什么我认为斯特鲁德尔所做的事情的理由只会随着时间的推移而变得更加强大的原因之一。如果更多的bug进入生产，那么快速找到和解决它们的能力就变得更加重要，而不是变得不那么重要。治理问题不仅仅是关于数据访问控制和权限——虽然这些很重要，团队应该在向任何AI系统授予访问权限的数据方面保持谨慎。它还关乎在正确的检查点处保持人类的参与，特别是涉及生产的任何事情。

展望未来，您是否认为可靠性工程的未来将转向AI优先的基础设施，自治系统将监控、诊断，甚至在人类意识到之前解决问题？如果是这样，未来工程师的工作流程将是什么样子?

我认为我们正在朝这个方向发展，但我对时间表保持现实。完全自治的系统在没有人类意识的情况下解决生产事件——这不是我们现在的状态，我也不认为在接下来的几年内会实现。同时，我认为这也没关系。

我相信的未来是，循环变得更加紧密和不那么痛苦。未来我所期望的，不是人类从等式中被移除——而是那些被整合到流程中的人类，花费时间在真正需要他们的部分。判断。新颖的情况。您以前从未见过的事件。AI处理模式匹配、上下文组装、常规分诊。工程师处理决策。

对于工程师来说，我认为这看起来像这样：他们不再在半夜被叫醒处理不需要叫醒他们的事情，他们有更多的时间来构建不会崩溃的系统。扑灭火灾并不会完全消失。但是，它变得是例外，而不是在运行大规模软件的公司中作为工程师的默认状态。这是一个值得努力的未来。

感谢您接受这次精彩的采访，希望了解更多的读者可以访问斯特鲁德尔。