共计 4703 个字符，预计需要花费 12 分钟才能阅读完成。
如何针对性破解 Linux 自动化运维落地的 18 个关键问题，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
不久前，我做过一个关于企业自动化运维落地经验及工具对比的分享和介绍，其中很多场景是我根据实践经验对一线互联网公司和传统行业的做法进行的对比阐述：如何将自动化运维形成一个整体? 如何从方法论的角度去理解自动化运维、去建设自动化运维?
通过整理运维爱好者们提出的一系列自动化运维落地的具体问题及讨论结果。
一、自动化运维平台风险
问题 1：自动化运维风险如何控制?
一是所有自动化功能模块的本质都是落到代码层面，那么就需要对自动化运维功能的代码进行测试，适用于开发项目管理的流程;
二是对于一些删除或者修改类的操作，需要考虑 double check 和回滚方案，对于不能回滚的操作不能做(这点其实和手工操作是没有区别的);
三是灰度策略，可以采用灰度的方式来验证自动化操作结果和预期是否一致，如果一致则继续进行，如果不一致则需要进行回滚;
四是监控配合，监控系统能够及时发现有问题的操作并及时报警;
五是权限管理，对于能够操作自动化运维平台的，需要有严格的权限控制;
六是通过 API 对接的系统，需要有鉴权机制。
问题 2：自动化运维平台的安全和权限如何控制?
个人认为应该注意以下几个方面：
对于 Web 页面操作的通过 AD 域加角色的方式进行权限控制;
对于接口调用的情况需要有相应的权限模块;
对于运维平台自身，要防止平台在未授权的情况下对生产资源进行删除和修改操作;
定期对平台进行安全扫描，扫描平台自身的漏洞。
二、自动化运维平台规划
问题 1：自动化运维的建设应该如何规划?
这个问题没有固定的答案，分几步需要结合具体情况，最终的目的是要实现所有的端到端的交付。一般来说大体可以分为以下几个阶段：
解决目前最急切的痛点(这里一般是指运维团队自身 *** 的痛点或者挤压已久的没有解决的其他团队提出的问题);
收集 IT 部门其他组 (开发和测试团队) 的自动化运维需求并内部排期解决;
在解决了前两者点上的问题之后，将各个点串联起来，消除点与点之间人肉工作;
在初步形成的自动化运维链条上查漏补缺，形成正向反馈链条。
问题 2：自动化运维建设中，标准化的规范如何制定?
标准化需要结合公司的具体情况，一般而言有以下几个方面需要进行标准化(供参考)：
服务器 Pod 标准化，一个 Pod 放几台机器，如何连接;
物理机机型，计算密集型、内存型、IO 密集型还是存储型，需要将不同厂商的机型归纳为几个标准机型;
操作系统标准化，包括操作系统版本、操作系统内核参数、盘符路径等;
软件安装标准化，包括软件版本、安装路径、日志路径、日志切割、参数调优等;
软件部署标准化，双节点不能部署在同一台物理机和同一个机柜上，避免主机和机柜级故障。
问题 3：在实际的运维环境中，我们该如何制定一套完整的自动化运维管理方案，用来支撑自动化运维工作?
制定自动化运维方案，需要考虑以下几个方面：
明确制定自动化运维方案的目的，这是制定自动化运维方案的指导思想;
明确自动化运维方案的服务对象角色;
明确不同的对象角色在自动化运维过程中的抓手分别是什么;
明确自动化运维方案落地过程中需要注意的安全问题(例如权限细化、调用鉴权、操作审计等);
通过调研的方式进一步了解其他同事的运维需求;
在方案里明确建设自动化运维平台计划分几个阶段，将需求分散在这几个阶段里;
明确将自动化运维方案落地为自动化运维平台时的具体方式(自研、外购还是基于外购进行二次开发);
在自动化运维方案中明确平台在使用过程中的正向反馈流程。
问题 4：自动化运维的建设，需要分几阶段进行? 应如何做规划?
这个问题没有固定的答案，分几步需要结合具体情况，最终的目的是要实现所有端到端的交付。一般来说大体可以分为以下几个阶段：
解决目前最急切的痛点;
收集 IT 部门其他组 (开发和测试团队) 的自动化运维需求;
在解决了前两者点上的问题之后，将各个点串联起来，消除点与点之间人肉工作;
在初步形成的自动化运维链条上查漏补缺。
三、CMDB 数据采集问题
问题 1：CMDB 建设过程中，如何实现自动发现?
CMDB 的自动发现一般基于以下几种方式：
通过调用被采集方软件的 API 接口获取相关信息，例如 VMware、EMC 存储等;
通过某种协议(公有或者是私有协议)，例如 SNMP 去获取相关配置信息;
通过在主机上执行命令，并对结果进行处理，例如抓取主机上中间件的信息;
通过执行中间件的命令来获取信息。
自动化发现一般是通过以上几种方式的组合来实现自动发现的目的。
问题 2：自动化运维的建设中如何选择 CMDB 自动收集数据?
这个问题有点大了，具体到数据收集这个点上而言，CMDB 的数据要想收集全面，需要从两个方面去考虑：一是 CMDB 采集工具自身的自动化采集能力，二是有些数据需要通过流程的方式来督促人工录入，例如业务系统名称、业务系统运维负责人、开发负责人、测试负责人这些信息自动采集工具是采集不到的，需要人工维护。
如果需要建设 CMDB 系统，有三种思路：
完全自研，这就要求团队的研发能力比较强，并且有人对 ITIL 的流程比较了解，自动采集实现较慢;
直接采购商业的 CMDB 产品，好处是快速上线、自动采集能力强，缺点是有些需求可能无法直接满足，需要定制开发;
基于开源的产品做二次开发，例如基于 IOP，但是自动发现能力还是要自己实现，优势是有一个基本可用的框架。
问题 3：如何同时保证 CMDB 数据的实时性与一致性?
实时性：保证 CMDB 数据的实时性需要依赖 CMDB 工具的自动化采集能力;
一致性：一致性需要流程控制和定期的数据审计操作，数据审计操作可以借助 CMDB 平台的能力来实现。
四、运维工具选型
问题 1：自动化运维工具选择时，应该对哪些因素进行考量?
在选择自动化运维工具时笔者认为应该从以下几个方面考量：
自动化运维工具的成熟度，即在业界的受众面。这里无论是对商用的还是开源的都可以从这个角度进行评估;
自动化运维工具的功能能否满足运维需求;
如果是选择开源的自动化运维工具还要考虑工具的技术栈和公司人员的技术栈是否匹配;
自动化运维工具在安全方面是否有良好的支持;
自动化运维工具在工作过程中对主机性能的影响，尤其还要测试在并发大的时候，对运维工具平台自身服务端的压力;
还要考虑选择的自动化运维工具是否满足公司后续技术栈的发展需要。
问题 2：自动化运维建设中的运维工具的规划和集成问题?
目前而言，大多数公司的确会存在这样的问题。在我看来问题之所以会存在，最主要原因是在前期缺乏一个宏观的整体规划，各个组织各自为政，没有统筹管理。
那么对于已经存在的现状要如何处理呢? 在我看来要做以下几件事：
需要成立一个治理小组，成员包括各个存在系统的 Owner，然后由一位领导担任组长;
各个系统 Owner 阐述当初建设这个系统的背景以及该系统现在能解决什么问题、还有什么问题没有解决;
依据第二步的讨论结果进行合并工作，将能合并的系统进行合并，不能合并的但是功能有重叠的进行数据打通，统一进行输出;
后续新建系统时需要由治理小组统一规划，避免类似事情再发生。
问题 3：自动化运维产品如何选择?
自动化运维涉及的面非常广，一般大家谈到的包括资源的自助服务、监控、调度任务、应用发布等。那么在选择产品的时候需要考虑以下几点：
梳理清楚自身的痛点，即目前最需要解决的问题是什么;
规划：计划在 3 年内做到什么样的效果;
所选自动化运维平台的产品成熟度(同行业案例多少);
自动化运维平台的开发程度，能否进行二次开发或者是支持功能拓展;
平台的技术框架是否是主流的技术框架;
通过试用来测试和本地实际情况的结合程度。
五、其他
问题 1：AIOps 和自动化运维是什么关系?
AIOps 是自动化运维的一部分，是这几年随着 AI 火爆后开始出现的领域，自动化涉及运维操作的方方面面，AIOps 仅仅是将 AI 技术应用到现有的 Ops 平台上，一般同时都会结合大数据技术一起使用。
问题 2：是否可以结合当前的一些先进技术，如云计算、大数据等，使得自动化运维更加高效、智能?
结合云计算能力，可以快速扩容自动化运维平台的服务能力; 结合大数据和人工智能技术，可以使自动化运维平台提供更强大的功能，就是现在很多人开始关注的 AIOps。
风险需要人工来审核，比如基于大数据和人工智能技术对某种行为进行自动操作，那么在刚开始使用这个技术的时候需要人工进行 double check，并且对划定优先级和重要性级别。对于一个低优先级和低重要级的可以自动处理。
问题 3：在运维的关注点上，传统企业与互联网企业有哪些不同?
传统行业与互联网在运维环节的不同在以下几个方面：
运维代码化：传统行业的运维更多的还是停留在人工操作运维平台的层面甚至是纯人工操作，而互联网更多的是通过代码来进行运维，避免人工操作，这也是为什么互联网公司对运维有要求开发能力的原因;
点化与线性化：传统行业的运维分不同时间购进了很多运维平台，而各个运维平台之间是独立的、离散的。而互联网的运维平台多是线性的，可以实现端到端的交付与串联;
对人员要求不同：互联网公司无论是哪个层面的运维都要求有一定的开发能力或者是一些原理的深入了解(代码层面)，而传统行业更多的是对操作层面的要求。
问题 4：自动化运维平台如何能更好的贴近业务? 及时发现业务的已经发生的风险和将要发生的风险?
自动化运维要更好的贴近业务首先需要收集业务的自动化运维需求，通过平台来满足业务的自动化运维需求，这是 *** 步要做的工作。
其次需要对业务系统进行监控，在此基础上，需要和业务沟通风险指标，将风险指标进行量化，并配置到自动化运维平台的监控系统中，利用平台的监控能力进行 724 小时监控，当出现指标达到报警阈值的时候，就通过短信、微信、邮件等方式进行告警。
***，对于风险指标的配置可以通过大数据分析和 AI 的结合来逐步完善，形成一个适合每个业务系统的正向反馈链。
问题 5：传统的 IT 运维与自动化运维有什么差别?
之所以会出现半自动化的运维，其实就是因为这些解决的都是点上的问题，都是把每个点的人工操作变成了脚本化或者平台化的自动动作，是离散的，本质上还是点而不是线，更不是面。真正的自动化运维是要达到端到端的自动化交付，是从开发到测试到运维全链路的自动化，去除人工操作。
举一个例子，创建一个 Redis 中间件，半自动化的做法是：
在虚拟化平台申请机器;
网络分配 IP 地址(人工);
通过另外的脚本对机器进行初始化(人工执行脚本);
通过安装脚本安装 Redis(人工安装);
邮件或者人工告知申请方。
自动化的做法是：提交创建 Redis 需求，自动化平台做好所有的事情，然后调用邮件接口，通知申请者。
问题 6：自动化运维自主研发的边界如何界定? 既可以做到自主可控，又可以全面发挥和提升员工的能力?
自主可控有两种思路，一种是完全自研; 另一种是基于一个采购的自动化运维平台进行二次开发。
对于 *** 种情况，需要公司人员具备一定的开发能力，优势在于可以并充分结合本地需求，缺点是对人员要求比较高并且平台成型较慢;
对于第二种情况，需要采购一个平台技术栈实现与本公司开发或者运维人员匹配的平台，并且要求平台方开放源代码或者提供丰富的二次开发接口，优势是可以快速满足至少 80% 左右的需求，劣势是需要理解已有的代码，灵活性不够。
以上关于企业自动化运维落地的 18 个问题的解答，希望对各位朋友有所帮助~
关于如何针对性破解 Linux 自动化运维落地的 18 个关键问题问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
