自从 DevOps 成为 IT 界的常用术语以来,发生了很多事情。由于生态系统的很大一部分是开源的,因此回顾它为何开始以及它对 IT 职业生涯的意义非常重要。
什么是 DevOps?
虽然没有统一的定义,但我认为 DevOps 是一个流程框架,它确保开发和运维团队之间的协作,以便以可重复和自动化的方式更快地将代码部署到生产环境中。我们将在本文的剩余部分解读这一说法。
“DevOps”一词是“开发”和“运维”两个词的组合。DevOps 有助于提高交付应用程序和服务的速度。它使组织能够高效地为客户服务,并在市场上更具竞争力。简而言之,DevOps 是开发和 IT 运维之间在更好的沟通和协作方面的对齐。
DevOps 假定一种文化,即开发、运维和业务团队之间的协作被认为是旅程的关键方面。它不仅仅关乎工具,因为组织中的 DevOps 为客户创造持续的价值。工具是其支柱之一,与人员和流程并驾齐驱。DevOps 提高了组织以快速的速度交付高质量解决方案的能力。它自动化了从构建到部署应用程序或产品的所有流程。
DevOps 讨论的中心是开发人员(为生计编写软件的个人)和运维人员(负责维护该软件的人员)之间的关系。
开发团队的挑战
开发人员通常充满热情,并愿意采用新的方法和技术来解决组织的问题。但是,他们确实面临挑战,例如
- 竞争激烈的市场给按时交付带来了很大压力。
- 他们必须满足生产就绪的代码管理和新功能实施。
- 发布周期很长,因此开发团队必须在应用程序部署之前做出一些假设。在这种情况下,解决生产或暂存环境中部署期间出现的问题需要更多时间。
运维团队的挑战
运维人员历来专注于 IT 服务的稳定性和可靠性。因此,运维团队关注对资源、技术或方法的更改,因为他们追求稳定性。他们的挑战包括
- 随着资源需求的增加,管理资源争用
- 处理生产环境中应用程序执行所需的重新设计或调整
- 在应用程序部署后,孤立地诊断和解决生产相关问题
DevOps 如何应对开发和运维的挑战
公司没有一次发布大量应用程序功能,而是尝试看看是否可以通过一系列发布迭代向客户推出少量功能。这有几个优点,例如更好的软件质量、来自客户的更快反馈等。反过来,这些确保了较高的客户满意度。为了实现这些目标,公司需要
- 降低新版本的失败率
- 提高部署频率
- 在新版本导致应用程序崩溃的情况下,实现更快的平均恢复时间
- 缩短修复之间的提前期
DevOps 实现了所有这些目标,并有助于实现无缝交付。组织采用 DevOps 以实现几年前甚至无法想象的性能水平。他们每天进行数十次、数百次甚至数千次部署,同时交付世界一流的可靠性、稳定性和安全性。(阅读更多关于批次大小以及对软件交付的影响。)
DevOps 试图解决由先前的方法论引起的一系列问题,包括
- 开发和运维团队孤立地工作
- 测试和部署作为设计和构建之后完成的孤立阶段,并且需要比构建周期更多的时间
- 团队成员在测试、部署和设计上花费过多时间,而不是专注于核心——创建业务服务
- 手动代码部署导致生产中的错误
- 开发和运维团队在单独的异步时间线上,这会导致额外的延迟

