【.com快译】本文主要讨论：什么是DevOps？它与敏捷有何不同？流行的DevOps工具有哪些？Docker、Kubernetes和AzureDevOps在DevOps中能扮演什么角色？DevOps的重要指标和最佳实践。什么是DevOps？与围绕软件开发的许多流行语一样，DevOps没有达成一致的定义。有些人可以简单地用几个词来定义它，而另一些人则需要整本书才能完整而复杂地解释。以下是两个普遍接受的定义：AWS：DevOps是各种文化概念、实践和工具的结合，可以提高企业的适应能力，快速交付各种应用和服务。《DevOps概念和挑战调查》来自LLeite：DevOps是组织内的跨职能协作，以确保新软件版本自动且持续交付，同时确保正确性和可靠性。现在我们了解了DevOps的定义，让我们来看看软件开发是如何演变为DevOps的。瀑布（Waterfall）模型在软件开发的前几十年，大家主要关注的是瀑布模型。就像建造桥梁一样，瀑布模型通过多个阶段构建软件。这些阶段可以持续几周到几个月不等。如上图所示，大多数瀑布项目需要几个月的时间才能形成应用程序的工作版本。那么在瀑布模型几十年的发展过程中，我们总结出以下构建优秀软件的关键要素：沟通。反馈。自动化。首先，由于软件开发是一项涉及多种技能的跨职能任务，因此人与人之间的沟通对于软件项目的成功至关重要。虽然我们可以通过数千页与需求、设计、架构和部署相关的文档进行书面交流。但在实际项目中，我们还需要通过内部沟通赋能团队合作，通过各种技能的培养，实现跨职能团队之间的紧密协作（如上图所示）。其次，快速、及早地获得反馈远比等待数月才能获得最终结果重要得多。基于此，我们可以及时了解应用是否满足构建业务的预期，以及未来部署到生产环境时是否会出现问题。基于快速、及时的反馈，我们能够更早、更轻松地解决问题。第三，开发人员和部署人员都认识到手动执行操作速度慢且容易出错。因此，在软件开发和维护所涉及的各种活动中，我们需要引入下图所示的自动化方法。Agile的出现正是基于以上三个需求，业界也逐渐涌现出Agile的相关概念。它是指通过加强团队之间的沟通、及时获得反馈和引入自动化来实现它。通过敏捷方法，我们将业务和开发团队聚集在一起，致力于通过小迭代（通常称为冲刺）构建出色的软件。过去，我们在开发的每个阶段都花费数周甚至数月的时间，而敏捷更侧重于几天甚至一天内对整个开发周期的处理。我们将这些小需求称为用户故事（userstories），如下图所示。敏捷如何促进团队之间的沟通？如上所示，敏捷将业务和开发团队聚集在一起。业务代表（通常称为产品负责人）经常出现在团队中，以确保团队清楚地了解业务目标。也就是说，当开发团队对需求有误解时，产品负责人会帮助纠正，以确保整个团队最终交付的产品符合企业的业务目标。此外，敏捷团队的跨职能技能主要体现在：编码技能（包括：前端、API和数据库）、测试技能和业务技能。伟大的软件是通过人与人之间的交流以及在软件设计、编码、测试和打包方面的协作而构建的。敏捷与自动化我们经常会遇到一些软件产品存在先天缺陷，例如：产品本身存在技术缺陷，无法正常运行；或者存在难以维护和修复的代码质量问题。通常，敏捷团队希望通过专注于自动化来尽早发现并解决此类问题。通过自动化测试，敏捷团队可以用各种方法和类编写单元测试用例；他们可以为测试模块和应用程序编写集成测试用例。通过使用SONAR等工具，敏捷团队还可以评估应用程序的代码质量。如上图所示，提交版本控制、各种测试、代码质量检查都可以通过持续集成流水线实现自动化。在敏捷早期，最流行的CI/CD工具是Jenkins。敏捷如何促进即时反馈？如前所述，采用敏捷方法，公司不再需要等待数月才能看到最终产品，而是在每个冲刺结束时，可以向所有利益相关者展示目标产品的版本，包括软件架构师和业务团队。在为下一个冲刺确定用户故事的优先级后，可以处理所有反馈。以这种方式构建和交付的最终产品是企业真正想要的。敏捷方法带来的持续集成为即时反馈创造了有利条件。假设我们向版本控制系统提交一段代码，那么在30分钟内，如果这段代码会导致单元测试失败或者集成测试失败，我们可以得到及时的反馈；如果代码不符合代码质量标准，或者单元测试中代码覆盖率不够，那么我们也可以得到相应的反馈。微服务架构的演进随着开发模式的演进，微服务的架构开始出现。开发团队倾向于构建许多小型API而不是那些大型单体应用程序。与此同时，运营变得更加重要。如下图所示，我们可能需要每周发布数百个小微服务，而不是一个月后才发布单个应用。因此，调试微服务中的问题，了解微服务中发生了什么，也是非常重要的。DevOps的出现在软件开发和产品交付过程中，整个团队经常会遇到以下两个开发和运维团队之间的沟通问题：如何让部署更简单？我们如何让运营团队比开发团队更清楚地了解他们的工作？这时候，DevOps应运而生。在许多成熟的企业中，开发和运营团队往往是一个团队。他们有着相同的目标，也试图了解对方团队面临的各种挑战。因此，在DevOps的早期阶段，运维团队的代表可以直接参与Sprintstandups和retrospectives。除了敏捷的核心领域（例如：持续集成和测试自动化），DevOps团队还应致力于协助多个运维团队活动的自动化，例如：配置服务器、在服务器上配置软件、部署应用程序，以及监控生产环境。.在这里，我们会不时看到各种关键术语，包括：持续部署、持续交付和基础架构即代码。持续部署是在测试环境中持续部署软件的新版本。在谷歌、Facebook等成熟的组织中，为了不断将软件部署到生产环境，他们每天可能有数百次部署到生产环境。而基础设施即代码是将基础设施视为应用程序的代码。您可以通过配置以自动化方式创建服务器、负载平衡器和数据库等基础设施。此外，通过对基础设施进行版本控制，我们还可以跟踪基础设施随时间的变化。DevOps如何促进即时反馈？上面我们已经提到，运维团队和开发团队可以通过沟通协作共同处理以下问题：任何运维问题都会得到开发人员的及时关注。软件上线过程中的任何挑战都会提早引起运营团队的注意。然后通过采用DevOps方法，运维和开发团队可以通过持续集成、持续交付和基础架构即代码，在以下两个方面实现及时反馈：持续交付时，如果代码或配置发生变化，可能会破坏测试或暂存环境，然后我们将在几个小时内知道。通过“基础架构即代码”，开发人员可以配置他们的环境、部署代码并自行发现问题，而无需运维团队的任何帮助。事实上，您可能已经注意到敏捷和DevOps具有相似的目标，两者都包括：促进业务、开发和运营团队之间的沟通和反馈。通过自动化缓解痛点。事实上，在Netflix、Amazon和Google等创新型公司中，DevOps的故事每天都在发生：团队中的一名开发人员登录GitHub存储库，快速签出某个项目。快速创建本地环境并更改代码。对修改后的部分运行自动化单元测试并提交代码。代码已部署到QA模块的电子邮件。完成自动化集成测试后，QA团队根据需要进行手动测试并批准代码更新请求。新代码会在几分钟内导入到生产环境中。从字面上看，DevOps=开发+运维，是开发工具、框架和自动化的结合。DevOps主要关注人员、流程和产品。“人”是关于文化和建立良好心态的地方。也就是说，它是一种提倡开放式沟通、重视快速反馈、注重软件质量的文化。虽然上面的敏捷方法已经能够弥合业务团队和开发团队之间的沟通鸿沟。开发团队与业务团队合作，根据对业务优先级的理解提供有价值的“故事”。然而，开发和运营团队并不一致，并且有不同的目标：开发团队的目标是将尽可能多的新功能投入生产。运营团队的目标是尽可能保持生产环境稳定。可见，如果开发者和运营者不能保持一致，软件产品就很难投入生产。而DevOps正是为了使两个团队能够实现共同商定的目标而设计的。它使开发团队能够与运营团队协作，以了解和解决运营挑战。运营团队可以使用Scrum（译者注：一种迭代增量的软件开发过程，通常用于敏捷软件开发）来了解开发中涉及的各个功能。也就是说，在那些成熟的DevOps企业中，开发和运维属于同一个Scrum团队，彼此分担一部分责任。但是，如果您的企业处于DevOps的早期阶段，您如何让开发和运营共享共同的目标并“玩得开心”？一般来说，你可以尝试以下方法：可以让开发团队从一开始就分担运营团队的一些职责。例如，让开发团队负责在部署到生产后的第一周内发布新版本。这将有助于开发团队了解运营团队在推出新版本时面临的挑战，并共同寻找解决方案。您还可以让运营团队的代表参与Scrum站会和回顾等活动。DevOps用例上图展示了Kubernetes和Docker，两个简单的DevOps工作流，即：使用Terraform和AzureDevOps将Kubernetes集群的基础设施配置为代码。使用AzureDevOps持续部署微服务构建Docker镜像并将其部署到Kubernetes集群。让我们首先讨论：使用AzureDevOps和Jenkins进行DevOps持续部署。开发人员将代码提交到版本控制系统后，将立即执行以下步骤：单元测试。代码质量检查。集成测试。通过Maven、Gradle和Docker等工具打包应用程序，构建可部署版本的应用程序。应用程序的部署，即启用新应用程序或应用程序的新版本。向测试团队发送电子邮件以测试应用程序。一旦通过测试团队的批准，应用程序将被部署到下一个环境（NextEnvironment）。这就是持续部署。如果您要部署到生产环境，则称为持续交付。目前最流行的CI/CD工具是AzureDevOps和Jenkins。接下来，让我们看看使用Terraform将DevOps基础设施作为代码使用。谈到基础设施即代码(IaC)，您需要了解以下内容：基础设施团队可以专注于增值工作（而不是日常工作）。少犯错误并从失败中快速恢复。具有服务器的一致性，避免配置偏差（ConfigurationDrift）。上图展示了基础设施即代码的基本步骤，主要包括：通过模板配置服务器（或启用云服务）、安装软件、配置软件等。通常，配置工具用于准备和提供联网的新服务器能力。目前，最流行的基础设施即代码工具是Ansible和Terraform。使用Terraform，您可以配置服务器、负载均衡器、数据库和基础设施的其他部分，例如网络。您可以使用Packer和AmazonMachineImage(AMI)等工具为这些服务器创建预构建的映像。目前比较流行的配置管理工具有Chef、Puppet、Ansible、SaltStack，可以在现有服务器上安装和管理各种软件。Docker和Kubernetes在DevOps中的作用我们可以使用Java、Python和JavaScript构建各种微服务。对于不同的应用，不同的微服务也可能以不同的方式部署在服务器上。这些都给运营团队的工作带来了很大的困难。那么我们如何以类似的方式部署多种类型的应用程序呢？答案是：容器和Docker。如上图所示，使用Docker，你可以摆脱语言和基础设施的限制，用同样的方式构建和运行不同的微服务镜像。这大大简化了操作开销。同时作为补充，Kubernetes通过协调不同类型的容器来实现集群上的部署。如下图所示，Kubernetes还可以提供服务发现、负载均衡、集中配置等服务。可见Docker和Kubernetes可以让DevOps更容易实现。重要的DevOps指标以下是您需要随着时间的推移持续跟踪和改进的重要DevOps指标。部署频率——应用程序部署到生产环境的频率是多少？上市时间——从编码到生产大约需要多长时间？新版本的失败率——有多少版本失败了？修复时间——修复生产环境需要多长时间，发布到生产环境需要多长时间？平均恢复时间——从重大问题中恢复生产环境需要多长时间？DevOps良好实践简单来说，DevOps良好实践包括：具有跨职能技能的标准化团队关注团队文化那么我们如何衡量DevOps实施的成熟度呢？请参考以下重要方面：开发是否每次提交都会触发自动化测试和自动化代码质量检查？代码能否持续交付到生产中？你用过结对编程吗？是否使用了测试驱动开发（TDD）和行为驱动开发（BDD）？有很多可重用的模块吗？开发团队可以自己配置环境吗？快速修复生产环境需要多长时间？测试是否有可能使用高质量、类似生产的测试数据进行全自动测试？当自动化测试失败时，构建也会失败吗？测试周期短吗？是否有自动NFR测试？部署方法开发和生产是否对等？是否使用A/B测试？是否使用了金丝雀部署？是否可以一键部署？是否可以一键回滚？基础设施能否一键开通和发布？是否使用基础架构即代码和版本控制？监控团队是否使用集中监控系统？开发团队是否可以一键访问日志？如果生产出现问题，团队是否能够收到自动警报？团队和流程团队是否能够不断寻求改进？团队是否具备业务、开发和运营所需的所有技能？团队是否能够跟踪关键的DevOps指标并加以改进？是否存在接受本地发现(LocalDiscoveries)并将其用于全球改进(GlobalImprovements)的文化？过渡到DevOps的最佳实践最重要的是，领导者愿意“买账”并准备各种前期成本（UpfrontCosts）来设立专业知识中心（CenterofExpertise，COE），协助团队选择合适的应用程序，让团队从小事做起通过实时交流、Communication、COE等方式分享和学习探索和自动化的思维方式，鼓励团队真正认识DevOps团队彩蛋：免费知识拓展资料十步学习Docker-https://links.in28minutes.com/in28minutes-10steps-docker十步学习Kubernetes-https://links.in28minutes.com/in28minutes-10steps-k8s。通过十个步骤了解AWS-https://links.in28minutes.com/in28minutes-10steps-aws-beanstalk。【翻译稿件，合作网站转载请注明原译者和出处.com】
