社区译者：陈文峰
审校：韦世滴
原作者：Grace Barnott
(原文地址)：https://www.devopsonline.co.uk/the-top-10-devops-trends-of-2019-the-professionals-prediction/
流水线自动化
在可能且实用的地方建立自动化任务是整个 DevOps 的公认趋势。软件自动化管道的概念已经变得无处不在。例如，可以看到自从 GitHub 引入 GitHub 操作以来，持续集成和持续交付(CI/CD)工具的数量持续增长。
随着自动化的普及，“基础结构即代码”工具的不断兴起。Terraform、AWS Cloud Formation、Azure 资源管理器和 GCP 部署管理器等工具允许在开发过程、CI 管道甚至交付和生产过程中随意对环境进行拉起和删除。这些工具正在不断成熟。
Kubernetes
似乎在2019年，Kubernetes 无处不在。自2015年问世以来，尽管有 Mesos 和 Docker Swarm 等产品的竞争，这个非常受欢迎的容器编配器在 DevOps 社区中占据了最大的份额。像 RedHat 和 VMWare 这样的主要软件供应商都全力支持 Kubernetes。越来越多的软件供应商也在 Kubernetes 上默认交付他们的应用程序。
Kubernetes 的使用仍在增长。虽然该平台还没有证明自己适合所有类型的工作负载，但它背后的动力似乎足够强大，可以支持它一段时间。
服务网格化
关于实施 Kubernetes 的讨论越来越多地与关于服务网格化的讨论结合在一起。“服务网格化”是一个松散的术语，它涵盖了在一个平台中处理服务到服务通信的任何软件。
服务网格化可以处理许多标准应用程序任务，这些任务是应用程序团队传统上必须在自己的代码和设置中解决的，比如负载平衡、加密、身份验证、授权和代理。使这些特性可配置并成为应用程序平台的一部分，可以解放开发团队，使他们能够改进代码，而不是在分布式应用程序环境中改进服务管理的标准模式。
可观察性
DevOps 中的另一个趋势是讨论应用程序中的可观察性。可观察性常常与监控相混淆，但它们是两个截然不同的概念。理解这种差异的一个好方法是将监控看作活动，将可观察性看作系统的属性。可观察性是一个来自现实工程和控制理论的概念。当一个系统的内部状态可以很容易地从它的输出中推断出来时，我们就说这个系统具有可观察性。这在实践中意味着很容易从应用程序的内部状态表示中推断出在任何给定时间发生了什么。随着应用程序在本质上变得更加分布式，确定它的某些部分失败的原因(从而影响整个系统)变得更加困难。
这就是相关的基数概念(指系统存储的时间序列数据的离散项数)出现的地方。通常，基数越高，系统就越有可能被观察到，因为在尝试排除故障时，您需要查看更多的数据片段。当然，收集的数据仍然需要与系统的潜在故障点相关，并且仍然需要一个心理地图来有效地排除故障。
DevSecOps
虽然 DevOps 组合词已经成为 IT 讨论的标准部分有一段时间了，但其他新词也开始崭露头角。DevSecOps 就是其中之一。随着团队的目标是从一开始就将安全性“融入”到他们的管道中，而不是在开发完成后才试图将其固定下来，这个概念正在获得越来越多的关注。因此，安全性越来越成为 DevOps、SRE 和开发团队的责任;因此，工具如雨后春笋般出现，帮助他们解决这个问题。
诸如 InSpec 之类的“法规遵从性”工具已变得越来越流行，因为自动化连续安全性成为组织在同时跟踪众多应用程序，服务器和环境的压力下屈服的优先事项。
随着应用的激增，容器镜像和其他伪像的自动扫描也已成为常态。Aqua 和 SysDig 等产品在持续的安全领域中争夺市场份额。
您可能还会听到提及 DevSecNetQAGovOps，因为越来越多的应用程序生命周期都在努力使自己成为自动化管道的一部分。 但是，DevSecOps 仍然是对目前较经典的 DevOps 配对方式的一种重现。
SRE 的兴起
网站可靠性工程（Site Reliability Engineering）是一门源于 Google 的工程学科（2003年甚至还没有创造出 DevOps 这个词之前），在同名的《网站可靠性工程》中进行了详细描述。Google 放弃了对运行中应用程序的支持和维护的传统方法，因此将运营人员的水平提高到了相当于其工程职能的水平。在此范例中，SRE 工程师的任务是确保实时问题得到监控和解决，有时通过编写新软件来提高可靠性。此外，开发团队还将就结构和返工的可靠性和稳定性提出反馈。 SRE 在 Google 的运营范围内运作，由于基础架构的规模，SRE 可能需要在开发和运营之间进行划分（通常是 DevOps 的反模式）。当平台庞大且需要跨数百个数据中心进行标准化时，很难实现一个团队负责从开发到生产的整个应用程序（更传统的 DevOps 方法）。 与2019年的“DevOps Engineers”相比，DevOps 公司招聘“SRE 工程师”的频率更高。这可能是因为认识到 SRE 所具有的特定工程重点，而非 DevOps 在整个公司范围内。
人工智能
人们越来越多地猜测人工智能（特别是机器学习）在辅助或扩展 DevOps 实践中所起的作用。尽管诸如 Science Logi 的 S1 之类的产品仍处于应用初期，但它们开始进入市场并获得吸引力。 这些产品使用机器学习来基于先前观察到的或规范的行为来检测应用程序中的异常行为。
除了传统的监控活动外，AI 还可用于优化测试用例，确定在每个构建中要运行还是不运行。这样可以减少将应用程序投入生产所需的时间，而不会冒系统稳定性的不必要风险。
从理论上讲，谷歌已经发布了有关使用机器学习算法来预测硬件故障的信息。 随着机器学习变得越来越主流，期望有更多此类产品进入 DevOps 领域。
无服务器化
自2014年 AWS 推出 AWS Lambda 以来，Serverless 一直是个流行语。此后，随着其他提供商和产品的加入，事情一直在升温。
“无服务器计算”一词可能令人困惑，部分原因是服务器仍需要在某种程度上参与其中。本质上，它描述了一种情况，其中应用程序的部署者不必关心代码的运行位置。 所谓“无服务器”是指开发人员无需处理服务器。 通常，无服务器应用程序与其底层计算平台紧密结合，因此您需要确保适应这种级别的锁定。
CI/CD 中的“左移右移”
今年，CI/CD 中的“向左移动”和“较小程度向右移动”的概念越来越受到关注。随着发布周期变得越来越小，“向左移动”意味着通过在发布周期的较早版本中使构建失败而提高效率—不仅是通过标准应用程序测试，而且还有代码检验，QA/ 安全检查以及任何其他可以发出警报的检查 开发人员应尽可能早地解决他们的代码问题。
“右移”测试在生产（或类似生产）环境中进行。 它旨在在引发监控或用户问题之前将问题暴露在生产中。
总结
这些只是我们在2019年 DevOps 世界的混乱中所观察到的较值得注意的趋势中的一部分。缩写词“CALMS”(文化、自动化、精益、度量、共享)是构建 DevOps 工具和技术思想的一种很有帮助的方式，从2019年到2020年，本文中的10个 DevOps 趋势无疑是这些原则的例证!
