关于运维:面向故障处理的可观测性体系建设

8次阅读

共计 5255 个字符，预计需要花费 14 分钟才能阅读完成。

笔者从 12 年开始入行，从事 DevOps 研发工作，做过部署零碎、监控零碎、可观测性相干产品，也做过 SRE 一线和管理工作，对于可观测性的了解和实际，有一些小小的见解，利用本文和大家做一个探讨分享。本文次要内容包含：

可观测性在整个商业体系中的地位和价值
如何疾速发现故障，应用哪类指标告警
SRE 在议论故障定位的时候，谈的是什么
如何找到故障间接起因，找到止损根据
如何让可观测性零碎出现观点，辅助洞察，定位故障

做一个事，首先得有价值，如果价值太小不值得投入。可观测性也不例外，咱们首先剖析一下可观测性在整个商业体系中的地位和价值。思考第一个问题：作为在线类产品，咱们心愿客户 / 用户有一个好的产品体验，那怎么算一个好的产品体验？

很显著，产品体验包含性能体验和可靠性体验。性能体验依赖产品设计和迭代速度，跟明天的话题关系不大暂且按下不表。可靠性体验呢？可靠性体验外围就是谋求高可用、低提早，艰深讲就是每次关上站点或 app，都不报错，速度嗖嗖的。那如何能力具备好的可靠性体验呢？

其实如果一切正常，就应该是可用且速度快的，除非哪里出了问题，也就是产生了故障，才会报错或者提早大增。那技术团队要做的，除了继续优化架构和性能，就是一直和故障做奋斗了。升高故障产生的频率，升高故障的影响范畴，升高故障的复原工夫。演绎为 6 个字：降产生、降影响！

怎么做？有没有方法论来领导？咱们能够从故障的生命周期着手，来优化生命周期的各个环节，每个环节都做好了，实践上后果就是好的。故障生命周期的梗概图如下：

从大面上，能够分成事先、事中、预先三个大的阶段：

事先：及时发现危险，做好架构、预案、演练
事中：及时发现故障，及时定位，及时止损
预先：排查根因，落实复盘改良项

看起来寥寥数语，没有非凡的货色，但实际上每个环节要做好，都不容易。那可观测性，在这整个过程的职能是什么？在哪个环节施展价值？

显然，可观测性，是在故障发现、定位环节发挥作用的，外围价值就是帮咱们疾速发现故障、疾速定位故障，进而升高故障的影响。如此，可观测性的地位和价值就很明确了，用一张图概括：

客户 / 用户须要好的产品体验，好的产品体验包含可靠性体验，要想有好的可靠性体验，就得缩小故障，所谓的降产生、降影响，而这，又依赖了可观测性的能力。所以：可观测性最终是服务于产品体验、服务于商业胜利的（想不想获得商业胜利？依据方才的剖析可观测性可是重点因素哦），外围指标是疾速发现、定位故障。

那么，如何疾速发现故障？

要想可能疾速发现故障，得先定义什么是故障！简略来看，产品体验受损，就是故障！比方：

电商产品：用户无奈下单、无奈领取、无奈查看商品、无奈查看历史订单
存储系统：用户无奈读、无奈写、或者读写提早过高
流媒体产品：无奈开启播放、无奈拉流、无奈浏览视频信息

既然可能定义如何算是产品体验受损，那就能够梳理出相干的监控指标，比方：

电商产品：订单量、领取量、商品 / 订单拜访成功率 / 提早
存储系统：读 / 写成功率、读 / 写提早
流媒体产品：播放量和成功率、拉流提早、视频浏览成功率 / 提早等

大家有没有发现这类指标的特点？显然，都是能够量化客户体验的指标，这类指标咱们称为后果类指标（前面会介绍起因类指标），大面上能够分为两类，一类是业务指标，另一类是 SLO 指标。

个别公司做监控的时候，可能会意识到要做 SLO 指标的监控，容易疏忽业务类指标的监控。其实，业务类指标才是老板更为关注的指标，而且，SLO 指标失常的时候，业务指标未必失常。比方客户到服务端的网络出问题了，服务端的成功率、提早指标都是失常的，然而客户无奈下单，订单量会上涨。所以，肯定要器重业务指标体系的构建和监控。

听起来，业务指标和 BI 数据很像有没有？的确，最大的相同点是：都是老板关注的，哈哈。不同点呢？BI 数据对准确性要求很高，对实时性要求没有那么高，而业务指标监控，对准确性要求没有那么高（只有能发现数据趋势出问题了就能够了），对实时性要求很高，毕竟是用来发现故障的，如果实时性太差，黄花菜都凉了。

