【运维】什么是DevOps？

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

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

实际上&＃xff0c;最好的 DevOps 流程和文化超出了开发和运营的范围&＃xff0c;在软件开发生命周期中融入了所有应用程序利益相关者的建议 - 包括平台和基础架构工程、安全、合规、管制、风险管理、业务部门、最终用户和客户。

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

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

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

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

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

这些敏捷开发实践越能有效地加速软件开发和交付&＃xff0c;它们暴露的孤岛式 IT 运营就越多 - 系统置备、配置、验收测试、管理、监控&＃xff0c;而这将成为软件交付生命周期的下一个瓶颈。

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

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

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

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

安全&＃xff1a; 瀑布方法和敏捷实施是在交付或部署后“附加”安全工作流&＃xff0c;而 DevOps 力求从一开始&＃xff08;规划&＃xff09;就融入安全措施&＃xff0c;因为此时安全问题最容易解决&＃xff0c;且解决成本最低&＃xff0c;然后在开发周期的其余阶段持续实施安全措施。 这种安全性方法称为左移&＃xff08;请参阅图 1 以便更轻松地理解这个概念&＃xff09;。 一些组织的左移工作不甚理想&＃xff0c;这也导致了 DevSecOps 的兴起&＃xff08;见下文&＃xff09;。

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

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

在组织级别&＃xff0c; DevOps 要求所有软件交付利益相关者持续沟通、协作和共担责任&＃xff0c;包括软件开发和 IT 运营团队、安全、合规、管制、风险和业务部门团队&＃xff0c;从而实现快速持续创新&＃xff0c;并从一开始就确保软件质量。

在大多数情况下&＃xff0c;达到这一目的的最佳方法是打破孤岛&＃xff0c;重新组建跨职能的自主式 DevOps 团队&＃xff0c;他们能够从头到尾&＃xff08;从规划到反馈&＃xff09;处理代码项目&＃xff0c;而不必移交项目或等待其他团队的批准。 在敏捷开发背景下&＃xff0c;共担责任和协作是形成共同的产品关注点并能够产生重大成果的共同的基石。

在技术级别&＃xff0c; DevOps 需要致力于实施自动化&＃xff0c;使项目在工作流内部和工作流之间顺利推进&＃xff0c;同时重视反馈 和 措施 &＃xff0c;使团队能够持续加速周期&＃xff0c;提升软件质量和性能。

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

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

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

目前&＃xff0c;云原生应用通常

• 使用微服务构建 - 松散耦合并且可独立部署的组件&＃xff0c;具有各自独立的技术栈&＃xff0c;并通过 REST API、事件流或消息代理相互通信。
• 部署在容器中 - 可执行代码单元&＃xff0c;包含运行应用程序所需的全部编码、运行时和操作系统依赖项。 &＃xff08;对于大多数组织&＃xff0c;“容器”等同于 Docker 容器&＃xff0c; 但也存在其他容器类型。&＃xff09;
• 使用 Kubernetes 大规模运行&＃xff1b;Kubernetes 是开源容器编排平台&＃xff0c;用于调度和自动执行容器化应用的部署、管理和扩展。
  在许多方面&＃xff0c;云原生开发和 DevOps 是相辅相成的。

例如&＃xff0c;开发 和更新微服务&＃xff08;即&＃xff0c;将小代码单元迭代交付到小代码库&＃xff09;非常适合 DevOps 快速发布和管理周期。 如果没有 DevOps 部署和运营&＃xff0c;就难以应对微服务架构的复杂性。 IBM 最近对开发人员和 IT 主管进行的一项调查发现&＃xff0c;78&＃xff05; 的现有微服务用户希望增加他们投入到体系架构的时间、金钱和精力&＃xff0c;而 56&＃xff05; 的非用户很可能在未来两年内采用微服务。

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

大多数领先的云服务提供商&＃xff08;包括 AWS、Google、Microsoft Azure 和 IBM Cloud&＃xff09;都提供某种形式的托管 DevOps 管道解决方案。

DevSecOps 是一种 DevOps&＃xff0c;它在整个 DevOps 生命周期持续集成和自动化安全功能 - 从头到尾、从规划到反馈再回到规划。

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

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

站点可靠性工程 (SRE) 利用软件工程技术自动执行 IT 运营任务&＃xff0c;例如&＃xff0c;生产系统管理、变更管理、事件响应&＃xff0c;甚至应急响应。如果没有 SRE&＃xff0c;这些任务则需要系统管理员手动智行。 SRE 旨在将传统的系统管理员转变为工程师。

SRE 的最终目标类似于 DevOps 的目标&＃xff0c;但更具体一些&＃xff1a;SRE 旨在平衡组织对快速应用开发的需求和达到与客户和最终用户的服务级别协议 (SLA) 中规定的性能和可用性级别。

站点可靠性工程师实现这一平衡的方法是确定应用程序引起的操作风险的可接受水平&＃xff08;称为“错误预算”&＃xff09;和自动执行操作以达到该水平。

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