DevOps

menu icon

DevOps

DevOps 通过结合并自动执行软件开发和 IT 运营团队的工作,以更快速度交付更高质量的软件。

什么是 DevOps?

根据定义,DevOps 概述了软件开发流程和组织文化转变,通过自动执行并集成传统上各自为政的开发和 IT 运营团队的工作,以更快速度交付更高质量的软件。

在实践中,最出色的 DevOps 流程和文化能够扩展到开发和运营职能之外,将来自所有应用利益相关方 (包括平台和基础架构工程、安全、合规、治理、风险管理、业务线,最终用户和客户)的输入整合到 软件开发生命周期中。

DevOps 代表了过去 20 年软件交付周期发展的最新成果,从每几个月甚至几年的巨型应用代码发布,发展为迭代式的小型功能,或者每天或每天多次频繁发布的功能更新。

最终,DevOps 可满足软件用户对于频繁的创新型新功能以及不间断的性能和可用性的不断增长的需求。

如何实现 DevOps

直到 2000 年之前,大多数软件都是使用瀑布式方法开发和更新的,这是大规模开发项目的线性方法。 软件开发团队可能需要花费数月时间,开发会影响大部分或所有应用的体量巨大的新代码。 由于这些变更非常广泛,因此他们还需要花费数月时间将这些新代码集成到代码库中。

其次,质量保证 (QA)、安全和运营团队仍需要花费数月时间来测试代码。 因此,前后软件发行版之间的间隔时间以及发行版之间的几个重大补丁或错误修订之间的时间间隔达到数月甚至数年。 通常,这种“大爆炸”式的功能交付方法的特点包括:具有复杂而充满风险的部署计划;难以安排与上游和下游系统的联动;以及 IT“祈祷”在发行版正式投入生产环境之前的几个月中,业务需求不会发生巨大变化。

为了加快开发速度和提高质量,开发团队开始采用敏捷软件开发方法,这些方法是迭代式而非线性的,重点是对应用代码库进行更小但更频繁的更新。 这些方法的主要例子包括持续集成 持续交付 (CI/CD)。 采用 CI/CD 方法时,小型新代码块每一两个星期合并到代码库中,然后自动集成、测试和准备,以部署到生产环境。 敏捷将“大爆炸”的方法演变成一系列“更小的代码块”,这样还有助于隔离风险。

这些敏捷开发实践越有效地加速软件开发和交付,就越暴露出孤岛式的 IT 运营 (包括系统供应、配置、验收测试、管理、监控) 成为软件交付生命周期中的下一个瓶颈。

DevOps 源自于敏捷方法。 它添加了新的流程和工具,将 CI/CD 的持续迭代和自动化扩展到软件交付生命周期的其余部分。 它在流程中的每一步都实现了开发和运营之间的密切协作。

DevOps 如何工作: DevOps 生命周期

显示 DevOps 生命周期路径的图表

图 1: DevOps 生命周期

