百度智能运维的技术演进之路

随着大数据、人工智能、云计算技术的日渐成熟和飞速发展，传统的运维技术和解决方案已经不能满足需求，智能运维已成为运维的热点领域。同时，为了满足大流量、用户高质量体验和用户分布地域广的互联网应用场景，大型分布式系统的部署方式也成为了高效运维的必然之选。如何提升运维的能力和效率，是保障业务高可用所面临的最大挑战。

6 月 23 日，由百度开发者中心、百度云智学院主办，极客邦科技承办的第 79 期百度技术沙龙邀请了来自百度智能云主任架构师王栋，百度智能云架构师哈晶晶，百度智能云资深运维架构师杨涛，百度智能云架构师章淼，百度智能云架构师余杰及百度智能云资深工程师廖洪流六位讲师，分享百度在 AIOps、DevOps 上的实战经验，并以百度统一前端接入（Baidu Front End, BFE）、数据库以及 Redis 三个具体系统为例，介绍百度在系统架构设计和变更、监控、故障处理和性能管理等贯穿线上系统生命周期的运维层面上，如何保证系统的高可用。

1 高可用性系统的架构与运维实践

百度智能云主任架构师王栋做了开场演讲。他首先介绍了百度运维发展的历史，主要分为三个阶段：一、基础运维阶段。提供机器管理，服务管理和权限管理，保证线上基本服务运行，并对线上基本数据管理进行监控。二、开放运维时代。以开放 API 的形式，把第一阶段业务层面的运维交给各个业务部门。但是面临着垂直场景重复制造轮子，所积累运维知识和数据难以汇聚的问题。三、智能运维阶段。构建统一的运维知识库，一致的运维工具开发框架以及全局可见的算法复用平台。

下图为百度智能运维整体框架图。最下方是基础运维平台，提供最基本的运维能力，在此平台的基础上构建运维开发框架、运维知识库和运维策略库，在面临不同的场景和不同的业务将所有场景的算法抽样出来提供服务。

智能运维和要解决的问题场景

王栋现场对运维问题的复杂程度做了区分，如下图所示。纵轴表示问题的难易程度，横轴表示问题发生的频率。这样运维问题可以总结分成四个象限，对于每一个象限采取不同的应对措施。左上角低频高复杂问题，可以希望智能辅助决策，增强人的能力；右上角高频复杂问题，希望达到智能的决策，智能执行，并可迁移，而人只需做一些基本辅助工作即可；左下角低频且简单的场景，这是比较好解决的问题，只需把问题的解决策略规范化、流程化；右下角高频但是简单问题可通过自动化、自助化将问题解决。

2 百度 AIOps 实践

百度运维经历了脚本 & 工具、基础运维平台、开放运维平台阶段，在 2014 年开始智能化运维的探索，并且围绕可用性、成本和效率方向的运维目标，在诸多运维场景落地。百度架构师，智能监控业务技术负责人，智能故障自愈方向技术负责人哈晶晶以百度故障处理场景为例，介绍百度故障预防的智能 checker 自动拦截异常变更，故障发现的异常检测算法，以及故障自愈的单机房故障自动止损实践。

百度 AIOps 技术架构

百度智能运维将 Gartner 中提到 AIOps 的大数据和机器学习的理念应用于四大运维场景，开发成一系列的智能模型和策略，并融入到运维系统中，帮助提升运维自身的效率，以及解决传统运维方法所不能解决的挑战。

首先，为了解决不同业务线对运维对象的定义、操作接口、运维模式差异化的问题，百度提出了指导智能运维的三个原则：

• 书同文：一致运维“语言”；如运维应用、服务、机房、集群的定义

• 车同轨：一致运维“方法”；如扩缩容执行、流量切换执行

• 行同伦：一致运维“模式”；如故障诊断策略、弹性伸缩策略、流量调度策略

根据以上 AIOps 中书同文、车同轨、行同伦的指导思想，百度基础运维和智能运维平台也聚焦在：数据、工程和策略三个方向。如下图所示。

• 数据方向：运维数据仓库 & 运维知识库

• 工程方向：运维大数据平台 & 运维工程研发框架

• 策略方向：运维策略算法平台和运维大脑（运维策略库）

该平台最终支持了故障管理、变更管理、服务咨询和容量管理场景的解决方案，并且应用到百度的内部、公有云和私有云客户。

运维知识库

运维知识库是一个基于 CMDB、数据仓库、知识图谱技术，对各类型运维数据，进行统一的 ETL 处理，形成一个完整的运维数据存储并且提供查询和使用的服务。该知识库系统功能第一要全第二要准，同时对整个架构的可用性要求较高，以便供运维使用。

