“你只有一项工作”：为何二十年的 DevOps 仍未把它做好

本文信息来源：honeycomb

让我们从一个问题开始。DevOps 的核心究竟是什么？

• 同理心！
• 打破壁垒！
• 迫使运维工程师编写更多软件！

我来告诉你我的答案。回过头看，我认为整个 DevOps 运动是一场持续二十年的艰苦战斗，只为实现一件事：建立一个将开发人员与生产环境连接起来的单一反馈回路。

从这个角度看，它失败了。

失败并不是因为软件工程师不称职，或者不够用心。失败的原因在于技术本身不够成熟。我们交到他们手里的工具并非为此而设计，使用这些工具往往会让他们完成本职工作的时间——也就是编写业务逻辑——轻易地翻倍、三倍甚至四倍。

当然，这并非在所有地方都如此。请记住，如果你可以假设拥有无限的时间、资金和工程能力， 所有数据工具在本质上都是可以相互替代的 。如果不得已，你甚至可以用 Excel 电子表格来支撑生产系统，而且确实有一些 SRE 曾经这样做过 。但这并不意味着这是一个优秀的解决方案、资源的合理使用方式，或者对大多数工程组织来说是可行的选择。

好消息与坏消息

好消息是，AI 改变了这一切 。我们如今拥有的技术，首次让普通规模的工程团队也能够在开发者与生产系统之间建立起真正的反馈闭环。

坏消息同样是，AI 也改变了这一切 。我们现有的反馈机制还没有准备好应对当下如此庞大的“代码垃圾”规模。而我想我们都心知肚明，代码垃圾的数量接下来会走向何方：

（哦，对了，你猜我假期学会了什么？火柴人艺术，宝贝。）

我知道这是一个分量很重、也很“辣”的断言。而且，和任何人一样，当厂商发布“DEVOPS 已死”之类的标题党内容时，我也曾感到无比愤怒。所以，我打算退一步，从头开始展示我的论证。我并不是以指责或煽动性的方式在说这件事。事实是，我们所有人都在感知并围绕着同一个问题打转，而那个问题本身是正确的。在当时所拥有的工具条件下，我们已经尽力而为了。

创造价值的反馈回路

如果你的业务是通过构建软件产品来赚钱，那么进步的样子就是这样：你构建一些新东西，把它交付给用户，然后观察会发生什么。

这就是用软件创造业务价值的理论反馈回路。正如我们在 Intercom 的朋友们常说的那样：“发布是公司心跳的节律。”每当你部署一个新的 diff，这个创造价值的回路就会被启动。用火柴人示意图来表示，就是这样：部署 -> 观察 -> 学习。

之所以没有展示“Build”，是因为它不算数。只有当代码被部署之后，价值才会被捕获。这也是为什么软件专家总是不厌其烦地敦促我们要频繁发布 。就像这样：

或者甚至……

（看看这些学习成果！😍）

每一次部署都是了解你的产品、系统、用户、功能等的新机会。但如果你部署了新的代码，却没有进行观察呢？

如果你不进行观察，就学不到任何东西 。你的部署就成了一个开放回路 ，你是在盲目交付。

顺便说一句，这正是可观测性的作用所在。它是一种感知机制，使你所有其他反馈回路得以运转。它是连接各个点并闭合回路的信息通道。

现在，让我们从价值创造的理论回路，转向人们当下在开发新软件以及运营既有软件时所使用的实际反馈回路。

开发者的实际反馈回路

软件开发者通常一天中的大部分时间都待在他们的开发环境里。他们构建东西、运行测试，再构建更多东西，再运行更多测试。（或者，他们会与 Cursor 或 Claude 进行漫长、日益“亲密”的对话，讨论代理应该如何代他们完成这些事情；但为了简化起见，我们还是使用传统术语。）

构建->测试->学习，构建->测试->学习。这些才是驱动开发者日常工作的真实反馈循环。当我们准备合并时，可能会先进行代码评审。

如果所有测试都通过，而我们的同事也批准了，我们就合并代码！值得庆祝的一天。接着进入下一个工作单元。

运行测试让我们“学到了”什么？我们学到的是测试通过了。仅此而已。

