场景再现
你正在午休，正梦见中了彩票，突然收到电话告警，说服务对外接口 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 等各类可观测性数据，作为一个数据的全局入口，可以有效提升故障发现和定位的效率。如果您有兴趣，欢迎联系我们交流，联系我们的邮箱即可：[email protected] ，或者到下面的网址提交一个申请，我同事会联系您约时间交流：