本文作者：Alan Shimel。作为《DevOps.com》和《Container Journal》的总编辑，艾伦·希梅尔对科技领域十分熟悉。艾伦创办并协助了多家科技企业，包括 StillSecure，在该公司期间，他带领公司向市场推出了创新且高效的网络和安全解决方案。希梅尔是安全和科技界经常被引用的人物，也是行业及政府会议和活动中备受欢迎的演讲者。除了在《DevOps.com》和《Network World》上发表文章外，他关于科技现状的评论还通过其博客和播客《Ashimmy, After All These Years》（www.ashimmy.com）受到众多行业内部人士的密切关注。艾伦凭借深厚的商业背景和渊博的科技知识，助力多家科技公司取得了成功。他的法律背景、在该领域的长期经验以及纽约街头智慧，共同塑造了他独特的个人特质。
译者注：本文的原标题是《从可观测性到可操作性：为何仅有指标远远不够》。原文很有洞见、引发思考。海量的指标、花哨的仪表盘、炫酷的拓扑图都很好，但切记不要忘了我们最终的目标：让数据给人洞察，辅助人决策和行动，即最终的 Actionability。
我们创办快猫星云，构建可观测性产品和解决方案，对外一直讲的理念是：我们更加面向故障处理过程，侧重点是加速故障定位，和 Shimel 观点很有共鸣，故翻译此文以飨读者。
核心摘要
- 可观测性已经完成了从传统监控到指标、日志、追踪三大支柱的进化，但“看得更多”并不等于“解决得更快”。
- Actionable Observability 的关键，是把遥测数据转化为可执行的故障定位、发布决策、SLO 管理和自动化修复动作。
- 仅堆积仪表盘和告警会带来告警疲劳、上下文割裂、人工关联成本高，以及平均恢复时间难以改善等问题。
- 平台工程和内部开发者平台应把可观测性嵌入黄金路径，让开发者获得和代码、发布、用户体验相关的反馈，而不是被迫解读几十张图表。
- 自动化必须有边界。目标不是用机器取代工程师，而是让机器处理重复性修复，把人的判断留给高风险决策和策略设计。
什么是 Actionable Observability？
Actionable Observability，可以理解为“可操作的可观测性”或“面向行动的可观测性”。它不止回答“系统发生了什么”，还要进一步回答“这件事意味着什么”“影响了谁”“下一步该怎么做”，并在合适的场景下触发自动化动作。
传统可观测性强调收集和展示遥测数据，包括指标、日志和分布式追踪。Actionable Observability 则强调从数据到行动的闭环：
- 收集关键遥测数据，理解系统内部状态。
- 关联日志、指标、追踪、发布变更和用户体验。
- 判断问题优先级，区分噪音、异常和真实影响。
- 给出明确处置建议，辅助工程师快速定位。
- 在可信场景中自动回滚、重新路由、扩容或执行修复。
因此，Actionable Observability 不是替代可观测性，而是让可观测性从“数据基础设施”进入“故障处理和运营决策系统”。
可观测性为什么走到了转折点？
不久前，云原生社区似乎已经在可观测性方面取得了胜利。我们拥有三大支柱，即指标、日志和追踪，也拥有一系列 CNCF 项目和开源工具来收集这些数据。Prometheus、Grafana、OpenTelemetry、Fluentd 等工具，让可观测性成为现代 DevOps 和平台工程的重要组成部分。
但任何 SRE（网站可靠性工程师）或平台工程师都会告诉你：仪表盘越来越多，警报不断触发，而实际问题也层出不穷。我们比以往任何时候都观察得更多，但对于所看到的信息，我们真的能更好地利用吗？
一个令人不安的事实是：可观测性已经进入停滞期。我们已经掌握了数据收集的艺术，但真正的挑战变成了如何将海量遥测数据转化为实际行动。
从监控到可观测性的演进
第一代监控很简单，主要是运行时间检查、CPU 图表和 Nagios 警报。这些能力有用，但无法应对微服务和分布式系统的复杂性。
随着 Kubernetes 和微服务架构的迅猛发展，团队需要更深入的系统理解。可观测性不再只问“它是否在运行”，而是开始追问“系统内部到底发生了什么”。
- Prometheus 为团队提供了丰富的指标。
- Fluentd 和 ELK 让日志可以被大规模索引和检索。
- Jaeger 和 OpenTelemetry 让分布式追踪成为现实。
- Grafana 为这些数据提供了可视化仪表盘。
“日志、指标、追踪”成为云原生生态系统的基石。公平地说，这是一次巨大进步。但进步不等于终点。
为什么只有指标和仪表盘远远不够？
问题在于，更多的数据并不必然意味着更多的洞见。可观测性一旦停留在“收集和展示”，就很容易变成走过场式的选项：数据存在，图表漂亮，但故障仍然需要人肉排查。
常见问题包括：
- 告警疲劳：工程师淹没在大量无用告警中，其中很多并不需要立即行动。
- 仪表盘蔓延：每个团队都构建自己的面板，但很少有人能统一理解业务影响。
- 相关性缺口：日志、指标和追踪数据通常孤立存在，需要人工把它们拼接起来。
- 恢复效率不足：即使数据更多，许多组织的平均恢复时间也未必显著改善。
换句话说，仅有可观测性并不能保证行动能力。关键问题不是“你是否拥有数据”，而是“你能否快速、果断、可信地根据这些数据采取行动”。
Actionable Observability 的能力总览
| 能力方向 | 传统可观测性关注什么 | Actionable Observability 进一步解决什么 |
|---|---|---|
| 数据采集 | 收集指标、日志、追踪 | 保留和故障定位、用户体验、业务影响相关的关键上下文 |
| 关联分析 | 分别查看图表、日志和链路 | 将遥测数据、发布变更、服务依赖和 SLO 放在同一语境中分析 |
| 告警处理 | 发现异常并通知人员 | 降低噪音，突出需要行动的信号，并给出处置方向 |
| 发布验证 | 人工观察发布后的指标 | 基于实时遥测数据推进或回滚金丝雀发布、蓝绿部署 |
| 故障修复 | 工程师手动排查和处理 | 对已知模式触发重启、流量重路由、资源分配等自动化动作 |
| 团队协作 | 依赖经验理解图表含义 | 将下一步动作嵌入开发、运维和平台工程工作流 |
这张表的重点不是制造新的概念层级，而是明确可观测性需要进入工作流。只有进入工作流，数据才会真正服务于故障处理和业务连续性。
从可观察到可行动：行业正在发生什么变化？
行业已经开始意识到，仅具备可观测性是不够的。我们真正需要的是可采取行动的可观测性。它意味着从数据收集转向决策支持，再从决策支持转向自动化行动。
几个趋势正在指向这个方向。
AIOps：用分析能力过滤噪音
人工智能驱动的分析，也就是 AIOps，试图利用机器学习排除干扰、识别异常，并突出真正重要的信号。它的价值不在于制造更多告警，而在于帮助工程师更快区分“背景噪音”和“需要处理的事件”。
持续验证：让遥测数据参与发布决策
持续验证将可观测性与渐进式交付相连接。金丝雀部署和蓝绿部署不应只依赖人工观察，而应根据实时遥测数据自动推进或回滚。
自动修复：处理已知模式下的重复动作
当系统检测到已知故障模式时，可以自动采取纠正措施，例如重启服务、重新路由流量或分配资源，而不必等待人工操作。这里的前提是模式明确、风险可控、结果可验证。
SLO 驱动运营：从资源指标转向用户体验
SLO 驱动的运营，会把注意力从原始指标转向服务级别目标。相比“CPU 使用率 80%”，与用户体验和业务结果相关的目标更能帮助团队判断是否需要行动。
这就是观察与行动之间的区别。
现实世界里的信号
这种转变已经在云原生生态中出现。
- OpenTelemetry 正从追踪领域拓展，通过语义上下文整合日志和指标，使关联分析更具可操作性。
- Keptn 和 Argo Rollouts 将可观测性集成到交付管道中，实现了金丝雀分析的自动化。
- 云服务提供商正将异常检测和人工智能驱动的建议整合到他们的可观测性堆栈中。
- 具有前瞻性的平台团队正在使用遥测技术，不仅向人员发出警报，也触发流水线、策略和补救措施。
故事正在从“发生了什么”演变为“我们该怎么办”。
平台工程为什么更需要可行动的可观测性？
在平台工程时代，这种转变更为重要。内部开发者平台（IDP）和黄金路径的目标，是减少开发者的工作阻力。说实话，开发者并不想整天盯着 Grafana 仪表盘，也不想费力梳理 Kibana 日志。
开发者想要的是快速、相关、和代码变更相关联的反馈循环：
- 如果部署在金丝雀测试中失败，就自动回滚。
- 如果服务超出了错误预算，在问题解决前停止发布功能。
- 如果检测到异常，给出明确的下一步操作，而不是甩出 50 张需要解读的图表。
可观测性应当成为无形的基础设施：始终存在、始终可靠，只在工作流中呈现关键信息。平台工程有机会将可观测性直接嵌入黄金路径中，让系统默认具备可操作性。
从安全行业看“可执行情报”的共同困境
从我从事安全工作以来，我们就一直追寻着“可执行情报”的梦想。这个理念不仅仅是收集日志、警报和威胁情报，更在于理解它们、对它们进行优先级排序，并最终依据它们采取行动。
然而，现实并非如此。很长一段时间里，我们一直淹没在日志的海洋中，这让安全和运维工程师对那些真正需要行动的关键信号变得麻木。我们把“收集”当成了“控制”。
在可观测性方面，我们正处于类似的境地。我们的收集能力比以往任何时候都强。遥测数据就在那里，仪表盘美观漂亮，追踪信息丰富详实。但如果不将这些数据与有意义的自动化操作相结合，那么在系统发生故障时，我们能做的就只是盯着好看的图表。
可执行的可观测性并非“可有可无”。没有它，我们就是在浪费已经取得的进展。
自动化行动的风险与边界
当然，Actionable Observability 需要深思熟虑。缺乏信任的过度自动化可能会适得其反。
- 误报可能触发不必要的回滚或中断。
- 人工智能驱动的异常检测可能是黑箱。如果工程师不信任它，他们就不会使用它。
- 人在回路中仍然至关重要。并非每一个决策都应该自动化。
目标不是淘汰人类，而是提升人类。让机器处理繁琐和重复性的修复工作，让人类专注于判断、策略和高风险决策。
FAQ
Actionable Observability 和传统可观测性有什么区别？
传统可观测性主要解决“能否看到系统内部状态”的问题，重点是指标、日志、追踪等遥测数据的收集、查询和展示。Actionable Observability 更进一步，要求这些数据能够支持故障定位、发布决策、SLO 管理和自动化修复。
为什么说更多指标不一定带来更多洞见？
因为指标、日志和追踪如果彼此割裂，就会增加工程师的人工关联成本。告警过多、仪表盘过多、上下文不足时，团队虽然拥有大量数据，却仍然难以快速判断业务影响和下一步动作。
Actionable Observability 是否等于 AIOps？
不是。AIOps 可以成为 Actionable Observability 的一部分，用于异常检测、噪音过滤和建议生成。但 Actionable Observability 的范围更广，还包括持续验证、SLO 驱动运营、自动修复、平台工程工作流和人在回路中的决策机制。
自动修复是否应该完全替代人工处理？
不应该。自动修复适合处理模式明确、风险可控、结果可验证的重复性问题。对于高风险、影响范围大或上下文不完整的决策，仍然需要工程师参与判断。
平台工程团队应该如何理解可观测性的目标？
平台工程团队不应把目标停留在“提供更多仪表盘”。更重要的是把可观测性嵌入内部开发者平台和黄金路径，让开发者在发布、排障和运营过程中获得明确、相关、可行动的反馈。
结语：可观测性的下一步是行动
可观测性为我们提供了数据，这是第一个巨大的飞跃。但现在，挑战更大了：让可观测性变得切实可行。
云原生的未来不仅仅是看得更多，而是要利用我们所看到的做更多事情。这意味着将遥测数据与业务成果关联起来，实现持续验证，自动化安全响应，并最终靠近长期以来承诺的可执行智能目标。
我们在“数据收集”阶段停滞太久了。是时候迈向新的阶段了：将可观测性转化为行动。归根结底，没人会因为搭建了漂亮的仪表盘而获得晋升。真正重要的是确保系统可靠、用户满意以及业务正常运转。而这需要的不仅仅是可观测性，更需要行动。
本文翻译自：https://cloudnativenow.com/features/from-observability-to-actionability-why-metrics-alone-arent-enough/
