本文联合作者：王鹏程（运维总监）；贾晓辉（云公司负责人）；韩晓光（运维负责人）
导读：走在熙攘的马路上，想起一首歌：像一颗海草海草随波飘摇，海草海草浪花里舞蹈。是的，我们像海草一样渺小，但我们每个人内心深处总有那么一块情怀支撑我们坚强地努力着，舞出我们自己的芳华人生。
我们是干技术的，是有技术情怀的，它能带来什么收获？这些问题在本文末再探讨，首先谈谈运维自动化技术。
本文从实际出发，探究本质，梳理出业内几个经典的运维自动化架构，有理论有架构，有图有文有实践。不仅让你看到架构是什么样的，更让你知道如何实现这个架构，并且坦诚告诉你该系统在真实生产业务中的特点和问题，而且还要帮你总结出运维自动化（智能化）一些普适性思路经验，最后探讨职业发展，直面人生情怀，追寻人生意义。
正所谓倾心之作以为观止：实践运维智能化，我们不一样；探索人生十字路，海草有梦想。
本文目录：
〇、 运维自动化学不会，做不好的原因分析
干技术的都喜欢看干货，读了那么多运维自动化，智能化，运维架构的文章，总感觉讲的很到位，但就是学不会，模仿不出来，为什么？
原因归纳有三点：
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为核心基础对象，通过算法对各业务系统间关联和运维组织、流程策略等生产关系进行综合分析，能够做到预测、分析、研判、故障定位及处理。
关于智能化，其他不再多说，大家都在琢磨中，人类发展贵在追求梦想，运维智能化当前也贵在梦想，万一实现了呢:)
五、 情怀常在，匠人不老，不唯技术，重在实践
《道德经》言：道生一，一生二，二生三，三生万物。本文因此注重讲道理，讲思路，只介绍三个案例，凡是不可穷尽，事不过三，点到为止。希望本文给读者的是方向和方法论，具体情况还得因人因事而异，只要你有所顿悟，并执着实践你的梦想，那么美好明天就在眼前——这就是情怀。
情怀是一份梦想，一种追求，一个期待，一厢情愿，一路走来。
情怀有信仰，有力量，有希望，没有情怀的人生缺少情趣、难得幸福、失去意义。
情怀看似无用，内心却是必需，融入骨髓。你我如海草般漂浮，奔走在茫茫人海，会经历不同的事情，每个人都有不同的境遇，我们各自不一样，但却都有共同的情怀，正是这种骨子里的东西，驱使我们愿意付出代价而去追求美好，谁说小人物，不可以做英雄，海草也有梦想，海草也有芳华。
知道了内心梦想，还需要去实践探索。要揽瓷器活，得有金刚钻。因此作为技术人生，我们需要自己的金刚钻。那么如何取得自己的金刚钻？首先愚以为三种道路不可取：
1.没有目标信仰：如果初衷不定，缺乏准备，没有目标而胡乱努力，这样成功的概率不会高；
2.只关注眼前细节：仅纠结于细枝末节而不顾核心大局,看起来很忙很累，但实际可能成长很慢；
3.纸上谈兵眼高手低：如果仅仅是天马行空，好高骛远，那么也只能是飘着。
那么要想取得金刚钻，非得有真本领。随着社会的迅猛发展，很多工作场景会被大数据和人工智能淘汰，要么像海草一样随波飘摇，消失于海浪中。要么像海草一样浪花里舞蹈，穿行于风口浪尖。作者认为未来的浪尖人才需要具备“十型人才”特征。
高度：具备高远的视野，高屋建瓴的能力，方向掌控能力。有能力，有执行力，带领团队走在一个道上。
深度：能敏锐的抓住问题，事情的关键点。有比较好的毅力和韧性去做事情。在某一领域有所专长。
宽度：有宽广的技术知识面，有宽广胸怀和气度，有包容协调的能力。
六、 结束语
本文出自三位作者，在各自领域努力着，本文带着一种情怀，抽丝剥茧看本质，深度归纳出了一些案例套路，各位读者要做的：审视一下自己的梦想是什么，借鉴别人的经验，演绎出自己的精彩。
作者：王鹏程（运维总监）；贾晓辉（云公司负责人）；韩晓光（运维负责人）
END
追求技术进步的道路上，我们永不停歇
终有一日，你将站在舞台的中央
DevOps 国际峰会，这是一场技术的盛宴
2天的时间，为您呈现互联网公司与海外企业的实践经验与工具技术，聚焦 DevOps 在金融、通信、零售等行业的系统性实践，不空谈！不务虚！专注 DevOps 落地！
扫描二维码进入大会官网