企业自动化运维落地的实践经验及运维工具选型对比分析线上交流探讨精华汇总

字数 5285阅读 4973评论 0赞 4

随着IT技术的快速发展，IT系统的运维复杂度不断增加，IT部门的体量不断扩大，传统的人工操作和借助管理流程的方式已不能满足日益增长的运维工作量。而智能时代的到来，无论是DevOps的思想还是AIOps思想，自动化就像人的“手”一样，决定着最终这些技术思想的是否能够落地，决定着未来一个IT运维的生产力。

当你把自动化运维这个话题抛给不同的角色，他们的反应也一定是不一样的，程序员眼中的自动化运维可能是可以自助申请资源，可以点点点的进行应用发布；应用运维人员眼中的自动化运维可能是自动的监控每个应用的状态有简单的问题就按照约定的动作去自愈，复杂的问题通知给我，我去处理或者是过期的日志清理等；基础资源运维人员眼中的自动化运维可能是硬件服务的自助系统安装，自动的环境初始化，垃圾文件清理等，这些理解都没有错，但是这些都是一个一个的点，没有形成一个整体，没有从方法论的角度去理解自动化运维，去建设自动化运维。

在8月3日的线上交流活动中，围绕着企业自动化运维落地的实践经验及运维工具选型，方案选型等进行了问题的讨论，也得到了各位专家的支持，大家针对自动化运维的相关问题体现出了非常大的热情，在此也对相关问题及大家的观点总结如下：

# 一、自动化运维平台风险
## 典型问题：
**Q1：自动化运维风险控制问题？**
**Q2：自动化运维平台的安全和权限如何控制？**

## 问题解答：
A1:
首先，所有的自动化功能模块的本质都是落到代码层面，那么就需要对自动化运维功能的代码进行测试，适用于开发项目管理的流程；二是对于一些删除或者修改类的操作，需要考虑double check和回滚方案，对于不能回滚的操作不能做（这点其实和手工操作是没有区别的）；三是灰度策略，可以采用灰度的方式来验证自动化操作结果和预期是否一致，如果一致则继续进行，如果不一致则需要进行回滚；四是监控配合，监控系统能够及时发现有问题的操作并及时报警；五是权限管理，对于能够操作自动化运维平台的，需要有严格的权限控制；六是通过api对接的系统，需要有鉴权机制。

A2:
个人认为应该注意以下几个方面：
一是对于web页面操作的通过AD域加角色的方式进行权限控制；
二是对于接口调用的情况需要有相应的权限模块；
三是对于运维平台自身，要防止平台在未授权的情况下对生产资源进行删除和修改操作；
四是定期对平台进行安全扫描，扫描平台自身的漏洞；

# 二、自动化运维平台规划
## 典型问题：
**Q1：自动化运维的建设应该如何规划？**
**Q2：自动化运维建设中，标准化的规范如何制定？**
**Q3：在实际的运维环境中，我们该如何制定一套完整的自动化运维管理方案，用来支撑自动化运维工作？**
**Q4：python 自动化运维方案有哪些？？**
**Q5：自动化运维的建设，需要分几阶段进行？应如何做规划？**

## 问题解答：
A1：
这个问题没有固定的答案，分几步需要结合具体情况，最终的目的是要实现所有的端到端的交付。一般来说大体可以分为以下几个阶段：
一是解决目前最急切的痛点(这里一般是指运维团队自身最大的痛点或者挤压已久的没有解决的其他团队提出的问题)；
二是收集it部门其他组（开发和测试团队）的自动化运维需求并内部排期解决；
三是在解决了前两者点上的问题之后，将各个点串联起来，消除点与点之间人肉工作；
四是在初步形成的自动化运维链条上查漏补缺，形成正向反馈链条。

A2：
标准化需要结合公司的具体情况，一般而言有以下几个方面需要进行标准化（供参考）。一是服务器pod标准化，一个pod放几台机器，如果连接；二是物理机机型，计算密集型、内存型、io密集型还是存储型，需要将不同厂商的机型归纳为几个标准机型；三是操作系统标准化，包括操作系统版本，操作系统内核参数，盘符路径等；四是软件安装标准化，包括软件版本，安装路径，日志路径，日志切割，参数调优等；五是软件部署标准化，双节点不能部署在同一台物理机和同一个机柜上，避免主机和机柜级故障。

