ku酷游官网-ku酷游网络股份有限公司

　　凌晨 2 点，你的手机突然震动。网站宕机了，Slack 上满是红色警报，用户已经开始在推特上抱怨。你半睡半醒地盯着屏幕，完全不知道该从哪里着手排查。

　　这是站点可靠性工程师（SRE）们再熟悉不过的场景。这些工程师必须不惜一切代价保障在线服务持续运行，而当服务中断时，压力值会瞬间飙升。故障恢复是一场与时间的赛跑，但大多数团队在真正开始排查问题前，就要花费第一个小时收集线索。

　　“最初五分钟是恐慌期，” 纽伯德（NeuBird）首席执行官兼联合创始人高瑟姆・拉奥表示，“接下来的 25 分钟是召集团队确认问题 —— 比如是代理错误，然后赶紧上 Slack、打电话、联系相关人员。” 应急指挥室迅速组建，电话会议紧急召开，团队之间相互指责，而故障持续的时间仍在一分一秒流逝。

　　拉奥对这种痛苦深有体会。这位连续创业者曾不得不从旧金山飞往阿姆斯特丹，在漆黑的数据中心里修复自己产品的漏洞 —— 只因为客户不允许远程访问。这次故障的持续时间，基本上就是他的飞行时间。他意识到一定有更好的解决办法，于是纽伯德公司应运而生。

　　这家初创公司得到了微软的投资，且与亚马逊云服务（AWS）建立了合作关系，其推出的产品正让上述繁琐的故障处理流程成为历史。这款名为 “鹰眼”的产品是一款人工智能驱动的 SRE 工具，能在你的团队还没完全清醒时就自动展开故障调查。拉奥强调，这绝非另一款用于查询日志的聊天机器人，而是一个能形成假设、通过遥测数据验证假设，并最终告诉你实际故障点的智能体系统。

　　拉奥表示，SRE 自动化的实现早已箭在弦上。支撑现代软件运行的架构，恰恰也是让故障排查变得极为棘手的根源。在过去二十年里，面向服务架构成为了行业标准，因为它能让团队更快地开发产品。然而，这种架构也形成了一张错综复杂的依赖关系网，很少有人能完全理解。这些复杂系统中，在一个系统中进行的微小操作，可能会导致数千英里外的另一个系统崩溃。

　　拉奥描述了这样一个场景：你的网站出现超时问题。凭直觉判断，这似乎是用户界面（UI）或 Web 应用层的问题，你可能会认为是前端出了差错。但真正的问题，其实是三层之下的某个数据库资源耗尽。

　　“网站运行缓慢的根本原因，与 Web 应用程序或计算资源毫无关系，而是因为容量不足，” 他解释道，“谁能想到会是这样？人们往往需要花费很长时间才能理清这些关联。”

　　本应提供帮助的工具，反而带来了新的问题。如今，AWS 环境中数千个资源会生成数百万个遥测数据点。你可以对所有内容进行监控，但更高的可见性往往意味着更低的清晰度 —— 这个问题被称为 “可观测性悖论”。

　　根据 AWS 的数据，70% 的警报需要工程师手动跨多个服务进行关联分析。通常情况下，工程师要花费 3 到 4 个小时调查复杂故障，这还不包括实际修复问题的时间。

　　拉奥很快指出，这并非要取代人类。“这不是用更少的人做同样的事，” 他说，“在任何创新周期中，情况从来都不是这样。真正的价值是用现有资源做更多的事。”

　　智能运维（AIOps）市场早已拥挤不堪，许多工具只是在日志查询功能上套了个聊天机器人的外壳，就宣称是创新。而 “鹰眼” 正在进行结构性的创新 —— 如果你要将生产环境的安全托付给它，这种区别至关重要。

　　大多数企业级 AI 产品采用检索增强生成（RAG）技术：将文档输入大型语言模型（LLM），进行向量化处理，然后就相关内容提问。这种方法适用于企业知识库和政策文件，但如果用于 IT 遥测数据，就会完全失效。

　　“你不能把所有 IT 遥测数据都复制到 ChatGPT 中，然后说‘帮我解决问题’，” 拉奥解释道，“这根本行不通。” 这些数据是由日志、追踪信息、配置数据和时间序列指标构成的动态集合，且以毫秒级的粒度捕获。你不可能把所有这些数据都输入提示窗口，还指望得到有用的结果。

　　智能体系统则颠覆了这种思路。它不是将内容输入 LLM 再提问，而是让 LLM 先确定自己实际需要哪些信息，然后从数据源中精准提取。LLM 生成的是调查程序，而非自然语言答案。

　　这正是 “上下文工程” 比 “提示工程” 更重要的地方。拉奥用医学类比来解释这种区别：即使是世界上最好的医生，如果患者无法准确描述症状，也无法做出准确诊断。

　　“LLM 的问题在于，无论你问什么，它总能给出答案，” 他说，“这对生产系统来说是个大问题，因为你不想误导他人。” 如果给 LLM 提供了错误的上下文，它会信心满满地去解决一个根本不存在的问题。关键在于，要确保它在开始推理之前，向正确的数据源提出正确的问题。

