文/余沛

时代变化所引起的运维视角不同

在计算机应用的发展历史中，运维工作一直是必不可少的重要环节。无论在什么年代、什么场景，保证服务的正常可持续运行都是运维的最终目标。但在不同时期，运维实施的手段、关注的重点却有所不同。

在计算机应用的早期，计算机仍然是一台昂贵且娇气的设备，那时非但应用场景远没有今天这样广泛，网络体系也没有今天这样的复杂和敏感，电子技术也远不如今天 成熟。在那个时期，运维关注的重点通常以硬件为主。除了计算机本身的硬件，与之相关的电力及其他配套设备也在范畴之内。

到了中期，计算机由 大、中型转向微型化，局域网络发展迅猛，金融、通信、电力、航空、学校等各类商用、民用场景的快速跟进，不但使得计算机的总体使用量大增，而且单位范围内 需要管理的计算机规模也在不断加大和复杂化。在这个过程中，形成了以设备管理(包括网络设备、操作系统管理)、数据存储与容灾、目录与内容管理、资产管理和信息安全管理为主的、一体化的早期运维体系。

再到后来，互联网模式占据了最新潮流且至今未衰，科技和业务模式带来的变化，也催生整个运维 体系的转变。早期一体化的运维系统被更加明确与细致的分工所拆散。IDC代替了自建的局域网小机房，使得通信主干的运维工作从原有体系中剥离；规模的爆炸 式扩大也使得即使同一IDC内的局域网管理也更加复杂；安全的挑战越来越严重，使得传统基于局域网粗暴隔离思想的安全管理无法满足开放互联网时代的要求。 同时，人们也发现一些运维事务简单地随规模增长而线性增加(如资产管理、自动装机等)，本身不具有复杂度的变化，而另一些与业务相关的事务，则随着规模增长复杂度成倍增加。

由于这些原因，使得运维工作开始明确分工，逐项剥离。系统、硬件、网络衍生出专职的系统管理员(SYS)职位，安全也开始从运维独立，资产管理、自动装机等工作不再是运维工程师关注的重点。相反，与业务可用性紧密关联的调度、监控、关系管理变得更加上层。

规模变化所引起的运维手段不同

在互联网时代以运维的角度来看，对于不同规模、场景的应用，运维所处的位置、发展的历程也有一定差异。

百台以下规模的运维

一般来说，小公司有几台到数十台机器的规模，运维主要关注的点还是在系统及应用服务的稳定性上，不一定有专门的运维人员，通常是RD自行维护所开发的系统。不会去系统化地梳理各项运维指标，而是以人的经验为主，来判断和设定系统正常与否的标准。

在这种场景下，运维工作通常扮演的是“救火队员”角色，一旦出故障，运维人员才开始跟进、解决。故障解决也基本是Case by Case的形式，不太会有流程化的总结和问题库、知识库。其运维方式无非是靠手工，辅以一些自行编写的小脚本。这种方式虽较为原始，但对许多初创公司来 说，也算是一种低成本下可灵活实施的手法了。

在这个阶段，一些小巧的工具显得很有特色，例如在系统管理方面，能够同时对多台机器进行操作的 Pssh、OmniTTY等，在数据库管理方面，phpMyAdmin等足以应付平时的工作。

千台规模的运维

当规模增长到一定程度，依赖手工管理自然已无力应对。许多互联网公司的服务器早已跨入几百甚至千台规模，脚本化、批量化管理占据非常大的比例。

同时，在这种规模下，按垂直划分的运维工具也开始大量应用，无论是自行开发的还是利用现有开源软件，针对某一特定领域的管理系统显得尤为重要。

在这个阶段，运维主要精力放在监控(采集、报警、展现图表)、部署上线(配置管理)、数据备份方面，因为机器数量庞大，所以集中式的操作平台是必备的，针对不同的领域，也有相当成熟的开源软件可以直接使用。

在监控方面，Nagois和Catci应用最为广泛。

作为一款开源的免费网络监视工具，Nagios能有效监控Windows、Linux和Unix的主机状态、交换机路由器等网络设置。在系统或服务状态异常时发出邮件或短信报警，在状态恢复后发出正常的邮件或短信通知(如图1所示)。

