- 工信部备案号 滇ICP备05000110号-1
- 滇公安备案 滇53010302000111
- 增值电信业务经营许可证 B1.B2-20181647、滇B1.B2-20190004
- 云南互联网协会理事单位
- 安全联盟认证网站身份V标记
- 域名注册服务机构许可：滇D3-20230001
- 代理域名注册服务机构：新网数码
行业资讯
实现自动化运维就是将复杂的事情简单化、标准化、流程化，通过工具重复性、周期性的实现。例如应用系统维护自动化，巡检自动化和故障处理自动化等。能够自动解决用户在 IT 管理中的日常运维问题，最终实现提升运维效率的目的。然后在应用这些自动化运维工具，如SaltStack、Ansible、Puppet等等的过程中肯定会遇到不少问题和难点，以下是部分典型问题汇总。
一、目前，市面上有很多自动化运维工具，例如SaltStack、Ansible、Puppet、Chef等。各个工具使用方式也不相同。在进行工具选型时，需要考虑哪些方面的因素？
1.各种运维工具只是用于帮助人员进行运维的，每种工具都有其使用的优势领域，Puppet适用于软件自动化配置和部署；SaltStack适用于基础设施管理，在几分钟内可运行起来，很容易管理上万台服务器，速度够快；Ansible适用于批量操作系统配置、批量程序的部署、批量运行命令等；运维人员不想维护过多的平台，我们都希望学习过程尽可能简单，使用的工具强大，二次开发的成本也低，从这几方面讲SaltStack是一个很好的选择。
2.从语言考虑：
SaltStack、Ansible python开发的
Puppet、Chef ruby开发的
从用户覆盖考虑：
Ansible 、SaltStack、Puppet、Chef
从学习成本考虑：
Ansible 、SaltStack、Puppet、Chef
开源社区支持程度考虑：
Ansible 、SaltStack、Puppet、Chef 都支持的很好：
大规模应用考虑：
SaltStack、Puppet、Chef 、Ansible
二、自动化运维工具有哪些方式实现故障的准确定位？
1.一个小小的故障出现必将引起数十个甚至上百的设备报警，那么现阶段的自动化运维软件能够把故障定位精确到什么程度？还是仅仅能做到提示，真正的故障原因还需要运维人员自己去手动找？故障定位算法采用机器学习中的二叉决策树的方式实现: 一方面希望将故障所产生的所有告警信息整合为一条信息，减少告警量；另一方面希望能够智能定位出故障点，减少工程师排查问题的时间，并引入自动化处理。以网络故障原因定位为例，实现上述目标需要三步: 第一步：将问题排障过程的经验提炼成二叉决策树；第二步：将告警信息按照时间分片算法进行分类分组；第三步：将分组的告警信息输出给决策树进行自动推理输出推理结果。智能定位出故障点，尽可能减少人工参与，提高运维效率。
2.设备的全面健康检查状态对比 巡检脚本的指标巡检完善度 同比类比，和趋势对比 准确定位目前需要专家分析 目前情况代码的稳定程度和it基础架构的稳定程度相对完善 出现问题，一般会实现故障转移，给我们时间进行故障分析避免再次发生
三、如何才能避免自动化运维工具使用后带来的风险？
1.自动化运维平台运行时，对于大批量操作，如版本变更，批量发布等一定要经过测试后才能进行批量操作。风险就是不知道执行的是否成功，有了校验也不知道校验的是否完全和执行是否成功。一般有了执行脚本就会有校验脚本。
所以以下几点值得注意：
（1）制定比较通用的校验架构，按脚本规范编写脚本利于脚本的校验；
（2）有一些像配置核查的功能也能够帮助我们找出配置的不一致，这些校验功能帮助我们查出风险；
（3）自己编写一些脚本各数据的脚本做成定时任务执行，定时的反馈信息；
（4）还有就是一些报表，报表也可以校验数据。不同的校验方法针对不同校验级别的数据和功能。
（5）还有限制一些风险的操作，例如：rm，像这些操作就要有审核机制或者其他管理方法。
（6）应对风险还有一种就是操作日志，可以通过操作日志进行方向操作能够找回数据。
2.权限控制，关键命令记录双人授权，变更时间窗口限制 批量执行的数量 等等 最简单的就是权限控制，和执行操作审批。
四、企业实现自动化运维的高效率需要哪些制度或措施提供保障？
1.运维制度的建立包括环境管理、资产管理、介质管理、设备管理、监控管理、网络安全管理、系统安全管理、恶意代码防范管理、密码管理、变更管理、备份与恢复管理、安全事件处置，应急预案管理等制度。
（1） 运维管理制度是衡量运维工作的一把尺子，完善的管理制度能有效的提升运维工作效率，日常工作以管理制度为依据，按规定的要求和规定的流程操作既快速又准确；
（2） 全面的运维管理制度能在问题和故障还没有出现没有造成损失前就被及时的发现，从而问题得到有效的处理，业务连续性得到了保障；
（3）运维管理制度为运维工作提供了规范化的解决方案，使运维人员在处理问题时有章可循快速找到问题的根本原因，把问题对业务造成的损失降到最低；
（4）运维管理制度是为业务服务的，业务是不断发展的，运维管理制度要跟得上业务的不断发展实现管理制度的创新。
2.双人审核，特权审批。能自动化操作的全部编写自动化脚本 定义自动化流程，减少前端运维人员手工操作风险。提高效率的关键是解放运维人员，把运维人员变成脚本开发人员或者程序开发者。
五、自动化运维如何体现价值，为客户带来怎样的收益？它的价值如何体现？
1.自动化运维平台的建设能为客户带来很多收益，包括以下几个方面：
（1）在没有 建设运维 平台之前，一个 新 业务上线，需要做很多操作， 例 如DNS变更、LVS变更、OS初始化、自动化测试、持续部署、持续反馈、监控、业务调用关系配置等等。现在新业务上线只需要简单的配置，剩余的工作由平台协调自动完成上线。
（2）通过建设自动化运维平台实现了对业务流程的有效梳理，有效的了解现有的IT资源、运行状况、可靠性与可用性，使企业从全局掌握IT资源和资产的详细信息，为企业的决策提供了有力的支撑；
（3）通过建设自动化运维平台提高了运维工作效率，以前有很多需要人工参与处理的故障和事件，现在绝大部分由运维平台自动按预定的规则进行处理，在运维响应时间上有了很大的提升；
（4）通过建设自动化运维平台发现潜在的问题，降低了故障率，运维人员再也不是以前的救火队员了，一些潜在的问题在萌芽阶段就被发现和处理了，避免了故障造成的业务中断；
（5）通过建设自动化运维平台有利于故障的快速恢复，通过对以往时间点配置的保存建立配置基准快照，然后根据出现故障前后的配置基准的比对快速的发现故障的线索和根源，及时找到故障处理办法恢复系统运行。
2.配置的标准化比例将大幅提高 操作的规范化比原来会有质的提升。
六、如何在运维自动化软件真正实现标准化，规范化？
1.标准化和规范化是自动化运维平台建设的基础和关键点：
（1）实施自动化前提需要标准规范与流程化。比如如果系统版本，主机名，IP不统一规范，则可能会导致saltstack部署执行，日志监控部署，应用部署等一系列问题。
（2）运维自动化需要规范标准化，当然运维自动化又促进规范标准化。运维自动化，标准化需要落实，不能空谈，标准要深入人心，融入日常行为中 。
（3）由于业务增长迅速，系统（应用）环境需求天天都有很多 ， 运维自动化与标准化往往是由业务，IT环境驱动的，逐步优化完善出来的。
（4）标准与自动化需要持续性改进优化 ， 运维自动化不是一蹴而就，而是逐渐持续性优化改进（ITIL理念）和实施的。
2.真正实现标准化，规范化。在我看来全部是人员问题。规范化：从人员抓起，规范是给人制定的，不按照规范进行操作进行惩罚和相关操作。无违规操作的进行奖赏。标准化：确定标准基线，不标准的一概进行整改，按时完成。无法完成的进行相关惩罚，对标准化高的进行奖励。
七、细化自动化运维，制定相关标准，才能引领高效运维之路？
1.企业需要自动化运维，但是需要什么样的自动化运维？是基于基础平台方向，还是业务运维方向？应对自动化运维进行专业细化，并制定相关标准，才能吸引更多的传统中大型企业开展自动化运维。目前，我国的自动化运维相关开发均采用SaltStack、Ansible、Puppet等开源产品，开源产品本身漏洞多、迭代更新快，这让传统大型企业自身的运维人员难以承受，这就需要涌现出几个大型头部自动化运维厂商出来拿出标准化的自动化运维产品来引领中国自动化运维发展。
2.制定相关的行业标准是自动化运维发展一个保障，标准化是自动化运维的基础，想要实现标准化，从小处讲首先识别各个运维对象，然后我们日常做的所有运维工作都应该是针对这些对象的运维。如果运维操作脱离了对象，那就没有任何意义。同样，没有理清楚对象，运维自然不得章法。例如扩容，首先确定是服务器的扩容，还是应用的扩容，还是其它对象的扩容。你会发现，对象不同，扩容这个场景所实施的动作是完全不一样的。如果把服务器的扩容套用到应用的扩容上去，必然会导致流程错乱。同时对于对象理解上的不一致，也会增加无谓的沟通成本，造成运维效率低下。这种情况下的自动化运维不但不能提升效率，还会越自动越混乱。
八、如何在已有平台实现实现Ansible 的的集成设计？
1.在已有平台实现ansible 的集成设计包括两种方法：
（1）通过专门的Jenkins插件实现ansible 的集成 优点：Ansible脚本被SCM版本控制，有助于追踪历史记录。Ansible脚本与项目捆绑，容易查找并进行二次开发。缺点：积累难以复用，很容易陷入各自为战。运维工作交给研发，在DEVOPS推进前期阻力比较大。
（2）直接借助SSH实现ansible 的集成
优点：Jenkins和Ansible分开部署，各自发展，避免一锅端。Ansible脚本集中管理，方便知识共享。
缺点：个性化比较麻烦，比如针对已有项目的适配。
2.已有平台可以开发api接口 java 拼装命令发送给 api接口，接口调用 cli或者 python的ansible 接口运行 cmd命令 执行 解析返回结果入库 或者使用play'book 上层平台直接生产 playbook 然后用cli接口调用 ansble playbook 执行解析返回结果入库。ansible 返回结果可以自己定义，直接返回到数据库中这个需要修改 ansibe的返回部分代码网络上有相应案例可以参考。
九、Ansible主机访问目标主机的权限设置？
1.Ansible主机对所有目标主机都能够免密登录，这块存在一定的安全风险。如何确保Ansible主机的安全性，如何加强Ansible主机对目标主机访问的控制？
针对这个问题需要把握以下几点：
Ansible使用原生openssh，而openssh是全球范围内最严格审查的程序之一，具有轻量级
安全性高的特点。
在生产节点和非生产节点上启动Ansible必须分两批进行。
配置较低权限的运维专用帐号，不能通过密码或ssh密钥使用root登录。
2.Ansible 自有一个简单 acl 控制，输入配置文件中的密码才能向指定机器发布命令和执行playbook 但配置文件是明文的，可修改为加密方式需要修改下 ansible代码。
十、自动化运维工具安全审计问题？
1.一般机构都有堡垒机（运维审计平台）自动化运维绕过了审计，这方面是如何做的。像ansible 使用ssh 是如何与堡垒机对接的。还是单独建立帐户权限，或直接使用秘钥认证。
Ansible可以通过堡垒机管理被管节点，例如有三类节点：
管理节点，admin.example.com，是执行ansible命令的服务器
被管理的节点，internal1.example.com, internal2.example.com
堡垒机，bastion.example.com
管理节点不能直连 internal1 & internal2，需要通过堡垒机建立连接。
管理节点连接堡垒机的方式如下：
ssh -i keyfile_bastion -p 12345user@bastion.example.com
从堡垒机连接internal节点的方式如下：
ssh -i keyfile_internal -p 23456 user@internal1.example.com
ssh -i keyfile_internal -p 23456 user@internal2.example.com
2.自动化运维工具集成 ansible,记录所有操作内容和执行历史日志。
十一、对于多套不同架构的基础设施环境如何构建自动化运维平台？
1.随着公司多年的业务发展情况，已经形成了多套异构的基础设施生产运营环境，主要涵盖了：纯物理机集群环境、基于 Esxi 主机的虚拟化集群环境、采用 OpenStack 高可用方案的私有云集群环境，当前也已经从最初的小型机+x86 主机+SAN的硬件基础设施，替换成全 x86 主机的硬件基础设施。但由于三套不同的环境下均有生产性系统要保证持续的运行，对于三套不同的环境各有不同的运维要求，对整体的 IT 运维带来了很大的压力。但由于评估将基础设施环境全部替换为统一的基础设施需要的周期比较长，所以想先初步将多套环境的运维尽量采用自动化的方式进行提升，以减轻运维工作的压力。当前遇到的主要问题是，采用何种方案能够比较简便的实现对多套环境的统一自动运维，以及在后续进行环境迁移的时候，方便通过配置调整而实现自动化运维的灵活适应。
2.SaltStack提供三种运行方式，包括Local本地运行交付管理，Master/Minion方式，不需要客户端Salt SSH方式，SaltStack提供方法来管理目标系统的状态。通过高效的远程执行引擎，任何配置可以被管理应用到远程系统SaltStack。虽然它主要设计用于Linux平台，SaltStack也可以管理其他操作系统，包括VMware vSphere环境。可以通过saltstack创建Openstack虚拟机，实现Saltstack对Openstack的管理。
