问过一些技术方向的朋友，在他们眼中运维是做怎么样的事情？其中大部份人回答说：搬机器、装系统、收报警、写各种各样维护清理的shell脚本等等。运维真的只是做这些事情？

不同的公司、不同规模的集群，运维所做的事情是否一样？运维到底要解决什么样的问题？运维和研发会是一种什么样的关系？普通规模的集群运维和上万台机器级别的集群运维之间有怎样的跨度和差异？下面看看2011系统架构师大会上，百度运维部高级工程师余沛介绍百度运维部的相关技术。

自动化运维是现在很热门的一个话题，各类技术大会上大家都在谈，各个公司都期望以最快的速度奔向运维自动化。接下来介绍一下百度的自动化运维方向，主要介绍两部份内容：

第一个部份，介绍百度的运维发展到今天，所走过的路程，以及百度的自动化运维现状。

第二个部份，会给大家介绍下百度的自动化运维平台中，关联关系方向的组成体系以及解决方案。

一、百度的自动化运维现状

第一个阶段，人人皆运维

什么是“人人皆运维”呢？就是说，当公司规模还小的时候，产品线、机器都不多，公司不一定有专门的运维人员或部门，而运维所做的工作穿插在各类角色中。比如研发人员可以拥有服务器权限，自己去维护和管理线上代码及业务。没有成案的总结，谁的代码谁负责，出了问题直接上线解决。通常在几台到几十台机器的规模，其代表现象是：手工上线，手工管理；运维视角以模块为粒度。

 第二个阶段，纵向自动化

什么叫纵向自动化呢？就是指，在这个阶段，已经开始关注运维自动化，开始针对不同的运维问题能够有一套单独的解决方案。但这些解决方案通常是有一件解决一件，不具有平台化的性质。所以我们叫它纵向自动化。比如需要搞自动化监控了，那就去搞一套开源的监控的东西；需要自动化上线了，再去搞一套开源的上线的东西。两者之间没有关联，各解决各的问题。

在这个阶段的特点是：公司开始有专门的运维人员，从事日常的安装维护工作，扮演救火队员，收报警，有运维规范，但运维主要还是为研发提供后置服务。

有自己业务范围适用的自动化脚本、利用开源软件的拼装完成大部份工作。通常在上百台至几千台机器的规模公司。代表：各产品线自已编写的脚本、利用如SVN+puppet或chef来完成上线和配置管理等。运维视角是以机器为粒度。

 第三个阶段，一切皆自动

在这个阶段，运维自动化，会在各个问题的解决方案之间织网，形成一套关系型的平台。有统一的自动化运维体系，运维与开发已经是平行视角。运维更关心产品在架构层面的优化以及超大规模集群下的自动化管理和切换。能利用自动化平台完成各种产品线的监控、部署、关联关联管理。运维开始在整体架构层面为研发提供前置服务。通常在大几千台到上万台机器的规模公司，运维视角已经是以服务为粒度。

二、为什么我们要过渡到第三个阶段?

主要是由以下三个原因推动：

第一是：随着规模的增长、产品线的增多、变更越来越频繁，一个服务的运维环境越来越复杂化，机器粒度的状态已经不再能反应服务粒度的状态（比如一台，二台数据库机器挂掉，不代表整个MYSQL服务挂掉。）

第二是：单机+批量的操作模式较为粗放，不能满足精细控制。比如我们要做小流量上线，或者在上线的过程中对机器进行分组，并进行串、并行控制。

第三是：伴随规模的增长，服务之间的关系会变得交错纵横，互相影响。

三、自动化运维体系-关联关系方向

刚才我们说到了百度的整个自动化运维体系，包括了部署自动化、监控自动化、关联关系管理以及业务系统四个大块。接下来重点讲一下什么是关系管理，大家先来看看场景：

第一种，我们有很多业务模块，像流水线一样依次调度。A完成了执行B，B完成了执行C，假如A没有做完，那么B不能做，它们之间是有依赖关系的。

第二种，我们有一些业务模块，负责生产数据，有一些下游负责使用和分析这些数据，它们之间是有依赖关系的。

第三种，我们的程序配置中，经常会写使用到某些端口、IP、用户名，这些端口、IP都依赖于另一个服务所提供，它们之间是有依赖关系的。

我们可总结出依赖关系主要包括了： 任务与任务之间的时序依赖关系， 任务与任务之间的数据依赖关系，及任务与资源之间的引领依赖。

四、百度面临的挑战

上述场景介绍完毕后，大家想问，百度要解决的问题到底是什么？在业务量比较简单，模块数比较少，机器没有那么多的时候，各种关系没有那么复杂，那么无论是由人来维护，还是由程序内部编写代码，其代价都很小。但是当业务量逐渐增加，模块数开始多起来，机器也增多的时候，各种关系就开始错综复杂，程序间负责通讯的代码到处可见，一个模块出问题，可能导致一条大业务链上的很多环节都受影响。无论是人还是程序都会很头痛。

按服务器增加到万台以上，产品线也非常的多。这个事情就变成不可控的地雷。就像两个线头缠在一起很好理清，一百个线头缠在一起就很纠结，如果有一万个线头缠在一起呢？这些线头不解开，就会面临的问题：