运维数据分为元数据、状态数据和事件数据三大类：

• CMDB（MetaDB）：存储运维元数据和配置数据，包括不限于产品、人员、应用、服务、机器、实例、数据中心、网络等信息和关系

• TSDB（基于 HBase）：存储运维时序指标数据，包括不限于硬件和软件的可用性指标、资源使用率指标和性能指标

• EventDB（基于 Elasticsearch）：存储运维事件数据，包括不限于异常报警事件、故障处理事件、变更事件等

运维工程研发框架

每个运维智能操作都可以分解成感知、决策、执行这样一个标准流程，这样一个流程叫做智能运维机器人。如下图所示。运维工程研发框架提供感知、决策、执行过程常用的组件，便于用户快速构建智能运维机器人。例如这三种组件可以组织成简单的报警回调机器人和自动编排机器人。报警回调机器人可以应用于故障自愈，自动编排机器人可用于分级变更。

先来看 Sensor，Sensor 是运维机器人的眼睛和耳朵，就像人有两个眼睛和两个耳朵一样。运维机器人也可以挂载多个 Sensor 来获取不同事件源的消息，比如监控的指标数据或者是报警事件，变更事件这些，甚至可以是一个定时器。这些消息可以通过推拉两种方式被 Sensor 获取到。这些消息也可以做一定的聚合，达到阈值再触发后续处理。

再来看 Decision-Maker，DM 是运维机器人的大脑，所以为了保证决策的唯一，机器人有且只能有一个 DM，DM 也是使用者主要要扩展实现的部分。除了常见的逻辑判断规则之外，未来我们还会加入决策树等模型，让运维机器人自主控制决策路径。

最后看 Executor，执行器是运维机器人的手脚，所以同样的，执行器可以并行的执行多个不同的任务。执行器将运维长流程抽象成状态机和工作流两种模式。这样框架就可以记住当前的执行状态，如果运维机器人发生了故障迁移，还可以按照已经执行的状态让长流程断点续起。

运维大脑

有了数据和工程就有运维大脑。运维大脑包括异常检测和故障诊断，这两个部分的共同基础是基本的恒定阈值异常检测算法。恒定阈值异常检测算法利用多种概率模型估计数据的概率分布，并由此产生报警阈值。在数据的特点随时间发生改变时，算法可以利用最近的数据修正概率模型，自动产生新的报警阈值。

由于许多数据具有上下波动的特性，恒定阈值法不能很好的描述数据的特点，所以百度发展了基于环比和基于同比的异常检测方法。环比的异常检测方法假设输入的时序数据总体上比较平滑，通过平滑算法预测数据的基准值。然后将数据的观测值与基准值相减即可获得残差，恒定阈值算法应用在残差上就能够检测异常。环比方法主要用于检测突增突降类型的异常，但是有些数据在发生异常时上涨或者下跌比较平缓，这就是环比算法无法胜任的了。

在故障诊断方面，百度基于异常检测算法开发了指标自动排查算法和多维度分析算法。指标自动排查算法能够自动扫描所有监控指标，并筛选出在故障发生前后发生剧烈变化的异常指标。然后算法将这些异常指标整理为异常 pattern，并将异常 pattern 排序，把与故障原因最相关的异常 pattern 呈现给运维工程师。

而多维度分析聚焦于带有多个 tag 的业务数据。它先利用异常检测算法标记异常的业务数据，然后利用信息理论的方法寻找覆盖多数异常的 tag 组合。这些 tag 组合常常可以直接指明故障的原因。如果把每个 tag 看作是高维空间的一个维度，异常数据相当于分布在一个超立方体中的点。寻找覆盖最多点的子立方体，所以称为多维度分析。

故障管理 AIOps 实践

故障的完整生命周期包括隐患阶段、故障发生、故障发现、故障止损、故障恢复、故障分析、故障改进和故障规范阶段，每个阶段都可以使用 AIOps 相关的方法提升故障管理的质量。如下图所示。

故障预防实践

互联网企业产品迭代的速度非常之快，但是有变化就会有风险，2017 年的服务故障有 54% 是来源于发布，release 是当之无愧的服务稳定性第一杀手。基于此问题，百度提出了不同的预防措施：

1. 从测试流量到真实流量，百度首先部署 sandbox，这种情况下是无损失的

2. 从一个 IDC 到更多 IDC，百度挑选流量最少的 IDC，异常情况下损失较少，或者可以快速切流量止损

3. 从少数实例到更多的实例：百度先部署某个机房的 1%，再部署 99%

