什么是 DevOps？

DevOps 是一种不断演变的理念和框架，倡导加快和优化应用程序开发过程，更快地向客户发布新的或经修订的软件功能或产品。

DevOps 实践鼓励应用程序开发团队 (Dev) 与 IT 运维团队 (Ops) 之间进行顺畅持续的沟通、协作、整合，同时保持可见性和透明度。

“Dev”和“Ops”之间的这种密切关系贯穿 DevOps 生命周期的每个阶段：从初始软件规划到编码、构建、测试和发布阶段，再到部署、运维和持续监控。这种关系推动了持续的客户反馈循环，包括进一步改进、开发、测试和部署。这些工作可实现的结果之一是更快、更持续地发布必要的功能变更或新功能。

有人将 DevOps 目标分为四类：文化、自动化、衡量和共享 (CAMS)，而 DevOps 工具恰好可以提供这些方面的帮助。这些工具可以使开发和运维工作流程更加精简、更具协作性，将集成、开发、测试、部署或监控中涉及的以往耗时、手动或静态的任务自动化。

DevOps 致力于打破开发团队和 IT 运维团队之间的沟通与协作障碍，其核心价值是让客户满意并更快地交付价值。DevOps 还旨在推动业务创新和持续流程改进。

DevOps 实践鼓励更快、更好、更安全地向组织的最终客户交付业务价值。这种价值的交付形式可以是更频繁的产品发布、功能或更新。这可能涉及产品发布或新功能上线的速度，所有这些都设有适当的质量和安全级别。或者可能侧重于识别问题或错误，然后解决并重新发布产品的速度。

底层基础架构还支持 DevOps，并在软件开发、测试和发布到生产环境时提供无缝的性能、可用性和可靠性。

组织可以使用几种常见的 DevOps 方法来加快和改进开发和产品发布。它们采用软件开发方法和实践的形式。其中最受欢迎的是 Scrum、Kanban 和 Agile：

• Scrum。Scrum 定义了团队成员应如何协同工作来加速开发和 QA 项目。Scrum 实践包括关键工作流程和特定术语（Sprint、时间盒、每日 Scrum [会议]），以及指定角色（Scrum Master、产品负责人）。
• Kanban。Kanban 起源于丰田工厂车间的一次效率提升活动。Kanban 规定了在 Kanban 板上跟踪的进行中 (WIP) 软件项目的状态。
• Agile。早期的敏捷软件开发方法仍在很大程度上影响着 DevOps 的实践和工具。包括 Scrum 和 Kanban 在内的许多 DevOps 方法都融入了敏捷编程的元素。一些敏捷实践涉及到更好地响应不断变化的需求和要求、将需求记录为用户案例、举行每日站会以及整合持续的客户反馈。Agile 还规定了更短的软件开发生命周期，而不是冗长的传统“瀑布式”开发方法。

DevOps 实践的追随者通常会在其 DevOps“工具链”中使用某些 DevOps 友好型工具。这些工具的目标是进一步简化、缩短和自动化软件交付工作流（或“管道”）的各个阶段。此外，许多此类工具还可在开发和运维团队之间推广自动化、协作和集成等核心 DevOps 原则。下面显示了 DevOps 生命周期各个阶段使用的工具示例。

• 规划。此阶段有助于定义业务价值和要求。示例工具包括 Jira 或 Git，可帮助跟踪已知问题和执行项目管理。
• 编码。此阶段涉及设计软件和创建软件代码。示例工具包括 GitHub、GitLab、Bitbucket 或 Stash。
• 构建。在此阶段，您可以管理软件的构建和版本，使用自动化工具帮助编译和打包代码以便将来投入生产。您可以使用源代码存储库或软件包存储库，这些存储库还可以“打包”产品发布所需的基础架构。示例工具包括 Docker、Ansible、Puppet、Chef、Gradle、Maven 或 JFrog Artifactory。
• 测试。此阶段需要持续测试（手动或自动）以确保最佳代码质量。示例工具包括 JUnit、Codeception、Selenium、Vagrant、TestNG 或 BlazeMeter。
• 部署。此阶段可以包括一些帮助管理、协调、计划和自动将产品发布到生产环境中的工具。示例工具包括 Puppet、Chef、Ansible、Jenkins、Kubernetes、OpenShift、OpenStack、Docker 或 Jira。
• 运维。此阶段涉及在生产过程中管理软件。示例工具包括 Ansible、Puppet、PowerShell、Chef、Salt 或 Otter。
• 监控。此阶段涉及识别和收集有关生产中特定软件发布的问题的信息。示例工具包括 New Relic、Datadog、Grafana、Wireshark、Splunk、Nagios 或 Slack。

