百度自动化运维的演进（二）：百度自动化运维编年史

在本系列的上一篇文章《百度自动化运维的演进（一）：聊聊百度自动化运维》中，百度运维部元老级高工运小皮介绍了他眼中的自动化运维以及百度的自动化运维标准。在本篇文章中运小皮将详细介绍百度三代运维平台，百度运维平台从 web 化走向开放，最终达到智能的过程。

百度自动化运维标准中能力等级与能力描述对应关系如下：

L0–人工（无自动化）

L1–工具辅助的自动化

L2：部分自动化

L3：有条件的自动化

L4：高度自动化

L5：完全自动化

2008 年以前 无运维平台

这段期间，是分散的团队、小组各自为政的时期。开源、自研方案不一，抽象层次不一，自动化层次也不一，可以认为大多数在 L1，部分还依然完全靠人肉（L0），少量已经踏进了 L2。

2008-2011 年 第一代运维平台，Web 化

2008 立项开发的第一代运维管理平台（嗯，这就是很多友商经常提起的 Noah 平台），标志着百度自动化运维全面迈向 L2。这期间我们的主要工作是研发一个统一的运维平台来代替人工执行一系列运维工作，包括资源的管理（增删改）、服务运行状态的采集、服务变更操作等等。

服务树：资源、机器管理

由运维人员管理的资源有哪些？归根到底是三类：软件、硬件和人；具体讲主要就是服务、机器和权限。

2008 年，我们第一次以服务为中心来进行组织和管理资源，也即“服务树”：

• 首先，通过“公司/部门/产品线”这类客观存在的管理范围，自顶向下地定义树形结构，并且允许通过自定义子树节点的方式来扩展管理多个服务；

• 其次，机器挂载到服务树的叶子节点上，这样就可以通过服务及其从属关系来管理大量的机器；

• 最后，将人员归属到一系列角色权限中，并以服务树来定义其作用域。

在统一到服务树这个模型之前，虽然已经有诸多解决方案和工具了，无论形式上到底是命令行还是一些开源平台，但究其本质上都是通过数组结构来管理若干个机器列表。树形结构在表达归属、层级、继承等关系上的优势，大大方便了其他运维系统组件的设计和实现。

监控：标准化采集

基于服务树提供的具有层次和继承关系的机器管理方案，监控系统就方便多了：只要专注于服务状态的采集、呈现和报警策略即可。

第一代监控系统包含机器监控和服务监控两大类。机器监控全覆盖地采集机器的基本信息，包括各类硬件资源的使用情况（cpu、内存、磁盘 io、网络带宽等）。服务监控以探针（probe）的方式检测服务的健康状态。探针支持不同的协议和方式（HTTP、Socket），并且定义了最简单的自定义数据采集协议（基于 Bash 命令行）。

随着产品服务的迭代，对服务的运行状态需要更精细的掌控，第二代监控系统应运而生。 监控功能不断拓展，增加了进程级的资源数据采集、基于日志匹配的业务指标统计监控、报警的汇聚与合并。与此同时，我们也在实践过程中提炼同类服务间的共同点，提出了第一版的监控规范，赋予数据特定的运维语义（存活性、资源消耗、业务功能等等）。

上线系统：自动化部署

Noah 上线（又称 Noah web 上线、ad-web 上线）系统是第一代的自动化部署系统，其核心设计目标是，实现一个通用的平台来替代运维工程师在上线时的手工操作；所以其基本设计思想是翻译上线步骤（备份、下载、替换、重启等文字描述）为一系列标准的操作命令（wget、cp、mv、restart 等）。

2011-2014 年 第二代运维平台，开放

随着业务规模的扩张，集群规模也在指数型增长，统一的、Web 化的运维平台也遭遇了瓶颈：

众口难调：和业务特点相关的需求越来越离散（有的重效率，有的看重流程的完备性，有的对易用性要求高）再加上需求方越来越多，功能交付排队积压严重。

性能差：极端情况下，需要提交一个 K 量级机器的操作，平台响应长达数分钟，甚至还有比较高的错误率。

于是，这段时间，我们增强了运维系统的架构能力，使其可以更方便定制和集成，为全面进化到 L3 级自动化做好了准备，且在变更领域开始向 L3 迈进。

BNS：一种更简单、高效的服务发现和管理方案

服务树的路径，和文件的绝对路径一样，理论上可以作为服务的一个全局、权威的名字，但因为其路径中耦合了组织和管理上的信息，导致这部分的变化带来的协同修改成本非常高，于是 BNS（Baidu Naming Service）应运而生。

BNS 参考 DNS 的解决方案，类似域名。服务名包含如下两大部分

DNS 的解决方案，类似域名。服务名包含如下两大部分：

• 名字空间只包含两类和服务管理紧密相关的信息，即服务的物理部署（机房）和业务归属（产品线）

• 在名字空间下只需要保持名字唯一即可

这个名字可以稳定、一致地被用于各个系统之间交换服务实例列表（类似 IP 列表）。 除此之外，它也可以挂载到服务树上，继续满足组织、行政、权限等管理需求，同时这也保持了和服务树原有模型的向前兼容。

进一步，随着实例标签（Tag）的支持，我们可以以多维度视图的方式来管理服务，终于打破了树形结构的挚肘。

监控 3.0 Argus：高性能、灵活定制的监控解决方案

第三代监控系统，基于先前在监控数据应用场景的经验，抽象出来多维度时序数据的模型，设计和实现了相应的存储架构（时序数据库 TSDB）、计算架构（多维度流式聚合计算），打开了运维数据分析的新篇章。

与此同时，为了方便集成，监控采集方式更加灵活（采集接口、数据库直推等），监控配置规则也彻底 DSL 化，使监控的设计可以和开发编码阶段的工作流相结合。

大量的数据，带来了大量的辅助分析工具和数据可视化需求，运维平台和业务运维同学紧密配合，合作研发定制化的监控平台实践逐渐成熟。

一键上线 Archer：持续部署的瑞士军刀

由于 Noah web 上线只维护当次上线涉及什么文件、什么命令，是典型的“增量”模式，只能看到局部的 diff，不利于服务生命周期内更多场景下的自动化工作开展，诸如：服务迁移、故障处理、测试调研实验等同源环境搭建等。

所以在 2011 年我们推出了它的继任者，Archer 上线，其基本设计原则，来源于当时业界的“持续集成/交付”和“DevOps”思潮：将决定服务运行逻辑的所有代码、配置、数据、运维接口等信息进行同源（仓库）管理并全量发布，基于此简化部署系统的内部设计实现复杂度、提高了二次开发的灵活度，促进了整个构建、测试、上线流水线的自动化。

2014 年-当前 第三代运维平台，智能

2014 年是百度智能运维元年，自此之后，异常检测、多维度分析、关联推导等算法策略逐渐应用，感知、决策、执行的工程框架逐渐定型。我们迎来了 L3 自动化的大规模实施，并开始迈向 L4。

总结

从 2008 年以前至今，百度运维平台经历了 web 化、开放、智能三次重大变革，期间百度运维部研发了服务树、监控系统、Noah web 上线、BNS、监控 3.0 Argus、Archer 等系统，助力百度运维逐步走向智能化。

作者介绍：

运小皮，百度资深运维工程师，负责百度智能运维平台的设计和实施。曾负责网页搜索、移动搜索产品运维和服务高可用、持续部署等技术方向。

本文转载自公众号 AIOps 智能运维（ID：AI_Ops）。

原文链接：

https://mp.weixin.qq.com/s/66K0hg79mDVEn_H87tTPPg