有了合理的 stage，就可以基于发布平台做自动化检查的工作。在每个 stage 结束之后，会自动检查是否有报警发生，如果有则会停止变更。

变更通常会检查可用性指标、系统相关指标和业务逻辑类的指标。但是人工检查的时候会遇到以下问题：指标覆盖率不会很高，阈值设置困难导致的漏报 & 误报。使用智能 Checker 的程序自动检查方法可以解决这些问题。

故障发现实践

我们面临的业务种类繁多，业务指标类型众多，比如请求数、拒绝数、响应时间、流水和订单等类型的数据。不同业务不同数据的曲线，波动模式也不一样，在监控阈值配置时通常会遇到以下的问题：1. 不同的监控项需要应用不同的算法；2. 忙时 & 闲时、工作日 & 休息日阈值设置不同；3. 后期随着业务发展需要不断完善阈值配置；4. 监控指标爆发式增长，配置成本极高。

在这样的背景下，我们对数据进行分类，针对不同的场景提供不同的异常检测算法解决人工配置困难和监控漏报 & 误报的问题。

• 周期波动的数据，典型场景：广告收入、搜索流量等。算法：同比基准值检测

• 关心突变的数据，典型场景：交易订单、流水等。算法：环比基准值检测

• 关心是否超出了一定波动范围的数据，典型场景：pvlost。算法：基于概率的恒定阈值检测。

故障自愈实践

人工处理故障通常面临着响应时间不够迅速、决策不够精准、执行误操作的情况发生。故障自愈是通过自动化、智能化处理故障节省人力投入，通过设定的处理流程提高故障处理可靠性，同时降低故障时间，为业务可用性保驾护航。

单机房故障是业务的常见故障，百度的核心业务线均实现了 2 到 5 分钟内的故障自愈。如下图所示，整个这个框架充分利用了前面提到的运维策略库、运维开发框架和运维知识库构建单机房故障自愈程序。整个自愈程序也是感知、决策、执行判断的。自愈程序分两个，一个是机房外网入口故障，通过外网监控发现问题，通过 DNS 流量调度来解决；另一个是在百度内网机房故障和业务单集群故障，通过业务监控发现故障，通过内网流量流量调度、服务降级和主备切换多种手段结合进行止损。

3 大规模数据中心变更风险应对之道

在大规模数据中心中，对生产环境的变更来自于各个方面，有机器类操作、机器环境变更、服务操作等等。这些变更无论是自动化的还是手动的，任何一次变更都会带来服务稳定性风险。百度智能云资深运维架构师杨涛从具体的案例出发，介绍百度应对变更风险的防御机制演变及最佳实践。

变更是什么？

变更就是对于生产环境，也就是线上环境进行的任何非只读动作。比如说最基础的机房网络调整变更、物理机重装重启、基础环境变更、容器实例的变更等等。这些变更有很多来源，以前最主要来源是人工，根据业务需求或者稳定性的需求进行；另外一个主要的来源是自动触发，包括发布流水线、机器自愈系统、弹性扩缩容等。

历史上出现的三次 Case

杨涛首先介绍了百度历史上出现的三次 Case：

• 误操作导致网页数据库被大规模删除

• 程序 Bug 导致网页数据库丢失 1% 数据

• 程序 Bug 导致少量虚拟机被 Kill

然后从 Case 中分析出了变更的基本模式：

• 方案审核：所有线上变更方案，均需要进行方案 Review

• 变更检查：线上变更之前以及完成后，需要按照检查列表进行检查，保证服务正常

• 分级操作：并发度、间隔、小流量、抽样、分组操作

但是同时提出，最大的困难是如何指定合理的机制来确保所有人和系统都遵守变更的基本模式。

变更怎么做？

杨涛介绍了变更的四大风险，其实本质上就是人的风险：

第一是操作不一致的风险

操作内容受操作者自身经验、知识深度、对服务的了解程度、稳定性意识而不同，从而制定出完全不同的变更方案，并有不同的变更流程。

解决方案有二，一是制定流程规范，变更之后要有变更方案评审。百度的实践是一周完成全部变更计划，然后再审核、发单、检查；二是制定标准 SOP 手册，形成指导日常工作的规范，所有的人参照标准的 SOP 进行线上变更，从而保证操作内容一致性。

第二是操作不准确的风险

变更方案和具体实际执行不一致，特别是手动的误操作的风险。这个解决方案就是运维最基本的能力 - 自动化。而 SOP 进行自动化的时候，需要有先后顺序，主要根据如下标准选择：复杂程度，风险程度，操作频次。

第三是流程退化的风险