测试很重要，但从业务视角来看，运行测试并不会让我们获得任何新的认知。所有这些工作都很重要，但你并没有学到任何东西。直到你将代码部署到生产环境之前，你不可能学到任何东西。先记住这一点。

接下来，让我们看看涉及生产环境的反馈循环。

真实的生产反馈回路

大多数开发者并不会每天都与生产环境打交道，除非他们在追查某个漏洞之类的问题。那是谁在做这件事？是你的运维团队——或者更常见的称呼是云工程、基础设施、SRE、DevOps，或平台工程。

不管你怎么称呼他们，总得有某个人来处理运维反馈回路。他们是在持续不断的威胁面前守护系统的最后一道防线。用足球来打比方，他们就是守门员。

只要有人被呼叫（或者顾客抱怨得足够激烈以触发升级流程），运维反馈回路就会被启动。无论白天黑夜、风雨无阻，总会有人登录生产环境进行调查、分级处理，并修复问题。

运行层面的反馈循环始终是被动的。有时你还能判断刚刚发生了什么变化（部署？迁移？），但更多时候却无法确定。异常的流量模式、新的客户端版本、数据库中的缺陷、两年前的一个漏洞刚好触及临界点……可能性不胜枚举。

它可能看起来更像这样：

或者这样：

基础设施领域一个不为人知的肮脏秘密是：很多事情发生得如此频繁，而我们却根本无法理解其中原因。其中一部分或许可以被草率地归结为复杂系统的涌现特性，但更多的问题源于这些反馈回路过长、滞后且信息损耗严重。

这两种反馈回路都至关重要

这里也许是一个合适的时刻，让我停下来强调一点： 两种反馈回路都不可或缺 。不存在孰优孰劣的问题。我们两者都需要。用 Stephen Jay Gould 的话来说，它们属于“互不重叠的权威领域”。（呃，当然，实际上它们确实有大量重叠。）

我之所以要把这一点说得非常清楚，是因为在这个行业里，我们很容易相互指责，动不动就变成：“你怎么这么蠢？”

“愚蠢的运维人员，为什么你们不在生产环境里一有变化就发出告警，这样我们就能从中学习？”

“愚蠢的开发人员，为什么你们在每次部署之后就不能去<em>看一眼</em>你们的图表？”

说实话，我对此感到相当内疚，因为我认为自己在很大程度上推动了后一种叙事。我已经记不清有多少次告诉别人“让你的开发人员值班！”好让他们更加关注生产环境。需要说明的是，我并不是在说这一定是个坏主意，也不一定是个好主意。我想说的是，这并不能解决问题本身。

运维和开发有着不同的视角

问题在于，这是两个不同的领域，它们在根本上拥有不同的视角。这并不一定意味着它们需要不同的工具（还记得我说过所有数据工具在本质上是可互换的吗），但它们值得被同等对待、同等考量。

运维视角

这里是最基本的运维/开发契约，以最简单的形式呈现。运维（或平台，或其他类似角色）为开发者提供一个运行其代码、查询等的环境。开发者则负责编写在其上运行的代码。

如果我们稍微拉远视角，并将复杂度简化约一千万倍，情况看起来就是这样：运维/平台/SRE 的职责是提供一个稳定、可靠的环境，让代码行能够执行。

为此，他们会从系统以及其各个组成部分的视角收集大量遥测数据：磁盘、Pod、网络设备、数据库等等。其中大多数是第三方代码，你无法修改；你只能被动接受它们发送给你的指标或日志 。

开发者的视角

开发者关心的是，是否具备从每一位顾客的视角来理解产品体验的能力。在实践中，这可能意味着代理、用户、移动端设备类型、笔记本电脑、电脑端、销售终端设备等各种组合或排列。

他们还需要能够对这些数据进行切片、拆解和组合，并与构建 ID、提交标签、 功能标志 、容器 Pod，以及应用程序遥测所采集的任何其他信息进行任意组合。

开发者不可能亲自接触世界上每一部手机、每一台笔记本电脑和每一个销售终端设备。但如果使用合适的工具，他们可以将这些遥测数据以流的方式回传到应用程序中，并以一种保留其从系统层面进行探索、提出开放式探索性问题能力的格式呈现。

