智能运维 | 百度自动化运维是怎么做的（下）——运维编年史

百度智能云

于 2018-04-04 11:47:50 发布

阅读量423

点赞数

文章标签：运维大数据编程语言数据库人工智能

原文链接：https://cloud.baidu.com/event/ABCFinance-2018/index.html

版权

在本系列的上一篇文章《百度自动化运维是怎么做的（上）——概念以及标准从何而来？》中，介绍了百度自动化运维以及自动化运维标准。在本篇文章中我们将详细介绍百度的三代运维平台，从web化走向开放，最终达到智能的过程。

首先确定的是，百度自动化运维标准中能力等级与能力描述对应关系如下：L0：人工（无自动化）、L1：工具辅助的自动化、L2：部分自动化、L3：有条件的自动化、L4：高度自动化、L5：完全自动化。

2008年以前无统一运维平台，这段期间，各团队处于开源、自研方案不一，抽象层次不一，自动化层次也不一的状态，可以认为大多数在 L1，部分还依然完全靠人肉（L0），少量已经踏进了 L2。

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

2008 立项开发的第一代运维管理平台（嗯，这就是很多友商经常提起的Noah平台，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 的解决方案，类似域名。服务名包含如下两大部分：

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

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

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

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

第二代监控系统（ Argus）：高性能、灵活定制的监控解决方案

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

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

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

第二代部署系统（一键上线Archer）：持续部署的瑞士军刀

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

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

运维数据仓库（ODW）：统一的运维数据管理方案

随着运维工具和平台的持续完善，以及运维服务规模的逐渐扩大，运维产生的数据也变得十分惊人。一方面，这些运维数据大多数都被都随意、分散地存储，而疏于被再利用；一方面，希望分析这些数据的业务或人，很难高效准确地获取所需要的数据。

伴随着Big Data技术的成熟，ODW平台应运而生，我们将监控指标数据、报警数据、上线变更的事件数据、服务管理配置数据等等，集成到一个数据仓库中。并在此基础上，提供开放的数据查询服务和计算服务。一般用户，可以直接在ODW平台，提交数据接入和数据计算的任务，平台可以为用户自动完成计算，并输出结果；而有复杂需求和自有计算资源的用户，也可以订阅所需要的高时效性的数据，自行完成数据分析工作。借助大数据的能力，运维在成本管理、效率管理、用户体验等方向得到全面提升。