上周，我和一些非常资深的同事们专门讨论了一下现在到底新出了多少DevOps工具，日常追随这些工具为什么变得越来越麻烦，以及整个领域内它们到底处在什么位置。因此，我问了一下他们这几个工具——Ansible、Terraform、Salt、Chef、Bamboo、CloudFormation它们所处的位置，为什么要用他们来和其他工具对比？它们是在做同一件事吗？我是不是错过了一个更重要的工具？然而，我得到了同样茫然的目光。所以，我在想我应该做一些研究，试着让大家都明白它的意义，这样我们就可以把产品分成我们都熟悉的类别或应用场景。

开始讨论DevOps工具和类别之前，我们先了解一下DevOps的常见术语以及含义。

计算机/服务器（Computer/Server）——一种具有中央处理器（CPU）、内存（RAM）以及本地存储（磁盘）并运行操作系统的物理设备。

虚拟机（Virtual Machine）——在主机上运行的一种仿真计算机系统；通常会在CPU、内存和磁盘方面与其他操作系统隔离。

容器（Container）——一种带有软件包及其所有依赖项的包，以便它可以在任何基础架构上一致地运行。最受欢迎的容器目前是Docker。使你可以打包一堆东西（开发好的软件、配置和其他软件）以便于部署和迁移。你可以将容器视为虚拟机时代的下一代演化。

网络设备（Network Device）——在设备之间路由网络流量的一种硬件。如路由器、负载均衡器和防火墙。

软件（Software）——编写好并在操作系统上运行的代码。

DevOps——传统上是说，有人开发（Development），并有另一些人运维（Operations）。两者就像经营一家商店的模式一样。从2010年开始，到2018年左右，DevOps的理念已近普及，DevOps的理念是“一套最佳实践，旨在减少向系统提交变更和将变更投入正常生产之间的时间，同时确保高质量。”

当你在思考如何构建和运行一套非比寻常的系统时，肯定需要考虑很多。如：

获取计算机/服务器硬件

配置计算机/服务器硬件（操作系统，网络等）

监控计算机/服务器硬件

获取网络设备（负载均衡器，防火墙，路由器等）

DevOps以前，我们通常有4个不同的团队多这些事：

开发人员——他们一般负责#7、#8，有时也会做#10

QA团队——他们一般负责#9，有时也会做#11

系统管理员——他们一般负责#1、#2、#3、#12

网络管理员——他们一般负责#4、#5、#6

对于硬件，网络设备和软件的配置，每个团队可能都会用他们自己的脚本和工具集，且在许多情况下，还会手动进行“软件发布”的操作。

对我而言，随着DevOps的出现，最关键的是能够打破不同团队间的障碍，让每个人都成为“一个团队”的一部分，这能使所有系统的配置、部署和管理方式保持一致。

云（Cloud）——要定义作为IT史上负载体量最庞大的术语是很难的，但我非常欣赏T恤上写的“世上本无云，它只是别人的计算机。” 最初，云服务刚开始时，它们实际上只是其他人的计算机（或运行在他们计算机上的VM），或存储。随着时间的推移，它们已经发展出许多增值服务。大部分硬件都被抽象掉了。现如今，你无法在大多数云服务中购买硬件设备，但你可以购买由硬件设备提供的服务。

Code）——一个新概念，可以让我们通过配置文件来定义数据中心内所有项目的完整设置，包括VM，容器和网络设备。我们可以创建一些配置和脚本，然后使用CI/CD工具运行它们，它们在数据中心中自动提供所有服务。CI/CD作为IAC的前身，多年来一直致力于构建/测试/集成/部署的自动化，而使用云基础架构则是对它的自然扩展。这也降低了成本，加快了投产上市的时间，减少了人为操作风险。

随着IAC的出现，许多传统的开发工具现在都可以用来管理基础架构。DevOps工程师现在可以使用以下工具，如软件代码仓库（Software Repository），构建工具，CI/CD，代码分析器和测试工具，来构建和维护基础架构。之前这些工具都是软件开发人员所使用的。

“随着DevOps的出现，对我来说最关键的想法是……让每个人都成为‘一个团队’的一部分，使所有系统的配置、部署和管理方式保持一致。”

我们已经掌握了基本术语，现在，让我们回到对DevOps工具进行分类的任务，以使我们更容易理解：在什么时候使用什么工具。

