导读：我们梳理出业内几个经典的运维自动化架构，有理论有架构，有图有文有实践。不仅让你看到架构是什么样的，更让你知道如何实现这个架构，并且坦诚告诉你该系统在真实生产业务中的特点和问题，而且还要帮你总结出运维自动化（智能化）一些普适性思路经验，最后探讨职业发展，直面人生情怀，追寻人生意义。

本文目录：

〇、 运维自动化学不会，做不好的原因分析

走在熙攘的马路上，想起一首歌：像一颗海草海草随波飘摇，海草海草浪花里舞蹈。是的，我们像海草一样渺小，但我们每个人内心深处总有那么一块情怀支撑我们坚强地努力着，舞出我们自己的芳华人生。

我们是干技术的，技术情怀是什么？能帮我们带来什么超能力？这些问题在本文末再探讨，首先谈谈运维自动化技术。

干技术的都喜欢看干货，读了那么多运维自动化，智能化，运维架构的文章，总感觉讲的很到位，但就是学不会，模仿不出来，为什么？

原因归纳有三点：

1.太理论缺实践：别人理论讲的很精彩，娓娓道来，字字在理，可你却头脑满满、两手空空，无法实际搭出一套运维系统。

2.有实践缺方案：别人非常棒地介绍一些实践小程序，可你却无法看到整体运维自动化解决方案。

3.有方案缺理论：即使有架构，有实践案例介绍，但总归篇幅有限，或者半遮半掩让你无法上升华到到理论高度，你仍然无法模仿，灵活变现。

说到底，这是因为干货是别人实践总结的，没有经过我们自己深度系统化思考，是无法看清其事物本质，因此不会转化成我们自己的思路和阅历。
好吧这次本文要给你不一样的视角，带着技术情怀去深度思考运维自动化。

一、 运维平台案例一

1.1 应用场景

某媒体企业，很多规模企业也在使用该套架构系统。

1.2 案例特点

架构清晰轻巧，注重安全管控，灵活扩展，适合中大企业运维自动化场景。

1.3 案例特点

1.4 架构解析

• 统一管控:总控系统可以管控异地多网络节点的Master和Login,进而对各Master节点所属的Minion机器统一管控。

• 开发工具：Python+Saltstack+Vue+Redis+Infuxdb

• 权限管理：

  1.生产机器登录权限自主式申请，管理员审批
  2.权限到期体型，过期清理
  3.管理员可以赋予多个运维角色，日常批权限，部署，协同管理

• Master用于后台运维管理人员使用，Login作为网络节点跳板机，用于日常用户登录使用。master控制各自的Minion, Master之间彼此隔离。

• 权限管理流程：员工注册登录总控Web系统，进而活的各自login登录权限，进而登录业务机器。
• 总控系统可以跟所有Master、Login、minion内网隔离开，也可以跟某一组资源在一个内网里。
• 总控直接操作相关的Master，通过Master间接操作Minion
• login的redis只允许总控和节点master存取，总控的redis只允许master 写。实际企业里部署中，在login有一个redis ，用于快速存取该节点内的机器相关信息。各自master 集中在总控redis写，总控的redis是共享的。
• Master通过监听事件获得各自minion的信息，时序数据存放于各自的infuxdb,实时写一份数据在总控Redis作为实时监控数据，总控本地获取展现实时数据或者调用各节点Master的influxdb展现历史数据。
• 实际系统截图如下：
  

1.5 架构总结

架构清晰简约，注重安全管控，注重扩展性。

总体架构基于saltstack原理架构，将saltstack界面化，可对标海外saltstack企业版，同时做了些权限精细化控制功能。

该系统主要实现功能：统一管控、权限管理、云堡垒机、实时监控、自动化部署、安全审计。

该架构扩展方便，支持异地及多网络区域节点统一管控，新的网络里只需要部署一台Master和一台Login系统即可。

二、 运维平台案例二

2.1 应用场景

该架构思路源于某搜索公司、某数字公司、某旅行服务公司，经过多次演进。

2.2 案例特点

架构简约不简单，偏向监控领域，可以承担十万级以上服务器海量高并发管控。

2.3 架构图：

2.4 架构解析：

• 本架构使用Agent客户端编程模型，即在服务器上布置一个Agent，它负责采集数据；
  

  1.一般来说，服务端编程模型，特征是：服务器开监听端口，等待客户端连接的到来。
  2.也有Agent客户端编程模型，特征是：agent客户端开监听端口，服务器端主动发起连接去连接我们的agent。