DevOps 生命周期(以线性方式描述时,也称为持续交付管道)是一系列迭代式、自动化的开发流程(也称工作流程),在更大的自动化和迭代式的开发生命周期内执行,旨在优化高质量软件的快速交付。 工作流程的名称和数量因人而异,但通常可归结为以下六类:

  • 规划(或构思):在这个工作流程中,团队会根据划分了优先级的最终用户反馈和案例研究,以及来自所有内部利益相关方的输入,确定下一发行版中新功能和特性的范围。 规划阶段的目标是通过生成在交付后可实现预期成果和价值的功能的待办工作列表,最大程度地提高产品的业务价值。
  • 开发:这是编程步骤,开发人员根据待办工作列表中的用户情景和工作项,测试、编码和构建新功能和增强功能。 常用的实践组合包括测试驱动的开发 (TDD)、配对编程和同级代码评审等。 开发人员通常使用本地工作站来执行代码编写和测试的“内部循环”,然后再将代码发送到持续交付管道。
  • 集成(或构建,或持续集成和持续交付 (CI/CD)):如上所述,在这个工作流程中,新代码集成到现有代码库中,然后测试并打包到可执行文件中以进行部署。 常见的自动化活动包括将代码变更合并到“主”副本中,从源代码存储库中检出代码,自动执行编译、单元测试然后打包为可执行文件。 最佳实践是将 CI 阶段的输出存储在二进制存储库中,用于下一阶段。
  • 部署(通常称为持续部署):(来自集成的)运行时构建输出部署到运行时环境 - 这通常是执行运行时测试的开发环境,用于验证质量、合规性和安全性。 如果发现错误或缺陷,开发人员有机会在任何最终用户看到问题之前拦截并修补任何问题。 通常存在开发、测试和生产环境,每个环境都需要逐步“严格”的质量关口。 部署到生产环境的最佳实践通常是首先部署到最终用户的子集,然后在产品趋于稳定后最终向所有用户部署。
  • 运营:如果将功能交付到生产环境描述为“第 1 天”,那么功能在生产环境中运行就可称为“第 2 天”。 监控功能的性能、行为和可用性可确保功能为最终用户增添价值。 运营确保功能平稳运行,并且服务中没有中断 - 也就是确保网络、存储、平台、计算和安全态势都正常! 如果出错,运营可确保发现事件,提醒适当的人员,确定问题,并应用修复措施。
  • 学习(有时称为持续反馈):收集来自最终用户和客户对特性、功能、性能和业务价值的反馈,根据这些反馈,规划下一个发行版中的增强和功能。 这还包括来自运营活动的任何学习和待办工作项,旨在帮助开发人员主动避免将来再次发生过去的任何事件。 这就是规划阶段的“总结”,我们“不断改进”!

这些工作流程之间还有另外三个重要的持续工作流程:

持续测试:典型的 DevOps 生命周期包含集成和部署之间发生的一个单独的“测试”阶段。 而 DevOps 更进一步,可以在各个工作流程中执行测试的某些要素,例如在规划中执行行为驱动的开发;在开发中执行单元测试与合同测试;在集成中执行静态代码扫描、CVE 扫描和 linting;在部署中执行烟雾测试、渗透测试、配置测试;在运营中执行混沌测试、合规性测试;在学习中执行 A/B 测试。 测试是一种强大的风险和漏洞发现方法,为 IT 提供接受、缓解或补救风险的机会。

安全:虽然瀑布式方法和敏捷实施在交付或部署后添加了安全工作流程,但 DevOps 努力从一开始(规划)就整合安全工作流程(以确保能够以最低的代价尽早解决安全问题), 并且在整个开发周期中持续整合安全工作流程。 这种安全性方法称为左移(请参阅图 1 以便更轻松地理解这个概念)。 一些组织的左移工作不甚理想,这也导致了 DevSecOps 的兴起(见下文)。

合规性:合规性(治理和风险)也在开发生命周期的早期和整个过程中得到最有效的满足。 受监管行业通常必须强制性满足特定级别的可观察性、可跟踪性以及可访问性,以表明自己如何在运行时运营环境中交付和管理功能。 这需要在持续交付管道和运行时环境中规划、制定、测试和执行策略。 合规性措施的可审计性对于向第三方审计机构证明合规性而言极其重要。

DevOps 文化

人们普遍接受的一种看法是,如果没有对 DevOps 文化的承诺,DevOps 方法就不可能成功,这可以概括为软件开发的另一种组织和技术方法。

在组织层面,DevOps 需要所有软件交付利益相关方之间持续沟通、协作和分担责任, 这当然包括软件开发和 IT 运营团队,但安全、合规、监管、风险和业务线团队也责无旁贷; 只有所有团队同心协力,才能快速持续地进行创新,并从一开始就保证软件的高质量。

在大多数情况下,实现这一目标的最佳方法是分解这些孤岛结构,将其重组为跨职能的自主式 DevOps 团队, 自始至终(从规划阶段一直到反馈阶段)负责从事代码项目, 而不需要交接,也无需等待其他团队的审批。 在敏捷开发背景下,共担责任和协作是能够产生重大成果的共同产品重点的基石。

