Author Neil Meyer

人们之所以追逐技术，其中一个重要的原因是，技术在创造和促进数字趋势方面当之无愧的声誉，其中一些趋势与市场变化相一致，当然也有一些技术名过于实。例如应用交付方面的趋势——敏捷开发和云计算，都属于前者，为众多企业带来了巨大的收益。

最近在和一位“Big 4”咨询公司高级主管会面时，聊到了DevOps，他认为DevOps更像是品牌的重塑，是一种“fad”，而非真正的改变，毕竟有很多公司已经采用了自动化运维、内置回归测试和定期部署。

这让我想起了大家之前对于SaaS的讨论，有些人认为SaaS只是2000年代初的“应用程序服务提供”（ASP）的一种重新标签。没错，ASP和SaaS有一些相似之处：您根据共享资源提供服务并定价，每个买方只支付总成本的一小部分，成本更贴近实际使用，而不是需求高峰的价格。

然而，ASP模式实际上无法与现代SaaS产品相比较，无论是部署时间、相关定价，还是上限／下限的套期保值，都是ASP模式需要克服的巨大障碍。

DevOps会是昙花一现吗？

DevOps会是昙花一现吗？想要搞明白这个问题必须先搞明白DevOps是什么、不是什么？如果您通过团队使用的工具数量来定义DevOps，那么DevOps恐怕不会像宣传的那样具有变革性。

而如果您把DevOps理解为更广泛的交付及运维功能，那么它产生的变革和收益将会是更为巨大和深刻的。

DevOps文化是在应用的整个生命周期内促进高质量代码产出和交付。如果开发者只是在自己的“仓库”中工作，然后把代码扔给围栏外的运维团队就完事的话，贴再多的DevOps标签也是无济于事的。

DevOps在我们寻找现代化的持续迭代、更改、发布解决方案时，是有用的。当我们从本质上拥抱这样的解决方案，就会发现，DevOps带来的改变可以让我们更好的驾驭市场变化。

在发布流程不可预测且容易出错的情况下，业务的不确定性和业务/IT功能关系方面的挑战会变的令人紧张。在传统的开发和运维环境中，发布实时代码的ownership往往是孤立的，业务会像一个沮丧的服务买家一样坐在门外。

但是在敏捷的DevOps环境中，这种ownership将一直存在于交付工作代码中，而成功的产出也就意味着业务的价值。

当敏捷项目团队赋予业务所需的功能增强，DevOps便可以让开发人员定期交付高质量可预测的应用。在这一变化中，我们很可能会用到先进的DevOps工具、技术和平台，但更为重要的是，IT部门对于应用生命周期的思考——一个“共享”相同目标的团队。

市场的反应

想要验证市场实际情况和宣传是否一致，不妨看看企业在招聘新人才时说的话。我常常会关注招聘市场对于DevOps相关人才的需求，这对于了解市场变化很有用。

最初，只有一些很酷的创业公司会雇佣“DevOps工程师”，但现在，各种规模的企业都出现了DevOps方面的人才需求。这也说明，众多企业都在寻求节约成本和应用交付能力的增强，无论是自动化还是部署速度。

Beyond today

成功的DevOps实施，不仅仅是团队协作、自动化构建、交付质量的改变，更是一种文化上的转变，赋予应用生命周期中所有相关方提高交付效率、降低交付成本的能力。这样的价值观、流程和原则也就是DevOps的准确总结。

我认为DevOps就像云计算一样，不会是昙花一现的。当然了，两者都需要我们更好的理解、评估、实施，从而对企业产生真正有益的影响。