原创

基于DevOps平台构建自己博客:4-DevOps入门介绍

温馨提示:
本文最后更新于 2022年11月15日,已超过 490 天没有更新。若文章内的图片失效(无法正常加载),请留言反馈或直接联系我

什么是DevOps?

DevOps 是一种软件开发方式,开发人员和运维人员协同合作,灵活、快速地开发软件。DevOps 通过将人员、方法和工具联系起来,消除了开发和运维团队之间的孤岛。这种方法可以加速应用程序和服务的开发。此外,通过加快对IT基础设施管理的响应,可以在应对当前瞬息万变的市场的同时引入和更新IT产品。

DevOps 的目的是弥合为应用程序创建代码的软件开发 (Dev) 和运行应用程序并将其提供给最终用户进行维护的 IT 操作 (Ops) 之间的差距。它从敏捷开发和精益制造方法演变而来. 敏捷开发是一种提高 IT 开发组织响应能力的技术,它专注于将工作分解成小块并在较短的时间间隔内重复它们。精益制造是一种减少浪费和最大化工厂生产力的方法。

DevOps 集成并简化了以前孤立的软件开发、质量保证和 IT 运营团队。

DevOps 消除了与敏捷开发相关的瓶颈。在敏捷开发中,开发人员经常创建新软件和更新代码。然而,传统的运维团队发现很难快速测试并将软件投入生产,失去了高速开发的真正价值。然而,虽然敏捷开发的流行增加了软件设计和构建的可重复性和灵活性,但它并没有成为跨越软件开发生命周期(SDLC)的方法。

DevOps 是一种文化或哲学方法,强调持续开发、协作和透明度。DevOps 对 IT 运维的看法是全面且以价值为导向的。我们的目标不是专注于单个业务孤岛,而是通过查看从创意到提供产品和功能的整个流程,并优化其间的一切,从而快速获得更大的业务价值。当 DevOps 运行良好时,它不仅可以加快编码迭代和部署,还可以缩短新想法的上市时间、减少错误并提高基础设施的稳定性。

DevOps:开发和运维

敏捷软件开发的开端是2001年17位开发者发表的简短的一句话《敏捷软件开发宣言》 。该宣言提出了四项基本原则:

  • 与个人对话,而不是流程和工具。

  • 比综合文档更好的软件。

  • 与客户合作而不是合同谈判。

  • 响应变化而不是遵循计划。

传统的瀑布式开发涉及严格的排序和文档、角色、工具和流程的严格定义以及开发。另一方面,即使开发团队开始实践敏捷开发以加速软件产品迭代并敏捷响应需求等不断变化的情况下,IT运维团队也并不总是准备好跟上这种新的速度。

2008年,比利时的 Patrick Debois 和美国的 Andrew Clay Shafer 开始讨论将“敏捷”引入IT基础设施的挑战。一年后,Debois在比利时根特首演了“Dev Ops Days”活动。自此事件以来,“DevOps”一词便用于IT领域。

DevOps 的以下三个基本原则首先由DevOps 支持者 Gene Kim 编写。参考:The Three Ways: The Principles Underpinning DevOps

  • 系统思考:更全面的 IT 方法。从开发人员到测试人员、基础设施经理、代码和软件用户,我们关注整个系统的性能,而不是单个孤岛的性能,例如运维和部门。

  • 反馈循环增强: Kim 指出,“大多数过程改进活动的目的是缩短和增强反馈循环,以便可以持续进行必要的修改”

  • 持续试验和学习:敏捷软件开发宣言强调响应和协作,而 DevOps 的重点是持续改进:发现更好的新方法。Kim说,有必要创造一种“鼓励不断尝试、冒险和从失败中学习的文化,并理解重复和实践对于成熟至关重要”。

DevOps 文化基于来自不同学科的团队成员,他们不断构建和部署新功能和服务。在 DevOps,开发人员负责维护他们编写的代码。通过这样做,您不仅能够有效地解决事件,而且在开发任何东西时也将关注可靠性。DevOps 团队还将专注于整个产品生命周期,而不是专注于创建新功能或设计新 Web 组件等单个项目。此产品原则(有时称为“产品而不是项目”)具有使 IT 与业务价值保持一致的效果。通过优先考虑对业务和最终用户有贡献的运营,我们促进传播和使用,培养客户忠诚度并增加利润。这就是你通过实践 DevOps 可以获得的效果。