DevOps 与敏捷与传统 IT
DevOps 经常与其他 IT 实践一起讨论,尤其是 敏捷 和瀑布 IT。
敏捷是一套用于生产软件的原则、价值观和方法。例如,如果您有一个想要转换为软件的想法,您可以利用敏捷原则和价值观。但是该软件可能仅在开发或测试环境中有效。您需要一种以简单且安全的方式快速且可重复地将软件转移到生产环境中的方法,而这种方法是通过 DevOps 工具和技术。敏捷软件开发方法侧重于开发流程,但 DevOps 负责开发和部署——以最安全和最可靠的方式。
将传统的软件瀑布模型与 DevOps 进行比较是理解 DevOps 优势的好方法。以下示例假设应用程序计划在四周后上线,编码已完成 85%,应用程序是全新启动,并且采购用于交付代码的服务器的过程刚刚启动。
传统流程 | DevOps 流程 |
---|---|
在订购新服务器后,开发团队进行测试。运维团队根据企业的要求,处理大量文书工作以部署基础设施。 | 在订购新服务器后,开发和运维团队共同处理流程和文书工作以设置新服务器。这可以更好地了解基础设施需求。 |
关于故障转移、冗余、数据中心位置和存储要求的详细信息存在偏差,因为没有来自对应用程序有深入了解的开发团队的输入。 | 由于来自开发团队的输入,关于故障转移、冗余、灾难恢复、数据中心位置和存储要求的详细信息是已知且正确的。 |
运维团队不了解开发团队的进度。运维团队根据他们的理解制定监控计划。 | 运维团队完全了解开发团队正在取得的进展。运维团队与开发团队互动,他们共同制定满足 IT 和业务需求的监控计划。他们还利用应用程序性能监控 (APM) 工具。 |
在上线之前,负载测试使应用程序崩溃,从而延迟了发布。 | 在上线之前,负载测试使应用程序变慢。开发团队迅速修复了瓶颈,应用程序按时发布。 |
DevOps 生命周期
DevOps 包括采用某些常用实践。
持续计划
持续计划利用精益原则,以便通过识别测试业务价值或愿景所需的资源和结果、持续适应、衡量进度、从客户需求中学习、根据需要灵活地调整方向以及更新业务计划来从小处着手。
协作式开发
协作式开发流程使分布在不同时区的业务、开发和测试团队能够协作,以持续交付高质量的软件。这包括多平台开发、对多语言编程的支持、用户故事的创建、想法的详细阐述和生命周期管理。协作式开发包括持续集成的流程和实践,这促进了频繁的代码集成和自动构建。通过频繁地集成应用程序代码,可以在生命周期的早期(当问题更容易修复时)识别集成问题,并通过持续反馈减少总体集成工作,因为项目显示出持续且可证明的进展。
持续测试
持续测试降低了测试成本,同时帮助开发团队平衡速度和质量。它还通过虚拟化服务消除了测试瓶颈,并简化了虚拟化测试环境的创建,这些环境可以轻松共享、部署和更新,随着系统的变化而变化。这些功能降低了配置和维护测试环境的成本,并通过允许在生命周期的早期进行集成测试来缩短测试周期时间。
持续发布和部署
此采用路径需要一项主要实践:持续发布和部署。持续发布和部署提供了一个持续交付管道,可以自动化关键流程。它通过启用一键式部署来减少手动流程的数量、资源的等待时间和返工量,从而确保更高的发布数量、减少的错误和端到端的透明度。
自动化在确保软件以可重复和可靠的方式发布方面发挥着关键作用。一个关键目标是将构建、回归、部署和基础设施配置等手动流程自动化。这需要源代码的版本控制;测试和部署脚本;基础设施和应用程序配置数据;以及应用程序依赖的库和软件包。查询所有环境状态的能力是另一个重要因素。
持续监控
持续监控确保企业级报告功能,帮助开发团队了解生产环境中应用程序的可用性和性能,甚至在将应用程序部署到生产环境之前。持续监控提供的早期反馈对于降低错误成本和将项目引导到正确的方向至关重要。这种做法通常 包括可观察性工具,这些工具倾向于公开与应用程序性能相关的指标。
持续反馈和优化
持续反馈和优化为分析客户旅程和查明痛点提供了可视化证据。可以为生产前和生产后阶段启用反馈,以最大限度地提高价值并确保更成功地完成交易。这可以立即了解影响行为和影响业务的客户困境的根本原因。