在技术层面, DevOps 需要承诺实现自动化,确保项目在工作流程之内和之间移动;并且需要承诺实现反馈衡量,使团队能够持续加快周期,提高软件质量和性能。

DevOps 工具: 构建 DevOps 工具链

DevOps 和 DevOps 文化需要各种工具以支持异步协作,无缝集成 DevOps 工作流程,以及尽可能自动执行整个 DevOps 生命周期。 DevOps 工具的类别包括:

  • 项目管理工具 - 使团队能够建立构成编码项目的用户情景(需求)的待办工作列表,将其分解为较小的任务,并跟踪任务直至完成。 许多工具支持敏捷项目管理实践,如开发人员引入 DevOps 的 Scrum、精益和 Kanban。 热门开源选项包括 GitHub Issues 和 Jira。
  • 协作式源代码存储库 - 进行版本控制的编码环境,允许多个开发人员对同一代码库开展工作。 代码存储库与 CI/CD、测试和安全工具集成,以便在代码落实到存储库后,可以自动移至下一步。 开源存储库包括 GiHub 和 GitLab。
  • CI/CD 管道 - 自动执行代码检出、构建、测试和部署的工具。 Jenkins 是这个类别中最受欢迎的开源工具; 许多以前的开源备选工具,如 CircleCI,现在仅提供商用版本。 作为持续部署 (CD) 工具,Spinnaker 在应用和基础架构之间充当代码层。 ArgoCD 是 Kubernetes 原生 CI/CD 的另一热门开源选择。
  • 测试自动化框架 - 这包括用于自动执行单元、合同、功能、性能、可用性、渗透和安全测试的软件工具、库和最佳实践。 这些最优秀的工具支持多种语言;有些使用人工智能 (AI) 自动重新配置测试以响应代码变更。 测试工具和框架的扩展范围很广! 热门开源测试自动化框架包括 Selenium、Appium、Katalon、Robot Framework 和 Serenity(以前名为 Thucydides)。
  • 配置管理(基础架构即代码)工具 - 这些工具支持 DevOps 工程师通过执行脚本来配置和供应完全版本控制并且完整记录的基础架构。 开源选项包括 Ansible (Red Hat)、Chef、Pupet 和 TerraformKubernetes 为容器化应用执行相同的功能(请参阅下面的“DevOps 和云原生开发”)。
  • 监控工具 - 这些工具帮助 DevOps 团队发现并解决系统问题; 他们还实时收集和分析数据,以揭示代码变更如何影响应用性能。 开源监控工具包括 Datadog、Nagios、Prometheus 和 Splunk。
  • 持续反馈工具 - 通过热图(记录用户在屏幕上的操作)、调查或自助式问题凭单收集用户反馈的工具。

DevOps 和云原生开发

云原生方法用于构建利用基础云计算技术的应用。 云原生的目标是在公有云、私有云和多云环境中实现一致和最优的应用开发、部署、管理和性能。

目前,云原生应用通常

  • 使用微服务构建 - 微服务是松散耦合并且可独立部署的组件,具有各自独立的技术栈,并通过 REST API、事件流或消息代理相互通信。
  • 部署在容器中 - 容器是包含运行应用所需的所有代码、运行时和操作系统依赖关系的可执行代码单元。(对于大多数组织而言,“容器”是 Docker 容器的同义词,但存在其他容器类型。)
  • 使用 Kubernetes 大规模运行;Kubernetes 是开源容器编排平台,用于调度和自动执行容器化应用的部署、管理和扩展。

在许多方面,云原生开发和 DevOps 是相辅相成的。

例如,开发和更新微服务, 也就是将小型代码单元以迭代方式交付到小型代码库, 就完美适合 DevOps 的快速发布和管理周期。 如果没有 DevOps 部署和运营,就难以应对微服务架构的复杂性。最近对开发人员和 IT 主管进行的一项 IBM 调研发现,78% 的当前微服务用户期望增加他们在架构方面投入的时间、资金和工作量,56% 的非用户可能在未来两年内采用微服务。 要探索这些受访者所述的微服务的某些具体优点和挑战,请使用以下交互式工具:

(来源: "企业中的微服务之 2021:切实的益处,值得承受挑战。

通过打包和永久固定所有操作系统依赖关系,容器支持快速的 CI/CD 和部署周期,因为所有集成、测试和部署都发生在同一环境中。 Ansible、Puppet 和 Chef 为非容器化应用执行持续配置任务,而 Kubernetes 编排为容器化应用执行相同的任务。

最主要的云计算供应商( 包括 AWS、Google、Microsoft Azure 和 IBM Cloud) 提供某种 DevOps 管道管理解决方案。

什么是 DevSecOps?

DevSecOps 是在整个 DevOps 生命周期中自始至终持续集成和自动执行安全性的 DevOps - 覆盖从规划到反馈再回到规划的整个过程。

另一种看待 DevSecOps 的方式就是 DevOps 从一开始就集成安全性。 但是,在采用 DevOps 的早期,存在两个主要的挑战,即使随着时间推移也无法克服:一个是将安全专业知识集成到跨职能团队(文化问题);另一个是将安全自动化实施到 DevOps 生命周期中(技术问题)。 安全性被视为“说不”的实践,在许多 DevOps 实践中成为成本不菲的瓶颈。

DevSecOps 是一种特殊的工作,从一开始就集成和自动实现安全性。 在 DevSecOps 中,安全是和开发和运营并列的“头等公民和利益相关方”,它将安全集成到开发流程,将安全作为一个产品重点。

观看“什么是 DevSecOps?”,以了解有关 DevSecOps 原则、优点和用例的更多信息:

DevOps 和站点可靠性工程 (SRE)

站点可靠性工程 (SRE) 使用软件工程方法,自动执行 IT 运营任务, 例如生产系统管理、变更管理、事件响应,甚至紧急响应; 这些任务原本都应该由系统管理员手动执行。 SRE 旨在将传统的系统管理员转变为工程师。

SRE 的最终目标与 DevOps 的目标相似,但更具体: SRE 旨在平衡企业对快速应用开发的期望,以及他们满足与客户和最终用户签订的服务级别协议 (SLA) 中规定的性能和可用性级别的需求。

站点可靠性工程师通过确定应用引起的可接受的运营风险级别 (这称为“误差预算”), 并且通过自动开展运营以满足所需级别,从而实现这种平衡。

在跨职能 DevOps 团队中,SRE 可以充当开发和运营之间的桥梁,为团队提供所需的指标和自动化,尽快通过 DevOps 管道推送代码变更和新功能,而不会违反组织 SLA 的条款。

了解有关站点可靠性工程的更多信息

DevOps 和 IBM Cloud

DevOps 要求业务、开发和运营利益相关方开展协作,以快速交付并运行可靠的软件。 使用 DevOps 工具和实践同时转变企业文化的组织为数字化转型奠定了强大的基础;随着自动化需求广泛覆盖业务和 IT 运营,使应用实现现代化

要实现更大程度的自动化,首先要从可衡量的小型成功项目起步,然后可针对其他流程和组织的其他部分扩大规模和进行优化。

通过与 IBM 合作,您可以访问基于 AI 的自动化能力,包括预先构建的工作流程,使每个 IT 服务流程更加智能化,使团队能够专注于最重要的 IT 问题并加速创新。

采取下一步行动:

即刻开始使用 IBM Cloud 帐户

IBM Cloud Pak for Watson AIOps 使用机器学习和自然语言理解,实时关联运营工具链中的结构化和非结构化数据,以探寻隐藏的洞察,帮助更快确定根本原因。 无需使用多个仪表板,Watson AIOps 可以将洞察和建议直接反馈到团队工作流程,从而加快了事件解决速度。

关于作者

Andrea C. Crawford 是 IBM 杰出工程师,在传统和现代 DevOps 方面拥有丰富的专业知识。 她热衷于帮助客户通过实现人员、流程和工具现代化,转变应用交付模式。 Andrea 喜欢探索比较冷门的技艺,比如园艺和骑摩托车。

https://twitter.com/acmthinks(链接位于 IBM 外部)

https://medium.com/@acmThinks(链接位于 IBM 外部)