运维和开发关注点不同

运维和开发的关注点也各不相同。

运维侧的反馈回路是为了保护系统及其组件免遭灾难性威胁。只要系统没有故障、没有损坏、没有漏洞、没有性能迟缓等问题，运维大多并不关心——这不在他们的职责范围内。

而开发者则非常在意超出漏洞和灾难之外的事情。开发者的工作是为业务创造新的价值：构建产品、实现功能、开展实验。尝试新事物，看看用户是否愿意接受并持续使用。

可以这样理解：运维是建筑检查员，开发是建筑师。检查员只会出现来查找违规代码、结构问题和安全隐患；而建筑师把大部分时间花在设想能建造什么、人们会如何使用这个空间、什么会让他们感到愉悦。两者都关心安全，但检查员的全部工作都是风险管理，而建筑师的工作关乎可能性。

“我该如何让我的开发者去看看它 ？”

去年 11 月，我在柏林的 LDX 大会期间与不少人交流。事后回想起来，我意识到我听到的问题中， 超过一半 ——来自 staff+ 工程师、总监以及高管——都只是同一个主题的不同变体：“ 可我到底该怎么让我的开发者去看它呢？”［指他们的仪表盘］。

这可能是我第一次真正从头到尾地认真思考，这件事对开发者来说究竟有多么令人沮丧和困惑。

使用运维工具为你的代码添加监控埋点：并不容易

想一想。你和你的伙伴 Claude 正在一起构建一个新的结账功能，你希望采集一些有价值的遥测数据，比如 user_name 和 order_total。它们应该放在哪里？

• 它们应该作为指标（metrics）吗？
• 它们应该写入日志（logs）吗？
• 还是应该成为一次 trace 的一部分？某个 span？
• 如果你想在结账失败时同时查看这些信息呢？
• 如果结账变慢时想看到性能分析数据呢？

系好安全带，我们才刚刚开始。如果它是一个指标，它应该是：

• 计数器？
• 仪表？
• 直方图？
• 摘要？
• 速率？
• 分布？

如果是计数器，它什么时候重置？如果是直方图或摘要，桶的边界在哪里？我需要打什么标签吗？cardinality 是否重要——对数据本身和/或标签而言？我是不是还得考虑成本？有没有命名规范？

假设你已经搞定了指标这一块。那它们是否也需要进入日志或追踪？所有信号类型都要吗？是把它们追加到现有的某条日志行（哪一条？），还是新建一条？它们需要索引吗？ 能给它们建索引吗？有没有模式（schema）？

我们还可以再问上五页左右的问题。我不知道自己是否真的认真思考过，当我们让开发者去做这些事情时，究竟预设了多少领域知识。所有那些时间、恐惧和决策疲劳……都会不断累积。

至少这是一次性的投入，之后就一劳永逸了，对吧？最终一切都是值得的？

啊，对了，说到这个……

用运维工具来找到你的遥测数据： 同样不容易

要查看你新增的监测埋点，通常只需要等代码部署完成，然后为你添加的遥测数据找到合适的工具（或多种工具），并基于这些属性创建一个新的仪表板。我会直接快进跳过这些步骤，因为这在很大程度上取决于具体厂商，而细节本身并不重要。

我想回到大家在柏林问我的那个问题： 如何让你的开发者主动去查看他们的遥测数据 ？

答案是：你做不到。

我们现在已经具备了这样的技术。 我们把遥测数据送到他们面前。

把遥测数据带给开发者

不管这些年来我们花了多少时间对他们大喊大叫，大多数开发者真的并不想离开他们的开发环境（除了去用 Slack 之外，什么都不想）。

如果一直以来他们都是对的呢？

来看看这个演示吧。只有 3 分 37 秒，展示了 Jessitron 演示我们去年 9 月发布的一些 AI 能力。如果你没耐心，想直接看看它在你的开发环境中的样子，可以快进到 2 分 21 秒。

事实证明，聊天几乎是用于“拷问”你的软件、了解其在生产环境中运行状况的完美接口。

为他们提供可用的遥测数据