A3：
制定自动化运维方案,需要考虑以下几个方面：一是明确制定自动化运维方案的目的，这是制定自动化运维方案的指导思想；二是明确自动化运维方案的服务对象角色；三是明确不同的对象角色在自动化运维过程中的抓手分别是什么；四是明确自动化运维方案落地过程中需要注意的安全问题（例如权限细化、调用鉴权、操作审计等）；五是通过调研的方式进一步了解其他同事的运维需求；六是在方案里明确建设自动化运维平台计划分几个阶段，将需求分散在这几个阶段里；七是明确将自动化运维方案落地为自动化运维平台时的具体方式（自研、外购还是基于外购进行二次开发）；八是在自动化运维方案中明确平台在使用过程中的正向反馈流程。

A4：
我理解您的意思应该基于python开发的运维方案？市面上完全基于python的运维方案这个我不太清楚，但是使用python可以自己去实现运维平台，而且有现成的基于python的ansible能够帮你解决很多问题，可以考虑基于ansible开发自己自动化运维方案。

A5：
这个问题没有固定的答案，分几步需要结合具体情况，最终的目的是要实现所有的端到端的交付。一般来说大体可以分为以下几个阶段：一是解决目前最急切的痛点；二是收集it部门其他组（开发和测试团队）的自动化运维需求；三是在解决了前两者点上的问题之后，将各个点串联起来，消除点与点之间人肉工作；四是在初步形成的自动化运维链条上查漏补缺。

# 三、CMDB数据采集问题
## 典型问题：
**Q1：CMDB建设过程中，如何实现自动发现？**
**Q2：自动化运维的建设中如何选择CMDB自动收集数据？**
**Q3：如何同时保证CMDB数据的实时性与一致性？**

## 相关解答：
A1:
CMDB的自动发现一般基于以下几种方式：一是通过调用被采集方软件的api接口获取相关信息，例如vmware、emc存储等；二是通过某种协议（公有或者是私有协议），例如snmp去获取相关配置信息；三是通过在主机上执行命令，并对结果进行处理，例如抓取主机上中间件的信息；四是通过执行中间件的命令来获取信息。自动化发现一般是通过以上几种方式的组合来实现自动发现的目的。

A2:
这个问题有点大了，具体到数据收集这个点上而言。CMDB的数据要想收集全面，需要从两个方面去考虑，一是CMDB采集工具自身的自动化采集能力，二是有些数据需要通过流程的方式来督促人工录入，例如业务系统名称、业务系统运维负责人、开发负责人、测试负责人这些信息自动采集工具是采集不到的，需要人工维护。如果需要建设CMDB系统，有三种思路，一是完全自研，这就要求团队的研发能力比较强，并且有人对ITIL的流程比较了解，自动采集实现较慢；二是直接采购商业的CMDB产品，好处是快速上线，自动采集能力强，缺点是有些需求可能无法直接满足，需要定制开发；三是基于开源的产品做二次开发，例如基于itop，但是自动发现能力还是要自己实现，优势是有一个基本可用的框架。

A3:
实时性：保证CMDB数据的实时性需要依赖CMDB工具的自动化采集能力；
一致性：一致性需要流程控制和定期的数据审计操作，数据审计操作可以借助CMDB平台的能力来实现。

# 四、运维工具选型
## 典型问题：
**Q1：自动化运维工具选择时，应该对哪些因素进行考量？**
**Q2:自动化运维建设中的运维工具的规划和集成问题？**
**Q3:自动化运维产品如何选择？**

## 相关解答：
A1：
在选择自动化运维工具时笔者认为应该从以下几个方面考量：一是自动化运维工具的成熟度，即在业界的受众面。这里无论是对商用的还是开源的都可以从这个角度进行评估；二是自动化运维工具的功能能否满足运维需求；三是如果是选择开源的自动化运维工具还要考虑工具的技术栈和公司人员的技术栈是否匹配；四是自动化运维工具在安全方面是否有良好的支持；五是自动化运维工具在工作过程中对主机性能的影响，尤其还要测试在并发大的时候，对运维工具平台自身服务端的压力；六是还要考虑选择的自动化运维工具是否满足公司后续技术栈的发展需要。

A2：
您好，您说的这个情况确实是目前大多数公司存在的问题。在我看来存在这个问题的最主要原因是在前期缺乏一个宏观的整体规划，各个组织各自为政，没有统筹管理。那么对于已经存在的现状要如何处理呢？在我看来要做以下几件事：一是需要成立一个治理小组，成员包括各个存在系统的owner，然后由一位领导担任组长；二是各个系统owner阐述当初建设这个系统的背景，以及该系统现在能解决什么问题，还有什么问题没有解决；三是依据第二步的讨论结果进行合并工作，将能合并的系统进行合并，不能合并的但是功能有重叠的进行数据打通，统一进行输出；四是后续新建系统时需要由治理小组统一规划，避免类似事情再发生。

