DevOps 工作流程中 7 个扼杀开发人员效率的因素

关于开发人员日常工作流程的安排方式如何导致效率低下，已有大量文章论述。例如，一天中安排不必要的会议，会让每个人都无法进入深度专注状态。今天，我想探讨影响开发人员效率的最大杀手：DevOps 工作流程的配置和设置方式。在我遇到的几乎所有情况下，都存在一些可以快速见效的技巧，可以帮助你避免大多数问题。

致命陷阱一：在没有合适工具的情况下全面采用微服务

当团队采用单体架构时，一切似乎都能正常运转。工具链能够很好地处理这个单体应用，但没错，哪怕只是改动一小块，也需要重新部署整个单体应用。为了验证一切是否正常，必须运行端到端测试。单体应用越大，效率就越低。因此，团队决定采用微服务架构。他们的初体验非常棒，同事们可以独立开发各自的服务，部署频率也提高了，大家都非常满意。

当团队过度沉迷于微服务架构，并过分强调“微”这个概念时，问题就出现了。从工具的角度来看，你现在需要处理大量的 YAML 文件、Docker 文件，以及这些服务变量之间的依赖关系、路由问题等等。它们都需要维护、更新和保养。你的 CI/CD 设置、组织结构，甚至人员配置可能都需要重新调整。

无论出于何种原因，如果您决定采用微服务架构，请务必预留充足的时间来重构您的工具配置和工作流程。只需统计一下您需要维护的脚本数量即可。思考一下这项工作需要多长时间，由谁负责，以及哪些工具可以帮助您更好地管理这些脚本。如果您选择使用工具，请确保该工具拥有一个活跃的社区，并且有其他用户也将其用于微服务架构。

第二个致命缺陷：采用容器技术却没有配置外部化的计划

容器化技术在很多情况下都非常出色。然而，它也会带来一些代价，并可能影响你的工作效率。容器会增加安全性方面的开销，也需要进行必要的配置和环境管理等等。如果团队之间没有就某些规范达成一致，容器化还会损害你的工作效率和开发者体验。

我看到最常见的错误是：将配置文件或 环境变量硬编码 到容器中。 容器化的核心理念 是可移植性。如果将配置硬编码，您将不得不为每个环境编写文件和流水线。想更改 URL？没问题，那就去 20 个不同的地方更改它，然后重新构建所有内容。

在大规模生产环境中使用容器之前，团队应该坐下来共同商定哪些配置规范对你们来说至关重要。务必在代码审查和回顾会议中持续讨论这些规范。事前重构会非常麻烦。

杀手锏#3：错误地采用 Kubernetes 

所有时髦的开发者都对名为Kubernetes 的开源项目趋之若鹜 。然而，Kubernetes 难以维护，也难以集成到你的开发流程中，同时还要保持高生产力和高用户体验。很多环节都可能出错：

Kubernetes 最糟糕的情况：同事 XY 非常想亲自动手，于是在网上找到了一份入门指南。他们在裸机上搭建了一个集群，测试应用运行良好。之后，他们开始迁移第一个应用，并要求其他同事使用 kubectl来操作集群。现在，团队中有一半人都在忙着学习这项新技术。可怜的维护集群的同事，一旦第一个生产环境的工作负载上线，就得全身心投入其中。CI  /CD 系统完全没有做好应对这种情况的准备，整个团队都在努力平衡 Kubernetes 的运行，导致整体生产力下降。

如何避免这种情况：Kubernetes 是一项非常棒的技术，如果运用得当，可以帮助开发者获得类似 PaaS 的体验。毕竟，它源自 Borg——谷歌为了方便软件工程师构建大规模可扩展应用程序而开发的平台。因此，它某种程度上可以看作是谷歌内部平台的开源版本。

最佳实践：

1. 团队应尽可能避免自行搭建和运行裸机集群，而应使用托管的 Kubernetes 服务。请阅读相关评测，选择最适合您需求的托管 Kubernetes 集群。在我撰写本文时， 从纯技术角度来看， Google Kubernetes Engine (GKE) 无疑是最佳选择（尽管权限架构仍然令人头疼——Google，你们的权限问题到底是怎么回事？），Azure Kubernetes Service (AKS) 紧随其后。Amazon Elastic Kubernetes Service (Amazon EKS) 正在奋力追赶。
2. 使用 Humanitec 提供的自动化平台或持续交付 API。它们允许您在 Kubernetes 上运行工作负载，而无需开发人员的直接参与。让每个人都了解整个设置的复杂性几乎没有任何价值。我知道有人会说“每个人都应该能够做所有事情”，但变化的速度如此之快，自动化程度如此之高，这种做法真的没有意义。
3. 如果团队真的希望开发人员自己管理 Kubernetes 集群，就应该给他们足够的时间去真正理解架构、设计模式、kubectl 等，并真正专注于此。

杀手四：忘记处理持续交付 

