很多团队已经构建了各类监控和可观测性系统，但真实故障发生时，仍然会遇到漏报、告警噪音大、定位慢、止损慢的问题。根因通常不是缺少工具，而是缺少面向业务和故障定位的建设方法。
核心要点
- 可观测性建设应先从业务目标入手，而不是先堆工具。
- 业务指标和 SLO 指标是技术团队与业务团队沟通稳定性的共同语言。
- 数据采集要围绕排障路径设计，避免指标、日志、链路和 Profiling 各自孤立。
- 数据关联能力会直接影响故障定位效率。
- 自动化响应适合已经反复出现、模式稳定的故障，不适合一上来就全自动闭环。
1. 从业务入手
优先保障公司最重点的业务，业务指标（通常称为北极星指标）、SLO 指标，是最应该关注的指标。
在微服务、K8s 时代，某个机器的 CPU、内存跑高了甚至宕机，可能对业务是无影响的，重点关注用户视角的指标和老板视角的指标，这是 ROI 最高的做法。
- 业务指标：即老板视角的指标。比如订单量、收入等，通常不在 TSDB 中，而是存在 OLAP 或 OLTP 的库里。
- SLO 指标：可参考 Google 四个黄金指标、RED 指标。
作为技术团队，和业务团队之间的沟通有时容易自说自话，在稳定性领域，业务指标和 SLO 指标是一个良好的沟通基础，是一种共同语言。
落地时可以先问三个问题：
- 哪些业务最不能出问题？
- 哪些指标能代表这些业务是否健康？
- 当这些指标异常时，技术团队第一步应该看哪里？
这三个问题回答清楚，比盲目增加监控项更重要。
2. 从定位路径入手
如果业务指标和 SLO 指标出问题，接下来就是故障定位，定位需要数据支撑，要收集的典型数据就是指标、日志、链路数据等，但不要眉毛胡子一把抓，而是从定位路径着手。
何为从定位路径着手？就是先想清楚如果故障（业务指标和 SLO 指标异常通常就是故障），在排障时先看什么数据再看什么数据。
典型的定位路径是：
- 全局技术视角的驾驶舱，需要所有服务的 SLO 数据，一目了然看全局，框定故障范围
- 下钻到出故障的服务，分析该服务相关的各类观测数据的特征
- 最后查看细粒度的日志、链路数据、Profiles 等确定根因
何为数据特征？举几个例子：
- A 地域的服务 SLO 指标正常，B 地域有问题
- A 版本的服务 SLO 指标正常，B 版本有问题
- 哪个时间开始出现大量 Error 日志
- 哪个时间开始 P99 延迟变高
- 哪个时间开始流量突增，是缓慢增长还是突然增长
好的定位路径应该让新值班人也能跟着走，而不是只能靠资深同事口口相传。每一次故障复盘后，都应该把有效的排查顺序沉淀下来。
3. 注重数据之间的关联
如果指标、日志、链路、Profiling、变更等系统相互割裂，会极大增加学习成本，增加排障时间。很多普通研发甚至都无法确切知道想看的数据在哪个系统查看。
能够从一类数据快速精确跳转到另一类数据，越来越变成观测系统的重要能力，比如：
- 错误率指标变高，快速查到 5xx 相关的日志
- 从 5xx 日志中找到 request id，快速拉出链路追踪的瀑布图
- 依赖的下游服务延迟变高，快速查到下游服务的变更记录、SLO 数据
所有这一切，都需要数据之间的良好关联，通常需要公司级的规范：
- 统一的标签规范
- 统一的资源属性规范
- 统一的语义规范
OpenTelemetry 在这块做得比较好，在尝试缔造一个规范和采集 Pipeline。
对企业内部而言，规范不只是技术文档，还要落实到代码埋点、采集配置、资源标签、告警规则和仪表盘里。否则，数据虽然被采集了，但无法在故障现场串起来。
4. 自动化问题响应
一旦确定了反复出现的故障模式和故障排除模式，那就可以尝试自动化或半自动化处理过程。比如：
- 重启失败的服务
- 清理磁盘空间
- 切换到备份集群
- 限流自保
一些自动化的逻辑甚至可以直接写到业务系统的代码中，这会让业务系统变得更加健壮，但也会变得更加复杂，可能会引入一些新的问题，需要权衡折中。
自动化响应的前提是模式稳定、风险可控、回滚路径明确。对于高风险动作，建议先做人机协同，例如自动生成处置建议、自动准备上下文、由值班人确认执行。
5. 自顶向下推进
最容易的推进方式是自顶向下推进，就像当年亚马逊做微服务改造，是 CEO、CTO 推进的，会顺利的多。
在研发框架里统一埋入也是很好的抓手，大部分公司都有较为统一的开发语言开发框架，这为统一埋点奠定了基础。但是统一埋点只能覆盖服务边界调用，服务内部逻辑还是要靠研发啦。
最不济的，只能是靠标杆效应了，先在部分业务试水，拿到成果再推广更多产品线。
一个最小落地顺序
如果只能用一分钟记住这篇文章，可以按这个顺序推进：
- 选一条最重要的业务链路。
- 定义业务指标和 SLO 指标。
- 画出故障定位路径。
- 补齐路径上需要的指标、日志、链路、Profiling 和变更数据。
- 建立统一标签和资源属性。
- 把高频、低风险的处置动作半自动化。
- 用一个标杆业务跑通，再向更多业务推广。
FAQ
Q1：可观测性最佳实践的第一步是什么？
A：第一步不是选工具，而是明确要保障的业务和对应的业务指标、SLO 指标。
Q2：为什么数据关联比单个工具更重要？
A：故障通常跨越服务、组件和数据类型。只有指标、日志、链路、事件能围绕同一对象关联起来，排障路径才会变短。
Q3：自动化响应什么时候适合做？
A：当故障模式反复出现、处置动作稳定、风险可控并且有回滚方案时，适合自动化或半自动化。
总结
可观测性建设不是把所有数据都采集起来，而是围绕业务健康和故障定位建立一套可执行的路径。先看业务，再看 SLO，再看定位路径和数据关联，最后再谈自动化。这样建设出来的系统，才更容易减少漏报、降低噪音并缩短故障恢复时间。
监控、可观测性这摊事确实非常驳杂，如果想要建设这套体系，欢迎和我们交流产品和落地经验：https://flashcat.cloud/contact/