DevOps和敏捷的区别

DevOps 将软件开发的敏捷原则扩展到软件部署。敏捷软件开发宣言的转变旨在改进软件的开发方式,而 DevOps 将敏捷开发扩展到版本,并在整个软件开发生命周期中应用类似的原则。换句话说,范围的不同就是敏捷和 DevOps 的不同。

DevOps的持续发展

持续开发包含持续集成和持续交付 (CI/CD) 以及持续实施的 DevOps 概念。与其每年(或更少)批量发布大型版本,不如频繁地进行、发布和评估小改进,以便 IT 团队可以不断改进他们的产品和服务。在市场上,创新型初创企业压倒整个市场的情况并不少见,更别说是顶级企业了。无论是来自 Netflix 或 Instagram 等基于软件的公司的核心产品,还是改进您的网站或 IT 服务,DevOps 的持续发展让您在这些市场中保持竞争力。

DevOps中的持续集成

DevOps 中的持续集成是一种在每个任务之后将新代码合并到主源代码中的技术。当您将新代码提交到中央共享存储库时,它将自动在那里构建以测试和验证您的更改。这样,您可以快速发现问题,为开发人员提供即时反馈,并让他们立即着手进行所需的更改。

DevOps中的持续交付

DevOps 中的持续交付是一种以集成方式测试新代码的方法,利用了持续集成的速度。持续交付会自动测试和暂存新代码,使其为部署做好准备。

这个过程包括单元测试、集成测试、功能测试和回归测试,视情况而定。一旦代码获得批准,它将自动进行部署。但是,持续的软件交付并没有自动部署检查的代码。它将持续进行。

DevOps中的持续部署

通过持续集成和持续交付集成和批准新代码然后自动发布它的过程是 DevOps 中的持续部署。一旦在自动化交付过程中通过测试的代码被分阶段并发布到生产环境中,最终用户就可以使用新功能。

持续部署是有风险的,因为在代码从开发人员到达最终用户之前没有人工干预。基本上,持续部署是针对低风险产品和功能的。由于敏感数据处理、高安全风险、监管义务和重大财务风险,DevOps 实践很少是持续部署。尽管有这些考虑,但持续部署通常被认为是 DevOps 的关键目标之一,因为它可以加速并最大限度地缩短价值实现时间。

持续交付和持续部署通常缩写为“CD”,并且经常被混淆。但是,持续交付是指交付已准备好发布的软件。而持续部署(或手动部署)将新软件置于最终用户的生产环境中。持续交付中的交付物通常是我们的可部署软件,在目前的行业实践中,大多为docker镜像。持续部署则是将持续交付中的软件部署到指定环境,这里的环境可以是生产环境,也可以是测试环境。通常CD是镜像+目标环境。

DevOps架构:云、虚拟化等

DevOps 架构通常是指有助于实现 DevOps 文化目标的基础设施。DevOps 没有特定的架构,因此 IT 组织在部署 DevOps 时不必丢弃现有的架构。但是,您的 DevOps 组织架构有一些关键原则和最佳实践。

随着 DevOps 的出现和云平台的同时出现,云和其他虚拟化技术对 DevOps 的成功做出了重大贡献。支持 DevOps 并帮助组织部署和实践 DevOps 的常用技术包括云平台、虚拟化和微服务。

  • :云平台允许您在虚拟环境(云)而不是本地配置资源,为用户提供快速和极大的灵活性(请参阅下面的“云在 DevOps 中的作用”)。

  • 虚拟化:在虚拟化出现之前,服务器都是真实世界的硬件,如果你需要第二台服务器,你必须购买真实的东西。虚拟化允许您创建虚拟服务器(或虚拟桌面等),因此软件团队可以在现有的本地或云服务器上创建虚拟环境,而不是安排另一块硬件。所以对于想要敏捷工作的团队来说,这个大瓶颈已经被消除了。自动配置还减少了开发人员在几分钟内访问所需资源的时间。

  • 微服务:微服务的架构由数量有限的松散耦合的功能单元组成,它们共同构成了整个系统。对于大型系统和应用程序,如果它们由这些单一功能、可重用的模块组成,则更容易构建和修改。借助这些独立组件,DevOps 从业者可以部署更新,对其依赖项的影响较小,从而使他们能够更快地移动,同时降低更改失败的风险。在 DevOps 书籍DevOps:  A Software Architect's Perspective 中,作者 Len Bass、Ingo Weber 和 Liming Zhu 说:“微服务的架构风格是 DevOps 的开端。它旨在解决许多问题。”