三支柱可观测性带来的认知负担，是我们长期以来难以让开发者使用运维工具的原因之一。另一个原因更简单： 这些工具不值得 。

想象一下，你完全照着运维的要求去做——为了把合适的埋点加进去，你把交付业务逻辑的时间翻了一倍、甚至三倍。你发布了改动，然后想去看看这些改动对用户使用产品的体验产生了什么影响。最终，在经历了无数次折腾、等待和来回点击之后，你得到的却是……汇总值？直方图？该死的桶 ？

如果你试图用这些工具去提出关于用户实际体验下产品质量的探索性、开放式问题，那你本质上就是在“用 Excel 表格来运行生产系统”。

AI 改变了可观测性埋点的游戏规则

过去，埋点工作既繁琐又需要跨多个领域的专业知识，而自动埋点往往在“做得过多而失效”和“做得过少而无用”之间来回摇摆。

OpenTelemetry 通过标准化代码埋点方式改变了这一局面，使埋点模式保持一致且有完善文档，并积累了海量示例。LLMs 正是在这些基础上接受训练，因此能够按照指令实现埋点，或将其添加到软件项目中。

埋点的成本实际上已降至零，AI 模型和智能体能够理解你代码中的关键模式，并基于它们已掌握的埋点模式进行泛化。

AI 已经改变了分析领域的玩法

如果你的代理式胸背带能够在开发环境中运行你的代码、检查输出、验证其是否按预期工作等，那么当你准备将变更合并到生产环境时，你其实已经验证过：这些监控与埋点能够在生产环境中把自身状况清楚地反馈给你。

自动化的端到端反馈回路才是关键。与其花上数小时翻查追踪数据，寻找异常值和可疑的症状……不如让你的小伙伴来做。与其把 IDE 放在屏幕左侧、把冗长而详细的追踪日志放在右侧，然后逐行、逐跨度地分析……也让你的小伙伴来完成这些工作。

从运维工具和传统模型中获取你所需的信息，并非不可能的任务 。确实有不少工程师和团队做到了。但这并不意味着这是一个优秀的解决方案、资源的合理使用方式，或是对大多数工程组织而言可负担、可落地的选择。

AI 已经改变了对验证的需求

未来的形态正变得愈发清晰。开发者将花更少时间逐行编写代码，把更多精力投入到编写规格说明、思考问题空间、进行实验，以及验证他们所构建的成果上。

不再是：写代码 → 测试 → 代码审查 → 合并 → “但愿能跑！”

这变成了：编写代码（借助 AI）→ 部署 → 观察与验证 → 学习 → 迭代。

看到了吗？你实际上是在把每一次变更中学到的东西，直接反馈到下一次变更的产品中。以 AI 的速度， 充满信心地快速交付。

瓶颈从“我能多快写代码？”转变为“我能多快理解正在发生的事情，并据此做出正确决策？”

如果 AI 让写代码几乎变得没有成本，那么在生产环境中理解并验证这些代码实际做了什么，就会成为最主要的约束。

工程师将更像是在进行实验并解读结果的科学家，而不再只是把规格说明翻译成语法的打字员。

迎面呼啸而来的货运列车

这一切都令人无比兴奋，乐趣无穷。

稍微令人恐惧的是，直到今天，大多数公司仍然通过冗长、失真且滞后的运维反馈回路来完成对生产环境的所有学习与观察。

而且大多数组织已经习惯于在白天收到告警时高声喊一句：“是谁刚刚发布了这个变更？”并假定合并了该差异的人必然理解其工作原理，能够迅速在事后修复。

当你刚刚部署的代码根本没有人写过，而且也没有人真正理解它时，会发生什么？

我想我们（所有人）都会拭目以待。😉

DevOps 并未消亡

DevOps 运动并没有“死亡”。它为整个行业带来了巨大的积极影响：打破了组织孤岛，倡导同理心与协作的价值，并大幅减少了繁重的重复性劳动。

回顾来看，我逐渐意识到，这一切努力的核心在于试图将开发者与其代码在生产环境中产生的后果真正连接起来。我们并未成功，但绝非因为不曾尽力。我们是在现有工具条件下，尽了最大的努力。

而现在，我们可以做得更好。