流程存在退化情况，刚开始遵守流程，随着时间的推移，例外越来越多；另外自动化的脚本或系统，维护成本较高，其很难实现全流程（如变更自动检查）。于是可以通过软件工程的方式解决问题 – 平台化。平台化的要点是：使用 API 关联相关系统，提供稳定有效的服务，对基础流程进行标准化，保证流程可执行。

以 UItron 为例，它解决了机器管理的三个问题。第一个问题是怎么做机器环境初始化和怎么保证线上所有机器一致性。第二个是故障机器自动维修，自动恢复服务。第三个问题是如何在不停服务维修磁盘故障。Ultron 中每一台机器都有一个状态机，依赖百度的标准化服务，当机器发生硬件故障时进行服务迁移，维修成功后又加入到资源池，保证容量的稳定性。

第四是检查不充分的风险

解决方法是检查机制，分为变更后的检查和变更前的检查。变更后的检查主要是通过联动 SLA 系统、监控系统、冒烟平台等第三方系统，进行变更效果检查。

而变更前的检查，则重点关注操作风险的防御，在操作尚未实施的时候就将危险操作拦截住，从而保证线上服务的稳定性。

更多的问题

最后，杨涛以一个开放性的 Case 结束了本次分享：

• 当自动化平台不可用的时候，人工执行了虚机迁移操作，操作错误出现故障

这个 Case 引申的问题很多：

• 如何保证自动化平台的高可用以及进行风险控制

• 如何保证人在习惯了自动化平台后，不丧失故障处理的能力

4 百度统一前端平台技术面面观

网络接入服务是用户和后台服务间的桥梁，对服务质量影响巨大。百度智能云架构师章淼介绍了 BFE 研发中包括网络协议、网络安全、高性能系统在内的多个技术方向，以及提升平台稳定性和研发效率的研发方法优化。

百度统一前端

百度统一前端 BFE 分为四个版块，上游是四层的网关 BEW，下面作为七层的转发网关具有七大功能，第一是转发，包括多种协议，除了最基本的 HTTP，HTTPS，还有 HTTP2。第二是流量调度，一个是外部还有一个内网。第三是安全和反攻击。第四个是海量访问日志分析与做实时流量报表。

BFE 若干技术点的深入

章淼将 BFE 的技术点分了四个方向，首先是接入转发，第二点全局流量调度系统，第三点数据分析，第四点平台运维和运营。

转发模型

如下图所示为 BFE 基础转发的步骤。用户解析域名，当达到第三步时，可以拿到 IP 地址请求四层网关 BW，BW 会把流量转到 BFE。左侧是 BFE 四步要做的工作，首先根据外网的 IP 或者运营确定租户，第二步确定它属于哪一个集群，第三步是 BFE 要确定它属于哪一个子集群，可以看这右图，三个椭圆表示三个不同的 IDC，最后确定把这个流量打到哪一个实例。

全流量调度系统

全局流量调度架构分为两层: GTC(外网) + GSLB(内网) 。下面是内网调度，任务是把 BFE 接入到流量，转发到下流多个应用的集群上。这个机制在 2013 年上线，当出现问题时可以通过内网调度执行。内网的处理百度主要考虑了两个因素，首先是到 BFE 流量，第二是考虑下游的流量是什么样的，同时考虑内网的因素，以本地优先为原则，如果出现流量大于本地流量的情况下，要负载均衡这是内网。

数据分析

章淼介绍了数据分析在 BFE 的价值，首先可以产生业务相关的报表，还可以用它了解下游集群的健康状况，另外还可以感知外部网络的状况。

那么 BFE 是如何实现准实时流量报表呢？ 百度自己定义了一个系统，内部称之为 FLOW。采用多级的方式，在 BFE 做一次汇计算，把汇计算结果打到一级汇聚，打到二级汇聚，最后把数据结果存十几个数据库 TSDB。

平台运维和运营

运维：保证整个平台的稳定运行

• 监控：转发引擎对外暴露数千个变量

运营：提高用户的满意度

• 投入 2 年以上时间研发用户平台

• 用户配置在 2 分钟内自动下发生效

• 每个租户都有独立的数据报表

• 完整的用户手册

5 百度数据库运维及 Redis 异地多活实践

最后，由百度智能云架构师余杰和百度智能云资深工程师廖洪流共同介绍百度 DBA 的 MySQL 服务和百度 Redis 异地多活实践。全面呈现百度 MySQL 服务生命周期内服务运维保障以及百度在使用分布式缓存系统时会遇到的问题以及对应架构的演化过程。

数据库高可用

