# 一分钟精华速览 #

可观测能力是指在复杂的软件系统中能及时、准确感知到服务状态，特别是异常或故障的发生，确定异常的影响范围、异常部位边界、判定异常点位、并由相关人员或软件做出准确决策的能力。

本文作者结合虎牙 SRE 实践及 20 余年架构、研发、运维经验，重点讲述如何设计和建设观测能力，做到分钟级感知故障、定位和快恢。

作者介绍

 《SRE 原理与实践》作者  张观石

TakinTalks 稳定性社区专家团成员，前虎牙 SRE 负责人，资深运维专家和架构师，拥有 20 年软件开发、架构、运维、SRE 经验。历任项目研发负责人、SRE 负责人、架构师，事故管理委员会委员、基础保障部架构师委员会委员。熟悉基于微服务架构的直播业务、音视频业务、海外直播业务的稳定的保障体系。在混合多云架构、可观测性、预案、变更管控、AIOps 等 SRE 领域有深入研究和丰富经验。参编信通院《信息系统稳定性保障能力建设指南》。

温馨提醒：本文约 5000 字，预计花费 10 分钟阅读。

后台回复 “交流” 进入读者交流群；回复“2251”获取课件资料；

背景

在以前，运维团队一般都是做后端运维，比如基础监控、操作系统、中间件、拨测等等，但是互联网平台以业务为中心，以用户为中心，平台的功能服务、质量和用户体验等是关键的目标，仅仅关注后台系统的可用性是不够的，以传统运维的视角来解决故障、做监控会比较被动。

运维想主动介入到业务中，我认为建设可观测能力是一个很好的办法，融入研发和业务部门的视角，甚至用户的视角，通过可观测性建设把 SRE 的工作推进到移动端、业务侧、微服务的内部，甚至可以用来度量相关的能力，真正深度参与到提升业务连续性中。作为 SRE 来讲，从用户的角度来保证业务的稳定性和质量是最终目标。

一、观测能力如何帮助快速定位？

这里我先从虎牙的一个实际案例，来展开讲讲观测能力是如何帮助快速定位的。

发现：

当一个业务出问题时，很可能会有大量微服务出现异常，但你可能不知道是哪一个。上图通过肉眼来看，大概能够知道它的原因——调用量突然大幅度上升，上升到一定程度就开始有部分调用超时了。

那么，告警里是否能把这种“肉眼可见”的信息体现出来？

告警：

这是其中一个告警信息，会呈现错误类型、调用方法、调用接口、被影响实例、具体日志错误异常等等，还会关联到这个服务的错误明细页。这个告警信息就可以比较容易做初步判断，通过链接进去能较快进行二次判断。

定位/分析：

当微服务告警很多时，我们还希望进一步了解，错误是否在某条链路上、是否都属于某一个业务的服务，以及它是怎么传播的、影响了哪些链路、哪些服务、哪些实例、哪些没有被影响、失败的调用源头是哪里、起点是哪里等等。

在这个调用链中能看到，这次告警影响了哪些链路、哪些服务、哪个是最根本的源头，通过调用链还能看到节点，而且能够和日志的详细信息做关联分析，接口错误次数、失败率、失败次数都能看得到。

告警会同步黄金指标存在的问题，并直接告知根因，比如，故障是哪个平台的、返回码是什么、占比是多少等等，如果有对应的预案，也会关联到对应的预案，这对我们分析问题有很大的帮助。

二、为什么要建立可观测能力？

2.1  我理解的可观测性

可观测性的本质，我理解是系统内外部状态的数字化表示。我们的系统是一个实体，它的状态可以通过一些直观的图表、文字、曲线表示出来，工程师可以通过观测系统看到系统的结构、状态以及变化。通过这套体系，在一个比较复杂的系统里找到变化的根源，并可以解释为什么会发生这些变化、变化的相关性、变化的逻辑性等等，这是可观测性的本质。

可观测性也会给 SRE 工作带来诸多收益——

第一，系统的稳定性、可靠性确实会有很大的提升。

第二，通过观测体系建设，比如数据上报、数据应用，可以让 SRE 工作推行更加顺利。SRE 通过观测性建设能够成为整个团队里比较关键的力量，可以参与到很多工作中去，和其他团队尤其业务团队的工作结合更加紧密。

2.2 监控观测范围的扩大过程

从传统的“以后台系统为中心”到当前的“以业务/用户视角为中心”，可观测性能力的建设是运维工作变被动为主动非常重要的抓手。

