老张，你的服务是不是挂了？论全局 SLI 的紧张性

场景再现

你正在午休，正梦见中了彩票，突然收到电话告警，说服务对外接口 95 分位延迟突增，惊出一身冷汗，睡意全无，抓紧打开监控体系，查看服务的 SLI 指标，发现确实有问题，已经持续 1 分钟，这服务我刚接手没多久，怎么办？怎么办？？对了，告警详情里有 SOP 预案手册，赶紧打开看看。

SOP 预案手册里写着：

• 1.研发运维群里确认是否有人刚有上线，如果有该服务的变动，及时回滚
  
• 2.该服务没有多活架构，无法切流，需要找到详细原因再针对性处理
  
• 3.登录 s 链接，可以查看该服务的 SLI（Service Level Indicator，反应服务康健状态的最紧张的几个黄金指标）
  
• 4.登录 x 体系，找到 a 索引，可以查看本服务的日记
  
• 5.打开 y 链接，可以打开仪表盘，展示该服务所在机器的各项性能指标
  
• …
  

于是，你急吼吼的在群里扣问大家是否有变动，同时，抓紧查看服务的 SLI 指标和日记，日记里有个很关键的线索：

请求某个依赖的下游服务（假设其名字是 a），发现超时了，打印了超时日记，但是无法区分是网络的问题导致的，还是就是 a 服务返回的慢了。此时，你肯定很想知道 a 服务当前是否康健，a 服务的各项 SLI 是否正常，如果 a 服务的 SLI 都正常，大概就是网络链路问题，如果 a 服务的 SLI 也不正常，那很大概就是 a 服务的问题了。

但是，TMD，我不知道去哪里看 a 服务的 SLI 啊…我甚至都不知道 a 服务是否对外袒露了 SLI 指标！！！
这个问题很常见，许多公司都建设了 Zabbix、Prometheus、Nightingale 等监控体系，但是却没有一个统一的地方查看各个服务的 SLI，其实，服务的 SLI 指标远比机器的 CPU、内存等指标来得紧张。最佳实践是什么？
SLI 最佳实践

之前我翻译过一篇文章，介绍 Facebook 的 SLICK：《Facebook 基于 SLO 的可靠性保障实践》。SLICK 其实就是一个公司级全局的服务 SLI 汇聚之地，工程师可以在这里查看依赖的其他服务的康健状态，这对于故障的快速定位起到了关键作用。

SLICK 虽然已经很大程度上解决了一些问题，但也有两个典型问题：

• 你必须知道你依赖的其他服务叫什么，如果你是个新手，大概未必知道
  
• 所有服务的所有 SLI 都在这里平铺，没有层级组织，信息过载，对于关注全局的人来讲，一下子看不外来
  

故而，我们希望这些服务之间有横向依赖关系，通常可以从 tracing 体系自动获取，如果没有 tracing 体系，也可以用 eBPF 或手工建立这个关系，手工建立其实也不麻烦，你对你的服务熟悉，你只需要配置你自己的服务即可，全公司大概 500 个微服务，终极是由 200 多个人分别去建立，每个人配置一两个微服务，也不是很难。除了横向依赖关系，还希望建立纵向层级关系，比如建立一个 体系-子体系-服务 的三层关系，底层服务如果出问题，问题上浮，在终极的体系层面画个红 x 之类的，首页只展示各个体系的康健状态，体系的数量通常不会特别多，就可以做到一目了然。这个纵向层级关系，是没法从某个数据自动天生的，通常都是需要手工配置，假设你是某个微服务的维护人员，相当于你要配置一下自己这个微服务的分组关系，应该归属到哪个体系或者哪个子体系。

有些朋友听到需要手工配置大概就望而却步了，大可不必，让微服务负责人配置自己的服务，分布式分担这个工作，每个人就比较轻松了。而且这个信息改动极少，一般只有新服务上线或者服务下线才会改动，不会频繁改动。别的，这属于稳固性治理层面的工作，数据颠末治理才能更有价值，才能更好的服务于故障发现和定位，才能更好的反向驱动各个微服务建立这些关键数据，让整体稳固性提拔。治理工作是工程工作的放大器和矫正器。

依据这个思路，我们创业建立了一个叫做灭火图的产品，来帮助公司建立这种全局 SLI 的治理。当然，灭火图除了建立上面讲到的这个能力，还可以串联 metrics、logs、traces、events 等各类可观测性数据，作为一个数据的全局入口，可以有用提拔故障发现和定位的效率。如果您有兴趣，接待联系我们交换，联系我们的邮箱即可：contact-us@flashcat.cloud ，或者到下面的网址提交一个申请，我同事会联系您约时间交换：

• https://flashcat.cloud/contact/
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。