什么是DevOps？ | DevOps完整指南（附示例）

什么是DevOps？为什么它被如此广泛地应用？

亚马逊、塔吉特、Etsy、Netflix、谷歌和沃尔玛这些公司有什么共同点？除了它们都是非常成功的公司之外，它们都在日常运营中使用一种名为DevOps的方法，以提高效率并缩短交付时间。在本DevOps指南中，我们将尝试解释什么是DevOps，以及它如何为您的业务带来益处。

什么是DevOps？为什么它被如此广泛地应用？

那么，DevOps究竟是什么呢？我们举个简单的例子来说明。假设有一家小型创业公司，专门生产人工智能清洁机器人。公司有3名开发人员（为了方便起见，我们姑且称他们为D团队），负责编写和执行代码来创建机器人；还有2名运维人员（当然是O团队），负责在实际环境中维护机器人基础设施，并为机器人用户提供支持。

D团队耗时8个月打造了最新款机器人。它能识别人物，接收Alexa设备的指令，当然还能高效地完成清洁工作。D团队在他们可控的开发环境中精心打造了这款机器人，目前一切运行正常。他们为此感到无比自豪。

他们将成果交给Team O，Team O随即把它推向现实世界。问题也随之而来。事实证明，这款完美的清洁机器人并非完美无缺。它无法识别所有人，对不同用户的Alexa指令反应不灵敏，而且无法清洁难以触及的架子。

O队既愤怒又沮丧。他们等这台机器人等了这么久，却没想到它竟然是一场彻头彻尾的灾难。而D队则转入了防守。他们认为在受控的测试条件下一切都运行完美，如今的惨状一定是O队执行不力造成的。

总之，市场上出现了一款不尽如人意的产品，现在看来，纠正和改进所需的时间几乎与产品推出时一样长，而且两个非常有能力的团队现在彼此厌恶，对自己的工作也感到厌倦。

简而言之，这就是DevOps诞生的原因，也是为什么2016年超过70%的中小企业在其公司中采用DevOps服务的原因。如果D团队和O团队从概念构思、执行到交付和支持阶段就能够通力合作，许多痛苦、挫败感和效率低下的问题本可以避免。然而，他们却各自为政，中间隔着一道无形的墙。

O团队在代码编写和机器人实际制造阶段完全没有参与，而D团队在机器人投入实际使用、清洁多户房屋时也完全置身事外。结果是，机器人未能达到上市标准，而开发团队至今仍不清楚如何解决问题。

可想而知，机器人最终上市还需要很长时间。D团队会不断修改，O团队也会将机器人送入实际环境进行测试，整个过程会经历多次迭代。而且，这个问题不仅存在于产品开发阶段，在机器人需要维护和升级时也会持续存在。因此，即使是小型初创公司最终也会变得效率低下、进展缓慢，很有可能因为其他公司能更快地将更优质的产品推向市场而败北。

随着技术的发展，企业开始逐渐意识到这个问题。运营团队和开发团队彼此隔离，导致交付速度变慢，产品和服务效率降低。此外，公司运营中许多原本可以轻松自动化以提高效率的流程，却因为开发人员对此毫不知情而未能实现自动化。

正是在那时，DevOps的概念开始兴起并被广泛采用。DevOps本质上是一套理念、实践和工具，它通过促进开发和运维职能的整合，帮助组织更快地交付更优质的产品。这使得像我们示例中的公司这样的企业能够更好地服务于客户和市场，并获得竞争优势。

这涵盖了从设计到整个开发过程，直至生产支持的整个流程。

DevOps是如何演变的？

DevOps 如今已走过了 10 个年头。与大多数具有实际应用价值的理念和工具一样，DevOps 也经历了从一堆杂乱无章的想法和原则发展成为拥有自身流程和工具的成熟学科的历程。

早在2007年，一位名叫帕特里克·德布瓦的项目经理就曾与比利时政府合作，协助进行数据中心迁移。他发现整个过程极其令人沮丧，因为开发人员和运维团队之间存在沟通障碍，这使得他的工作更加困难，交付速度也大大降低。