举个例子，一位虎牙主播正在直播时，如果网络抖动或其他原因，观众反馈卡顿了，之前的处理办法是主播、运营、主播端技术这三方进行沟通，上传日志，然后工程师后端做分析，或者让主播尝试重启。在接入可观测系统后，通过主播上报的数据、接入服务、后台的监控数据等，就能看见整个直播间的运行状态，不再需要主播和运营找研发侧做沟通。直接通过数据做对比实时分析，就能够较快找到问题，把里面的数据结合起来做分钟级的告警。

在扩大期建成了统一的观测系统后，在核心期还可以做到统一规范、上报、存储、展示，充分利用这些数据互相关联，引入大数据和 AIOps 的能力，快速感知、分析、诊断问题，同时利用这些数据来度量业务的质量以及整个稳定性工作的结果。

2.3 监控观测技术的演进

监控观测技术大家都很熟悉了，很多企业也都在往统一观测这个阶段去演进，比如全景监控、全链路立体、立体监控、融合监控等等叫法不一。

第四个阶段——综合感知能力，我觉得是未来的发展方向，即我们要做的不只是观测，更要强调综合的感知能力，不管是业务的感知，还是智能决策，比如自愈、触发容灾等。

三、如何建立分钟级的发现、定位和修复能力？

3.1  确定发现/定位/修复 需要的能力

3.1.1 发现故障

发现问题一定要监控业务，从用户最直观、最重要的服务开始监控。

在以前有一个比较尴尬的情况，传统方式只做后台监控，但工程师发现一个故障其实主要依赖软硬件的监控，还有系统后端服务的监控。这会导致用户、运营甚至老板发现问题了，但工程师却看不到异常指标；又或者知道某个微服务出问题了，但不知道对用户的影响有多大，即监控不能代表用户访问业务的质量。还有，在传统的方式里，工程师需要配置、维护大量指标监控，随着系统和对接人员发生变化，很难保证不出错。

所以要从用户最直观、最重要的服务开始监控，比如，辽宁省移动运营商的一部分用户看不了直播，在用户、云厂商发现之前，观测系统是否能提前发现问题，并发出告警信息这点很重要。

3.1.2 定界定位

评估故障影响范围、严重程度等，这要求系统有很强的分析定界能力。

再举个例子，当用户状态的全局成功率下降了 2%时，观测系统需及时找到问题点、快速确定范围，并找到问题的原因、影响用户、用户状态等等。

而传统的方式是分散建设，团队各自建设自己的监控系统，比如基础设施的有一套、容器的有一套、日志的有一套等等，各团队为了小团队的工作，构建了大量这样的监控系统，在各类公司中这样的监控系统基本不少于四套。如果监控数据割裂，则很难快速确定根因，比如，服务器上出了故障，要找微服务的监控；微服务的故障，要跨系统找基础设施、网络、日志的数据，这样的效率是非常低的。

3.1.3 决策修复

所有的监控数据必须上下关联做统一建设，并结合算法分析，才能做出更快更好的决策。

在监控数据统一的基础上，没有数据的需要补充数据，有数据的要充分利用数据，综合利用算法的能力，尽快确定影响范围，做初步的定位，通过告警的方式告知根因。再进一步推荐预案，直接关联到某个执行的预案里，只需一键执行或者简单操作即可，最终是希望能做到自愈。

3.2  从 14 个环节中发现改进点

为了更快修复故障，我们把故障的生命周期展开来看一看。

发现、定位、修复三步展开来，可以分为图中的 14 个环节。这张图摘录自我的新书《SRE 原理与实践》，这部分内容我在书中有详细介绍。

在这些阶段里需要尽量把工作往前做，比如在苗头阶段能够看出趋势就告警出来，不会出现大量的报警淹没，这样能做到更早、更主动地发现问题。

举个例子，还是以虎牙直播为例，在看直播时卡顿或者打不开，大多数用户是不会反馈的，不爽的时候直接就换个直播间或直接走掉了。当我们把故障生命周期分成 14 个阶段后，就能够细致分析在哪个节点的效率是可以提高的，比如，在苗头阶段能否发现、通知确认阶段能否缩短时长、告警是否可以更加敏感、定位是否可以更加高效、根因定位是否能更加准确等等，想尽一切办法来缩短整个 MTTR（平均修复时长）。

3.3 明确度量要求