1.谁能理清楚这些关系？

2.出现问题后，谁能知道影响有多大、应该通知谁。

3.谁能知道一条复杂的服务链条上，到底状态是怎么样？

 五、任务型关联关系

百度的自动化平台中，引入了三个子系统，组成ARM（R=Relation+Resource）， 自动化资源关系管理系统 （Auto Resource And Relation Management System）来解决以上的问题，它们分别是：任务调度系统、资源定位系统、数据配送系统。其中任务调度系统从背景上解决了两个问题：

在M台机器上跑着N个不同任务，第一种基于时间的依赖，A类任务定时在1点启，B类任务定时在5点启，但B任务必须有赖于A任务执行正常。第二种基于事件的依赖，A任务只要执行成功，B类任务就可以接着做下去，相当于链式任务。

对于这类关联的管理，只需要平台中注册自己的服务，然后在页面填写任务间的关系，或者直接在Flash上拖动线条将两个服务之间建立起关联来。这样当上游任务完成后，将通知下游任务跑起来，如果上游任务出现问题，平台会通过报警的方式通知上游服务的管理员，以及下游任务的管理员。管理员通过平台的管理界面，可以清楚的看到一连串的关系服务中，正在运行哪一个，哪一个出了问题，会影响到哪些服务。我们还可以按照服务或者机器的维度查看任务，对于服务级别，有仪表盘可以清晰的看到服务的状态。

大家可以看到，管理服务之间的关系通过线条就可以完成，关系的管理变得更加的简单。当由一连串服务组成的服务集合中，对于链条上的服务，哪些正在运行、有没有问题、运行时的状态收集等，都可以一目了然的看见。至于处理问题快捷，我举一个例子：百度有一些处于上游的服务，有很多的跨产品线的下游服务依赖于它们。如果上游运行失败了，在平台化以前，通常是上游的运维工程师收到报警，然后上线处理问题，然后逐一通知下游服务的运维工程师去手工启动这些任务。而现在，上游服务失败后，平台会自动报警给上下游人员，当上游运维工程师处理完任务后，只需点一下修补，下游即可按常运行。往常一些上百条、而且很多层级的关系线的复杂业务，一但出了问题，运维工程师至少要花好几个小时来解决，现在利用自动化平台通常几分钟就可以处理完成。

顺便提到一个额外的小收益是：因为任务型关联关系包括时间管理，百度服务器上的crond定时任务在去年底已经100%的迁移到平台中进行管理。通过平台即可对每台机器的定时任务进行管理，并且仍然可以在定时任务之间建立关系。通过平台中心即可随时查看或者分析crond任务的运行情况。服务程序也只需要关注自身的业务，不需要再去编写额外的有关通讯的代码。不需要再去编写网络通讯、不需要再去编写报警。

 六、数据型关联关系

在数据型关联关系管理中，先回顾一下之前讲到的场景：上游服务产生数据，下游服务需要使用。

有一些数据，比如搜索相关的一些词表，要传输到线上的上千台服务器上。一些业务原因使之没有放到集中式的存储平台中，分散到一台台服务器中，而我们的机器变更性很大，新增、维修、调整等，使得要发往的目标下游也经常发生变化。这些词表的传输，在时间上控制得很严，另外还要求几千台服务器的传输时有串并行的控制，当发生故障时，有一定的阈值控制逻辑。比如5000台机器分10个组，每组500台，单个组内最高允许失败5台，但所有组总共失败累计不能超过15台。这一类的场景在百度非常的多。我们通过对这些业务进行了仔细的分析，发现问题主要集中在以下几点：

数据的上下游定位问题

数据的更新及发现问题

数据的传输及控制问题

数据的传输后触发问题

日志、报警、报表等管理问题

为了解决这一类通用问题，百度开发了一整套基于数据触发的解决方案。在不同的应用服务之间搭起了桥梁，将基于数据依赖的关系管理起来，使得数据的上下游能够解耦合。

数据注册会分配给数据一个唯一的DATA-KEY，无论上游的数据存放地址如何变化，下游只需要使用传输工具访问这个data-key即能访问到实际的数据。

对于数据的存储，有两种方式：一种是仅注册地址，数据实体仍然存放在上游产生数据的服务器上。另一种则是将数据中转存放在百度的集群存储上。但无论哪种方式，对下游使用数据的应用来说都是透明的。而传输工具则将各种不同的协议给封装起来，支持限速及P2P传输。通过数据触发系统，可以集中化的管理数据在上、下游中的传输控制以及清晰的看到整个过程中的状态。

总结一下数据型关联关系（类似于报纸订阅，平台扮演的是邮局的作用。），一共有三点：

1，将数据型关联关系，抽象为 注册+订阅的模型。上游注册数据，下游订阅数据，平台管理整个配送过程。

2，把整个传输的过程透明化，包括协议、过程、验证，做到了对上下游服务间的透明化。

3，通过控制管理，加入报表、状态图等等辅助工具，将数据型关联关系由服务的程序间维护改造到了平台来维护。

以上，我们介绍百度面临的挑战和整体解决方案，接下来我们会分享更多的运维技术。