“等等，我已经有持续集成工具了。” 很多人误以为有了持续集成架构就万事大吉了。其实你还缺少 持续交付！很多厂商把“CI/CD 工具”挂在嘴边，让你以为有了 Jenkins、CircleCI 之类的工具就万事大吉了，这更加剧了人们的困惑——事实并非如此。

无论是自行编写脚本还是采用“即服务”模式，一套完善的持续交付体系在团队工具链中扮演着更为重要的“粘合剂”角色：

• 它可以将从源代码控制系统到 CI 流水线、从数据库到集群、从 DNS 设置到 IaC 的所有不同组件集成到一个精简便捷的开发者体验中。
• 它是一种用于构建、维护和管理日益增长的 yml 文件和配置脚本的方法。如果运用得当，开发人员可以动态地启动环境，这些环境包含由 CI 流水线构建的工件，并已完成数据库配置和所有设置。
• 它可以作为配置状态的版本控制系统，对部署内容、部署位置和配置进行可审计记录，并允许您回滚以及管理蓝绿金丝雀部署。 
• 精心设计的持续交付 (CD) 方案对开发人员的生产力有着颠覆性的影响。它们使开发人员能够更高效地完成工作，减少团队内部的依赖关系，同时提高方案的可维护性。 
• 采用这些做法的团队发布产品的频率更高、速度更快，整体绩效和满意度也更高。 

致命缺陷五：测试环境有限的情况下，测试自动化难以维护

没有自动化，高效测试就无从谈起。持续交付意味着持续的责任，即避免破坏任何现有功能。
你需要不断确保不会陷入 测试金字塔倒置的陷阱。为此，你需要能够在开发生命周期的正确阶段运行正确的测试。

充足的 CI 工具可以帮助您将单元测试和集成测试放在正确的位置，而具有配置管理和环境管理功能的 CD 工具可以帮助您以可靠的方式运行自动化端到端测试。

完善的部署方案允许开发人员或测试人员动态启动预配置的环境。务必将配置完全外部化，并确保配置管理系统能够在部署时注入这些变量。这将带来诸多积极的改进：

• 在合适的时间运行合适的测试，同时向开发团队提供有效的反馈。
• 开发人员获得自主权，同时减少了对关键人员的依赖。
• QA人员现在能够通过功能环境测试子集， 
• QA 可以并行化测试，从而节省时间，同时还能对数据的子集进行测试。 

杀手锏#6：自己管理数据库

刚刚离职的同事负责为客户项目搭建 MongoDB，当然，他使用的是开源项目自行运行。交接过程“完美无瑕”，数据库也未得到妥善保护，结果一天晚上，数据本应存在的地方却出现了这样的景象：

‍

当然还有： 

你检查备份。 

存在语法错误。 

现在你需要对所有数据进行逆向工程。 

这是一个经常发生的真实案例。

自建数据库存在运维和安全风险。它们既繁琐又无用，而且完全没有必要。使用 Cloud SQL 或其他云服务，就能高枕无忧。我们经常看到像 Aiven.io这样的公司提供托管服务。这些公司提供大多数数据库，可以在所有主流云服务提供商上运行，而且功能更丰富、更成熟、更完善。此外，它们通常更便宜，确保零锁定，并为开发人员提供更高的便利性——如果这三者兼得，我总是会优先选择它们。

杀手锏#7：毫无理由地使用多云架构

多云部署和设计云无关且可移植的系统之间存在区别。后者具有诸多优势，例如动态环境，比单纯的多云部署更有意义。当然，这其中也存在历史遗留问题：一些团队一直在使用 GCP，而另一些团队则从 AWS 开始，最终形成了现在的局面。其他因素还包括专业化。有人可能会说，GPU 在 GCP 上的运行效率比在 AWS 上更高，或者出于成本考虑。但这些优势只有在系统规模足够大时才会真正显现。简单的多云部署需要高度自动化，并且需要将配置和设置任务对开发人员进行屏蔽。否则，最终只会陷入脚本编写的泥潭。

一般而言：除非绝对必要，否则不要采用多云架构。

结论

我希望这些要点能帮助你避免在这个领域犯下最大的错误。记住妮可·福斯格伦、杰兹·汉布尔和吉恩·金在他们的著作 《加速》中写道：“排名前 1% 的团队发布产品的频率是其他团队的 10 倍。”

这是因为他们充分利用了当今的各种资源。我每月花一个小时审视我的个人工作流程、待办事项清单以及应用程序的组织方式。为什么？因为如果流程效率低下，几周下来就会造成很大的浪费。像搜索照片应用程序这样的小事都会分散你的注意力。每个月抽出一个下午，确保你的工作效率得到优化。这将帮助你专注于创新而非繁琐的配置，并打造一个更快乐的团队。

如果您有任何想法、意见或建议， 请直接与我联系 。或者，您也可以注册参加我们的免费网络研讨会，与我们交流。