故障过程的度量要求这里有 2 个参考，一个是阿里的“1-5-10”，即 1 分钟发现，5 分钟定位，10 分钟修复；二个是虎牙的“2-3-5”，即 2 分钟发现，3 分钟定位，5 分钟修复。

3.4 建设可观测性的 3 个要点

第一点，要做统一的规划建设，包括统一采集、规范、上报、存储、UI/API、公共算法等。

第二点，建议把影响用户的关键指标作为业务的黄金指标，并和业务研发、老板达成一致，从用户侧上报这些关键的质量指标，并为每个黄金指标配置一套完善的监控、分析、排查、诊断甚至修复预案的能力。

第三点，以终为始，通过黄金指标的建设，建立起一套度量的体系，一方面度量业务本身的质量、稳定性，另一方面可以度量整个过程，比如首发率、监控告警率、告警漏告率，以及发现时长、定位时长、修复时长等等，形成指标体系，以此在公司内部打通上下认知。

3.5 建立可观测性-指标范例

下图是虎牙在某个微服务的监控指标，供参考。

3.6 案例：可观测应用

下图是可观测帮助发现能力短板的又一个案例。分析此故障中，故障发现能力存在严重问题，工程师升级实例失败没有发现，也没有告警，而是通过调用此服务的上游业务告警后才发现。

以上就是可观测性建设的整体思路和方法，具体的实践细节在《SRE 原理与实践》的第四章中，有较大的篇幅重点来讲，包括一些实践案例在书中都有详细的讲解。

四、实践案例：AIOps 提高故障定位效率

AIOps 最大的作用，我认为是可以帮助理解海量的数据，在海量的数据里找到相互间的因果关系、正相关性等逻辑关系。比如，指标抖动后的分析各个维度之间的相关性、逻辑性，并能够通过算法分析。在过往可能每个维度都需要人工分析，而 AIOps 算法能够自动化地做这些分析。

4.1 观测帮助快速发现、定位、快恢

当某直播间总卡顿率出现异常时，需要确定是哪个维度及组合中的指标（集合）导致的。如图可以看出有三个线路都有卡顿，按码率只有一个 1200，按 P2P 有唯一的卡顿，这样通过人工来看，可以大概得出结论是按码率和 P2P 这个组合导致的卡顿。基于这个长期的经验，SRE 团队研发了卡顿多维度更新定位的算法，同时联合多个部门闭环解决。

如上图所示，我们在主播端加了一个智能的卡顿反馈按钮，点击卡顿时，后台就可以通过观测数据做算法分析，一部分确定是主播自己问题的，会反馈给主播并告诉主播如何修复，提供相应建议。另一部分通过分析发现是后台问题的，可以通过其他方式，比如切上行、切码率、切线路、切 P2P 等，做到部分自愈。无法自愈的部分，比较复杂的问题就会形成一个自动化的工单，进入工单系统中。

4.2 AIOps 帮助快速定位：技术方案

• 对任意给定的叶子节点，采用了两个指标 Influence Degree 和 Contribution Ability 评价它和异常的相关性。

• 采用加权关联规则挖掘的方式自行挖掘维度之间的关系。

• 采用迭代定位的方式处理同一时刻有多个根因的情况。

• 最终基于原始数据分布排序输出推荐的根因。

4.3 AIOps 帮助快速定位：效果

• 卡顿反馈按钮背后集成了 AI 卡顿定位模型，打通值班工单系统、一线 &研发值班处理流程，最终主播卡顿平均解决时长由 10 分钟缩短到 3 分钟，时长明显缩短；

• 有 1/3 问题准确识别，能给主播提供修复建议；

• 工单总量下降 50%，识别率达到 80%；

• 所有 Case 经过多维度根因定位模型分析，Top1 根因引发的报障由 23%下降到了 6%。

五、总结

以业务为核心进行，统一建设可观测性。在业务至上的时代，我们都要以业务为核心去做稳定性保障，而不是以技术工程师的视角认为只是保障 IT 系统或者软件。一个业务可能会涉及到很多微服务系统、庞杂的基础设施、庞杂的用户终端，孤立地只关注某个层面是不够的，必须要以业务为核心去把整个链路给串起来。

充分利用业务特点和 AIOps 算法，集成到发现和定位、判断决策的过程。不管定位还是修复，都需要尽量利用算法的能力

把分析结果与告警、预案等打通。让整个链路工作捋顺、上下游畅通。

添加助理小姐姐，凭截图免费领取以上所有资料

并免费加入「TakinTalks 读者交流群」    

声明：本文由公众号「TakinTalks 稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。