德布瓦非常推崇敏捷方法论，该方法论提倡在整个开发生命周期中持续迭代开发和测试，从而帮助开发团队更快地交付更优质的产品。他认为，类似的原则也应该适用于协同工作的开发团队和运维团队。

2008年，安德鲁·谢弗（后来成为知名的DevOps布道者）和德布瓦在一次会议上相遇，讨论了他们当时称之为“敏捷系统管理”的初步想法和原则。他们还在谷歌上创建了一个敏捷管理员小组，这便是DevOps的真正起源。

DevOps 发展史上的另一个里程碑事件是 Flickr 员工 John Allspaw（时任技术运营副总裁）和 Paul Hammond（时任工程总监）在 2009 年 O'Reilly Velocity 大会上发表的著名演讲。Hammond 和 Allspaw 通过一段既幽默又深刻的角色扮演，生动地说明了由于开发和运维之间存在壁垒，公司遭受了巨大的业务损失，而唯一的出路就是将两者无缝整合。

这次演讲被誉为DevOps的“决定性时刻”，因为科技界迅速意识到这种整合的必要性。这次演讲启发了Debois在比利时组织了一场名为Devopsdays的DevOps大会，而剩下的故事，正如人们常说的，就成了历史。

DevOps发展历程中的另一个重要时刻是美国首届DevOps大会。该大会于2010年在加州山景城举行，这里被誉为科技圣地。这标志着DevOps的到来，并将持续发展。事实上，到2018年，全球已举办了超过30场DevOps大会。

使用 DevOps对组织有哪些好处？

DevOps之所以能如此迅速地被广泛采用，是因为它从根本上改变了科技公司的运营方式。让我们来看看公司采用DevOps方法后能获得哪些好处。

加速创新

这就是DevOps诞生的主要原因。采用DevOps可以让公司更快地开发和部署产品。正如我们在之前的例子中所看到的，当开发和运维之间存在壁垒时，周期时间会显著延长。相反，当两者集成时，变更集会更小，每次需要解决的问题也更简单。此外，团队成员可以轻松地进行软件变更，因为他们只需要查看最新添加的代码，而无需查看全部代码。微服务和持续交付等技术使团队能够完全掌控项目，并更快地交付成果。

合作

正如我们的例子所示，开发和运维之间人为设置的壁垒往往会导致两个团队互不信任，各自为政。这会对团队士气和工作积极性产生长期影响。DevOps 方法则能促进两个团队之间的协作，让他们怀着共同的热情去实现共同目标。这创造了一个更加积极的工作环境，能够更快、更高效地达成目标。此外，它还能带来其他积极成果，例如更高的员工满意度和更低的员工流失率。

可靠性

在 DevOps 出现之前，更新应用程序以满足不断变化的用户需求简直是一场噩梦。每次更新都存在着降低用户所需质量的风险。
而借助持续集成和持续交付等 DevOps 工具，现在可以轻松测试软件功能，同时兼顾安全性和质量。监控和日志记录等其他流程有助于跟踪实时性能指标，从而维护软件的可靠性。

安全

如果没有 DevOps，您往往需要在速度和安全性之间做出权衡，这会导致交付时间大幅延长。而借助 DevOps，您可以利用自动化合规策略、细粒度控制和配置管理技术，在不牺牲安全性的前提下保持速度。

可扩展性

随着谷歌、亚马逊和 YouTube 等公司发现，在开发和运维之间设置壁垒导致大规模技术管理难度加大，DevOps 的重要性日益凸显。DevOps 带来的自动化和一致性，能够帮助企业更高效地管理和变更复杂系统。

有效DevOps的一些最佳实践有哪些？

虽然 DevOps 对不同的人来说仍然意味着不同的东西，但已经出现了一些最佳实践的核心，希望采用 DevOps 的公司应该将这些实践纳入其中。

• 积极的利益相关者参与

这是DevOps的基本指导原则。只有当开发人员、运维人员和支持人员都真正致力于协作并采用集成方法来实现目标时，DevOps才能成功。

• 自动化测试