DevOps 组织的架构使用云、虚拟化和微服务。我们还旨在优化测试自动化、监控和安全措施,以支持 DevOps 工作流程。一般来说,自动化是 DevOps 中的一个关键因素,并且有一种趋势是推动自动化以及云优先。这些趋势和最佳实践塑造了您的 DevOps 组织的架构。

云在DevOps中的作用

云计算对于 DevOps 文化至关重要。云的速度、规模和效率为实践 DevOps 的团队带来了敏捷性,以提高他们的工作速度和质量。软件即服务 (SaaS) 工具为软件团队提供了效率和经济性。SaaS 软件本身就是一个需要 DevOps 方法的持续迭代产品开发的例子。

您不必将所有应用程序都放在云中,但如果您正在部署 DevOps,那么考虑新应用程序的云优先是有意义的。在规划新的应用程序或服务时,请考虑“是否有理由不将其放在云中?”而不是“应该放在云中吗?” 在某些情况下,可能存在某些情况,例如云安全、监管需求或整个基础架构。但是在实践 DevOps 时,云应该是默认的,而不是一个考虑因素。

什么是DevSecOps?

DevSecOps 是一个包含安全措施的 DevOps 流程。每个人都对安全负责,而不是在流程结束时将代码传递给另一个安全团队。DevSecOps 可快速提供安全软件,同时防止在最后阶段发现缺陷以及由此产生的返工。

总的来说,DevSecOps 的三个基本原则是:

  • 从开发过程开始就引入安全措施。

  • 将安全视为一项重要的开发责任,而不仅仅是团队问题。

  • 自动化您的安全流程,以保持 DevOps 的高效流程。

2012年发布的DevSecOps宣言详细定义了DevSecOps的原则。

 

DevOps最佳实践

DevOps 文化核心的最佳实践描述了一种协作、灵活、高效、敏捷并专注于实现最终价值的方法。然而,将这一广泛的理念付诸行动并没有一套规则或最佳实践。DevOps 最佳实践和价值观因行业而异。软件开发人员的需求也因行业而异,包括零售、制造、医疗保健和金融服务。

 

DevOps 的最初倡导者 Damon Edwards 和 John Willis 开始使用缩写 CAMS,它代表关键开发原则。CAMS 代表文化、自动化、测量和共享。

此外,DASA(DevOps 敏捷技能协会)公布了 DevOps 的六项原则。大纲如下:

  • 以客户为中心的活动:一个简短的反馈循环,用于理解和接受客户的观点。

  • 目标意识创建:与其严格定义每个人的角色,不如鼓励整个组织思考如何为组织内外的客户创建 IT 产品。

  • 端到端责任: DevOps 消除了这些孤岛,而不是让每个人只对自己的角色负责(开发人员不参与基础设施故障,运营团队不负责代码故障)。我们的目标是达到目的以及整个团队的责任。

  • 跨职能自治团队:需要建立拥有所有技能和职责的团队,通过改进周期涵盖每个 IT 产品的发明、提供和处置过程。

  • 持续改进:实践 DevOps 的团队始终致力于提高速度、质量和消除浪费。

  • 将所有可以自动化的东西自动化:为了提高业务的速度、效率和有效性,尽可能利用 IT 自动化至关重要。这样做可以为团队成员提供更多空间来从事更有价值的任务并减少人为错误。

开发运维工具

DevOps 工具可帮助您开发、测试、管理您的基础架构并实施 DevOps 原则。DevOps 本质上代表了一种创建和交付软件产品的文化(请参阅下面的“如何部署”),但是自动化工具等产品对于实现这种文化的发展至关重要。

有许多工具声称易于部署 DevOps,包括用于源代码控制、配置和发布控制以及监控的工具。

