实施 DevOps 时要避免的十个陷阱

无论任何规模的公司，都可以通过软件来变革技术团队定义成功的具体方式，进而从中获得更大业务价值。更重要的是，通过定义自己所开发的软件如何向客户提供价值，这种做法也可用来定义自己的成功。以“拒绝”为代价的“入场券”和“稳定性”已经不再是 IT 的关键价值，现在的重点在于让开发者以更快的速度与业务形成合作关系。

为了跟上这种越来越快的节奏，领先的技术专家在开发软件时越来越重视精确度，并纷纷开始拥抱持续交付、集成、DevOps 等标准。对此，Shanhong Liu 曾经说过：“截止 2018 年，负责 Web 与移动应用程序开发和质量保障的技术专家中，仅 9% 称自己尚未采用 DevOps 并且对此完全没有任何计划。”

DevOps 文化一个最有意义的地方在于，在实现价值的旅途中可以接受失败。对于软件来说，这个旅途体现为持续交付的形式，它期待我们可以定期发布相关代码。“快节奏”不可避免会遇到失败，但同时也确保了如果遇到失败，我们可以快速从中学习并做出调整。这恰恰也是以业务形式获得成长的方式：我们可以从中获得更多见解，进而在这些见解的引导下最终实现成功。

鉴于很多已经采纳 DevOps 的人也曾犯过错误，我们当然可以从他们的经历中学习经验教训，避免自己也犯相同错误。我们可以本着 DevOps 和开源精神快速迭代，从前人的经验（和错误）中吸取教训。下文列举了 DevOps 旅途中一些最常见的错误及其解决之道。

1. 无序交付

为了加快自动化测试和反馈周期，有时候，开发者会同时进行持续交付（CD）与持续集成（CI）。作为一种实践，CI/CD 能够为软件交付的节奏带来很多好处，但风险在于，错误的代码配置很可能被直接交付到生产环境，而未能对其影响进行足够的研究，进而对自动化测试的价值产生负面影响。

我始终认为，在代码最终进入软件交付周期前，手工确认依然是必不可少的一个环节。因此必需具备一个能够在“投产前”进行部署和测试的阶段，借此开发者才能发现并解决可能存在的错误，避免直接发布到生产环境后让这些问题影响到最终用户。

在代码触及最终用户前，还必需进行必要的监视，这一点也非常重要。举例来说，需要对 CD 管道的结构进行必要调整，以便在开发的同时对代码进行测试，并确保变更不会自动部署出去。

虽然 DevOps 标准认为团队必需能扩展到“孤岛”范围之外，但部署工作始终应该由熟悉代码的人在管道的终点处负责验证。这就保证了在代码触及客户之前可以进行彻底的检查。

2. 对 DevOps 头衔的误解

一些组织会对 DevOps 的头衔产生误解。他们认为，DevOps 工程师的目标在于解决与 DevOps 有关的所有问题，而实际上 DevOps 意味着开发者和运维人员之间的合作。

DevOps 对开发和运维角色的整合方式也可能成为一种艰难的职业生涯路径。为保证能够正常运行，并且如果出现问题随时能够提供支持，开发者必需对自己的应用程序具备更深入的理解。而运维人员也必需成为应用程序缩放方面的专家，并对大规模监视和可观测性策略方面所涉及的指标有足够全面的理解。

实际上，DevOps 的目标在于帮助企业加快 IT 运维方面那些冗繁耗时任务的处理。例如，自动化测试能更快速地为开发者提供反馈，而自动化集成可以帮助开发者将更改后的代码更快速地融入代码库。DevOps 可能还需要围绕应用的收集、扩展和运行建立各种自动化流程。

组织的各种基本需求决定了 DevOps 专家的技能到底应该更侧重于运维或是开发方面，而这些情况必需与选择或雇佣 DevOps 团队的方法保持一致。举例来说，如果自动化是关键，那么就必需对软件开发和脚本编写技能划分出优先级（而没必要更强调容器方面的技能）。在雇佣人员的过程中，应该着力考虑你对 DevOps 经验的独特需求，至于完成工作所需的其他需求，完全可以让大家在工作中自行学习。只要雇佣的人具备不断学习的能力和意愿，最终就能为你的组织构建出“最强战队”。

3. 缺乏灵活性的 DevOps 流程

虽然 DevOps 原则为我们的工作奠定了基础，但每个组织都必须准备好围绕自己希望实现的成果对这个旅程进行定制和调整。企业必需确保实现 DevOps 的过程中具备妥善的核心 DevOps 支柱，但同时也需要对这些内容进行内部调整，以便更好地衡量自己所预期的成果。

为了构建技术进步所需的基础，DevOps 基本原则必不可少，尤其是 CALMS（文化、自动化、精益、测量、共享）这些支柱性原则。但 DevOps 的实施并没有“均码”的标准。只有意识到这一点，DevOps 团队才能从以往的失败中积累经验，并建立出行之有效的规划。在沿袭 DevOps 基本原则的同时，团队也需要准备好随时对自己的规划进行调整。

4. 更侧重于速度而非质量

