导读：难得看到一篇这么实诚的文章，分享给各位，尤其是各位运维总监、CXO。
可观测性项目失败，常见原因不是工具不够强，而是先买工具、后补战略。真正有效的可观测性策略，要从业务目标、系统环境、团队协同、指标体系和持续改进出发，把遥测数据转化为有意义的可靠性结果。
核心要点
- 可观测性不是目标，可靠性才是目标；可观测性只是通往可靠性的手段。
- 先工具、后战略，容易带来更多工单、更多噪音和更多维护成本。
- 可观测性策略应像架构设计一样，先明确业务目标、技术环境、团队责任和实施方式。
- 成熟度模型可以帮助团队判断当前阶段、下一步投资方向和故障响应能力。
- SLO、黄金信号、RED、USE、DORA 和业务指标需要结合使用，才能把技术影响连接到业务影响。
问题：没有策略的可观测性只是噪音
当我们听到“可观测性”时，首先想到的画面是仪表盘、彩色图表，甚至可能是精致的拓扑图。我还记得多年前第一次看到拓扑图的情景——那些追踪数据将系统连接在一起的方式，既美观又近乎神奇。
这话没错，但它造成了一种危险的错觉：即“神奇工具”能保证成功。很多时候，项目失败是因为缺乏战略，而工具却成了核心。事实上，真正有战略和设计的项目并不多见。
但多年来，在主导大规模可观测性和SRE计划的过程中，我也目睹了太多项目的失败。而根本原因几乎总是相同的：缺乏战略，采用工具驱动的方法。
在实际操作中，许多组织会成立一个SRE或可观测性团队，在几乎没有进行评估的情况下就迅速选定一款工具，并期望能有成效。如果没有相应的策略，结果是可以预见的：团队目标不一致、工单数量不断增加、又多了一款需要管理的工具，甚至本应减少工作负担的解决方案反而带来了新的麻烦。
在左侧的图片中，我们可以看到大多数近期项目都存在一个共同模式：企业觉得有必要“开展SRE工作”或“实施可观测性”，于是他们组建了一个专门的团队，仅经过基本评估就迅速选定了一款工具——并认为仅凭这一点就能取得成功。
右侧的图片展示了没有策略的现实：团队不协调、工单数量攀升、又多了一个需要维护的工具，甚至本应减少辛劳的实施过程反而制造了新的辛劳。
通常，可观测性计划始于高管购买昂贵的工具。团队急于部署代理、构建仪表板并配置警报。但很快：
- 工单数量增加。
- 错误的团队收到了通知。
- 工作量非但没有减少，反而增加了。
- 可靠性并未提升。
为什么？因为这个项目是先有工具，后有策略。没有策略的可观测性不过是噪音罢了。
解决方案：有目的地设计可观测性
可观测性的设计应如同架构设计一般——需经过精心规划。这要从提出恰当的问题开始：
- 我们试图实现哪些业务目标？
- 技术环境是怎样的——是遗留系统、混合系统还是云原生系统？
- 我们是否让合适的团队参与其中？
- 是否采用了像基础设施即代码（IaC）和自动化流水线这样的现代实践？
- 我们会使用可观测性即代码（OaC）吗？
从这一点来看，模型很简单：
- 战略定义——协调业务目标、确定指标、确保预算。
- 解决方案架构——定义数据收集、集成、OpenTelemetry以及 observability-as-code。
- 文化转型——培训团队、重组小组、嵌入事后分析。
- 持续改进——跟踪成熟度、采用新实践并适应不断变化的业务成果。
- 跨层级对齐。
这套模型的重点是顺序：先定义为什么做，再决定怎么采集、怎么展示、怎么告警、怎么组织团队。否则，工具会把原本就不清晰的流程进一步放大。
跨层级对齐
想想看。你们当中有多少人参与过SRE或可观测性项目，而领导层却要求快速出成果？要知道，可观测性建设是一个循序渐进的过程。那么，如何才能既实现短期成效，又取得可持续的成果呢？
另一个秘密因素：共识与认同。战略和设计至关重要，但共识可能决定一个项目的成败。
所有人——IT运维人员、架构师、SRE（站点可靠性工程师）、开发人员和高管——都必须拥有同一个指南针。保持一致并非官僚作风，而是能加速进展。
速胜能建立信任：高管看到成果，团队产生归属感，而你则获得追求长期目标的空间。缺乏共识，你就会在追逐投资回报率的过程中精疲力竭，却得不到任何实际成果。有了共识，变革就能加速推进。
跨层级对齐不是为了开更多会议，而是为了让不同角色对同一个问题有共同答案：
| 角色 | 需要回答的问题 |
|---|---|
| 高管 | 可观测性如何支撑业务目标和可靠性结果？ |
| 架构师 | 数据采集、存储、关联和平台集成如何设计？ |
| SRE/运维 | 告警、SLO、值班和故障响应如何闭环？ |
| 开发团队 | 埋点、日志、指标和变更风险如何进入日常工程实践？ |
| 业务团队 | 哪些用户体验和业务指标代表真实影响？ |
可观测性成熟度模型
进步并非一蹴而就。这就是为什么我将成熟度模型用作路线图。这无关急于登顶，而在于有目的地逐步发展。
目标是了解我们当前所处的位置、进展如何，以及哪些步骤对业务最为重要。
这是我的模型，但你可以根据自身环境、客户需求或现有专业人员情况来调整你的模型。其目的不是进行排名或评判，而是提供一张地图——一个指引下一步投资方向的指南针。
成熟度并非统一的。一个团队可能处于第4级，而另一个团队仍停留在第2级。这很正常。该模型在企业级和应用级均适用。
想象一次真实的故障。每个成熟度级别如何帮助你做出响应？在较低级别，你可能有监控，但大多会产生无用信息。在较高级别，你能更快地检测、分析和恢复。当系统出现故障时，成熟度的好处就会变得显而易见。
可靠性基准测试
现在让我们通过一个更丰富的视角——基准测试关系——来审视同样的中断场景。
像黄金信号、RED和USE这样的框架有助于评估数据，而DORA指标则用于评估工程绩效。它们共同将技术影响与业务影响联系起来。如果您不熟悉这些内容，请查看我写的另一篇文章。
你知道什么是DORA指标吗？如果不知道，可以看看Datadog页面上的这个解释：https://www.datadoghq.com/knowledge-center/dora-metrics/
现在让我们深入探究同一个故障场景的更多细节：
左侧：
我们对业务应用程序进行了监测。例如，结账服务会发送诸如转化率之类的事件，这些事件会与传统遥测数据一起被纳入可观测性平台。
右侧：
服务等级目标（SLOs）是所有这些指标的集合点，这些指标分为四个领域：可观测性指标、DORA指标、业务指标和团队成熟度指标。
- 可观测性指标：服务等级指标（SLIs）显示服务等级目标（SLO）的违规情况（例如，95%的请求耗时超过300毫秒，错误率上升）。
- DORA指标：变更失败率呈上升趋势，导致不稳定性加剧。
- 业务指标：结账转化率下降12%，影响500名用户，损失5万美元，品牌形象受损。
- 团队成熟度指标：错误预算超支、部署仓促、SRE实践薄弱——这些信号不仅关乎技术，也关乎文化。
这段内容说明一个关键点：可靠性不是单一指标。技术层面的延迟、错误率和资源利用率，必须和工程效率、业务结果、团队成熟度一起看。否则，团队可能只是在优化图表，而不是改善用户体验和业务连续性。
案例研究：有策略（战略）与无策略
这就是战略所带来的差异。
原文案例中，在一家财富 100 强公司，项目获得了领导层支持、团队协作以及明确的可观测性策略。原文称，结果包括：重复性工作减少 95%，18000 起事件自动解决，根本原因分析速度提升 50%，资源优化节省了数 TB 级内存和 CPU 资源。
它并非完美——没有哪个项目是完美的——但凭借清晰的目标、预算、支持以及合适的人员，我们围绕真实需求而非工具炒作构建了解决方案。
在另一家大公司，领导层通过购买工具和组建团队来“实现可观测性”。他们忽视了应用程序所有者、运维人员以及业务协同。结果呢？协同失调、精力浪费，最终以失败告终。
听起来很耳熟吧？事后补救的代价很高——就像房子已经着火了才去调整方向一样。
战略必须适应本地环境：巴西面临的挑战
你不能照搬其他公司或国家的模式。本地环境至关重要。
在巴西，我目睹了全球性挑战的加剧：
- 传统环境——银行、电信公司和政府仍依赖大型机；迁移速度缓慢。
- 以工具为中心的采购——集中化、规避风险的采购倾向于将大型供应商视为“安全”选择。
- 成熟度不一致——各团队的水平参差不齐，有的仅能进行基本的 uptime 检查，有的则已在尝试AIOps。
- 组织孤岛——层级结构和对指责的恐惧使跨团队协作更难实现。
这部分对国内企业也有借鉴意义：不要照搬某个厂商、某个国家或某个互联网公司的模板。遗留系统、采购机制、组织结构、团队成熟度和业务压力不同，可观测性策略就应该不同。
如何把策略落到行动？
可以从五步开始：
- 选定一个业务目标，例如降低核心链路故障恢复时间、提升结账成功率或减少无效告警。
- 梳理当前系统环境，包括遗留系统、云原生系统、混合架构、已有监控和数据孤岛。
- 定义可靠性指标，包括 SLI、SLO、错误预算、业务指标和 DORA 指标。
- 设计数据和平台能力，包括 OpenTelemetry、日志、指标、链路、事件、告警和可观测性即代码。
- 建立持续改进机制，把故障复盘、告警优化、埋点补充和团队培训纳入固定流程。
这个顺序比“先买工具再找场景”更稳。工具应该服务策略，而不是替代策略。
结语
有很多内容值得讨论——工具、指标、黄金信号、智能运维（AIOps）、成熟度模型。但核心信息是：
可观测性并非目标，可靠性才是。
可观测性是指南针。目标是具备韧性的系统、优化的成本以及客户的信任。
战略、设计、文化和协同合作是成功之路的关键。当可观测性与业务相契合时，它就不再是干扰，而会成为提升可靠性和创造价值的最有力助推因素之一。
蒂亚戈·迪亚斯·热内罗索是一位杰出的IT架构师、高级SRE（网站可靠性工程师）和资深发明家，现居巴西波苏斯迪卡尔达斯。上述文章为个人观点，不一定代表雇主的立场、战略或意见。原文：https://tiagodiasgeneroso.medium.com/observability-strategy-from-metrics-to-meaningful-reliability-e72d59cb5939
FAQ
Q1：为什么说可观测性不是目标？
A：因为企业真正想要的是更可靠的系统、更低的故障影响、更好的用户体验和更可控的成本。可观测性只是实现这些目标的手段。
Q2：可观测性项目失败的常见原因是什么？
A：常见原因是先买工具、后补策略。缺少业务目标、团队协同、指标体系和持续改进机制时，工具可能只会带来更多噪音和维护成本。
Q3：成熟度模型有什么用？
A：成熟度模型可以帮助团队判断当前阶段，明确下一步投资方向，并用故障场景验证检测、分析和恢复能力是否真的提升。
Q4：可观测性策略需要统一模板吗？
A：不需要。策略必须适应本地环境，包括遗留系统、组织结构、采购方式、团队能力和业务目标。照搬模板往往会失败。
