可观测性的未来：Actionable Observability

本文作者：Alan Shimel。作为《DevOps.com》和《Container Journal》的总编辑，艾伦·希梅尔对科技领域十分熟悉。艾伦创办并协助了多家科技企业，包括StillSecure，在该公司期间，他带领公司向市场推出了创新且高效的网络和安全解决方案。希梅尔是安全和科技界经常被引用的人物，也是行业及政府会议和活动中备受欢迎的演讲者。除了在《DevOps.com》和《Network World》上发表文章外，他关于科技现状的评论还通过其博客和播客《Ashimmy, After All These Years》（www.ashimmy.com）受到众多行业内部人士的密切关注。艾伦凭借深厚的商业背景和渊博的科技知识，助力多家科技公司取得了成功。他的法律背景、在该领域的长期经验以及纽约街头智慧，共同塑造了他独特的个人特质。

译者注：本文的原标题是《从可观测性到可操作性：为何仅有指标远远不够》原文很有洞见、引发思考。海量的指标、花哨的仪表盘、炫酷的拓扑图都很好，但切记不要忘了我们最终的目标：让数据给人洞察，辅助人决策和行动，即最终的 Actionability。

我们创办快猫星云，构建可观测性产品和解决方案，对外一直讲的理念是：我们更加面向故障处理过程，侧重点是加速故障定位，和 Shimel 观点很有共鸣，故翻译此文以飨读者。

不久前，云原生社区宣告在可观测性方面取得了胜利。我们拥有三大支柱——指标、日志和追踪，以及一系列CNCF项目和开源工具来收集这些数据。Prometheus、Grafana、OpenTelemetry、Fluentd——可观测性成了现代DevOps和平台工程的热门词汇。

但任何SRE（网站可靠性工程师）或平台工程师都会告诉你，仪表盘越来越多，警报不断触发，而实际问题也层出不穷。我们比以往任何时候都观察得更多，但对于所看到的信息，我们真的能更好地加以利用吗？

一个令人不安的事实：可观测性已进入停滞期。我们已经掌握了数据收集的艺术，但现在真正的挑战是将海量遥测数据转化为实际行动。

可观测性简史

第一代监控很简单：运行时间检查、CPU图表、Nagios警报。这些虽然有用，但无法应对微服务和分布式系统的复杂性。

随着Kubernetes和微服务架构的迅猛发展，我们需要更深入的东西。这就是可观测性的用武之地。可观测性不再仅仅关注“它是否在运行？”，而是会问“其内部到底在发生什么？”

• Prometheus为我们提供了丰富的指标
• Fluentd和ELK让我们能够大规模地为日志建立索引
• Jaeger和OpenTelemetry让分布式追踪成为现实
• Grafana为我们提供了可视化这一切的仪表盘

“日志、指标、追踪”这一口号成为了云原生生态系统的基石。公平地说，这是一大进步。

问题：无意义的指标

但问题在于：更多的数据并不必然意味着更多的洞见。

• 告警疲劳：工程师正淹没在大量无用告警中，其中大多数无需采取行动。
• 仪表板蔓延：每个团队都构建自己的面板，但很少有人能统一了解业务影响。
• 相关性缺口：日志、指标和跟踪数据通常孤立存在，需要人工将它们整合起来。
• 对平均恢复时间无影响：尽管数据更多，但许多组织的平均恢复时间并未显著改善。

换句话说，可观测性已经变成了一个“走过场式的选项”。没错，你拥有数据。但你能快速、果断且自动地根据这些数据采取行动吗？答案往往是否定的。

向可操作性的转变

行业开始意识到，仅具备可观测性是不够的。我们真正需要的是可采取行动的可观测性。

这意味着从数据收集转向决策支持——再从决策支持转向自动化行动。新出现的趋势指明了方向：