当前百度 MySQL 提供的架构为三层架构，业务方面使用的是 BGW 方式以及内部的 BNS 服务，中间层为自研中间层的代理，最底层为 MySQL 集群服务。如下图所示。

对 MHA 架构的调研：

MHA（Master High Availability）是一套优秀的作为 MySQL 高可用性环境下故障切换的高可用软件。在考虑不用代理的情况下，使用 Manager 提供的服务，直接对租户进行对接，可以处理在一些简单场景下对于高可用的需求，且 MHA 内部有一些数据补齐的能力和处理方式。

MHA 无法满足百度当前面临的需求，原因如下：

• 故障识别方面的一些处理方式无法满足当前遇到的场景；

• 由于 MHA 对集群内部信任关系的强依赖，出于对安全方面的考虑，百度不允许在上万台机器之间建设信任关系；

• 还有一些数据补齐，选取主库过程的一些问题。

数据库高可用—故障识别

结合完整数据库内部识别故障。首先收集节点信息以及状态，查看连接数，判断是否是由于 MySQL 实例自身的压力问题或其他问题导致感知到 DB 有异常的状态，进而上升到联合从库的信息检测当前的主库是不是正常。检测感知异常是否是由于假死或压力过大，然后上升集群内部的联合诊治机制。最终上升到整体数据库 APP 检测机制，以此来决策到底要进行怎样的切换。同时，在切换时要考虑主从之间延时的问题。基于前面的感知，以及识别，做真正的故障处理。

数据库高可用—故障处理

当在前面的识别阶段感知到做的主从切换的时候，百度会在代理层把主库完全替换掉，这个问题在一定程度解决切换的过程中出现主库重新写的问题。接下来就是选择主库的过程，当真正拓扑完成后，会将完成信息通过网通节点发送至代理节点。这一选取新主库的过程，就是进行故障处理的过程。

数据库高可用—脑裂问题解决

对这一问题的解决方案为引入第三方仲裁机制和机房区域内分机房的监测机制。通过两个管控节点，一个是区域内的 Agent，另外一个是全局管控节点，识别是否可以和其他区域内的实例通信，进一步判断是否属于区域性的网络问题，以及是否会出现脑裂，通过一系列的机制，来制定相应的决策。

一旦识别当前出现区域性网络问题，Zmaster 可以暂停本区域有主库，屏蔽区域内不可管制的部分实例的信息，杜绝了出现脑裂问题。

区域网络恢复后，Zmaster 和 Xmaster 会检测整体主从架构，再恢复区域网络代理信息，最终通过自动化方式，恢复至整体可用。

Redis 异地多活

随着业务发展，百度需要将服务部署至多个地域，同时要求数据一致。为了满足这个需求，百度提出了主地域的概念，所有数据写到主地域，其他从地域通过 Redis 自带的复制功能实现同步，这样就实现了不同地域间的数据同步。同时考虑到多地域之间数据主机房出现故障能够止损自愈，百度对整机房切换方案进行了支持。另外由于考虑到服务有可能不断扩容的需求，实现了在线扩容。

百度 Redis 架构是如图所示。设置一个 Reader，和地域之间的关系是 1：1。每一个 Redis 只对应一个 Reader，而这个 Reader 同步数据的目的地不是其他地域的 Redis，而是一个消息中间件，通过消息中间件的转发能力，实现地域的同步，而所有的 Reader 只负责将本地的信息传到 Redis。

但是在真正实践方案时会遇到什么技术难点？

Redis 跟 Reader 数据同步采取什么方案？很自然用 Redis 主从同步来做。但是主从同步是可靠的吗？先简单回顾一下 Redis 原生的增量同步的方案是什么，原生的增量同步是数据写入了 Redis Master，Redis Master 有一个环形队列，当 Redis 跟 Master 进行数据同步的时候，它会先尝试使用它当前同步点，就是 Offset，当这个 Offset 在这个里面会一次性同步给 Slave。但是这里面存在什么问题呢？当你的 Offset 不在这个序列里面，这个存在全量同步，同时还有一个问题在于它为了保证数据一致性，Slave 进行全量同步的时候，先将自己本身数据清掉，清掉以后再进行同步。

所以针对这个问题百度做了一些思考，在 AOF 基础上做了一些调整。采用按照一定大小进行切割的方式，同时引入 OP_ID 的概念。每一次操作名由 OP_ID 决定，这样从库拿原生的命令，还有 OP_ID 的信息，如果主从关系断了，它会拿现在 OPID 请求 Master，Master 会查找，找到这个 OP_ID，并基于 AOF 的数据进行同步。