现如今市面上有许多自动化工具可以胜任大规模运维的任务，但各个工具所适配的场景和对运维人员的能力要求不太一样，不同企业需要根据自身情况探索最适合自己的自动化工具。基于企业的运维环境以及运维规模，企业很多最终使用了Ansible开源工具作为自动化平台的基础，解决了传统运维效率低下的问题，迈出了自动化运维的第一步。
基于Ansible开源工具的自动化运维只是自动化运维开始的第一步，它解决了运维效率的问题，随之带来的运维安全管理，流程管理，脚本管理，数据收集和展示等等问题都是需要面对和逐一解决的，于是有了Ansible企业级产品的出现。Ansible企业级产品在Ansible开源工具的基础上做了一层封装，实现了权限管理及统计展示的功能，让自动化运维更加成熟和运维团队能更加把控运维风险。
针对企业自动化运维的痛点和解决方案，以及企业级Ansible和Ansible的应用中的具体难点，twt社区特邀银行实践专家和红帽资深架构师一起进行了交流答疑，以下是相关内容汇总，供大家参考。
1、企业自动化运维发展中的痛点有哪些？
@ManMaster 资深工程师：
在企业级运维发展的路上，痛点有很多，这些都是不可避免的，对于自动化运维发展上会逐步出现以下几个痛点:
1 企业运维效率太低，迫切需要自动化手段提升效率
2 自动化工具是用起来了，如何推广自动化工具，提高整体的运维效率
3 自动化工具普及了，越来越多的人都在这个自动化平台上做变更，怎么把控人为误操作风险
4 运维场景的进一步扩大，比如从系统级别的自动化扩展到虚拟化层面甚至是网络层面的自动化，如何更进一步的把控运维风险，让不同的人做不同的事
5 自动化平台上怎么展示，怎么与其他控制平台比如CMDB等做集成展示
6 在自动化平台建立之后，如何将自动化像智能化发展
这几个问题都是我本人在实践中逐步感受到的，从手工人肉运维到Ansible自动化运维，再到Ansible tower平台化运维，这些痛点都在踩坑的路上逐一解决。
使用Ansible来解决自动化的问题，使用Ansible tower来解决管理自动化的问题。
@he7yong 研发工程师：
就像常说“家家都有一本难念的经”，每个企业的业务流程不同，对IT运维管理的要求不同，因此痛点也不同。我总结一下如下几个方面可以参考：
1.业务发展，导致运维对象的数量猛增，如达到10000台，甚至更多，这种情况，没有理由，上自动化；
2. 部分企业对安全的要比较高，希望通过运维自动化工具，标准运维流程，如删库等等；
3.还有的情况，就是想提升效率，让运维同学不要这么苦逼，不用三更半夜的爬起来，这个时候自动化工具能够发挥一定的作用；
4.还有的出发点，是想改善IT服务满意度以及用户体验，增加自动化的工具；
5. 还有的是想提升IT运营的效益，如减少计算资源的使用，通过自动化工具可以实现；
6.也有不差钱，就是要上的。
2、企业自动化运维工具可以有哪些工具平台选择？应该如何选择？
@asdf-asdf 研究学者：
开源的有 puppet，saltstack，Ansible，chef
付费产品有 server automation 原来hp产品现在被卖掉了，商业公司在维护，bmc的baldelogic，等。
选择看技术能力和开发能力，大部分是页面加脚本，页面需要开发 脚本是基础。
3、自动化运维工具功能特点分析对比：Ansible/Saltstack/puppet/chef，金融企业如何选择自动化运维工具？
我们也准备上自动化运维平台，现在了解到自动化运维工具：Ansible/saltstack/puppet/chef，希望专家能对他们的功能特点进行比较，有助于我们选择哪个更适合我们。
@ManMaster 资深工程师：
Ansible，saltstack，puppet是三个现在比较火的自动化工具，其中Ansible是背靠红帽支持的，红帽也有自己的企业版Ansible tower。
这三个工具都各有优缺点，Ansible和saltstack是python实现的，puppet是ruby实现的，saltstack和puppet需要agent，而Ansible不需要，企业应选择适合自己的自动化工具。
@asdf-asdf 研究学者：
pytohn开发的Ansible，无agent方式 , 小规模运维(并发20台以下)，软件部署使用，7人以下小团队自己做工具用非常合适。
saltstack也是python开发的, mq + agent方式部署，master管理1000设备没有问题, 开发的api适合单体数据中心部署和对其进行二次portal开发，完成自身业务逻辑，但开源版本不支持aix和hpux。需要向厂商付费才能获得aix和hpux的agent。
puppet由ruby开发，基本是一个配置管理工具，在puppet6中去掉了 mco，自己配置管理能力增强,，独立的语法需要长时间学习和适应，刷配置失误会导致严重的系统故障业务停止等问题。目前使用时需要谨慎和完全测试。
chef由ruby开发结构master+mq+agent完成大并发，多模块，可单独编写菜单完成配置管理和命令行管理。但国内使用数量稀少，相应的人才太少，所有功能需要你自学成才。
4、企业级的Ansible产品具体是指？
企业级的Ansible具体是指使用AnsibleTower还是指？基于Ansible建立自动化原子平台，是基于Restful开发框架所建立的自动化产品么？如果只是封装，建立API资源，是否可以由运维人员来操刀。具体使用哪些web框架来建立呢？
@ManMaster 资深工程师：
一般说企业级Ansible指的是Ansible tower工具，Ansible tower是在Ansible的基础上做了一层封装，集成了web UI展示，用户权限管理，RESTFUL API，可审计，定时任务，工作流等一系列功能。Ansible tower也是为了让用户更好的使用Ansible自动化工具，不需要学习复杂的Ansible指令。
企业级的Ansible特指Ansible tower，提供RESTFUL API只是Ansible tower的一个部分功能，在后台还有诸如任务分发，消息缓存，数据库记录等等功能架构。
当然企业运维人员也可以基于Ansible tower的架构自主的开发适合自己的自动化平台。
5、Ansible Tower的功能有哪些？相比Ansible有哪些功能上的增强？
@ManMaster 资深工程师：
Ansible tower是在Ansible的基础上做了封装，相比于Ansible，Ansible tower具有以下功能：
1 web页面展示，人机交互更加友好
2 用户的权限管理，从organization，team到user.做了三级权限划分，权限控制更灵活
3 分布式协同工作，可以让多台Ansible并行处理同一任务，工作效率更高
4 日志记录，可以让执行过程可审计
5 工作流处理，可以把上下游的工作串起来，进一步提升自动化水平
6 提供RESTFUL API，可以把Ansible tower与其他运维平台做集成
而上述这些功能都是Ansible不具备的
如果说企业运维人员简单，运维规模不大的话，使用社区版Ansible就行。针对有庞大运维规模的企业还是ansible tower更能体现出它的价值。
@asdf-asdf 研究学者：
把 Ansible的 命令行功能变成图形了,另外多了写主机管理，和配置管理功能，还有一些 playbook 的yaml图形演示功能。
6、Ansible的管理能力？
Ansible的节点管理能力范围一般是多少，一个Ansible Server下一般纳管多少个client能够保证性能和运行流畅？
@ManMaster 资深工程师：
Ansible是基于SSH协议实现与被管通信的，Ansible的上限取决于服务器的SSH连接上限，一般几千台都没有问题。
况且Ansible是没有守护进程实时与被管节点通信的，几乎不可能在同一时间所有节点都需要通过Ansible做比较繁忙的工作。
Ansible的运行是否顺畅也取决于你Ansible服务器的性能如何，还有就是平常使用的playbook的逻辑是怎样的，有些任务比较消耗CPU，有些任务比较消耗内存，还有一些任务比较消耗网络带宽，正常使用Ansible的话上千台没问题。
7、Ansible企业级运维产品情况？
Ansible目前在银行业有无成熟的自动化运维产品，如有，该产品的实施周期需要多久，对于行方实施人员和使用人员的技术水平有何要求？该产品的售后支持如何？有无银行业实施案例可供调研？
@ManMaster 资深工程师：
Ansible本身就是一个成熟的自动化产品，Ansible相比于其他自动化工具具有agentless的特点，所以在初期开始实施搭建是比较简单快捷的。如果企业的运维环境不太复杂的话一星期就差不多能准备好了。
Ansible是基于python实现的自动化工具，服务器间的通信采用SSH协议，使用Ansible的核心在于playbook。playbook剧本是用yaml语言实现的，可以将playbook理解为Ansible执行的脚本。yaml语言本质其实就是key value键值对的嵌套，本身学习起来也不太复杂，会使用SSH协议，会写yaml就能把Ansible用的非常顺手。当然Ansible是基于python实现的，所有与Ansible相关的inventory,playbook等等也都是可以采用python实现。
如果企业内有使用过红帽的订阅，是可以选择红帽原厂支持的，当然电话和case手段也没有问题。若企业规模较大的话，可以考虑使用Ansible tower，Ansible tower在Ansible的基础上做了许多封装和集成，让Ansible的使用更加友好和合规。
8、现在商用的容器化平台都提供了很多自动化的能力，这些能力如何与Ansible进行结合？
@景显强 红帽软件资深解决方案架构师：
容器平台本身集成自动构建等一些自动化，它更侧重于平台自身。Ansible的使用可以在容器平台自身的基础上，对容器内部以及应用等做一些平台以外的自动化工作。同时如果您有CMP（云管）平台做云上层管理，这时候云管中应用商店和自服务等业务封装就可以通过调用Ansible作为执行实体进行技术打通。
9、企业级自动化运维平台是否需要基于自动化运维工具上进行二次开发？
@asdf-asdf 研究学者：
厂商平台是产品方式开发，如果想适用于大型数据中心都需要进行定制开发，可更加ansilbe的api接口进行二次开发，或者通过tower的api进行开发，cli也可封装成rest 的api 进行接口开发。
@景显强 红帽软件资深解决方案架构师：
平台建设的初期会有基础的功能存在，但随着自动化规模扩大，场景的增多，就需要进行功能扩展，这时候的定制要求商业软件提供二次开发的能力，或者API或者代码扩展。多数的工作在商业软件的二次开发上，对引用Ansible而言比较简单，可以调用Ansible tower的API或者cli方式进行封装。
二次开发基本都是自动化平台功能扩展和完善的过程，需要扩展时如果能借助Ansible来实现，功能会变得落地更加快速。
10、企业自动化运维中，脚本统一管理的好处并且有哪些好脚本管理策略？
@景显强 红帽软件资深解决方案架构师：
playbook = PB
1. Ansible 的playbook需要进行统一管理，以提高安全性和可用性，这些可以放到git中，以代码的形式进行管理
2. 对于批量脚本统一维护和执行需要更高的要求，比如Ansible tower 他能提供更多管理Ansible playbook的方法。1）PB的执行过程记录 2）PB的执行记录追溯 3）多PB的集成作业流 4）PB的API提供，供外部调用 5）执行PB的人员权限设置等等
这些功能对于企业在生产环境下安全使用Ansible是必不可少的
@asdf-asdf 研究学者：
1. 脚本区分为查询功能和修改功能
2. 脚本版本需要进行管理
3. 脚本权限需要管理
4. 脚本审核流程
5. 脚本危险操作命令提示
6. 执行历史完整保留
11、Ansible对运维人员知识技能的要求？
要安全掌握Ansible，对运给人员的知识能力有哪些要求，需要学习除传统设备运行之外的哪些方面的知识？
@景显强 红帽软件资深解决方案架构师：
Ansible的使用过程即是playbook的编写过程，语言为yaml，相对较为简单。但是编写格式较为严格，建议使用专门的工具进行playbook的编写，提高编写效率。
多数情况下playbook调用的module在Ansible社区中的core module中已经提供，极端情况下需要手动编写客户自定义module，这个需要掌握python。
掌握了yaml语言即可使用Ansible，掌握了python可以定制Ansible实现特殊自动化需求。
@ManMaster 资深工程师：
简单学习一下yaml语法，jinja2语法，能看的懂python代码用于分析问题就行
如果熟练掌握python的话上面的都不是问题，Ansible的一切都可以通过python来解释。
12、Ansible是否适用金融业应用变更？
银行系统数量多，基础软硬件环境千差万别，应用架构、开发规范更是风格迥异，日常变更量巨大，变更操作量大且运维价值低还存在误操作风险。请问针对纷繁复杂的应用变更，Ansible是否有比较成熟的实践方案，如有，实践的大致路径是怎样的？谢谢
@景显强 红帽软件资深解决方案架构师：
应用发布在银行业务系统中要求最为频繁。实现业务发布需要对每个系统进行一次发布流程的梳理。定义好标准。如文件压缩格式，存放的路径规范等。要求开发团队或者外包商遵循这个规范，之后定义好发布流程，既可以实现后续的复用。
实现技术路径为四层架构：展示操作层->流程层->执行层->物理层
1. 展示操作层为发布流程的图形操作层，它应该具备0代码编写的能力，使用应该是拖拉的方式，更改参数即可，不需要有代码的更改，每次发布通过更改参数即可实现，参数对应底层Ansible playbook中预留的参数
2 流程层应该讲发布的众多复杂过程集成起来，比如上传文件 - 解压文件 - 停止服务 -停止数据库 - 应用升级 - 启动数据库 - 启动服务 - 检查状态 - 失败回滚等服务集成链接起来
3. 执行层负责将流程中的每个子在目标物理层设备上执行起来，通过Ansible 调用提前以参数形式定义的playbook
4. 物理层为最终的目标设备，以IP为单位的节点。
@ManMaster 资深工程师：
金融行业的变更主要考验的是运维人员的作业编排能力，Ansible只是一个自动化工具，核心还是在playbook的编排上。
不过从我的个人经验来说，形成自动化的前提是标准化，只有做好标准化才能谈自动化。依靠自动化完成金融变更还是得从根本做起。
13、Ansible系统损坏，对被管理系统有什么影响？
用Ansible管理完，以后万一Ansible服务器坏了，对被管理的系统有什么影响？还需要在被管理系统上做什么修改？
@李尧 红帽企业级开源解决方案中心 培训师：
Ansible没有任何守护进程类服务，Ansible的架构可以分为Ansible的controll node和 managed host，我们在Ansible的管理节点（controll node）上安装Ansible的软件即可使用。
Ansible的工作原理是通过SSH或者WinRM，把Ansible module 传送到被管理节点上执行任务，所以我们只需要备份Ansible的inventory文件（被管理节点列表文件）以及您编写完成的Playbook文件就可以了，因为Ansible可以通过rpm进行安装。
@景显强 红帽软件资深解决方案架构师：
损坏后如果playbook也对丢了影响比较大，如果数据没丢，可以重建然后重新建互信即可快速恢复。
生产环境下Ansible以及tower的建设需要有高可用架构，对于tower的高可用架构，前端需要F5或者haproxy这些负载均衡器，后端的状态同步需要有postgresql 的replication多副本保证。
对于playbook的保护，最好有备份机制，或者放到代码库或者共享存储中。
@ManMaster 资深工程师：
只需要把认证关系inventory以及playbook备份好就行了，Ansible没有守护进程在运行。
14、普通用户密码怎么管理，大批量密码过期了怎么解决？
@ManMaster 资深工程师：
如果是针对Ansible被管理节点的用户密码过期了，在不修改密码的前提下无法使用Ansible去直接管理这些节点，建议后续使用密钥的方式来管理节点，这样就不涉及密码过期的问题。
如果是Ansible被管理节点的密码过期了，需要使用Ansible去修改这些被管理节点的密码，那只需要写一个很简单的playbook，把新密码在inventory里设置成变量，与不同的被管节点形成对应关系，直接执行批量改密即可。
@邓毓 某农信资深骨干工程师：
密码纳入堡垒机管理，堡垒机会按照策略，定期批量更新密码的，基本不存在密码过期一说。如果没有堡垒机，可通过Ansible 设置定时任务，批量更新密码。
@he7yong 研发工程师
一种是让用户自己登陆修改密码；如果大量服务器，这种方案不适用；
我们目前是做了一个自动化改密码的工具，该工具定时去修改服务器上用户账号的密码。这种适合管理员账号密码管理；
针对您的情形，我的建议是做一个批量修改密码的工具，可以批量选择服务器进行密码的修改，即可。
15、红帽的企业级服务如何看待异构的自动化运维这个难点问题？
自动化运维建设的最大难点在于异构的自动化运维，原因在于企业各类硬件、操作系统、软件、场景需求的异构，造成各类场景的设计和实现难度增加，需考虑场景下的每一种异构的解决办法。红帽的企业级服务是如何看待该难点问题的？
@张家驹 首席架构师：
个人认为Ansible的一个最大的好处就是通过他完善的生态（如众多的modules，galaxy的众多roles也可以被复用）去解决系统异构的问题。用户只需要了解module的用法，编写yaml文件，就可以完成对不同硬件及软件的管理及自动化。异构的难点其实被Ansible体系所屏蔽了。
评论：但有些情况下的异构很难处理，比如同样的软件和版本，但安装的路径和配置的标准不一样，这时就需要充分考虑这种异构的不同，用不同的代码来进行匹配，有时候可能并不清楚其中的不同，可能又需要花大量时间去调研。
@ManMaster 资深工程师：
虽说不同的软硬件，操作系统等都有自己的管理方式，但还是有一些相同点的，Ansible这些自动化工具就是抓住了这些共性实现跨平台运维的。
首先就是Ansible的工作原理，Ansible实现批量操作的关键就是SSH协议和python，很多硬件设备包括网络设备上都是有一个linux内核在运行的，而linux本身就自带SSH协议以及python解释器，这也是实现跨平台运维的基础。
而整体的异构化运维就考验运维人员的任务编排能力了，如果能把复杂的运维场景高度抽象化，并对抽象出来的逻辑通过Ansible的模块实现，当然也可以直接通过python实现，这样就能实现不同平台的异构化运维。
@景显强 红帽软件资深解决方案架构师：
多种异构设备需要进行统一自动化运维的前提是需要对每种设备上的系统进行标准化要求，按照标准进行批量操作才能提高效率。
对Ansible 而言，他本身无代理的模式已经决定了他能支持多种系统，同时Ansible的connection plugin能支持openssh winrm等协议，对于目标设备只要支持者两种方式登录，都可以进行自动化。
