专家们权衡了 DevOps 团队最近会有何期望。

“DevOps” 一词通常认为是来源于 这篇 2008 年关于敏捷基础设施和运营的讲演中。现在的 IT 词汇中，它无处不在，这个“混搭”的词汇出现还不到 10 年：我们还在研究它在 IT 中更现代化的工作方法。

诚然，多年来一直在 “从事 DevOps” 的人积累了丰富的知识。但是大多数的 DevOps 环境 —— 人与 文化 、流程与方法、工具与技术的融合 —— 还远远没有成熟。

更多的变化即将到来。Robert Reeves 说 “DevOps 是一个过程，一种算法”，他是 Datical 的 CTO， “它的绝对目标就是随着时间进行改变和演进”，这就是重点。

那我们预计接下来会发生什么呢？这里有一些专家们观察到的重要趋势。

1、 预计 DevOps、容器、以及微服务之间的相互依赖会增强

驱动 DevOps 发展的文化本身可能会演进。当然，DevOps 仍然将在根本上摧毁传统的 IT 孤岛和瓶颈，但这样做的理由可能会变得更加急迫。证据 A & B： 对容器和微服务的兴趣 与日俱增。这个技术组合很强大、可连续扩展、与规划和 持续进行的管理配合最佳。

Arvind Soni 说 “影响 DevOps 的其中一个主要因素是向微服务转变”，他是 Netsil 的产品副总裁，补充道，容器和业务流程，使开发者打包和交付的速度越来越快。DevOps 团队的任务可能是帮助去加速打包并管理越来越复杂的微服务弹性架构。

2、 预计 ”安全网“ 更少

DevOps 使团队可以更快更敏捷地去构建软件，部署速度也更快更频繁、同时还能提升软件质量和稳定性。但是好的 IT 领导通常都不会忽视管理风险，因此，早期大量的 DevOps 迭代都是使用了安全防护 —— 从后备的不重要业务开始的。为了实现更快的速度和敏捷性，越来越多的团队将抛弃他们的 ”辅助轮“（LCTT 译注：意思说减少了安全防护措施）。

Nic Grange 说 “随着团队的成熟，他们决定不再需要一些早期增加的安全 ‘防护栏’ 了”，他是 Retriever Communications 的 CTO。Grange 给出了一个阶段展示的服务器的示例：随着 DevOps 团队的成熟，他们决定不再需要阶段展示的服务器了，尤其是他们很少在试生产环境中发现问题。（Grange 指出，这一举措对于缺乏 DevOps 经验的团队来说，不可轻易效仿）

Grange 说 “这个团队可能在监视和发现并解决生产系统中出现的问题的能力上有足够的信心”，“部署过程和测试阶段，如果没有任何证据证明它的价值，那么它可能会把整个进度拖慢”。

3、 预计 DevOps 将在其它领域大面积展开

DevOps 将两个传统的 IT 部门（开发和运营）结合的更紧密。越来越多的公司看到了这种结合的好处，这种文化可能会传播开来。这种情况在一些组织中已经出现，在 “DevSecOps” 一词越来越多出现的情况下，它反映出了在软件开发周期中有意地、越来越早地包含了安全性。

Derek Weeks 说 “DevSecOps 不仅是一个工具，它是将安全思维更早地集成到开发实践中”，它是 Sonatype 的副总裁和 DevOps 拥挤者。

Red Hat 的安全策略师 Kirsten Newcomer 说，这种做法并不是一个技术挑战，而是一个文化挑战。

Newcomer 说 “从历史来看，安全团队都是从开发团队中分离出来的 —— 每个团队在它们不同的 IT 领域中形成了各自的专长” ，“它并不需要这种方法。每个关心安全性的企业也关心他们通过软件快速交付业务价值的能力，这些企业正在寻找方法，将安全放进应用程序的开发周期中。它们采用 DevSecOps 通过 CI/CD 流水线去集成安全实践、工具和自动化。为了做的更好，他们整合他们的团队 —— 将安全专家整合到应用程序开发团队中，参与到从设计到产品部署的全过程中。这种做法使双方都看到了价值 —— 每个团队都扩充了它们的技能和知识，使他们成为更有价值的技术专家。DevOps 做对了 —— 或者说是 DevSecOps —— 提升了 IT 安全性。”

除了安全以外，还可以让 DevOps 扩展到其它领域，比如数据库团队、QA，甚至是 IT 以外的潜在领域。

Datical 的 Reeves 说 “这是一件非常 DevOps 化的事情：发现相互掣肘的地方并解决它们”，“对于以前采用 DevOps 的企业来说，安全和数据库是他们面临的最大瓶颈。”

4、 预计 ROI 将会增加

Eric Schabell 说，“由于公司深入推进他们的 DevOps 工作，IT 团队在方法、流程、容器和微服务方面的投资将得到更多的回报。” 他是 Red Hat 的全球技术传播总监，Schabell 说 “‘圣杯’将移动的更快、完成的更多、并且变得更灵活。由于这些组件找到了更宽阔的天地，组织在应用程序中更有归属感时，结果就会出现。”

“每当新兴技术获得我们的关注时，任何事都有一个令人兴奋的学习曲线，但当认识到它应用很困难的时候，同时也会经历一个从兴奋到幻灭的低谷。最终，我们将开始看到从低谷中爬出来，并收获到应用 DevOps、容器、和微服务的好处。”

5、 预计成功的指标将持续演进

Mike Kail 说 “我相信 DevOps 文化的两个核心原则 —— 自动化和可衡量是从来不会变的”，它是 CYBRIC 的 CTO，也是 Yahoo 前 CIO。“总是有办法去自动化一个任务，或者提升一个已经自动化的解决方案，而随着时间的推移，重要的事情是测量可能的变化和扩展。这个成熟的过程是一个永不停步的旅行，而不是一个目的地或者已完成的任务。”

在 DevOps 的精神中，成熟和学习也与协作者和分享精神有关。Kail 认为，对于敏捷方法和 DevOps 文化来说，它仍然为时尚早，这意味着它们还有足够的增长空间。

Kail 说 “随着越来越多的成熟组织持续去测量可控指标，我相信（希望） —— 这些经验应该被广泛的分享，以便我们去学习并改善它们。”

作为 Red Hat 技术传播专家，Gordon Haff 最近注意到，组织使用业务成果相关的因素去改善他们的 DevOps 指标的工作越来越困难。 Haff 写道 “你或许并不真正关心你的开发者写了多少行代码、服务器是否在一夜之间出现了硬件故障、或者你的测试覆盖面是否全面”。事实上，你可能并不直接关心你的网站的响应速度和更新快慢。但是你要注意的是，这些指标可能与消费者放弃购物车或者转到你的竞争对手那里有关。”

与业务成果相关的一些 DevOps 指标的例子包括，消费者交易金额（作为消费者花销统计的指标）和净推荐值（消费者推荐公司产品和服务的意愿）。关于这个主题更多的内容，请查看这篇完整的文章—— DevOps 指标：你是否测量了重要的东西。

唯一不变的就是改变

顺利说一句，如果你希望这件事一蹴而就，那你就要倒霉了。

Reeves 说 “如果你认为今天发布非常快，那你就什么也没有看到”，“这就是为什么要让相关者包括数据库团队进入到 DevOps 中的重要原因。因为今天这两组人员的冲突会随着发布速度的提升而呈指数级增长。”