[caption id="attachment_13356" align="aligncenter" width="502"

caption="图1 Nagios报警通知界面"][/caption]

Nagios的特点包括以下几方面。

• 可以通过多种协议对目标服务器进行信息采集(SMTP、POP3、HTTP、NNTP、PING等)，避免在目标服务器安装客户端带来的风险。
• 本身体系非常开放，可以自定义编写采集脚本以监控系统、应用的状态。简单的插件设计使得用户可以方便地扩展自己服务的检测方法。
• 具有并行服务检查机制，同时具备定义网络分层结构的能力，用“Parent”主机定义来表达网络主机间的关系，这种关系可被用来发现和明晰主机宕机或不可达状态。
• 当服务或主机问题产生与解决时将告警发送给联系人(通过Email、短信、用户定义方式)。
• 可以定义一些处理程序，使之能够在服务或者主机发生故障时起到预防作用。
• 自动的日志滚动功能。
• 可以支持并实现对主机的冗余监控。
• 友好的Web界面用于查看当前的网络状态、通知和故障历史、日志文件等。

Nagios 和Cacti是经常配合在一起使用的监控系统，Nagios适合监视大量服务器上的大批服务是否正常，重点并不在图形化的监控，其集成的很多功能例如报警 都是Cacti没有或者很弱的；Cacti主要用途还是用来收集历史数据和画图，因此界面比Nagios漂亮很多。

而在部署方面，Puppet是用于大规模集群管理的神器。其本身使用Ruby语言开发，基于C/S架构(如图2所示)。在每台机器上部署的客户端每隔一个指定的时间会连接到Master检查资源变化情况，若资源发生变化，将按配置动作进行相应的操作。

Puppet将所有可操作对象抽象为资源，目前涵盖了40多种，如：File、User、Group、Host、Package、Service、Cron、Exec等。

Puppet 通过抽象资源的方式，使得每台机器能够“清楚”其本身“应该”是什么“状态”，而客户端根据当前是否达到这个状态决定采取指定的动作。这使得Puppet 不仅可用于传统的应用部署，而且通过合理的手段，也能够将比应用部署更频繁的配置管理一并解决。甚至可以在Master端外接自己开发的平台，通过集中配 置方式管理各项“资源”，实现高度灵活的自动化管理体系。

[caption id="attachment_13357" align="aligncenter" width="251" caption="图2 Puppet Master-Agent结构图"][/caption]

这类垂直管理系统的使用及活跃，极大减轻了运维人员在重复性、批量化操作方面的负 担，能够非常有效地在各自领域完成既定的运维子目标。但其缺陷在于只能针对某一垂直领域的特定问题进行高效处理，对于它们之间的关联性很难应对。因为运维 的本质是保证服务的可用性，而自动化运维则是在完全保证这一前提下，尽可能将需要人干涉的部分处理掉，所以判断其优劣的标准则是——与人工处理比，对服务 的保证有没有提高。如果仅是解决报警、部署这些单一动作，后续仍然需要人去处理、去关注、去判断的话，就离这个目标还有距离，谈不上真正的自动化，只能算 是工具化。

上万台规模的运维

对于规模已达到上万台、十万台的各互联网巨头来说，其业务间交织纵横，甚至某一单一业务内部可能也已非常复 杂。传统的开源软件大多已无法覆盖这样场景下的运维工作。另外，在这个阶段，除了各服务自身的监控信息、部署信息等需要运维外，服务与服务间的关联关系、 上下游变更所带来的影响、业务的串联也显得尤为重要，它们经常是牵一发而动全身。互联网巨头都在根据自身的业务特点，纷纷自行研发成体系的自动化运维平 台。在这个阶段，各公司更关注各平台之间的联动性，更关注运维的本质——即真正的自动化：不仅是自动发现问题，更要能自动协助解决问题，以保证服务的稳 定。

各大公司自主研发的历程，是由单一的任务解决向平台化过渡，运维关注的重点也由可用性发展到易用性、灵活性，最终实现自动容灾，以及资源可伸缩调度。

