可观测性最佳实践：一分钟精简版

构建了各类监控、可观测性系统（一个又一个数据孤岛），但故障漏报、定位止损慢，经常被老板怼？下面几条实践分享给你。

1.从业务入手

优先保障公司最重点的业务，业务指标（通常称为北极星指标）、SLO 指标，是最应该关注的指标。

在微服务、K8s 时代，某个机器的 CPU、内存跑高了甚至宕机，可能对业务是无影响的，重点关注用户视角的指标和老板视角的指标，这是 ROI 最高的做法。

• 业务指标：即老板视角的指标。比如订单量、收入等，通常不在 TSDB 中，而是存在 OLAP 或 OLTP 的库里。
• SLO 指标：可参考 Google 四个黄金指标、RED 指标。

作为技术团队，和业务团队之间的沟通有时容易自说自话，在稳定性领域，业务指标和 SLO 指标是一个良好的沟通基础，是一种共同语言。

2.从定位路径入手

如果业务指标和 SLO 指标出问题，接下来就是故障定位，定位需要数据支撑，要收集的典型数据就是指标、日志、链路数据等，但不要眉毛胡子一把抓，而是从定位路径着手。

何为从定位路径着手？就是先想清楚如果故障（业务指标和 SLO 指标异常通常就是故障），在排障时先看什么数据再看什么数据。

典型的定位路径是：

1. 全局技术视角的驾驶舱，需要所有服务的 SLO 数据，一目了然看全局，框定故障范围
2. 下钻到出故障的服务，分析该服务相关的各类观测数据的特征
3. 最后查看细粒度的日志、链路数据、Profiles 等确定根因

何为数据特征？举几个例子：

• A 地域的服务 SLO 指标正常，B 地域有问题
• A 版本的服务 SLO 指标正常，B 版本有问题
• 哪个时间开始出现大量 Error 日志
• 哪个时间开始 P99 延迟变高
• 哪个时间开始流量突增，是缓慢增长还是突然增长

3. 注重数据之间的关联

如果指标、日志、链路、Profiling、变更等系统相互割裂，会极大增加学习成本，增加排障时间。很多普通研发甚至都无法确切知道想看的数据在哪个系统查看。

能够从一类数据快速精确跳转到另一类数据，越来越变成观测系统的重要能力，比如：

• 错误率指标变高，快速查到 5xx 相关的日志
• 从 5xx 日志中找到 request id，快速拉出链路追踪的瀑布图
• 依赖的下游服务延迟变高，快速查到下游服务的变更记录、SLO 数据

所有这一切，都需要数据之间的良好关联，通常需要公司级的规范：

• 统一的标签规范
• 统一的资源属性规范
• 统一的语义规范

OpenTelemetry 在这块做得比较好，在尝试缔造一个规范和采集 Pipeline。

4. 自动化问题响应

一旦确定了反复出现的故障模式和故障排除模式，那就可以尝试自动化或半自动化处理过程。比如：

• 重启失败的服务
• 清理磁盘空间
• 切换到备份集群
• 限流自保

一些自动化的逻辑甚至可以直接写到业务系统的代码中，这会让业务系统变得更加健壮，但也会变得更加复杂，可能会引入一些新的问题，需要权衡折中。

5. 自顶向下推进

最容易的推进方式是自顶向下推进，就像当年亚马逊做微服务改造，是 CEO、CTO 推进的，会顺利的多。

在研发框架里统一埋入也是很好的抓手，大部分公司都有较为统一的开发语言开发框架，这为统一埋点奠定了基础。但是统一埋点只能覆盖服务边界调用，服务内部逻辑还是要靠研发啦。

最不济的，只能是靠标杆效应了，先在部分业务试水，拿到成果再推广更多产品线。

监控、可观测性这摊事确实非常驳杂， 如果想要建设这套体系，欢迎和我们交流产品和落地经验：https://flashcat.cloud/contact/