DevOps 的下一次演变

DevOps 的下一次演变

点击此处即可免费领取DevOps资料~

---

从2020年至今，随着社会从全球疫情中慢慢恢复，一些“表面上的正常”也开始恢复，技术继续向前发展。然而疫情已经改变了“正常”的含义，人员、流程和技术都应该适应和发展以应对这些挑战。对于许多从业者来说，疫情导致组织数字化转型的说法是正确的。

随着 2022 年的临近，DevOps 正处于最前沿和成熟的风口浪尖上，并且持续关注工程效率。以下是我们应该密切关注的五个 DevOps 演变。

01 工程效率是重中之重

工程效率是一个特别宽泛的总称。在基础层面，工程效率侧重于使某人（例如工程师）的工作效率更高。有许多学科相互交叉，从组织设计到工程/开发人员经验。工程效率对当今的组织越来越重要。疫情在资源和人员配备方面对技术部门产生了两个主要影响。

首先，在疫情刚开始时，所有资源都变得紧缺且未来不可预测；由于疫情的严重性，人们被迫居家办公，资金雄厚的企业还能抢夺资源咬牙坚持，更多中小型企业无奈破产。第二，在疫情恢复期，大辞职开始了，随之而来的是一场日益激烈的资源争夺战。两者都意味着资源的可用性，尤其是增加的资源，是稀缺的。

工程资源部落/行会的 Spotify 模型是一个有希望的演变；人们可以经常四处走动，减少工程资源面临的麻烦，让工程资源不仅可以更快地增加，而且可以提高参与度和保留率。该行业继续在通常定制的领域朝着标准化迈进，例如发布过程，我认为我们也将看到它继续发展。

02 Git无处不在

利用过去专供软件工程师使用的源代码管理 (SCM) 解决方案。但是，随着“代码即事物”的扩散已经触及从网络、存储到最终开发管道的技术堆栈的多个级别，以运营为中心的工程师采用软件工程师的许多特征的趋势仍在继续。在基础设施堆栈中使用更多临时/一次性基础设施进行迭代正在成为常态。为“代码即事物”源代码控制保存和打包大量配置是一个自然的发展领域。

构建源代码控制的是包管理器——你的 Docker 注册表、Helm 图表存储库等——用于更多可部署的工件；也就是说，将这些工件投入生产是一个过程。由于 Git 在整个技术领域变得无处不在，这导致 GitOps 的持续采用。由于 Weaveworks 于 2017 年编写了定义GitOps 范式的开创性文章，因此五年后，利用 GitOps 被许多组织视为可行的范式，尤其是在从绿地计划开始时。

03 Kubernetes 不再是出血边缘

2022 年，Kubernetes 将庆祝其在 GitHub 上首次提交的八岁生日。在 Kubernetes 之前 8 年（2006 年），VMware 仍然是一家私营公司，而在 vSphere 发布之前的几年（还记得 2014 年在虚拟机上运行工作负载的感觉），Kubernetes 生态系统仍在快速发展，但将工作负载置于 Kubernetes 上已不再是一个新概念。由于应用程序基础设施和架构采用了 Kubernetes 方式，在 Kubernetes 上运行合适的工作负载已经成熟。

Kubernetes 的设计是高度可插拔的。如果你不喜欢 Kubernetes 内部某些内容的意见或实现，你可以替换该意见；如果你不喜欢 Kubernetes 处理入口流量的方式，你可以从当今可用的众多入口控制器中选择一种。这只是几十个可插拔区域的几个例子。因此，Kubernetes 被视为一种动态的、非静态的资源。使用 Kubernetes 需要反复试验，让你的集群变得健壮、高性能和可靠是一个持续的旅程，需要不断的迭代。

04 作者可以成为执行者

毫无疑问，在现代软件堆栈中，我们被数据淹没。对可观察性指标、跟踪、日志的持续科学和探索为我们提供了很多工作。基于该数据做出决策，甚至是自动化决策，仍然至关重要。随着站点可靠性工程 (SRE) 实践的兴起，对使用、故障甚至安全相关项目的峰值做出反应或预测是现代团队课程的标准。

这些决策可以编写成特定平台理解的策略，例如云供应商的自动缩放规则或 Kubernetes 生态系统中的开放策略代理之类的东西。由于有如此多的项目向左转移到开发团队，找到合适的资源、技能或机构知识来编写这些规则可能需要多个团队的投入。由于“代码即事物”的兴起，无论这些规则的作者是软件工程师、DevOps 工程师、平台工程师还是介于两者之间的任何人，该作者都有能力强制执行。

05 向左移动…但复杂性也向左移动

复杂性就像一个算盘：你可以改变复杂性，但它永远不会真正消失。随着将责任转移给开发团队，这也意味着相关的复杂性也正在转移到开发团队。

现代平台工程团队为团队提供基础设施（如兼容的 Kubernetes 集群），在这些集群上运行的任何工作负载都取决于拥有它的开发团队。通常，开发团队更专注于特性和功能，管理大量非功能性需求——甚至是网络等核心基础设施需求——对于开发团队可能是一种负担。

如果你是 DevOps 或平台工程师，那么让你的内部客户（你的开发团队）取得成功是一个伟大的目标。对此至关重要的是传播专业知识。这可以是自动化和教育的形式。DevSecOps 运动的一个常见做法是将某种扫描步骤作为构建或部署过程的一部分，就扫描的执行方式、如果发现了什么会发生什么等方面传播内部。获得内部采用是一个在清晰和稳定的基础上建立良好的开发者体验非常重要。

---

2022年的演变

尽管去年给我们带来了所有挑战、颠簸和学习，但技术仍在不断发展和进步，甚至降低了进入门槛，不断变得更具包容性。专注于提高工程效率和减少劳动将允许更多的参与并降低进入门槛。

点击此处即可免费领取DevOps资料~

原文：https://devops.com/the-next-evolutions-of-devops/