核心要点摘要
- SLI（Service Level Indicator）应该优先服务故障发现和定位，而不只是服务自身大盘展示。
- 当一个服务依赖多个下游服务时，研发运维人员需要统一入口查看下游服务是否健康，否则排障会被“去哪看指标”拖慢。
- 公司级全局 SLI 平台需要同时具备横向依赖关系和纵向层级关系，才能兼顾局部排障和全局健康视图。
- 依赖关系可以来自 tracing、eBPF 或人工维护；系统、子系统、服务这类纵向分组通常需要治理配置。
- 灭火图的目标是把 SLI、metrics、logs、traces、events 等可观测性数据串起来，成为故障发现和定位的全局入口。
一个典型故障场景：接口延迟突然升高
你正在午休，正梦见中了彩票，突然收到电话告警，说服务对外接口 95 分位延迟突增，惊出一身冷汗，睡意全无，抓紧打开监控系统，查看服务的 SLI 指标，发现确实有问题，已经持续 1 分钟，这服务我刚接手没多久，怎么办？怎么办？？对了，告警详情里有 SOP 预案手册，赶紧打开看看。
SOP 预案手册里写着：
- 研发运维群里确认是否有人刚有上线，如果有该服务的变更，及时回滚。
- 该服务没有多活架构，无法切流，需要找到详细原因再针对性处理。
- 登录 s 链接，可以查看该服务的 SLI。SLI 是 Service Level Indicator，通常指反映服务健康状况的关键黄金指标。
- 登录 x 系统，找到 a 索引，可以查看本服务的日志。
- 打开 y 链接，可以打开仪表盘，展示该服务所在机器的各项性能指标。
- …
于是，你急吼吼的在群里询问大家是否有变更，同时，抓紧查看服务的 SLI 指标和日志，日志里有个很关键的线索：
请求某个依赖的下游服务（假设其名字是 a），发现超时了，打印了超时日志，但是无法区分是网络问题导致的，还是 a 服务本身返回慢了。此时，你肯定很想知道 a 服务当前是否健康，a 服务的各项 SLI 是否正常。如果 a 服务的 SLI 都正常，可能就是网络链路问题；如果 a 服务的 SLI 也不正常，那很可能就是 a 服务的问题。
但是，TMD，我不知道去哪里看 a 服务的 SLI 啊…我甚至都不知道 a 服务是否对外暴露了 SLI 指标！！！
这个问题很常见。很多公司都建设了 Zabbix、Prometheus、Nightingale 等监控系统，却没有一个统一的地方查看各个服务的 SLI。机器 CPU、内存等指标很重要，但在服务故障定位里，服务自己的 SLI 往往更接近用户真实感受，也更能帮助值班人判断影响边界。
为什么需要公司级全局 SLI
之前我翻译过一篇文章，介绍 Facebook 的 SLICK：《Facebook 基于 SLO 的可靠性保障实践》。SLICK 其实就是一个公司级全局的服务 SLI 汇聚之地，工程师可以在这里查看依赖的其他服务的健康状况，这对于故障的快速定位起到了关键作用。
SLICK 虽然已经很大程度上解决了一些问题，但也有两个典型问题：
- 你必须知道你依赖的其他服务叫什么，如果你是个新手，可能未必知道
- 所有服务的所有 SLI 都在这里平铺，没有层级组织，信息过载，对于关注全局的人来讲，一下子看不过来
这说明，全局 SLI 不只是把所有服务指标放到一个页面。它至少要解决两个问题：一是“我依赖谁、谁依赖我”；二是“这个服务属于哪个系统、哪个子系统、哪个业务视角”。前者帮助一线排障，后者帮助管理全局健康状态。
全局 SLI 应该具备两类关系
第一类是横向依赖关系。服务之间的调用关系通常可以从 tracing 系统自动获取；如果没有 tracing 系统，也可以用 eBPF 或手工方式建立。手工建立并不一定很重，因为每个服务负责人通常只需要配置自己熟悉的一两个服务。全公司即便有 500 个微服务，也可以由 200 多个人分摊维护。
第二类是纵向层级关系。比如建立 系统-子系统-服务 的三层关系：底层服务如果出问题，问题可以上浮到子系统和系统层面，最终在首页只展示各个系统的健康状况。系统数量通常不会特别多，这样关注全局的人才能一眼看到哪里出了问题。
这类纵向层级关系，通常没法从某个监控数据里自动生成，更多需要治理配置。假设你是某个微服务的维护人员，就需要配置这个微服务归属到哪个系统或子系统。
有些朋友听到需要手工配置可能就望而却步了，大可不必，让微服务负责人配置自己的服务，分布式分担这个工作，每个人就比较轻松了。而且这个信息改动极少，一般只有新服务上线或者服务下线才会改动，不会频繁改动。另外，这属于稳定性治理层面的工作，数据经过治理才能更有价值，才能更好的服务于故障发现和定位，才能更好的反向驱动各个微服务建立这些关键数据，让整体稳定性提升。治理工作是工程工作的放大器和矫正器。
灭火图如何承接全局 SLI 治理
依据这个思路，我们创业建立了一个叫做灭火图的产品，来帮助公司建立这种全局 SLI 的治理。灭火图不只是建立服务健康度视图，还可以串联 metrics、logs、traces、events 等各类可观测性数据，作为一个数据的全局入口，提升故障发现和定位的效率。
对一线研发运维来说，灭火图要回答的是：我负责的服务是否健康，它依赖的下游是否健康，异常是否已经上浮到系统层面，相关日志、指标、链路和事件入口在哪里。对稳定性治理来说，灭火图要沉淀的是服务关系、系统分组、关键 SLI 和异常状态传播逻辑。
结论
全局 SLI 的价值，不是多一个指标页面，而是在故障发生时让值班人更快判断“到底是我服务的问题、下游服务的问题，还是网络链路的问题”。如果每个服务的 SLI 分散在不同系统里，甚至没人知道有没有暴露，排障就会被信息寻找成本拖慢。
更可行的做法是：把服务 SLI 汇聚到一个全局入口，补齐横向依赖关系和纵向层级关系，再把 metrics、logs、traces、events 串成下钻路径。这样，SLI 才能从单个服务的大盘指标，变成公司级稳定性治理的数据基础。
FAQ
Q1：SLI 和 CPU、内存这类主机指标有什么区别？ A：SLI 直接描述服务健康状况，比如延迟、成功率、错误率等；CPU、内存描述的是资源状态。排查服务对外异常时，SLI 通常更接近用户体验，主机指标更适合继续下钻定位原因。
Q2：全局 SLI 一定要自动生成依赖关系吗？ A：不一定。tracing、eBPF 可以帮助自动发现横向依赖关系，但系统、子系统、服务这类纵向分组通常仍需要人工治理。让每个服务负责人维护自己的服务归属，是更现实的落地方式。
Q3：为什么不直接把所有服务 SLI 平铺展示？ A：平铺可以解决“有地方看”的问题，但容易带来信息过载。按系统、子系统、服务分层展示，并支持从全局健康状态下钻到具体服务，才更适合故障发现和定位。
如果您有兴趣，欢迎联系我们交流，联系我们的邮箱即可：contact-us@flashcat.cloud ，或者到下面的网址提交一个申请，我同事会联系您约时间交流：
🎯 关于快猫星云
快猫星云是一家云原生智能运维科技公司，由知名开源项目“夜莺(Nightingale)”的核心开发团队组成，创始团队均来⾃阿⾥、百度、滴滴等互联⽹公司。夜莺是一款开源云原生监控工具，是中国计算机学会接受捐赠并托管的第一个开源项目，在GitHub上有超过8000颗星，迭代发布了超过100多个版本，上百位社区贡献者，是国内领先的开源可观测性解决方案。
快猫星云以开源夜莺为内核打造的“Flashcat平台”，是国内顶级互联⽹公司可观测性实践的产品化落地，致力于让可观测性技术更好的服务企业，保障服务稳定性。Flashcat 平台具有以下特点：
- 统一采集：采用插件化思路，内置集成上百种采集插件，服务器、网络设备、中间件、数据库、应用、业务，均可监控，开箱即用。
- 统一告警：支持几十种数据源对接，收集各类监控系统的告警事件，进行统一的告警收敛、降噪、排班、认领、升级、协同，大幅提升告警处理效率。
- 统一观测：将 Metrics、Logs、Traces、Events、Profiling 等多种可观测性数据融会贯通，并预置行业最佳实践，既提供全局业务视角、技术视角的驾驶舱，也提供层层下钻的故障定位能力，有效缩短故障发现和定位时间。