　　“鹰眼” 的底层是纽伯德公司自主研发的 “渡鸦 AI 表达式语言（RAEL）”。这是一种结构化语法，能让 LLM 创建可验证的调查程序，而非自然语言响应。这些程序可以被验证和编译，从而消除调查过程中的幻觉问题（即 AI 生成虚假信息）。

　　“对我们来说，智能体系统是专家系统与生成式 AI 认知能力的结合体，” 拉奥解释道。该系统将专家系统的可靠性与生成式 AI 的创造性融为一体，既具备足够的结构性以确保可信度，又拥有足够的灵活性以应对新情况。

　　将调查技术编码化的能力，让工程师能够随着时间的推移调整调查流程。用通俗易懂的英语告诉 “鹰眼” 下次更关注网络问题，其底层的 RAEL 语法（由 LLM 自行创建）就会相应调整。你不是在配置一个静态的规则引擎，而是在训练一个认知系统。

　　有一位客户就发现了这一功能：当时 “鹰眼” 无法解释 DNS 请求突然下降的原因，最终查明根源是外部 Cloudflare 的故障，而 “鹰眼” 之前无法获取相关可见性数据。该客户随后在未来的调查中添加了 Cloudflare 状态检查功能 —— 这个系统在不断学习。

　　“鹰眼” 也并非依赖单一的 LLM 运行。纽伯德采用了拉奥所说的 “模型舰队”：有些模型更适合时间序列分析，有些则擅长解析 JSON 结构。目前的模型组合包括 Anthropic 的 Claude 和各类 GPT 模型，不过其架构设计允许随着市场发展更换模型。企业也可以接入自己的 Bedrock 模型，在使用 “鹰眼” 调查框架的同时，消耗已承诺的云服务预算。

　　该平台原生集成了 AWS 的多项服务，包括 CloudWatch、EKS、Lambda、RDS 和 S3，同时也支持 Azure 和本地部署环境。Dynatrace、Splunk 和 Prometheus 等标准可观测性工具栈开箱即用。对于使用自研工具的企业，模型上下文协议（MCP）可为专有系统提供连接桥梁。

　　安全性将是潜在用户的主要顾虑。“鹰眼” 仅拥有只读权限，且不存储任何遥测数据，仅保留一些用于标识环境特征的元数据，例如 EC2 实例数量或 Kubernetes 集群信息。对于需要额外隔离的企业，该平台提供完整的虚拟私有云（VPC）部署选项 —— 所有处理过程都在 VPC 内部进行，数据永远不会离开用户的 AWS 环境。

　　“鹰眼” 仅提供建议，不会自动执行修复操作 —— 这是刻意设计的。“我们特意限制了它的执行权限，” 拉奥解释道，他认为智能体系统对很多人来说有点像自动驾驶汽车：概念很酷，但还不够成熟，不足以让大多数人完全放手。不过，对于愿意自动化重复操作的客户，纽伯德也提供了相应的自动化选项。

　　一些完全无风险的操作（例如切换功能标志）是允许的 —— 这类功能标志本身已经过测试，其可能产生的后果也已明确。但编写代码或修补 Helm 图表？目前还不支持。

　　顾虑在于：95% 的成功率伴随着 5% 的严重失败，可能会彻底破坏人们对智能体系统的信任。因此，目前最好让人类参与决策循环，逐步建立信任。

　　当 “鹰眼” 无法解决某个问题时，它会如实告知。该系统会根据实际遥测数据验证自己的结论，因此最坏的情况是承认不确定性，而非信心满满地误导用户。它还有一个有趣的后台功能：利用相互竞争的 LLM 对彼此的发现进行辩论。这种辩证过程能让结果经过合理性检验，变得更加可靠。

　　“鹰眼” 的仪表盘会生成报告，显示每次调查节省的预估时间。定制技术解决方案提供商 Model Rocket 运行着包含 Lambda、RDS、ElastiCache 和 EKS 的复杂环境，部署该平台后，其平均恢复时间缩短了 90% 以上。

　　纽伯德处于一个有利地位：微软是其投资方，该公司还参与了雷德蒙德（微软总部所在地）的精英项目 Pegasus，得以接触到Adobe欧特克Autodesk）和雪佛龙等企业客户。在 AWS 方面，纽伯德入选了多个 AWS 项目，包括生成式 AI 加速器计划，并获得了生成式 AI 能力合作伙伴认证，其 “鹰眼” 产品也已在 AWS Marketplace 上架。

　　能取得这些成就，部分原因在于纽伯德明白：智能体 AI 并非配置一次就可以抛之脑后的软件。“你必须把它当作一个认知实体、一个认知系统 —— 因为这正是它的核心本质，” 拉奥说，“训练它、与它协作、给它反馈、让它参与协同工作。它不是一个非黑即白的二元系统。”

　　凌晨 2 点给 SRE 们打来的紧急电话不会消失。基础设施总会以各种意想不到的方式在不合时宜的时间发生故障。但如果纽伯德的愿景能够实现，那么当你穿着拖鞋、端着咖啡走到办公桌前时，“鹰眼” 可能已经在顺利推进根本原因分析了。