DevOps究竟是如何改变开发和运维人员的？

DevOps一种思想和文化的转变，结合自动化的理念，正在重新定义开发和运维人员的合作方式。

DevOps不仅仅只是字面上的开发和运维融合，多年以来，这两个群体一直被文化和知识界限所分开，尤其是在大型企业IT组织内部。

这种分开很直接，开发者只关心编码，运维人员则确保其正常运行。他们之间完全脱节，导致需要更长的QA周期。并且经常不能在环境上部署新程序，因为这样可能会导致宕机或者破坏其它程序。

这种组织划分，风险规避，顺序进行以及“瀑布式”软件交付模式的组合，会让软件更新的时间达到一年甚至更长时间。这种组合，至今仍然在许多大型组织中存在。

然而，在过去十年中，一些重大变革正在重塑IT领域。开发人员受够了部署代码时出现的诸多问题，开始编写自动化部署的软件。同时，运维人员也贡献他们的深厚专业知识去帮助开发人员更好的编写这类软件。

开发和运维之间曾经明确的界限正在慢慢变得模糊，从而导致应用程序的上线速度越来越快，QA周期越来越短，部署也越来越多。甚至我们结合了新的流程，比如使用持续集成和持续部署的方式。许多使用DevOps方法构建的大型应用程序，每天都会多次部署到生产环境中，而不是每年多次。

这不是一时的潮流，这种自动化的趋势，是在过去十年逐渐发展，并且在软件和流程方面都已经非常成熟。它对IT内部开发人员的意义是每个管理者需要认真考虑的。

如果你不理解DevOps为什么如此重要，并且没有做好准备去应对DevOps所带来的改变，那么这对你的公司会非常不利。

DevOps如何影响开发人员？

DevOps的起源可以一直追溯到诸如Puppet这样的工具刚诞生时，这些工具早在2005年左右就已经出现了。当时作为Ruby的开发人员Luke Kanies厌倦了手动配置Linux和手动修改配置文件。他梦想以一种更加编程并且可重复的方式，去配置类Unix系统。所以，他专门写了一个Ruby的脚本，帮他实现了以上过程，他将之命名为Puppet。

后来，出现了许多类似的工具，包括Chef，Ansible，SaltStack等。此外，社区将这些工具进行了组合。开发人员和运维专家将他们的部署代码打包上传，这样可以让你以类似的方式配置软件，而不需要考虑底层的Unix发行版。

使用这些工具，开发人员可以创建一个关于如何运行应用程序的自包含的程序化环境。它将包含应用程序所需的所有依赖项，并且只需运行一个脚本，就可以在各种Unix发行版上配置和启动它们。过去需要高技能专业人士数周才能设置和调整好的环境，现在在脚本的帮助下，可能几个小时就能完成。

虽然，开发人员现在可以比从前更快、更容易的部署代码。开发人员不再依赖于运维同事，开始自己负责维护自己运行的应用程序。

这也促进了另一种工具的发展，平台即服务，或简称PaaS。PaaS最初由Salesforce和Google设想，它要求开发人员编写一种可以将应用程序放到其平台上的特殊代码。但是，在HeroKu向开发人员展示这种运行代码的方法之前，PaaS并没有普及。

PaaS系统建立在DevOps自动化原则的基础之上。实际上，到目前为止，许多的PaaS系统都是通过DevOps工具来设置和运行它们。PaaS和应用程序的区别在于，使用PaaS，可以充分的管理运行在其中的应用程序。你可以通过API启动、关闭、扩展以及监控PaaS中的应用程序。在DevOps中，你可以创建一个工具集来管理你的应用程序，但是在PaaS中，这些工具是早就为你准备好。

最后，讨论DevOps就不得不提及docker和容器，PaaS最大的缺点就是它严格预定义了应用程序的架构。如果开发者想要更好的控制程序的环境，那么容器可以提供很好的速度和灵活性给用户。使用Chef或者Puppet花费几个小时部署的环境，最终可能也不能获取一个完全一致的副本。而使用容器，开发人员可以在很短的时间内，重现部署的Linux或者Windows环境，并确保它是一个完全一致的副本。

多年来，开发人员通过使用并且改进这些DevOps工具，已经创造出了巨大的生产力。随着运行应用程序的操作逐渐变成全自动的计算机代码。开发人员省去部署的日子即将到来。

DevOps如何影响运维人员？

尽管开发人员已经开始了DevOps革命，但是，系统管理员和运维专家才是其最终采用的关键。毕竟，这些工具也可以帮助他们提高工作效率。实际上，DevOps工具已经明显的改变了现代敏捷运维团队负责的工作范围。

在DevOps之前，系统管理员和运维团队负责保证各个应用程序的正常运行。包括设置数据库和web服务器，设置负载均衡，管理安全性以及换成系统等等。

DevOps实现了高标准化，仅需几个工具，就可以替代人工干预，使用有效的方式来部署、配置和运行许多的服务。

越来越多的情况是，运维人员负责部署和维护DevOps这种自动化的服务。例如：PaaS、Linux和Windows容器集群。开发人员只需要将各个应用程序部署到这种服务中，然后运维团队负责运行和扩展这类服务。DevOps平台和工具创建了一种环境，它允许开发和运维团队彼此独立工作。

随着DevOps的诞生，开发人员可以拥有配额，在一定的范围内，他们可以按照需求，实时部署环境。运维团队不再需要关心部署单个的应用程序。他们仍然采购硬件，并且配置和管理服务器，但是规模远远大于单个的应用程序。他们的责任：管理开发人员更容易使用的自动化DevOps服务。

这种技术环境将应用程序的生命周期分开，使开发人员和运维人员能够更紧密的协同工作。让开发人员在明确的系统中部署代码，而让运维团队管理该系统，则会确保开发人员有单独的职责。

但是开发人员和运维团队之间的联系者，DevOps工具已经成为一个责任模糊的协作生态系统。运维团队需要对运行和维护复杂软件系统，有深入的了解。开发人员则需要在没有运维人员的帮助下，部署程序到系统中。

越来越多的企业，开始招聘具有运维经验的程序员以及具有编程经验的系统管理员。总的来说，DevOps对运维团队的影响最大，他们越来越多地负责起运行应用程序的系统，这将为开发人员提供更自动化的按需部署选择。

DevOps，一种良性的循环

正如马克·安德森的名言“软件正在改变世界”，对于建立和运行应用程序来说，就像打电话和住进酒店一样。运行应用程序的任务一直是训练有素的系统管理员负责的，但是现在devops已经逐渐成为主流。

大多说知识都是无证的，并且像民间传说一样口头传承，代代相传。配置文件都有自己的独特格式，有些格式非常奇怪，以至于还会有编译成其他配置文件的配置文件。究竟如何以及为什么配置这些文件的技术，只有少数人知道。

DevOps已经变成一种将所有深奥的运维知识记录到开放标准中的方法，这些标准可以随时记录和跟踪。随着开发人员拥有更多的运维知识，系统管理员拥有更多的编程知识，他们的责任最终会融合。

Docker是领先的容器管理平台，也是这种发展的另一个例子。Github为开发人员提供了一个开放的环境，可以相互之间分享代码，并且比以前更容易协作。Docker Hub则正在为系统管理员创造相同类型的环境，引领着基础设施部署和管理的新复兴。

DevOps将会一直持续发展，并且总会有一个新工具，一个不同的框架以及一个很酷的趋势为它注入新鲜强劲的活力。正如它为软件开发带来持续集成和持续交付一样，它也为运维人员带来可编程基础架构。

原文链接：

https://www.infoworld.com/article/3230285/devops/how-devops-changes-dev-and-ops.html