软件代码仓库（Software Repository）——用于软件版本管理的工具。Git是当今使用最广泛的工具。

构建工具（Build tools）——一些软件打包或使用前需要先进行编译，传统的构建工具包括Make、Ant、Maven和MSBuild。

持续集成工具（Continuous Integration tools）——每次将代码提交仓库时，它都会触发构建，部署和软件测试。从而可以提高代码质量和缩短投产时间。市场上最受欢迎的工具有Jenkins，Travis，TeamCity和Bamboo。

代码分析器/审查工具（Code analyzer/review tools）——这些工具负责查找代码中的错误、代码格式和质量，以及测试覆盖率。这些因语言的不同而不同。SonarQube是这个领域的一个比较流行的工具。

配置管理（Configuration management）——配置管理工具和数据库通常存储有关硬件和软件的所有信息，并为自动化常规任务提供脚本和/或模板。这个领域似乎有很多参与者，常见的工具有：Chef、Puppet和 Salt。

部署工具（Deployment tools）——这些工具负责软件的部署，许多CI工具也可作为CD（持续部署）工具。通常，在Ruby中，Capistrano被广泛使用；Maven在Java中使用的比较多。所有的编排工具（Orchestration tools）也能支持某些部署。

tools）——这些工具可配置，协调和管理IT系统和软件。它们通常将“自动化”和“工作流”作为其服务的一部分。Kubernetes是一款非常流行的编排工具，其专注于容器。Terraform也是一款非常流行的编排工具，它的应用范围更加广泛，包括云编排。此外，每个云提供商都有一套自己的工具，如CloudFormation，GCP Deployment

监控工具（Monitoring tools）——这些工具用来监控硬件和软件。通过监控应用程序和日志等，以确保系统的正常运行。Nagios和Prometheus都是比较流行的监控工具。

测试工具（Testing tools）——测试工具用于管理测试以及测试自动化，其包括性能和负载测试。

当然，就像其他产品一样，类别之间的界限并不一定是清晰的。许多工具跨类别并提供两个或更多类别的特性。下面是我试图向大家展示当下比较流行的工具，并将其归类在相应的位置。

正如你所见，像Ansible、Terraform和云工具（AWS、GCP和Azure）这样的厂商正试图将他们的产品跨越在部署、配置管理和编排的类别中。较老的工具集，如Puppet、Chef和SaltStack则更专注于配置管理和自动化，但也已经扩展到编排和部署。还有一些工具，如GitLab和Azure DevOps，则试图跨越几乎所有DevOps的类别。

希望本文的概述能帮助您理解DevOps的基础知识、现有工具的种类，以及当今市场上的各种产品是如何帮助实现其中一个或多个类别。多年来，在Solution Street我们已经使用了许多这样的工具，对我们来说，没有哪一个工具可以适合任何场景。到底选择哪一种取决于所选的技术、托管的位置(以及未来可能的位置)以及团队的能力和组成。

欢迎进入架构师智库，做有来领导力的架构师

做为一名DevOps人士，或者您正在成为一名DevOps人士，不管是工程师、产品经理、领导还是任何其他角色的相关人员。本文中即将谈的的软件都应该在你的电脑上存在，废话不多说，即使是你不编写代码，也应该对这些程序混个脸熟才对。

本文的目标是开启DevOps的第一个阶段- Level 1 个人级别的DevOps，除了要具备DevOps的思想之外，还要按照DevOps的原则和工具处理自己的工作。分享各种工具的效用和体验也是改进，不仅自己可以收益，还可以为DevOps的下个级别-团队级别的DevOps做好准备。

本文描述的软件不区分操作系统类型，所谈到的工具一般都支持Win，MacOS，Linux等平台。注意本文提到的工具，不是说建议安装，而是建议全部安装和正常使用。

有时在云中使用DevOps的IT专家会犯一些错误，而这些错误只是可以避免的。问题在于，最好的措施还没有被很好地理解。Liza Kosh在本文中介绍了在云中应用或运行DevOps时应遵守的一些做法。

云被确定为提供自动化测试工具和扩展服务，以适应可能对应用程序产生某些影响的可能变更。开发DevOps是为了简化应用程序过程，以便可以根据适当的应用程序生产尾部来映射用户需求。