DevOps 的优势
DevOps 可以促进协作环境,使开发人员和运维人员作为一个团队朝着共同的目标努力。此过程中的一个重要里程碑是持续集成和持续交付 (CI/CD) 的实施。这使团队能够以更少的错误更快地向市场发布软件。
DevOps 的重要优势是
- 可预测性:DevOps 为新版本提供了显著降低的失败率。
- 可维护性:它使在新版本崩溃或禁用应用程序时能够轻松恢复。
- 可重复性:对构建或代码进行版本控制使早期版本能够根据需要恢复。
- 更高的质量:结合基础设施问题提高了应用程序开发质量。
- 上市时间:简化的软件交付将上市时间缩短了 50%。
- 降低风险:将安全性纳入软件生命周期可以减少整个生命周期的缺陷。
- 成本效率:提高软件开发中的成本效率会让高级管理层感到高兴。
- 弹性:软件系统更稳定、更安全,并且更改是可审计的。
- 将较大的代码库分解为可管理的部分:DevOps 基于敏捷编程方法,该方法支持将较大的代码库分解为更小、更易于管理的块。
DevOps 原则
DevOps 的采用产生了几个已经发展(并且仍在发展)的原则。大多数解决方案提供商都开发了自己的变体。所有这些原则都采用了 DevOps 的整体方法,各种规模的组织都可以采用它们。
针对类似生产环境进行开发和测试
目标是允许开发和质量保证 (QA) 团队针对行为类似于生产系统的系统进行开发和测试,以便他们可以在应用程序准备好部署之前很好地了解应用程序的行为和性能。
应用程序应尽早地在生命周期中暴露于类似生产的系统,以解决三个主要的潜在问题。首先,这允许在接近实际环境的环境中测试应用程序。其次,它允许预先测试和验证应用程序交付流程。第三,它使运维团队能够在生命周期的早期验证他们的环境在部署应用程序时的行为方式,从而使他们能够创建微调的、应用程序感知的环境。
使用可重复、可靠的流程进行部署
此原则允许开发和运维团队在整个生命周期中支持敏捷软件开发流程。自动化对于创建迭代、可靠和可重复的流程至关重要。因此,组织必须创建一个交付管道,以实现持续的、自动化的部署和测试。频繁部署还允许团队测试部署流程,从而降低实际发布期间部署失败的风险。
监控和验证运维质量
组织擅长监控生产中的应用程序,因为他们拥有可以实时捕获指标和关键绩效指标 (KPI) 的工具。此原则将监控提前到生命周期的早期,确保自动化测试监控应用程序的功能和非功能属性。每当测试和部署应用程序时,都应捕获和分析质量指标。监控工具提供关于环境中可能在生产中发生的运维和质量问题的早期警告。这些指标应以所有业务利益相关者都能理解和表达的格式收集。
放大反馈循环
DevOps 流程的一个目标是使组织能够更快地做出反应和进行更改。在软件交付中,此目标要求组织获得早期反馈,然后从其采取的每个行动中快速学习。此原则要求组织创建沟通渠道,使利益相关者能够访问反馈并根据反馈采取行动。开发可以通过调整其项目计划或优先级来采取行动。生产可以通过增强生产环境来采取行动。
DevOps 工具速查表
# | 域 | 生命周期 | 流行的开源 DevOps 工具 |
---|---|---|---|
1 | 开发 | 计划 | Kanboard、Wekan 和其他 Trello 的替代方案;GitLab、Tuleap、Redmine 和其他 JIRA 的替代方案;Mattermost、Roit.im、IRC 和其他 Slack 的替代方案 |
2 | 代码 | Git、 Gerrit、Bugzilla; Jenkins 和其他开源 CI/CD 工具 | |
3 | 构建 | Apache Maven、Gradle、Apache Ant、Packer | |
4 | 测试 | JUnit、Cucumber、Selenium、Apache JMeter | |
5 | 运维 | 发布 | Kubernetes、Nomad、 Jenkins、Zuul、Spinnaker、 Ansible、Apache ZooKeeper、etcd、Netflix Archaius、Terraform |
6 | 部署 | ||
7 | 运行* | ||
8 | 监控 | Grafana、Prometheus、Nagios、InfluxDB、Fluentd 以及 本指南 中涵盖的其他工具 |
* 运行最好编号为运维团队的最后一步,但其工具与发布和部署生命周期阶段重叠。为了便于阅读而移动了它。
结论
DevOps 是一种日益流行的方法,旨在将开发人员和运维人员连接成一个有凝聚力的单元。它与传统的 IT 运维截然不同,并且补充了敏捷(但与敏捷不同)。
您是否认为您的 IT 部门是 DevOps 采用者?请在评论中讲述您的故事。
本文改编自 DevOps 工具和框架:您需要了解的一切。经许可重新发布。
3 条评论