很多企业往往更看重生产交付，但对产品质量关注不足。如果相关人员的 KPI 仅仅以投产时间为中心，这很容易导致产品质量脱离控制。由于被督促着尽可能快速地发布，这可能导致将本应用于监视性能的终结点被拖延到未来的版本中，并将尚未投产就绪的软件视作成功的结果。

身处当今快节奏变化的市场，几乎没有任何团队能够在满足客户或内部需求所要求时间的前提下交付最佳质量的产品。为了维持市场竞争优势，很多公司急于在尽可能短的时间里完成尽可能多的 DevOps 项目。也许听起来这种做法还不错，但期待着 DevOps 成为一种步调飞快的旅程，这种想法本身可能会让我们得不偿失。

在速度和质量方面同时提高，这是 DevOps 最重要的价值。但这一点并不容易实现，需要运维和开发人员用全新，并且更完善的方式来编写测试。只有妥善实现这一点，才能实现质量和速度的双丰收。

5. 构建专属 DevOps 团队

理论上，构建专属团队并全神贯注于新专家的培养，这种做法在 IT 领域很合理。DevOps 旅途全程必需是无分歧并且无缝的，对吧？但随后很快会遇到两个问题：

现有的质量保障（QA）、运维和开发团队成员觉得自己被忽视，可能会尝试着给新团队的工作制造障碍。

新团队变成了另一个孤岛，虽然可以提供新技术，但无法推动公司在 DevOps 的目标上有效前进。

更好的做法是让新人和 QA、运维、开发等团队中对 DevOps 有兴趣的原有成员共同组成一个混合团队。这样的团队对各种制度具备更全面的了解，并能对 DevOps 举措提供更宝贵的价值。

6. 忽视数据库

实施 DevOps 的过程中，数据库始终是至关重要，但被忽视的关键技术领域之一。新开发的“用后即抛”型应用程序可以用前所未有的速度经历 DevOps 的完整流程，但数据密集型应用程序在开发方面并未获得相同程度的简化。

如果缺乏有效的自动化整合机制，独立环境中创建的数据快照可能，并且终将影响数据准确性。很多专家疲于进行层出不穷的集成和代码工作，但往往会在数据库的自动化处理方面遇到障碍。数据库必需妥善管理，对于以数据为中心的应用这一点更重要。数据库在此类应用中扮演了重要角色，因此可能需要专门的技能，使其独立于其他应用程序实现自动化。

7. 事件处理流程的缺乏

一旦有什么东西出错（这一点不可避免），DevOps 团队应当具备事件处理流程。事件处理应当是一种持续不断且主动进行的流程，以一致性和避免错误为最终目标。这意味着为了制定完善的事件处理流程，我们必需记录并描述有关事件响应的要求。目前围绕 Runbook 文档和无可指责的事后检验已经有很多研究，为了最终成功，我们可以从中学习大量宝贵的经验。

8. 缺乏对 DevOps 的了解

虽然近年来 DevOps 的接受度正在飞速提高，但很多应用程序专家在工作中可能依然对质量控制流程缺乏了解。因而很多时候，我们的团队可能会缺乏成功实施 DevOps 过程中，在技术、文化、流程等领域引发改变所需的能力。

采纳 DevOps 实践，这是一种明智的举措，但这一举措若要成功，必需具备丰富的经验和准备。某些情况下，结合自己的独特需求提供所需经验，这往往需要雇佣外部专家（声明：我本人就管理着一家 DevOps 咨询公司）。这些训练有素的专家应当在所需技术方面具备认证，并且公司还必需避免在实现切实成果的前提下快速做出与 DevOps 有关的决策。

9. 忽视安全性

安全性和 DevOps 应该是共进关系。DevOps 旅程本身就很难，因而很多组织会忽略安全指南，因为这些指南实施起来更难。但这会导致很多问题，例如一开始确实从开发者身上获得了最大化的成果，但随后却又发现开发者忽略了应用程序的安全保护。安全性必需认真对待，建议研究一下 DevSecOps，看看它是否更适合你的组织。

10. 疲于实现的 DevOps

如果建立 DevOps 团队的初衷是从原本一年发布一个产品的节奏变为每周推送 10 次，那么你的举措很可能最终会失败。随意挑选一些放在 PPT 中看起来可能不错的指标，这样的做法并不能对团队产生任何激励作用。DevOps 并不是一种简单的技术活动，而是一种与文化有关的重大革新。

企业规模越大，实现 DevOps 实践所需的时间就越长。我们应当用可测量的方法，分批分阶段应用 DevOps 方法论，并以切实获得的成果作为值得为之庆祝的里程碑。员工需要培训，第一轮应用开发工作进行之前也需要安排足够的休整。你的第一个 DevOps 管道实现起来可能会显得非常慢，但这才是现实世界里的持续改善应有的样子。

为了在竞争中维持优势，很多企业正在快速采纳 DevOps，但他们的实施过程中经常会犯一些共同的错误。为了避免遇到常见陷阱，只有经过精确规划并应用最适合的策略才能实现更成功的 DevOps 成果。

本文最初发布于 OpenSource.com ，原作者 Mehul Rajput。