导读 ：百度搜寻零碎是百度历史最悠久、规模最大并且对其的应用曾经植根在大家日常生活中的零碎。坊间有一种乏味的做法：很多人通过关上百度搜寻来验证本人的网络是不是通顺的。这种做法阐明百度搜寻零碎在大家心目中是“稳固”的代表，且事实确是如此。百度搜寻零碎为什么具备如此高的可用性？背地应用了哪些技术？以往的技术文章鲜有介绍。本文立足于大家所相熟的百度搜寻零碎自身，为大家介绍其可用性治理中对于“稳定性问题剖析”方面应用的精密技术，以历史为线索，介绍稳定性问题剖析过程中的困厄之境、破局之道、翻新之法。心愿给读者带来一些启发，更心愿能引起志同道合者的共鸣和探讨。
全文 5110 字，预计浏览工夫 11 分钟。
上周，在《百度搜寻稳定性问题剖析的故事（上）》中，曾经介绍了咱们是如何通过全面的数据系统建设解决问题追究的死角，没看过的敌人能够从新看下这篇文章。接下来，将分享咱们如何进行故障的自动化、智能化剖析，进步问题追究的效率。
第 4 章 再翻新：利用价值的再开释
4.1 巨浪——故障剖析的“起点”
回绝的剖析是一个定性的过程，依据回绝 query 激发的日志信息，就能够定位业务层面的起因，或者定位到引起异样的模块。
这个过程能够形象为上面几步：
(1) 故障（回绝）信号的感知
(2) 故障单位（query）全量信息（日志）的收集
(3) 依据收集到的信息进行故障单位（query）的归因
(4) 对批量故障单位（query）的起因进行再归类，以及特色开掘
整个过程须要在秒级实现，时效性要求很高。过程的顺利执行面临上面 8 个挑战：
挑战 1 ：如何实现疾速的日志检索。在采集到回绝信号之后，回绝的剖析须要疾速拿到日志原文，这些信息如果间接从线上扫描，速度和稳定性上显然达不到要求。
挑战 2 ：回绝定位的实时性和准确性之间的矛盾如何解决。日志越残缺，回绝起因的剖析后果越精确。然而因为网络提早等起因，剖析模块无奈保障马上拿到所有的日志。接管到回绝信号后就开始剖析，能够确保剖析的实时性，然而准确性难以保障。而提早一段时间再剖析，可能会拿到更残缺的日志，然而会影响回绝剖析的实时性。
挑战 3 ：如何精确全面地形容故障。生产环境的故障“形形色色”，如果一一进行表白和治理，保护老本会十分高。须要寻找一种计划，把所有的故障（规定）零碎、精确、全面地治理起来。
挑战 4 ：特色工程如何进行。在拿到日志原文之后，咱们须要确定从日志中应该拿哪些信息，如何采集这些信息，并且以程序能够了解的形式将这些特色表达出来，最终和回绝起因关联起来，即特色的抉择、提取、表白和利用。
挑战 5 ：如何还原 query 现场。在线零碎为了保障可用性，要害模块上都会有重查。在定位回绝时，须要还原出残缺的调度树，这样能力看到由根节点登程到叶子节点各条门路失败的起因，不然可能会失去矛盾的后果。如下图所示，A-1、B- 1 和 B - 2 节点都产生了重查，当拼接谬误时（C 模块的实例挂到了谬误的 B 模块节点下），B-1（或 B -2）的谬误状态和挂在它之下的 C 模块的日志状态可能是矛盾的，无奈得出正确的定位论断。
挑战 6 ：如何对回绝特色进行深度开掘。主动定位难以定位到根因，更准确的定位依赖人工参加的持续剖析。剖析工具须要能从各种回绝中找到汇集特色并以肯定的优先程序展现给用户，为根因定位或者止损提供更多线索。query 中能够提取的信息包含 query 的查问词（word），发送 query 的 client 端 ip，query 的语种或者解决 query 的机器所在的物理机房等。比方，当发现零碎回绝都和某个 ip 的攻打流量无关时，能够对该 ip 进行封禁止损。
挑战 7 ：级联故障如何感知。当某个模块故障引起回绝时，可能会产生级联的次生故障，体现为回绝间接起因多样化。下图展现了 一种典型的级联故障：E 异样后 B 对 C 发动了大量重查，首查叠加重查流量彻底把 D 压垮，最初 A 对 B 也开始发动大量重查。回绝的流量在个个模块都有可能命中限流策略，体现为不同的回绝起因。因而，在产生故障时，依赖某一个工夫点的回绝统计信息可能会覆盖引起回绝的根因。
挑战 8 ：如何定位未知故障。故障是偶发的，咱们进行回绝起因划分的时候所应用的划分汇合，无奈残缺体现零碎可能呈现的回绝起因。对于未知故障或者未被纳入到回绝定位规定中的回绝，咱们须要有伎俩“制作”故障，发现未知或者未采集到的故障。
上面，将顺次介绍咱们是如何解决这 8 个问题的。
4.1.1 索引镜像技术
为了实现日志的疾速检索，日志索引由在线采集模块提取后，除了推送本机建设索引之外，还将定位须要的子集被动推送至旁路索引模块，该模块会以日志对应的 queryID 为 key 写入内存介质的全量索引存储中。这里的索引反对多列稠密存储，雷同 queryID 的多条日志 location 能够追加写入。这样，单条回绝 query 的 location 信息能够已 O(1) 的工夫复杂度拿到，接下来并行地到指标机器上捞取日志，并将其写入长久化的故障日志存储中。最初对这些日志进行特征提取并剖析回绝起因。
4.1.2 流式剖析
为了解决问题 2，咱们借鉴了流式剖析的理念。无论是剖析模块收到了回绝信号还是增量的回绝日志信号，都触发一次回绝起因的剖析，并更新论断。这里有 2 个关键点：一是剖析主动触发，线上只有产生回绝，回绝剖析就开始工作。二是增量更新，只有某个回绝 query 的日志有更新，就从新触发故障起因剖析。对于入口模块，在线采集端会依据其日志中的指定字段判断是否是回绝，并将这个信号连同索引一起推送到旁路索引模块。旁路索引模块在收到该信号后会立刻告诉剖析核心对这个 queryID 进行剖析，因而剖析流程能够在回绝报警收回之前触发，最大化故障定位止损效率。当旁路索引模块向剖析模块触发完一次剖析申请后，会将这个 queryID 记录到全量索引存储的 pvlost 表中，当后续有非入口模块日志的索引达到时，旁路索引模块拿该索引中的 queryID 到这个表中查找，即可判断是否是须要触发增量剖析。增量剖析会合并所有已知日志，并更新剖析论断。
4.1.3 齐备 labelset
在入口模块接管到用户 query 后，该 query 会经多个模块的解决。每个模块都有读取、解析申请包，申请后端，解决后端返回后果，以及最初的打包发送流程。在这个形象层级上，申请解决各个步骤的划分是足够明确的，并且都可能呈现失败而引起 query 在该模块的回绝。所以，咱们对这个处理过程中可能失败的起因进行了枚举，构建了单模块故障起因齐备模板，将该模版利用到所有的必查模块就形成了故障起因的齐备汇合。
4.1.4 特色工程
在确定了齐备 labelset（回绝起因）之后，咱们须要在程序中实现主动的特征提取、表白，并和回绝起因建设映射。不同模块的业务日志差别很大，为了解决特色的提取问题，咱们实现规定提取引擎，输出为日志原文和提取规定，输入为采集到的特色。特色的类型次要有 2 种：指定内容是否存在、值是多少。在提取出特色之后，咱们应用一个向量示意各个特色的取值，当向量中某些特色的取值满足指定的条件（等于、在指定范畴等）时，就给出对应的回绝起因。
4.1.5 单 query 现场还原
日志剖析模块拿到的日志只是互相独立的节点，进行 query 现场还原后能力开始剖析。从入口模块开始，搜寻零碎的各个模块会把本人的 span\_id，以及所调度的多个后端的 span\_id 打印进去，根据这些信息即可还原调度现场。须要留神的是，模块发动的首查和重查是有先后顺序的，通过对一个节点的孩子节点的 span\_id 进行排序，即可还原这种调度上的先后秩序。在还原调度树之后，将调度树由根节点到叶子节点门路上的所有异样日志汇总，从中拿到所有的特色并和规定列表进行比对，即可失去该门路（调用链）的回绝起因。
4.1.6 智能 rank 算法
问题 6 的难点在于：在一批 query 所有维度的特色中，找到有显著汇集性的一个（一组）维度。这能够进一步示意为：在不同维度之间进行排序，找到排名最考前的维度，而排序的根据就是该维度外部取值是否有高度的汇集性。为了解决这个问题，咱们借用了熵的概念——当回绝的 query 在某个维度上取值汇集越强时，它的熵就会越低。在构建排序模型时，咱们对不同维度的取值进行了变换，确保不同维度可比，并退出了人工教训确定维度权重。这样就能够在呈现回绝时，依照程序给出回绝 query 在不同维度的汇集性，帮忙定位根因或制订止损策略。
4.1.7 工夫线剖析机制
为了精确感知到回绝的演化过程，咱们实现了 timeline 机制。收到回绝报警后，该工具会主动从巨浪获取回绝信息，依照秒级粒度进行回绝起因数量统计，并进行二维展现，如下图所示。在该展现后果上，能够看到不同秒级工夫各种回绝的数量，以及不同回绝起因随工夫的变化趋势，帮忙咱们定位根因。
4.1.8 混沌工程技术
问了解决问题 8，咱们引入了混沌工程的技术。混沌工程提供了向在线服务准确注入各种故障的能力，这样就能够拿到丰盛且带标记的样本补充到定位知识库中。这样不仅解决了日志样本问题，还可晋升对未知故障的预测能力，从“亡羊补牢”进化到“防患未然”，防患于未然。
这 8 大技术，很好的解决了后面的 8 个问题。在定位成果上，准确率可达 99%，呈现回绝后，产出模块粒度的回绝起因能够在秒级实现，剖析能力可笼罩大规模回绝。
4.2 长尾批量剖析
搜寻零碎中存在着一些响应工夫长尾，为了解决这个问题，咱们基于全量 tracing 和 logging 数据，实现了一套例行长尾起因剖析机制。该机制订时从入口模块拿到响应工夫长尾的 query，再对每个 query 调用全量调用链的接口拿到残缺的调度树。在剖析长尾起因时，从入口模块开始，通过广度优先遍历的形式，逐渐向后端模块推动，直到找到最初一个响应工夫异样模块，即认为长尾是由该模块引起的。
模块响应工夫异样的定义为：该模块的响应工夫超过了失常申请的极限响应工夫，并且它所调用的模块的响应工夫是失常的。在确定异样模块之后，能够进一步从全量调用链中有针对性的拿到该模块的日志，从日志中依据规定找到该模块解决耗时异样的阶段。
4.3 异样状态全流程追踪
为了确保用户体验的稳定性，搜寻会定期剖析未召回预期后果的 query。query 没有返回预期后果，可能是因为它命中了“捣鬼者”写入的 cache，也有可能它穿透了 cache，召回了有问题的后果，这里问题的起因可能是偶发的或者是稳固的。咱们须要能筛选出能够稳固复现的问题进行追究。为了实现这个需要，咱们先拿到各个 query 的 tracing 以及 logging 信息，依据这些信息能够：
（1）找到哪些 query 命中了“捣鬼者”写入的脏 cache；
（2）哪些 query 穿透到了后端并从新进行了检索。
将命中 cache 的 query 和写入 cache 的 query 关联起来，即可失去下图所示的后果——异样状态的全流程追踪。只有异样成果持续时间内的 cache 命中是间断的，并且触发了屡次 cache 的更新，那么就能够认为在这一段时间内，故障是稳固复现的，能够投入人力追究。
第 5 章 总结
本文首先介绍了百度搜寻可用性保障的窘境，超大的服务规模、极高频的变更和参加人数、海量数据和申请量、多样且多变的故障品种等形成的简单零碎，对年只能停服 5 分钟的极其严格可用性指标形成了极大挑战。而后，以工夫程序介绍了咱们对百度搜寻可用性保障的解决经验和教训。
首先，为了解决问题追究死角的问题，咱们建设了可观测根底——logging、tracing、metrics，这些没有精密加工的根底数据解决了可用性保障中的一部分问题，然而咱们发现根底数据的自动化水平较低、智能性较差，简单问题须要大量人力投入，剖析成果强依赖人工教训，甚至根本无法剖析。
更进一步，为了解决可用性保障的效率问题，咱们对体系中的各个组件进行降级，使可观测性的产出变得可观测，简单的成果故障由不可追究变得可追究，回绝剖析从人工变得主动、精确、高效。在整个体系建设过程中，咱们从数据的消费者，变成数据的生产者和加工者，通过数据的生产、加工、剖析全流程闭环，使得百度搜寻中各种故障无处遁形、无懈可击，使得百度搜寻可用性保障摆脱困境，继续维持较好的用户口碑，同时本文也心愿给读者带来一些启发，更心愿能引起志同道合者的共鸣和探讨。
本期作者 | ZhenZhen；LiDuo；XuZhiMing
招聘信息 ：
关注同名公众号百度 Geek 说，点击菜单栏“内推”即可退出搜寻架构部，咱们期待你的退出！
举荐浏览 ：
|百度搜寻稳定性问题剖析的故事（上）
|百度对于微前端架构 EMP 的摸索：落地生产可用的微前端架构
|社群编码辨认黑灰产攻打实际
|PornNet：色情视频内容辨认网络
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注