• 由往上转发(Trasfer)到一个分布式管道再转接，就像搭积木一样，这样可以做到灵活处理数据、架构可扩展，集群分布式。
• 采集数据进行汇总之后分两个部分
  1.一是数据库存储，主要做监控数据展示和后续排查问题。
  2.二是实时监控，制定很多的监控的报警项。
• 每个服务器上监控项大概二百多个，默认的频率是5秒钟一次的采集点。可以说每秒钟大概有40多条数据的采集。
• 这个系统基本上不能做Cache，必须实时运算。因为服务器监控系统，我们做服务端应该都知道，延迟报警，还不如不报。报警一旦出了问题，就要尽可能快的把这个东西报出来。
• 控制系统本身没有任何状态，任何状态都是保存在数据库中。
• 要想构建海量执行，需要深入了解python异步多线程机制和模块，对GIL有深刻体会，建议了解下epoll、select模型。
• 要想构建高并发任务控制系统，需要深入理解和利用linux的fork守护进程运行原理，深入了解多进程、多线程机制和应用场景。建议了解下网络事件库libevent和libev、异步DNS解析库c-ares。
• 架构要scalable，flexible，可以任意横向扩展，适应各种防火墙ACL。在某数字公司的时候机房比较多，各种防火墙的ACL非常多，彼此会出现各种访问的问题。要适应各种系统，就需要通过一些模块来适应。
• 要想做一个海量执行、稳定可扩展的运维控制系统，除了上述知识外，还需要清楚如何构建一个分级分层的架构，重点考虑如下因素：
  1.如何统一收集和管控命令内容，确保命令有效收集、管理、海量发布、路由管控命令；
  2.如何设计分层调度转发海量命令,既保证各业务之间互相隔离不影响，又能负载均衡海量传递命令，还能灵活扩展；
  3.如何有效接收和执行命令，确保执行正确高效，并海量收集执行效果。

2.5 总结：

本系统架构以监控为主，可以海量高并发执行命令，可以监控数万级设备。在实际开发中，发现搞的越复杂坑越多，特别是在限制要求特别高的情况下，最后返璞归真，不断优化，出来的就是每个模块极其简单，感觉就是分布式管道，都可以在linux系统里找到影子。做到简洁，因为有的模块，我们写代码都知道，从产品来看，就是从这儿到那儿。写代码如果在设计上复杂化，很多东西都绕，加班加点也不一定能搞明白。

三、 运维平台案例三

3.1 应用场景

某综合门户网站

3.2 架构图

3.3 架构解析

本运维自动化综合管理平台的设计理念是：尽量融合、统一管理现有的各个运维工具平台，统一监控管理系统资源，有效关联整合数据信息，打造智能一体化运维监控管理平台。自主开发与外部引入相融合，定制适合自身需要的综合运维管理平台。

3.3.1 功能模块设计

本解决方案立足从三大维度构建，分别是IT运维流程、IT监控平台整合、IT运维自动化。这三大维度主要具有如下几大功能模块。

• IT运维流程模块：资产管理、知识库管理、安全管理、事件管理、日常事项管理。
• IT监控平台整合模块：监控报警管理、日志管理、性能管理、报表管理。
• 运维自动化模块：应用管理、配置管理、程序运行管理。

本系统一期实际实现的功能模块如下图所示：

3.3.2本解决方案使用的开发语言及工具

• 后端开发主要通过Python、Shell等程序语言实现。
• 信息采集使用syslog，logstash，agent，saltstack
• 数据写入MySQL、Redis数据库，ES
• 前端WEB展示以及与后台数据层、应用层的交互通过Django框架实现。
• 界面修饰美化使用HTML、CSS、Bootstrap等框架工具。
• 图表展示主要使用Echarts，Kibana

3.3.3 智能运维监控体系流转思路：

一套运维系统应考虑从上线到下线全生命周期管理，全业务链监控管理，保证业务系统可部署、可变更、可审计、可追溯、安全可控。运维管理应具备流程化、合规化、可视化、智能化。当监控触发告警，并将告警消息自动写入事件工单系统，响应岗位人员需要处理该工单，对于稳定高复用、风险小的场景可以改为系统自动化处置，涉及到变更系统的行为则会触发CMDB信息的更新，同时触发审计行为记录，经典的工单处理经验可以流转到知识库。