• 人工智能驱动的分析（AIOps）：利用机器学习排除干扰，识别异常，只突出重要内容。
• 持续验证：将可观测性与渐进式交付相连接，以便根据实时遥测数据自动推进或回滚金丝雀部署和蓝绿部署。
• 自动修复：当检测到已知模式时，系统会采取纠正措施——重启服务、重新路由流量或分配资源——而无需等待人工操作。
• SLO驱动的运营：从原始指标（“CPU使用率80%”）转向与用户体验和业务结果相关的服务级别目标。

这就是观察与行动之间的区别。

现实世界信号

我们已经看到这种转变正在发生：

• OpenTelemetry 正从追踪领域拓展，通过语义上下文整合日志和指标，使关联分析更具可操作性。
• Keptn 和 Argo Rollouts 将可观测性集成到交付管道中，实现了金丝雀分析的自动化。
• 云服务提供商正将异常检测和人工智能驱动的建议整合到他们的可观测性堆栈中。
• 具有前瞻性的平台团队正利用遥测技术，不仅用于向人员发出警报，还用于触发流水线、策略和补救措施。

故事正从“发生了什么？”演变为“我们该怎么办？”

平台工程视角

在平台工程时代，这种转变更为重要。内部开发者平台（IDPs）和黄金路径旨在减少开发者的工作阻力。说实话，开发者并不想整天盯着Grafana仪表盘，也不想费力梳理Kibana日志。

开发者想要的很简单：快速、相关且与他们的代码相关联的反馈循环。如果部署在金丝雀测试中失败，就自动回滚。如果服务超出了其错误预算，在问题解决前停止发布功能。如果检测到异常，给出明确的下一步操作——而不是需要解读的50张图表。

可观测性应当成为无形的基础设施：始终存在、始终可靠，却只在工作流中呈现关键信息。平台工程有机会将可观测性直接嵌入到黄金路径中，使其默认具备可操作性。

Shimmy 的观点

从我从事安全工作以来，我们就一直追寻着“可执行情报”的梦想。这一理念不仅仅是收集日志、警报和威胁情报，更在于理解它们、对它们进行优先级排序，并最终依据它们采取行动。

然而，现实却并非如此。长久以来，我们一直淹没在日志的海洋中，这让我们的安全和运维工程师对那些他们需要采取行动的关键信号变得麻木。我们把“收集”当成了“控制”。

在可观测性方面，我们正处于类似的境地。我们的收集能力比以往任何时候都强。遥测数据就在那里，仪表盘美观漂亮，追踪信息丰富详实。但如果不将这些与有意义的自动化操作相结合，那么在系统发生故障时，我们所能做的就只是盯着这些好看的图表而已。

可执行的可观测性并非“可有可无”，这才是关键所在。没有它，我们就是在浪费已经取得的进展。

风险与权衡

当然，我们需要深思熟虑。缺乏信任的过度自动化可能会适得其反：

• 误报可能会触发不必要的回滚或中断。
• 人工智能驱动的异常检测可能是一个黑箱——如果工程师不信任它，他们就不会使用它。
• 人在回路至关重要：并非每一个决策都应该自动化。

目标不是淘汰人类，而是提升人类。让机器处理繁琐和重复性的修复工作，而人类则专注于判断和策略。

结语

可观测性为我们提供了数据。这是第一个巨大的飞跃。但现在，挑战更大了：让可观测性变得切实可行。

云原生的未来不仅仅是看得更多，而是要利用我们所看到的做更多事情。这意味着将遥测数据与业务成果关联起来，实现持续验证，自动化安全响应，当然，还要最终实现长期以来承诺的可执行智能目标。

我们在“数据收集”阶段停滞太久了。是时候迈向新的阶段了：将可观测性转化为行动。因为归根结底，没人会因为搭建了漂亮的仪表盘而获得晋升。让你获得晋升的是确保系统可靠、用户满意以及业务正常运转。而这需要的不仅仅是可观测性——更需要行动。

本文翻译自：https://cloudnativenow.com/features/from-observability-to-actionability-why-metrics-alone-arent-enough/