指标体系的构建，除了后果类指标，与之对应的还有起因类指标。都须要，然而咱们配置告警的时候，个别是针对后果类指标来配置。因为 产品的外围业务性能是可枚举的，每个性能对应的后果类指标就是可枚举的，做好后果类指标的告警，就能够保障告警是全的，做到有故障必有告警！举个例子：实时交易类零碎，交易量忽然上涨。

如果，面向起因类指标配置告警，则永远无奈配全，无奈做到有故障必有告警！实际上，起因类指标不用肯定要配置告警，出故障的时候可观测，其实也根本够了。

如上，要构建可观测性体系，首先要建设齐备的指标体系，其中十分要害的是后果类指标，即业务指标和 SLO 指标，后果类指标配合告警零碎能够疾速发现故障！从这里也能够看出，监控（monitoring）和可观测性（observability）是相辅相成的，非代替关系。

OK，既然能够发现故障了，下一步就是定位故障了。

在探讨这个问题之前。先分享一个信息层级的概念。说：信息分 4 个层级，最底下是数据，横七竖八，比方海量的指标、日志、链路追踪的数据；数据下面是特色，比方最大值、最小值、同环比等，比方 5 个服务实例，提早的最大的是哪个，这叫数据特色；特色下面是观点，从故障定位场景来举例，比方依据特色数据分析之后发现，数据库没有问题，依赖的第三方服务也没问题，这就是观点；观点之上就是洞察，或称洞见，综合所有观点，得出故障定位论断，得悉具体是哪个模块的什么起因导致了本次故障，就是最终洞察。画个图示例一下：

要想得到最终的洞察（定位到故障），首先要依赖底层的数据齐备性，否则就是巧妇难为无米之炊！然而故障起因形形色色，数据能全 么？做过 SRE 或者运维的敌人必定感触颇深，故障可能是电源模块坏了、机房空调坏了、机柜压住网线了、供电不稳、某个盘故障了、中间件配置错了、被黑客攻击了、分布式中间件脑裂了、写日志 hang 住了、程序配置错了、程序连贯第三方的地址错配成线下地址了、DNS 配错了、证书过期了、代码 Bug 了、疏漏了某个常见用户流程 … 等等等等。

这么多可能的故障起因，要通过可观测性数据分析进去，这数据能全么？比方代码 Bug，要想能依据可观测性数据分析出是哪一行代码的问题，岂不是要像在 IDE 里调试那样，每一行代码的输入输出都得拿到啊，这老本谁扛得住啊，性能损耗谁扛得住啊 …

如果咱们的指标只是定位间接起因，找到止损根据尽快止损，这个底层数据需要就少多了。比方咱们不须要晓得是哪行代码出了问题，咱们只有晓得是某个模块做了变更导致了故障，就能够去止损（这个场景的止损动作就是回滚）了。再比方，多活的服务，有时仅仅晓得是 A 机房的问题就能够了，把流量切到 B 机房就能够解决。

综上，个人观点：应用可观测性数据定位根因，几无可能 100% 笼罩全副场景！因为数据就不可能全！但如果只是用可观测性数据定位间接起因，找到止损根据，则 100% 是能够做到的，而这，才是咱们应该致力的方向。

当 SRE 在议论故障定位的时候，其实议论的时是如何找到间接起因，尽快止损。而根因，能够留在复盘阶段缓缓找的。

答复这个问题之前，咱们先来看看一个服务要想失常运行，依赖了哪些内容，或者说一个服务如果出故障，可能会是哪里的问题。如果咱们可能枚举故障类别，那么咱们就能够针对每个类别去剖析，找到故障的间接起因。

首先，依赖的基础设施（根底网络、硬件、Runtime 环境）不能出问题，依赖的第三方其余服务不能出问题，这两个方面大家比拟容易了解，不多说了。还有就是服务自身的变更，比方二进制变更、配置的变更、部署形式的变更、流量接入形式的变更，等等，也可能引发问题。最初就是上游拜访的形式，比方流量突增，显然也可能会带来故障。

那针对这些故障场景，咱们应该去看哪些数据呢？这其实就是可观测性数据底座的建设方向。

咦？说来说去，还是要建设 metrics、logs、traces、events？是的，但不仅是，只有数据还远远不够，咱们须要通过平台工具，通过数据经营整顿，帮忙用户找到数据特色，建设初步观点，最终造成洞察定位故障间接起因。还记得那张信息层级的图吧：

网上有人批评可观测性三支柱的说法，外围要点是：不能只关注 raw data，就像一道菜，只有原料还不能称之为一道菜，没有炊具、菜谱、厨师，无奈最终产出那道菜（客人要的是那道菜，那道菜才是后果，应该没有哪个餐厅说，你看我原料都有，完活了，让客人吃吧，应该没有这样的餐厅 …）。