典型智能运维事件流程图设计如下：

3.3.4 日志可视化监控实现思路

通过logstash收集并格式化网站访问日志信息，然后将格式化数据送到redis里，然后有个逻辑处理程序来消费redis数据库，将访问地理信息，访问内容等信息进行逻辑处理，再将分析统计结果暂时放到mysql里，前端通过js请求获得mysql的统计数据，然后定时刷新到web前端的Echarts控件上进行绘图展示，于是一个高大绚丽的可视化展示模块实现了。

另外，实际上我们大量日志可视化是通过ELK来实现的。来一个系统截图如下：

3.3.5 资产管理模块实现思路：

基于django的CBV开发模式快速实现资产的增删改查。好处是（如果你善用CBV）利用现成的类库和机制可优雅、快速地实现功能，不好的地方是（如果你无法驾驭CBV）自定义的功能需求会大大受限于CBV开发模式。

3.3.6系统及应用自动化部署实现思路

agent初始化实现思路：一个空白的操作系统，首先基于指定的IP对其推入salt minion及系统agent,实现对该系统进行管控，agent采集系统信息,sever端口开放监听端口接收agent数据并汇总到CMDB数据库中。通过salt minion可以实现对系统的日常操作，批量部署常见应用，这些应用是预先打磨好的salt状态。

kvm虚拟机全自动部署思路：用户界面输入设定主机名、IP、镜像、所在物理机等信息，后台逻辑处理通过salt master往minion推入salt状态及预先指定的系统镜像，通过kvm Libvirt接口实现kvm系统全自动批量部署。
系统自动化部署模块截图如下：

3.4 架构总结

本解决方案考虑的过于大而全，后期开发实现时发现力不从心，而且很多模块使用率不高。最终实现比较实用的模块是资产管理模块、系统部署、应用部署、系统信息查询等功能模块。

本方案适合运维各产品整合的思路，但对于开源产品的整合缺乏整合力度，整合数据和打通数据是难点。

在账号权限管理模块中，二次开发融合了CBV和FBV权限管控，实现对url、操作接口、函数模块的精准管控。

对审计管理模块的设计稍显笨重，难以很好地格式化审计信息，后期考虑调整审计思路：被审计模块吐json数据，审计模块对json数据进行有效存储、格式化和统计分析。

对于图表分析，趋势分析类展示，后台数据存储用mysql存储及使用都显得蹩脚，后续考虑改用ES、Influxdb存储。

四、 运维智能化的本质

其实人类一直走在智能化的道路上，运维行业发展之初至今一直伴随着智能化，只是随着人文和技术的发展，大众逐步忽视或不再认为之前的事物是智能化了。

那么未来可预期的运维智能化是什么样子呢？答：自动化+大数据+AI+流程策略

自动化系统是平台对象，大数据是生产资料，AI是（算法）生产力，流程策略是生产关系。

要实现运维智能化，目前现实而言，要做到的是：依托运维自动化平台，通过收集海量运维数据和日志作为生产资料，以CMDB为核心基础对象，通过算法对各业务系统间关联和运维组织、流程策略等生产关系进行综合分析，能够做到预测、分析、研判、故障定位及处理。

关于智能化，其他不再多说，大家都在琢磨中，人类发展贵在追求梦想，运维智能化当前也贵在梦想，万一实现了呢:)

五、 运维自动化经验规律20条

1)初心：运维自动化系统要实用，能够很好支撑业务，而不是仅仅做成纯技术理论产品。

2)好的运维系统架构：通常可靠稳定，简单实用，可扩展性好。

3)核心架构设计不好：后面等着无限返工，或者直接烂尾停工。

4)设计二八原则：运维系统架构设计不易高大全，功能要精专，模块要解耦，不宜过分设计。

5)不必把运维自动化做到大而全，面面通。不必把运维自动化做到技术极致。贴合业务，做到小而精是个好选择。

6)生命周期原则：自动化运维体系处理的对象是CMDB全生命周期，是一条集采集、监测、管理、控制、处置、舆情一体的全流程闭环系统。