自动化回归测试是敏捷团队经常采用的工具，因为它有助于立即解决问题并交付更高质量的代码。这在DevOps中也同样适用，因为运维人员的迫切需求之一就是确保交付的代码符合一定的质量标准。

• 集成配置管理

在 DevOps 环境中，配置管理不仅适用于当前正在开发的解决方案，还适用于该解决方案与组织其他基础架构之间的配置问题。集成配置管理有助于运维团队更清晰地了解新版本发布的潜在影响，从而更好地决定何时发布。

• 整合变革管理

通过整合变革管理，运营和开发团队共同努力，了解使用不同技术将如何影响整个组织，然后努力管理这些影响。

• 持续集成

通过持续集成，每次将更新的代码提交到版本控制系统时，都会对代码进行测试和分析。这可以立即反馈代码缺陷，使开发人员能够以较低的风险构建高质量的解决方案。

• 综合部署计划

DevOps 方法意味着运维工程师将与开发人员紧密合作，根据组织部署计划来规划产品的部署。

• 持续部署

在持续部署模式下，当一个沙箱中的集成成功后，它会自动提升到下一个沙箱，并在下一个沙箱中继续集成。这个过程会一直持续到需要人工验证为止。这通常发生在从开发环境过渡到运维环境的时候。

• 生产支持

在DevOps模式下，开发人员不仅负责新版本的开发，还会参与解决已上线生产环境中的关键问题。虽然他们是最后也是第三个参与解决生产问题的团队，但这相当普遍，并且能让他们深入了解生产环境中的问题，从而从一开始就设计出更好的解决方案。

• 应用监控

这指的是在生产环境中对解决方案进行实时监控和日志记录的做法。这使我们能够获得性能指标，从而提高解决方案的可靠性并防止故障发生。

• 自动化仪表盘

DevOps 使我们能够为多个关键指标创建自动化仪表盘。当然，并非所有指标都能实现自动化，但借助自动化仪表盘，我们可以实时查看多个关键指标，从而获得重要的商业情报。

DevOps 工具有哪些？

为了实施上述DevOps最佳实践，一些工具应运而生，旨在自动化和简化不同的DevOps流程。虽然合适的工具在有效实施DevOps中发挥着关键作用，但仅仅使用这些工具并不意味着DevOps的真正应用。工具只有在作为最后阶段使用时才有意义——即在组织已经接受DevOps理念并致力于执行其最佳实践之后。

尽管DevOps最初并非着眼于工具，但随着近几年的发展，许多最初概念之外的技术如今已成为DevOps不可或缺的一部分。据市场研究公司Gartner称，如果DevOps想要实现其预期的变革，构建一个相互关联的技术工具链至关重要。近年来，针对不同DevOps实践的DevOps工具呈爆炸式增长。以下仅列举几个例子。

发布工具

• 詹金斯
• 特拉维斯
• TeamCity
• 竹子

配置管理工具

• 木偶
• 厨师
• Ansible
• Cfengine
• Saltstack

编排工具

• 动物园管理员
• 诺亚
• 中部

监控、虚拟化和容器化工具

• AWS
• OpenStack
• 流浪汉
• Docker
• 新遗物
• 森苏
• 胆量
• 纳吉奥斯

编码工具

• 吉拉
• Git
• 蚀

测试工具

• JUnit
• 和风
• 硒
• 流浪汉
• SoapUI

有效采用DevOps的关键

在组织范围内全面推行DevOps并非易事，因为它需要理念和文化上的变革，以及工具和最佳实践的切实应用。如果一个组织仅仅追求DevOps背后的协作和效率理念，而不付诸实践，那么DevOps就永远停留在理念层面，而无法真正落地。

同时，仅仅采用 DevOps 实践和工具，而没有将 DevOps 的理念和文化渗透到整个组织，也是徒劳的。在组织内成功实施 DevOps 的起点应该是让开发和运维团队完全认同并致力于此。只有在他们完全接受 DevOps 之后，最佳实践和 DevOps 工具才能真正发挥作用。

原文发表于Cuelogic 博客