关于自动化运维

--------------转载文章，同意其观点、留备日后查看。

以下主要关注千台规模以上的运维：

千台规模的运维

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

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

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

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

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

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

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

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

图1 Nagios报警通知界面

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

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

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

图2 Puppet Master-Agent结构图

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

上万台规模的运维

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

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

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

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

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

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

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

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

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

云计算带来的变革与挑战

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

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