7)开发工具：运维人员建议选择python开发运维产品，前端可以用bootstrap,WEB框架可以用django,flask，要想动画酷炫可以选择vue、Grafana，常规数据存到mysql里，性能数据、趋势分析数据可以选择时序数据库，例如infludb，RRDTool等，消息缓存用redis，Kafka，历史数据可以放到hbase里或者mysql里。其他很多优秀软件都可以用。

8)开发进阶：善用如下这些关键词，让你事半功倍，paramiko（ssh网络通信模块）、Celery（分布式任务调度）、epoll（异步多线程）、threading（多线程模块）、queue（队列模块）、twisted（基于事件网络模块） supervisor（非daemon的进程管理）、subprocess（系统交互模块）、urllib2（网络访问），CBV开发模式。

9)运维自动化系统设计与实现最好选择既懂运维又懂开发的团队，只懂开发的团队或只懂运维的团队都难以开发实用的运维自动化系统。

10)实施支撑面向业务的运维自动化系统，需要团队既要懂开发又要懂运维，同时还得懂业务。
11)规范化：设计运维自动化、CMDB系统首先你要做规范化，确定好资源CI，梳理清楚资源关系、组织架构、技术架构和流程规范。

12)确定好监控指标，信息采集方式，确保数据采集和变更一致性、正确性。

13)运维自动化软件系统是软件工程，遵循项目工程规律，不可当做作坊式直接上来就“敲砖”。

14)数据库表结构设计关系到你要采集与展示什么数据，并影响你程序逻辑的复杂度。

15)数据库选择影响到你的存储架构、分布式架构和性能问题。

16)选择社区活跃、评分高的产品工具，不一定选择最新的。

17)不要轻易重复造轮子，造之前先看看有无业内优秀思路、产品可借鉴的。

18)产品模块间数据打通，流转复用是难点也是成功亮点。

19)运维自动化的安全是把双刃剑：要特别注意安全防护和权限控制，一定要避免一些高危动作，避免执行rm *等，要建立完善的运维安全和审计制度。

20)机遇风险同在：运维自动化是给运维人员带来曙光和契机，但不要寄希望于一套运维自动化系统解放运维人员全部工作。人类有了飞机，但仍离不开火车，人类有了电梯，但仍离不开楼梯，为什么？

五、 情怀常在，匠人不老，不唯技术，重在实践

《道德经》言：道生一，一生二，二生三，三生万物。本文因此注重讲道理，讲思路，只介绍三个案例，凡是不可穷尽，事不过三，点到为止。希望本文给读者的是方向和方法论，具体情况还得因人因事而异，只要你有所顿悟，并执着实践你的梦想，那么美好明天就在眼前----这就是情怀。

情怀是一份梦想，一种追求，一个期待，一厢情愿，一路走来。

情怀有信仰，有力量，有希望，没有情怀的人生缺少情趣、难得幸福、失去意义。

情怀看似无用，内心却是必需，融入骨髓。你我如海草般漂浮，奔走在茫茫人海，会经历不同的事情，每个人都有不同的境遇，我们各自不一样，但却都有共同的情怀，正是这种骨子里的东西，驱使我们愿意付出代价而去追求美好，谁说小人物，不可以做英雄，海草也有梦想，海草也有芳华。

知道了内心梦想，还需要去实践探索。要揽瓷器活，得有金刚钻。因此作为技术人生，我们需要自己的金刚钻。愚以为三种道路不可取：

1.没有目标信仰：如果初衷不定，缺乏准备，没有目标而胡乱努力，这样成功的概率不会高；

2.只关注眼前细节：仅纠结于细枝末节而不顾核心大局,看起来很忙很累，但实际可能成长很慢；

3.纸上谈兵眼高手低：如果仅仅是天马行空，好高骛远，那么也只能是飘着。

随着社会的迅猛发展，作者认为未来的人才需要具备“十型人才”特征。

高度：具备高远的视野，高屋建瓴的能力，方向掌控能力。有能力，有执行力，带领团队走在一个道上。

深度：能敏锐的抓住问题，事情的关键点。有比较好的毅力和韧性去做事情。在某一领域有所专长。

宽度：有宽广的技术知识面，有宽广胸怀和气度，有包容协调的能力。

六、 结束语

本文出自三位作者，在各自领域努力着，本文带着一种情怀，抽丝剥茧看本质，深度归纳出了一些案例套路，各位读者要做的：审视一下自己的梦想是什么，借鉴别人的经验，演绎出自己的精彩。