A3：
自动化运维涉及的面非常广，一般大家谈到的包括资源的自助服务、监控、调度任务、应用发布等。那么在选择产品的时候需要考虑以下几点：一是梳理清楚自身的痛点，即目前最需要解决的问题是什么；二是规划，计划在3年内做到什么样的效果；三是所选自动化运维平台的产品成熟度（同行业案例多少）；四是自动化运维平台的开发程度，能否进行二次开发或者是支持功能拓展；五是平台的技术框架是否是主流的技术框架；六是通过试用来测试和本地实际情况的结合程度。

# 五、其他
## 典型问题：
**Q1：AIOPS和自动化运维的关系？**
**Q2：是否可以结合当前的一些先进技术，如云计算、大数据等，使得自动化运维更加高效、智能？**
**Q3：在业务系统中，各个部分的运维自动化程度的高低程度是怎样的？**
**Q4：在运维的关注点上，传统企业与互联网企业有哪些不同？**
**Q5：自动化运维平台如何能更好的贴近业务？及时发现业务的已经发生的风险和将要发现的风险？**
**Q6：传统的IT运维与自动化运维有什么差别？**

## 相关解答：
A1：
aiops是自动化运维的一部分，是这几年随着ai火爆后开始出现的领域，自动化涉及运维操作的方方面面，aiops仅仅是将ai技术应用到现有的ops平台上，一般同时都会结合大数据技术一起使用。

A2：
结合云计算能力，可以快速扩容自动化运维平台的服务能力；结合大数据和人工智能技术，可以使自动化运维平台提供更强大的功能，就是现在很多人开始关注的aiops。风险需要人工来审核，比如基于大数据和人工智能技术对某种行为进行自动操作，那么在刚开始使用这个技术的时候需要人工进行double check，并且对划定优先级和重要性级别。对于一个低优先级和低重要级的可以自动处理。

A3：
在笔者看来，问题中涉及的点都可以用自动化运维来进行管理，这个在一些类似阿里巴巴、腾讯、华为这样的大厂都已经实现很久了，在技术上不存在问题。具体到某一个公司，还要结合两方面来看，一方面是目前公司最痛点的地方在哪里；另一方面是是否存在部门墙，导致不能把整个过程串联起来。

A4：
自动化运维要更好的贴近业务首先需要收集业务自动的自动化运维需求，通过平台来满足业务的自动化运维需求，这是第一步要做的工作。其次需要对业务系统进行监控，在此基础上，需要和业务沟通风险指标，将风险指标进行量化，并配置到自动化运维平台的监控系统中，利用平台的监控能力进行724小时监控，当出现指标达到报警阈值的时候，就通过短信、微信、邮件等方式进行报警。最后，对于风险指标的配置可以通过大数据分析和ai的结合来逐步完善，形成一个适合每个业务系统的正向反馈链。

A5：
之所以会出现半自动化的运维，其实就是因为这些解决的都是点上的问题，都是把每个点的人工操作变成了脚本化或者平台化的自动动作，是离散的，本质上还是点而不是线，更不是面。真正的自动化运维是要达到端到端的自动化交付，是从开发到测试到运维全链路的自动化，去除人工操作。举一个例子，创建一个redis中间件，半自动化的做法是：1，在虚拟化平台申请机器；2，网络分配ip地址（人工）；3，通过另外的脚本对机器进行初始化（人工执行脚本）；4，通过安装脚本安装redis（人工安装）；5，邮件或者人工告知申请方。自动化的做法是：提交创建reids需求，自动化平台做好所有的事情，然后调用邮件接口，通知申请者。

A6：
自主可控有两种思路，一种是完全自研；另一种是基于一个采购的自动化运维平台进行二次开发。对于第一种情况，需要公司人员具备一定的开发能力，优势在于需求可以并充分结合本地需求，缺点是对人员要求比较高并且平台成型较慢；对于第二种情况，需要采购一个平台技术栈实现与本公司开发或者运维人员匹配的平台，并且要求平台方开放源代码或者提供丰富的二次开发接口，优势是可以快速至少满足80%左右的需求，劣势是需要理解已有的代码，灵活性不够。

智能化运维运维自动化运维

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

企业自动化运维落地的实践经验及运维工具选型对比分析线上交流探讨精华汇总

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料