最好的DevOps工具是什么?

最好的 DevOps 工具是用于塑造 DevOps 文化的流程和人员的工具。如果您购买和部署产品,DevOps 并不是您可以说“已引入 DevOps”的东西。DevOps 技术专家 Alex Honor在 DevOps 诞生后不久发表了一篇文章: People Over Process Over Tools

也就是说,有许多知名产品支持 DevOps 操作。专注于突出的工具,开源和专有工具都在下面列出。

  • 源代码控制:Git(GitLab、GitHub)、Bitbucket
  • 构成管理:Puppet、Chef、Ansible、CFEngine
  • 发布管理:Jenkins、Travis、CircleCl、TeamCity、Gradle、Bamboo
  • 编排:Mesos、Zookeeper、Kubernetes
  • 监控、虚拟化、容器化:Nagios、Igignia、Monit、OpenStack、Vagrant、AWS、Docker、Kubernetes
  • 日志和应用程序生命周期分析:Kibana、filebeats、Elasticsearch。

如何实施DevOps?

要实施 DevOps,首先要考虑您当前的文化。通过揭示阻碍快速开发、部署、反馈和持续迭代的孤岛和瓶颈,了解需要改进的地方。

Splunk 的顶级技术倡导者 Andi Mann就 DevOps 的实施提出建议:“DevOps 的路径应该基于每个组织的独特性,但它是成功的重要指标。一定要按住路点。” 指导原则是摆脱混乱并消除瓶颈,接受(和学习)失败,评估和不断发展。

在领先的 DevOps 软件制造商 Puppet 和 Splunk 的《2019 年 DevOps 现状报告》中,DevOps 实践的发展过程分为五个阶段,按照 CAMS 模型(文化、自动化、评估、共享)进行。我正在评估它。该报告还揭示了对 DevOps 的采用和成功至关重要的五种基本实践。

  1. 监控和警报可以由运营服务的团队设置。
  2. 重用部署模式来构建应用程序和服务。
  3. 重用测试模式来构建应用程序和服务。
  4. 其他团队有助于改进一个团队提供的工具。
  5. 开发运维关键绩效指标

主要KPI如下:

  • 部署频率:目标是经常进行小型部署。
  • 安装失败的频率:旨在减少。
  • 每季度发布的功能数量:不一定要按季度发布,但似乎很多企业领导者经常会考虑按季度发布。
  • 平均检测时间 (MTTD):从发生异常到发现异常的时间。
  • 平均恢复时间 (MTTR):从发生错误到解决错误的时间。
  • 平均提前期 (MLT):请求代码然后实施所需的时间。
  • 正常运行时间:通过测量计划内维护停机时间和计划外停机时间来跟踪可用性。
  • 缺陷忽略率:将带入生产环境的缺陷数量与 QA 团队捕获的缺陷数量进行比较。
  • 应用程序性能:比较更改前后的应用程序性能。

一旦挑战明确并且如何评估进展,您就可以开始形成新的 DevOps 文化。首先,消除将开发人员、测试人员、运营团队和安全分析师分开的孤岛。邀请业务分析师参加会议。我们的目标是教育每个人,不仅要明确他们需要做什么,还要对整个软件创建和交付的速度和质量承担责任。随着流程和基础设施的变化,提供教育机会以促进协作。

并且重要的是要做好 DevOps 不能在半年或一年内实现的准备。用 DevOps 支持者 Jez Humble的话来说,“DevOps 不是一个目标,它是一个无止境和持续改进的过程。”

结论:DevOps 创造未来

DevOps 并不是一种时尚。它也超越了其中一种选择的水平。10多年来,“IT与业务结合”的理念得到了整个组织的认可,更不用说管理层了。更快地交付更好的 IT 的 DevOps 理念和相关方法已经确立。Netflix、LinkedIn、Facebook、亚马逊和谷歌等“独角兽”公司通过拥抱 DevOpss 文化取得了显著成功。即使在传统企业中,DevOps 也正在成为主流。 今天,每家公司都在努力提高对市场的响应能力。甚至公共机构也试图改善他们的服务。随着客户期望的提高和数据的爆炸式增长,IT 无法保持现状。DevOps 已成为最活跃的趋势。

正文到此结束
本文目录