或者说，输给了即将到来的“代码垃圾”海啸。
先问个扎心的问题：DevOps 这二十年，到底在折腾什么？
是打破部门墙？是让运维写代码？还是天天喊着“同理心”？
回顾过去二十年，我认为 DevOps 运动本质上只为了达成一个目标：建立一条连接开发者与生产环境的单一反馈循环。
以此为标准，它失败了。
不是因为工程师不努力，也不是因为大家没情怀。失败的原因很残酷：工具太烂了。
我们给开发者的工具，根本不是为了这个目标设计的。用这些工具，写业务逻辑的时间会翻倍，甚至翻三倍、四倍。
当然，如果你有无限的时间、金钱和顶级大神，什么工具都能用。甚至有人真用 Excel 跑过生产环境。但这不代表它是个好方案，更不代表普通公司玩得转。
好消息是，AI 改变了一切。现在的技术终于能让普通工程团队建立起开发者与生产环境的连接。
坏消息也是，AI 改变了一切。现有的反馈循环根本没准备好面对即将到来的“代码垃圾”海啸。
你在“盲飞”吗？
如果你的业务靠软件赚钱，进步只有一种样子：构建新功能 -> 部署给用户 -> 看看发生了什么。
这就是价值生成的理论闭环。Intercom 的人说过，“发布是你们公司的心跳”。
每一次部署，都是一次学习的机会。
频繁发布，意味着频繁学习。
甚至更频繁。
看这满满的学习量！
但是，如果你部署了新代码，却不去观察呢？
如果你不观察，你就什么都学不到。
你的部署变成了一个“开环”。你在盲飞。
这就是可观测性的意义：它是所有反馈循环的感官机制，是连接点与点的信息通道。
开发者只关心测试通过，这很危险
现实中的开发者，一天大部分时间都在开发环境里度过。
构建 -> 测试 -> 学习。这就是驱动他们日常工作的真实循环。
如果测试通过，同事批准代码，合并！开心的一天。接着做下一个任务。
通过测试，我们学到了什么？我们学到了——测试通过了。
仅此而已。
从业务角度看，运行测试学不到任何新东西。所有这些工作都很重要，但在你部署到生产环境之前，你无法真正学到任何东西。
记住这句话。
运维是守门员，而不是建筑师
再看看生产环境的反馈循环。
大多数开发者不会天天盯着生产环境，除非他们在抓 Bug。谁在盯着？运维、云工程、基础设施、SRE、DevOps 或者平台工程。
不管叫什么，总得有人处理运营反馈循环。他们是系统面对永恒威胁时的最后一道防线。用足球术语说，他们是守门员。
运营反馈循环总是被动的。有时候你知道刚改了什么，但更多时候，你根本不知道原因。
流量异常？新版本客户端？数据库 Bug？两年前的 Bug 突然爆发？可能性无穷无尽。
基础设施肮脏的小秘密是：经常发生一些我们根本无法理解的事情。
这很大程度上是因为这些反馈循环太长、太滞后、损耗太大。
这两个循环都至关重要，但它们关注的点完全不同。
运维（或平台）的职责是提供一个稳定、可靠的地方来运行代码。
为了做到这一点，他们收集磁盘、Pod、网络设备、数据库等系统组件的遥测数据。
而开发者关心的是从每个客户视角理解产品体验。
他们需要把各种数据切片、组合，探索开放式的问题。
打个比方：运维是建筑检查员，开发者是建筑师。
检查员只负责找违规、结构问题、安全隐患。建筑师负责想象能造什么、人们怎么用空间、什么能让人惊喜。
别再逼开发者看仪表盘了
去年在 LDX Berlin，我和很多人聊了聊。事后我意识到，超过一半的问题——来自资深工程师、总监、高管——都在问同一个主题：
“但我怎么让我的开发者去看他们的仪表盘？”
这可能是第一次我真正意识到，这对开发者来说有多令人沮丧。
想想看。你和你的 AI 搭档正在做一个新结账功能。你想抓点数据，比如 user_name 和 order_total。
它们该放哪？
- 放指标里？
- 放日志里？
- 放追踪里？
- 如果结账失败，想看错误怎么办？
- 如果结账慢，想看性能分析数据怎么办？
这只是开始。如果是指标，是计数器？仪表盘？直方图？还是摘要？
如果是直方图，桶边界是多少？重置时间呢？基数呢？成本呢？命名规范呢？
好不容易搞定了。那日志和追踪呢？要加索引吗？能加吗？有模式吗？
这种决策疲劳太可怕了。
好吧，假设你终于搞定了插桩。现在，部署代码，找到工具，创建仪表盘。
然后呢？在经历了所有的折腾、等待、点击之后，你得到了什么？聚合数据？直方图？该死的桶？
如果你想用这些工具来探索用户体验，问一些开放式问题，那你基本上回到了“用 Excel 跑生产环境”的时代。
把遥测送到开发者手边
不管我们吼了多少年，大多数开发者真的不想离开他们的开发环境（除了去摸鱼刷 Slack）也许他们是对的？
现在的解决方案不是逼他们去看，而是：把遥测带给他们。
聊天界面其实是询问软件运行状况的完美接口。
AI 彻底改变了插桩和分析的游戏规则。
过去，插桩既费力又需要多领域专业知识。OpenTelemetry 标准化了插桩方式，而 LLM 学会了这些模式。
插桩的成本实际上降到了零。
如果你的 AI 代理能在开发环境运行代码、检查输出、验证工作正常，那么当你准备好合并到生产环境时，你已经验证了插桩能从生产环境给你反馈。
自动的、端到端的反馈循环才是关键。
从“打字员”变成“科学家”
未来的形状越来越清晰了。
开发者将花更少的时间写代码行，花更多的时间写规范、思考问题空间、运行实验和验证构建。
以前是：写代码 -> 测试 -> 代码审查 -> 合并 -> “祈祷它能用！”
现在变成了：写代码（用 AI）-> 部署 -> 观察并验证 -> 学习 -> 迭代。
你把每次变更学到的东西，直接反馈到下一个产品变更中。
瓶颈从“我能写多快代码”变成了“我能多快理解发生了什么并做出正确决策”。
如果 AI 让写代码几乎免费，那么理解和验证代码在生产环境中的表现就成了主要约束。
工程师变得更像运行实验、解读结果的科学家，而不是把规范翻译成语法的打字员。
谁写的代码，谁负责？
这一切都很令人兴奋。
但有点可怕的是，大多数公司至今还在通过漫长、有损耗、滞后的运营反馈循环来学习和观察生产环境。
大多数组织习惯了白天报警时大喊：“谁刚才部署了变更？” 假设合并代码的人肯定理解代码并能迅速修复。
当没人写过你刚部署的代码，也没人真正理解它时，会发生什么？
我想我们（所有人）很快就会知道了。
DevOps 没有死。它做了很多好事，打破了孤岛，减少了大量苦活。
回想起来，整个努力就是为了试图将开发者与他们在生产环境中的代码后果连接起来。我们没有成功，但这绝非缺乏努力。
我们只是用当时的工具，尽力了。
现在，我们可以做得更好。
参考链接：
https://www.honeycomb.io/blog/you-had-one-job-why-twenty-years-of-devops-has-failed-to-do-it