不恰当地，有时在云中使用DevOps的IT专家会犯下他们可以避免的错误。问题在于，最好的措施还没有被很好地理解。这两个领域都是相对较新的领域，但是这个问题可能与个人有关，而与技术无关，而且人的问题有时令人望而生畏。

在IT部门的细微差别方面有才华的人基本上不会理解DevOps的准确功能及其在技术领域的影响。云计算的历史已被世界上一些顶级DevOps证明了一些非常有趣的观点。

为了成功地帮助您解决此问题，让我们分解一些实践，以在云中应用或运行DevOps时遵守这些实践。

安全标准是常见的，可以在云中以一致的方式进行更改。通常，人们可以吸收不同种类的技术，例如与身份相关的安全模型，以提高云中的真实性。

但是，安全性还需要扩展到公司和单个DevOps设备，这将推动增强型云的发展。从长远来看，这可以保持每次结构程序的安全。

云部署中的应用程序性能问题自然是错误的应用程序设计的结果。许多这些性能问题被忽略了，最终进入生产阶段，客户最终对其进行了搜索，但这并不算好。性能测试是至关重要的参数，DevOps领域应该永远不要忽视它。扩展团队应该接受自动回归测试，将其视为通用用法，并且最好将其范围设置为测试优先策略，例如测试驱动开发（TDD）和行为驱动开发（BDD）。这样可以确保功能团队在被允许投入生产之前获得足够质量的解决方案。摆脱手动测试可提高交付速度，测试准确性和质量，从而大大减少了费用。

容器为您提供了补充的灵活性，可以在自治的基础上转移应用程序的元素。您可以在中间阶段熟练地监视和安排您的应用程序，以练习这些自治容器。将容器纳入DevOps程序将使增长程序更加可控。尽管容器不能应用于任何应用程序，但是一些应用程序需要不断增长的组合应用程序核心。确认您的应用程序要求以及该策略的标准。

4.云原生应用程序提供最佳服务

认真练习您的云讲台和基础架构，并选择设计不必依赖任何实物资本的应用程序。了解所有应用程序的增长和整体增长水平以及它们在云中的原始资源所包含的有效性。概率是，您可以将整体展示方式提高70％，这又可以节省协会资金，因为您的资源将得到更好的组织，从而使您的协会可以定期收取财务节省。

如果未正确调节，则在大气中承受的过程可能会导致程序阻塞。如果发生这种情况，则当您看到几个流程变得难以监控时，只有缺乏治理才能观察。为了避免这种情况，您必须创建一种管理安排，以证明有组织且有层次的工作流程；这可以通过在足够的时间之前准备好治理基础结构来轻松实现。它包括有助于加强，检测和监视内部设施的特性和操作。

在寻找合适的DevOps工具时，您需要非常精确。当您根据需要进行更改时，应选择特定于业务的云。您偏爱的云工具应满足您业务的确切要求。

7.DevOps在云转型中不应资金不足

为了使云中的DevOps为您提供可预测的成本节省，您必须在至少头两年的时间里充分利用资本。随着正常流程的进行，云和DevOps项目必须在此期间自力更生。这允许在云策略和技术中的DevOps验证其价值，并允许成员在将其转变为生产之前理解它们。

应将通过运行不断发展的技术而定位的艰巨任务视为机会，以表述如何最佳利用技术的概括。在申请前进行正确的培训将使您的商业广告更有价值。培训会议可帮助员工处理常见问题，并为在实施过程中可能发生的重大事件做好准备。如果得到正确的指导，则该设备可以成为将来支持的自治机构，这可能会减少故障并提高准确性。

为了获得包括基础设施即服务（IaaS）和平台即服务（PaaS）在内的云的全部好处，必须以与物理财产无关的方法创建应用程序。这在图片中引入了“可编程基础架构”或“基础架构即代码”一词。DevOps高度重视创建和维护具有程序化，自动化特征的重要基础架构元素的能力。

10.安全模型起着重要作用

直观地认识到，云中记录的安全模型与旧数据测量方法并不相似。这是需要特别考虑的，因为在讨论实施该系统时，安全是支柱。在将DevOps投放到环境中时，应确保每个执行阶段都能满足必需的安全性实践，应该安排自动化测试并将其纳入大气层的这些阶段。

通过将这十种实践应用于云中的DevOps，您将能够更熟练地吸收这两种实践，从而获得最大的成就。