同样是配置管理，初高级DevOps工程师处理方法有何不同？

首先，我们先来介绍一下 DevOps 的定义：

DevOps 是一种文化，它鼓励包括开发和运维团队在内的所有利益相关方之间进行协作，并通过自动化来改进流程，以提高软件交付的质量和速度。

虽然 DevOps 本身就在强调企业内部文化的变革，但是你会发现在公司中大家还是使用“DevOps 工程师”这个头衔，当然，与其它职位相同，DevOps 工程师也会有初级、高级之分。

我的整个职业生涯都专注于 DevOps，并在多家财富 500 强的公司工作过。本文中将和大家分享初高级 DevOps 工程师在面对配置管理相关问题时的不同解决方法。

配置管理

我对配置管理的定义是这样的：它是一种确保公司所拥有的所有软件和硬件资产在任何时候始终都是已知并被跟踪的原则——这些资产未来的任何变更都是已知且被跟踪的。您可以将配置管理看作是技术资产的一个随时更新的库存清单，一个单一的事实来源。

如何在 IT 部门中实施配置管理，与其说是一门科学，不如说是一门艺术：必须从引入变更的过程、实际变更的内容以及该变更是如何与许多其他依赖系统相关联的等许多不同的方面加以控制和跟踪。

对于 DevOps 工程师来说，配置管理最重要的 5 个方面是：

• 管理操作系统和中间件层软件的安装和配置
• 定义自己的 configuration-as-code（配置即代码）
• 无论环境如何，都能确保可重复的变更是幂等的
• 了解系统某一个部分的变更可能会对另一个部分产生的影响
• 定义自己的 networks-as-code（网络即代码）

下面，我们以操作系统和中间件层软件的安装和配置、networks-as-code 为例，来深入探讨一下初高级 DevOps 之间不同的处理方法。

管理操作系统和中间件层软件的安装和配置

这是有运维操作背景的人们最熟悉的地方，需要对应用程序运行其上的多个操作系统和中间件有技术上的了解，需要知道 /etc/hosts 文件是什么，以及它是做什么的，并且在大多数情况下，使用命令行多于 GUI。

问题： 在数十台甚至数百台的服务器上安装某些监控代理软件

初级 DevOps 工程师的方法

编写一个 powershell/bash 脚本，该脚本可以使用给定的主机名和凭证输入来安装和配置对应的代理。如果安装失败，则将失败信息写入日志中，以便稍后查看。

高级 DevOps 工程师的方法

• 查看需要安装此特定软件的操作系统和版本，并尝试将其标准化为受支持的最低版本。
• 将软件安装在基础镜像中，这样在默认情况下，就能将软件安装到任何新服务器上
• 使用配置管理工具，如 Chef 或 Ansible，而不是编写需要管理和维护的自定义脚本
• 思考并从配置脚本中推导环境变量，以便在一次性部署到 100 台服务器之前，先在预发布环境中测试安装变更
• 利用源代码控制系统，该源代码控制系统通常是基于 GIT 的，且具有可对代码进行测试的持续集成工具

总结

从本质上讲，高级 DevOps 工程师会以整体的视角来审视任何给定的问题，并试图理解如何在企业范围内实现这种变更，而不是简单地解决单一给定的问题。坦白地说，这种技能的技术含量较低，更多的是评估和解决问题的能力。

定义自己的 configuration-as-code

这个问题与在某些配置管理工具（例如 Ansible 或 Chef）以及如何用所选工具实现实际配置的技术技能有关。

问题： 标准 RHEL 配置需要一个额外的挂载存储驱动，该驱动的 /mount 位置需要 100gb 的可用磁盘空间。

初级 DevOps 工程师的方法

利用 Ansible 任务来连接磁盘驱动，扩展逻辑卷挂载并创建 /mount FS。并假定此操作仅在新配置的虚拟机上运行，因此，如果运行在现有服务器上，则可能会导致故障。

高级 DevOps 工程师的方法

• 为标准 RHEL 配置部署创建一个 Ansible 角色
• 使用 set_fact 模块为现存挂载点定义一个变量
• 如果 /mount 在给定的磁盘空间中不可用，则用脚本创建它

总结

和不同的开发语言（java 、.net 、javascript）一样，每种语言都有自己的方式来实现代码中的某些逻辑。高级 DevOps 工程师了解如何实现代码的逻辑，以便解决配置所面临的多种可能性，而初级 DevOps 工程师很有可能是首次使用给定的工具 / 语言来解决该问题，因此只是简单地尝试解决眼前的问题。

原文链接

https://medium.com/devops-dudes/differences-between-junior-devops-and-senior-devops-engineers-8d0f28b8b30b