DevOps 模式定义
DevOps 集文化理念、实践和工具于一身,可以提高组织高速交付应用程序和服务的能力,与使用传统软件开发和基础设施管理流程相比,能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户,并在市场上更高效地参与竞争。
DevOps 的工作原理
在 DevOps 模式下,开发团队和运营团队都不再是“孤立”的团队。 有时,这两个团队会合为一个团队,他们的工程师会在应用程序的整个生命周期(从开发测试到部署再到运营)内相互协作,开发出一系列不限于单一职能的技能。
在一些 DevOps 模式下,质保和安全团队也会与开发和运营团队更紧密地结合在一起,贯穿应用程序的整个生命周期。当安全是所有 DevOps 团队成员的工作重心时,这有时被称为“DevSecOps”。
这些团队会使用实践经验自动执行之前手动操作的缓慢流程。他们使用能够帮助其快速可靠地操作和发展应用程序的技术体系和工具。这些工具还可以帮助工程师独立完成通常需要其他团队协作才能完成的任务(例如部署代码或预置基础设施),从而进一步提高团队的工作速度。
DevOps 的优势
速度
快速交付
可靠性
规模
增强合作
安全性
DevOps 为什么很重要
软件和 Internet 改变了我们身处的世界,同时也改变了购物、娱乐、银行等行业的运营方式。软件不再仅仅是为业务提供支持,而是成为业务的方方面面都不可或缺的组成部分。当前,公司通过采用在线服务或应用程序交付的软件,在各种设备上与客户进行互动。他们还使用软件改变了价值链的各个部分(例如物流、通信和运营),从而提高运营效率。在整个 20 世纪,生产实体产品的公司通过工业自动化改变了其设计、构建和交付产品的方式,而在当今的环境中,公司必须以同样的方式来改变其构建和交付软件的方式。
如何采用 DevOps 模式
DevOps 的文化理念
向 DevOps 的过渡需要文化理念和心态上的转变。简单来说,DevOps 的宗旨就是消除两个传统上孤立的团队(开发团队和运营团队)之间的壁垒。有些组织甚至没有独立的开发团队和运营团队,工程师可能身兼两职。利用 DevOps,这两个团队可以携手合作,共同提高开发人员的生产力,同时增强运营的可靠性。他们力求频繁沟通、提高效率,并改善客户服务的质量。他们能够完全掌控自己的服务,并且经常越过自己的既定角色或职能的传统工作范畴,思考最终用户的需求以及解决这些需求。 质保和安全团队也可以与这两个团队紧密协作。凡是采用 DevOps 模式的组织,无论组织结构如何,参与团队都会将整个开发和基础设施生命周期视为己任。
DevOps 实践说明
有一些重要的实践经验能够通过自动实施和简化软件开发与基础设施管理流程,帮助组织加快创新速度。这些实践经验有大部分需要通过适当的工具来完成。
其中一个基本实践经验就是要频繁地进行小规模更新。这是组织能为客户快速提供创新的有效方式。与传统发布实践中偶尔的更新相比,这种更新通常更具渐进性质。频繁的小规模更新能够降低每次部署的风险。它们可以帮助团队更快速地处理错误,因为团队能够确定引发错误的最近一次部署。虽然更新的节奏和规模可能有所不同,但使用 DevOps 模式的组织与使用传统软件部署实践的组织相比,会更频繁更新。
此外,组织还可以使用微服务架构来提升应用程序的灵活性,从而加快创新步伐。微服务架构将大型的复杂系统拆分为简单的独立项目。应用程序被拆分为许多单个组件(服务),每个服务限定到单个目的或功能,这些服务既可以与其同级服务相互独立运行,也可以与应用程序一起作为整体运行。这种架构降低了更新应用程序的协调开销,当每个服务都与掌控各项服务的敏捷小型团队一一对应时,组织就可以实现更快的发展。
但是,微服务与较高的发布频率相结合会导致部署量大幅度增加,可能会带来运营挑战。因此,持续集成和持续交付等 DevOps 实践经验有助于解决这些问题,让组织能够以安全可靠的方式快速交付。与基础设施即代码和配置管理一样,基础设施自动化实践经验也有助于维持计算资源的弹性和对频繁变更的适应性。此外,进行监控和记录这一实践经验可帮助工程师追踪应用程序和基础设施的性能,以便他们快速应对出现的问题。
综合采用上述实践经验,可以帮助组织向客户更快交付更可靠的更新。对重要 DevOps 实践经验的简要介绍如下。
DevOps 实践经验
持续集成
持续集成是一种软件开发实践经验,采用持续集成时,开发人员会定期将他们的代码变更合并到一个中央存储库中,之后系统会自动运行构建和测试操作。持续集成的主要目标是更快发现并解决错误,提高软件质量,并缩短验证和发布新软件更新所需的时间。
持续交付
持续交付是一种软件开发实践。通过持续交付,系统可以自动构建和测试代码更改,并为将其发布到生产环境做好准备。持续交付可以在构建阶段后将所有代码变更都部署到测试环境和/或生产环境中,从而实现对持续集成的扩展。当持续交付得以正确实施时,开发人员将始终能够获得一个已通过标准化测试流程的部署就绪型构建工件。
微服务
微服务架构是一种将单个应用程序构建为一系列小服务的设计方法。其中每个服务均按各自的流程运行,并利用一种轻型机制(通常为基于 HTTP 的应用程序编程接口 (API))通过一个明确定义的接口与其他服务进行通信。微服务围绕着业务能力进行构建,每项服务均限定到单个目的。您可以使用不同的框架或编程语言来编写微服务,并将其作为单个服务或一组服务进行独立部署。
详细了解 Amazon Container Service(Amazon ECS)
基础设施即代码
基础设施即代码是一种实践经验,其中基础设施通过代码和软件部署技术(例如版本控制和持续集成)得以预置和管理。借助云的 API 驱动型模式,开发人员和系统管理员能够以编程方式与基础设施进行大规模互动,而无需手动设置和配置资源。因此,工程师可以使用基于代码的工具来连接基础设施,并且能够以处理应用程序代码的方式来处理基础设施。基础设施和服务器由代码进行定义,因此可以使用标准化模式进行快速部署、使用最新补丁和版本进行更新,或者以可重复的方式进行复制。
了解如何使用 AWS CloudFormation 来管理基础设施即代码
配置管理
开发人员和系统管理员使用代码将操作系统和主机配置、操作性任务等自动化。代码的使用实现了配置变更的可重复性和标准化。它将开发人员和系统管理员从手动配置操作系统、系统应用程序或服务器软件的任务中解放出来。
了解如何通过 Amazon EC2 Systems Manager 配置和管理 Amazon EC2 和本地系统
策略即代码
由于基础设施及其配置全都通过云进行代码编写,所以组织可以动态地大规模监控与实现合规性。因此,组织可以自动跟踪、验证和重新配置由代码描述的基础设施。这样一来,组织能够更加轻松地掌控资源变更,并确保安全措施以分布式方式得到妥善执行(例如,采用 PCI-DSS 或 HIPAA 确保信息安全性或合规性)。这使组织内部的团队能够更快速地运作,因为不合规的资源可能被自动标记为需要进一步调查,甚至被自动纠正为合规资源。
了解如何使用 AWS Config 和 Config Rules 来监控并实现基础设施的合规性
监控和日志记录
组织对各项指标和日志进行监控,以了解应用程序和基础设施性能如何影响其产品的最终用户体验。通过对应用程序和基础设施生成的数据进行采集、分类和分析,组织可以了解变更或更新如何影响用户,同时深入了解出现问题或意外变故的根本原因。由于服务必须全天候持续可用,而且应用程序和基础设施的更新频率不断提高,因此主动监控变得日益重要。此外,创建警报或对这些数据执行实时分析也能帮助组织更主动地监控其服务。
了解如何使用 Amazon CloudWatch 来监控基础设施指标和日志
了解如何使用 AWS CloudTrail 以日志方式记录 AWS API 调用
沟通与合作
增强组织内部的沟通与合作是 DevOps 文化的一个重要方面。DevOps 工具的使用和软件交付流程的自动化能够以物理方式将开发和运行的工作流程及职责结合起来,从而建立团队之间的相互协作。在此基础上,这些团队树立了强大的文化规范,提倡信息共享和通过聊天应用程序、问题或项目追踪系统以及 Wikis 来促进沟通。这有助于加快开发人员、运营团队甚至其他团队(如营销团队或销售团队)之间的沟通,从而使组织的各个部门围绕共同的目标和项目更紧密地结合在一起。