DevOps 实践反映了持续改进和自动化的理念。许多实践侧重于一个或多个开发周期阶段。这些做法包括：

• 持续开发。该做法贯穿 DevOps 生命周期的规划和编码阶段。可能涉及版本控制机制。
• 持续测试。该做法包括在编写或更新应用程序代码时进行自动的、预先安排的、持续的代码测试。此类测试可以加快将代码交付到生产环境的速度。
• 持续集成 (CI)。该做法将配置管理 (CM) 工具与其他测试和开发工具结合在一起，以跟踪所开发的代码中有多少已准备好投入生产。它涉及在测试和开发之间快速提供反馈以快速识别和解决代码问题。
• 持续交付。该做法在测试后自动将代码更改交付到预生产或暂存环境。然后，员工可以决定将此类代码变更推广到生产环境中。
• 持续部署 (CD)。与持续交付类似，该做法可自动将新代码或更改后的代码发布到生产环境中。进行持续部署的公司每天可能会多次发布代码或功能更改。使用 Docker 和 Kubernetes 等容器技术有助于在不同部署平台和环境之间保持代码的一致性，从而实现持续部署。
• 持续监控。该做法包括持续监控运行中的代码以及支持该代码的底层基础架构。反馈回路可报告错误或问题，然后传回给开发人员。
• 基础架构即代码。该做法可用于 DevOps 的各个阶段，以自动配置软件发布所需的基础设施。开发人员可从现有开发工具中添加基础架构“代码”。例如，开发人员可以按需从 Docker、Kubernetes 或 OpenShift 创建存储卷。该做法还可以使运维团队能够监控环境配置、跟踪更改并简化配置回滚。

DevOps 支持者描述了数项业务和技术优势，其中许多优势致力于提高客户满意度。DevOps 的一些优势包括：

• 产品交付更快、更好
• 问题解决速度更快、复杂性更低
• 可扩展性和可用性更高
• 操作环境更稳定
• 资源利用率更高
• 自动化程度更高
• 系统运行结果可见性更高
• 创新能力更出色

许多用于简化软件开发和部署的 DevOps 方法早期都以敏捷软件开发和精益编程为基础。然而，DevOps 最初是由几项基层运动演变而来的，目的是协调开发团队及运维团队的活动。

21 世纪初，人们需要维持 Google 和 Flickr 等热门网站的可用性，以应对巨大的点击量。这种需求催生了软件可靠性工程师 (SRE)——运维人员与开发人员密切合作，确保在将代码发布到生产环境后网站仍能继续运行。

2009 年，Flickr 工程师 John Allspaw 和 Paul Hammond 在一次会议上介绍了他们自己开发的类似于 DevOps 的方法。他们的演讲题目为“每天 10+ 次部署： Flickr 的开发与运维合作”。同年，Patrick Debois 在比利时举办了第一个“DevOps 日”。随着越来越多的 DevOps 日在世界各地举行，#DevOps 话题标签出现并热度大增。

在接下来的几年里，业界见证了大量开源工具和框架的涌现，从而进一步推动了 DevOps 目标的实现。

NetApp 利用 DevOps 帮助促进取得更好的业务成果：运维团队可以用更少的工程设计来交付自动化基础架构，而开发人员可以在可靠和可预测的环境下进行创建，并且摩擦更少。利用 NetApp® 技术，您可以从容地提供组织所需的服务和功能，在内部环境和云环境中最大限度地提高开发人员的工作效率。

借助 NetApp，开发人员、测试、QA 和运维团队可以轻松地将基础架构资源（例如持久性存储卷）用作代码，所有这些都可以通过 DevOps 管道中的熟悉工具来实现。例如，NetApp 存储 API 以及 IAC 与 Puppet、Ansible、Docker、Kubernetes 和 OpenShift 等工具的集成。

但是，NetApp 技术不仅能让开发人员轻松地以代码的形式使用存储，还能让运维人员从容地配置资源并将其交付给开发和测试人员。然后，开发人员和测试人员可以通过自行配置快速、省时的存储功能（例如快照或克隆）来加快编码和测试周期。借助这些功能，只需几秒钟或几分钟即可将实时生产数据或代码集的副本配置为代码，从而加快开发和 QA 工作流。详细了解为什么 NetApp 是 DevOps 的理想之选。

为什么 NetApp 是 DevOps 的理想之选？

NetApp 对社区的贡献延伸到了 thePub。此开发人员社区鼓励协作、分享提示和技巧，并围绕最新的 DevOps 实践和协议展开讨论。