以 Google为例，能够将URL(统一资源定位)的概念用于运维体系，将每一种服务(无论对内、对外)都抽象为一种资源，提供这种资源的服务将自身信息写 入，使用方通过URL来得到资源的实际位置，当资源发生变化时，使用资源的一方能够感知，并根据自身业务做出相应的动作。

国内的互联网公司也有不少家正在往这个方向追赶。这些自主研发的智能运维平台，除了像开源软件那样能满足常规的监控、部署备份等需求外，更能站在“服务”的角度关注其最终状态。

例如，某项服务有N台机器提供负载均衡，会向某个状态池集中写入其状态，相关的监控通过收集这些状态，按照指定的配置规则进行动态监控。一旦发现状态异常， 如负载过高时，能够触发部署动作，从资源池中再拉几台机器进行部署。部署信息都在状态池中，该安装什么软件、什么版本、如何部署都由系统自动完成。完成部 署后，新机器上的服务被启动，启动时再向状态池中注册自身，负责负载均衡的设备感知到关注的状态信息变化(有新机器加入)后，刷新配置将新机器的服务纳入 对外服务列表。

自动化运维与基础架构之间的关系

随着运维技术的进步以及运维体系的完善， 自动化运维作为一个既不算崭新却又充满活力的方向，也随着规模、场景的变迁迎来新的挑战和变化。运维的活动范围，更多介于硬件与操作系统之上、应用之下。 其与基础架构之间也像是人的两条腿，相辅相成，总是一前一后交替往前推进。基础架构决定运维方向，同样运维体系又使得基础架构发挥最大收益。

故而自动化运维平台的根本，不是说仅仅去把操作界面化、OA化，让人们简单地在Web上点击按钮就能管理系统。而是在底层的基础架构与上层的业务系统之间搭建一个良好的桥梁，使得业务系统能够充分、稳定却又不必过度关注底层架构特性。

这时的运维，已不再仅是消除故障、打扫设备的后置服务，而是能够在业务开发时期介入、伴随整个业务共同运行的一种特殊服务。以Google的Borg为例， 通过引入一套标准库，按照指定的规范编写应用，使得编写出来的应用本身就能满足对应基础架构下的可靠运维，无论是统一的运维状态接口，还是灾备、自动缩扩 容，以及变更时的关系调整，都能够很好地应对。

云计算带来的变革与挑战

虚拟化、云计算的 发展，又使得运维工作产生了进一步的变化。中小公司不必再考虑诸如容灾、备份方面的事宜，资源的按需交易不仅使得资源不再浪费，也使得业务调整时的伸缩变 得更加容易且经济上更加划算，的确大大简化了传统意义上的运维工作，是未来中小互联网公司发展的重要趋势。这时，运维工作的重点将转移到平台架构的选型与 优化上来，运维需要更关注业务特性及与之相关的技术体系，帮助研发决定各类云服务的选型、评估其对业务的适用性。

在可预见的未来，运维的角 色将变得越来越重要，这种重要性的提升关键在于运维在整个技术体系中的参与度及所处位置发生的变化。自动化运维的兴起，将传统意义上处于后置服务的运维人 员带到了服务前沿，以往简单的追查故障、保障服务虽然仍占据运维工作的一部分，但随着自动化运维技术的发展，运维人员有更多精力、条件，投入到整个服务架 构的梳理、设计中，甚至以提供基础组件的方式参与到研发过程，使得产品天生具有较高的可运维性。研发要关注运维，运维要有能力介入研发，具有对等能力的角 色配合，各自负责不同的领域方向，这是技术发展大体系下的必然分工，也是运维摆脱苦力劳作，继续往更深技术发展的必然之路。

作者余沛，艺龙网平台总监。原百度高级工程师，专注于分布式及自动化运维方向，曾参与百度自动化运维平台核心构建，现负责艺龙网基础平台及自动化控制系统。

本文选自《程序员》杂志2012年09期，未经允许不得转载。如需转载请联系 market@csdn.net

《程序员》2012年杂志订阅送好礼活动火热进行中