Martin Mao 已经也写过一篇文章《Beyond the 3 Pillars of Observability》来阐述这个事件。

他的外围观点是：只关注三支柱 raw data，认为有了三支柱数据就建设了可观测性，是不对的，咱们更应该面向后果来思考如何构建整个体系，Martin Mao 认为，所谓的后果，就是 Remediate，就是止损！英雄所见略同。

还是参考方才信息层级的图，有了 raw data 数据底座之后，可观测性体系还须要利用平台能力、通过数据经营整顿，出现数据特色、帮用户建设初步观点，最终造成洞察，定位故障间接起因。

这应该是可观测性体系提供给客户 / 用户的第一个观点，故障产生了，当初都是微服务的，你得高深莫测的通知我具体是哪个模块故障了不是。总不能让我写一条有一条的 promql，看一个又一个监控大盘，能力找到故障模块吧。故障解决可是要争分夺秒的，一个一个查看太浪费时间了。

既然要高深莫测，初始页面上的内容不能太多，从技术角度来看，个别模块都是有层级关系的，首先是零碎，而后是子系统，而后是模块。所以，初始页面应该展现零碎的健康状况，如果某个零碎有问题，应该能够点击进去查看详情（这个过程称为下钻），下钻到子系统，再下钻到模块，最终找到故障模块。

那如何掂量一个模块是否衰弱呢？这其实就能够应用 SLO/SLI 这套体系，每个模块都有几个 SLI，每个 SLI 异样，这个模块就能够定义为异样，进而定义子系统异样、零碎异样，这个过程也有种故障冒泡上浮的感觉。

我以咱们的产品来举例这种效果图：

这样的零碎咱们称为灭火图，最上层是一个个的零碎卡片，如果有问题就会有个飘红的小火苗，点击详情进入，能够看到相干子系统，点击故障子系统，能够看到模块以及外围接口的列表，进而能够定位到故障模块或外围接口。产品通过色彩做疏导，而且具备层级关系，即可做到高深莫测。

模块依赖的数据库、中间件、根底网络、机器硬件、第三方服务等等，都会影响模块的健康状况。所以，当模块异样的时候，咱们须要晓得各项依赖是否衰弱，如果依赖也异样，那么模块异样的间接起因根本能够判定是异样的依赖项导致的。

要用可观测性产品建设这样的视图，外围有两点，一个是依赖的关联关系，一个是依赖项的 SLO 视图（通常体现为 metrics 仪表盘）。下图是一个逻辑示意图：

线上故障，大略 70% 都是变更导致的，所以运维行业中流传一句话叫：“变更是万恶之源”。所以，当故障产生的时候，咱们须要晓得是否是变更导致的，如果是变更导致的，就要尽快止损。

如果迭代比拟快，每周的变更数量会很多，那么如何疾速定位到是哪个变更导致的故障呢？这须要可观测性产品提供一些数据特色给用户，用户能力不便剖析。典型的是在工夫维度上做文章。把故障和变更放到一张图上，在工夫维度上做比照，比方从故障时刻往前看 1 小时，看看有没有变更，如果有，那个变更很可能就是罪魁祸首。示意图如下：

留神，这里的变更不仅仅是代码变更，还包含配置变更、机器变更、网络变更等等，变更事件收集得越全，越有价值。

下面，我举例了三个可观测性产品须要为用户输入的观点：

可观测性体系要通知我故障模块
可观测性体系要通知我故障模块的各项依赖是否衰弱
可观测性体系要通知我是否是变更导致的

当然，还有其余观点能够输入，比方是否是容量有余导致的故障，大家能够自行思考看看还能够让可观测体系输入哪些观点。然而，罗马不是一天建成的，在某个阶段，可观测性体系输入的观点无限，不足以帮咱们定位故障，此时，可观测性体系还能够做什么呢？

至多，还须要提供工具帮咱们剖析数据特色，别让用户陷入海量散乱的可观测性 raw data 中。这须要多维分析疏导能力、数据串联买通能力。举一个数据串联的例子：

可观测性体系不能仅仅只有散乱的数据，而应让数据出现特色，让特色出现观点，让特色和观点辅助洞察：洞悉故障间接起因，实现止损！这才是建设可观测性体系的外围指标。诸君共勉。如果您认同咱们的建设思路和价值主张，也欢送关注咱们的产品：https://flashcat.cloud/，咱们违心成为您向上的台阶，让您的可观测性体系更加欠缺，让技术体系底气更足。快来聊聊吧：

正文完