关于开发人员是如何因构造其日常工作而导致生产力下降的文章很多。常见的一个例子是：在一天中安排了很多非必要的会议，因此没人能进入深度聚焦模式。今天，我想研究开发人员生产力方面的最大杀手：配置和设置DevOps工作流程的方式。在几乎所有情况下，我都遇到了一些捷径可以帮助您避免大多数问题。
＃1：无需适当工具即可全面投入微服务
当项目以整体设置中工作时，所有的工作都可以进行。工具链已准备好很好地处理这一个整体，但是，要更改一件小部分，需要部署整个整体。需要运行端到端测试，以验证一切仍然正常。整体越大，效率越低。因此，团队继续前进并采用微服务。他们的初次经验很棒，同事们可以独立进行单独的服务，部署频率提高，每个人都很高兴。
问题开始于团队不使用微服务，而对“微”则过于重视。从工具的角度来看，您现在将不得不处理更多的yml文件，docker文件，以及这些服务的变量之间的依赖关系，路由问题等。它们需要更新和维护。您的CI/CD设置，组织结构以及人员总数可能需要重新调整。
如果出于任何原因而进入微服务，请确保计划足够的时间来重组工具设置和工作流程。只需计算您需要维护的各个位置的脚本数量即可。考虑一下这将花费多长时间，由谁负责，以及哪些工具可以帮助您控制这一情况。如果选择工具，请确保他们拥有一个用户社区。
2：未将配置外部化的容器
在很多情况下，容器化都是一项了不起的技术。但是，它带有价值标签，可能会影响您的生产率。从安全角度以及通过必要的配置和环境管理等方面来看，容器会增加开销。如果您不同意团队的某些约定，那么容器也会损害您的生产力和开发人员的经验。
我看到的最常见的错误是：将配置文件或环境变量构建到容器中。容器化的核心思想是可移植性。通过硬编码配置，您将必须开始为每个单个环境编写文件和管道。您要更改URL吗？很好，请继续在20个不同的地方进行更改，然后重新构建所有内容。
在开始大规模使用和在生产环境中使用容器之前，请先坐下并同意对您重要的配置约定。确保在代码审查和回顾中始终如一地介绍这一点。重构这种先验是一种痛苦。
3：错误地采用KUBERNETES
所有人都对这个名为Kubernetes的开源项目大肆宣传。但是，Kubernetes很难保持运行，也很难集成到您的开发人员流程中，同时又要保持较高的生产率和经验。很多事情都会出错：
Kubernetes最坏的情况： XY同事真的很想弄脏他的手，并在线找到了入门指南。他们在裸机上建立了一个集群，它与该测试应用程序一起很好地工作。然后，他们开始迁移第一个应用程序，并要求其同事开始使用kubectl与集群进行交互。现在，团队的一半专注于学习这项新技术。现在，正在维护集群的可怜人将在第二个生产工作负荷达到第一的时候全职工作。CI/CD的设置完全没有做好应对这些的准备，并且由于整个团队都在尝试掌握Kubernetes，因此总体生产率正在下降。
可以做些什么来防止这种情况： Kubernetes是一项很棒的技术，如果做得正确，可以帮助获得类似于PaaS的开发人员体验。毕竟，它是Borg的后代。Borg是Google构建的平台，可让其软件工程师轻松构建可大规模扩展的应用程序。因此，它是对Google内部平台的一种开源解释。
最佳做法：
- 团队尽可能不要自己建立和运行准系统群集，而应使用托管的Kubernetes服务。阅读有关托管Kubernetes集群最适合您的需求的评论。在我撰写本文时，从纯粹的技术角度来看，谷歌Kubernetes引擎（GKE）到目前为止是最好的（尽管权限架构仍然很痛苦–权限问题，谷歌？）紧随其后的是Azure Kubernetes Service（ AKS）。亚马逊的Elastic Kubernetes服务（Amazon EKS）并正在追赶。
- 使用自动化平台或持续交付API。它们使您可以在开发人员看不见的情况下在K8上运行工作负载。使所有人都暴露于整个设置的复杂性几乎为零。我知道“每个人都应该能够做所有事情”的论点，但是变革的步伐是如此之快，而且自动化管理的程度如此之高，以至于这确实没有道理。
- 如果团队真的希望开发人员自己管理Kubernetes集群，那么他们应该给他们足够的时间来真正了解架构，设计模式，kubectl等，并真正专注于此。
4：忘记做持续交付
“等等，我已经有一个配置项工具”。常见的误解是，如果有持续集成设置，则工作做得很好。您仍然缺少连续交付！许多供应商创造了“ CI/CD工具”一词，这并没有给您带来困惑，如果您拥有Jenkins，CircleCI等，则给您留下了连续交付的印象-事实并非如此。
经过精心调整的“持续交付”设置（无论是自行编写的还是“即服务”的设置），更是团队工具链中的“粘合剂”：
- 它使从源代码控制系统到CI-Pipeline，从数据库到群集以及从DNS设置到IaC的所有不同组件都可以集成到简化的便捷开发人员体验中。
- 这是一种结构，维护和管理数量不断增长的yml和配置脚本的方法。如果做得好，这将使您的开发人员可以利用CI-Pipeline构建的工件动态地启动环境，并通过预配置的数据库和已设置的一切进行全面配置。
- 它可以用作配置状态的版本控制系统，并具有可审核的记录，以记录部署在何处，以何种配置运行，并允许您来回滚动以及管理蓝/绿/金丝雀的部署。
- 通过精心设计的CD设置，可以改变开发人员的工作效率。它们使开发人员能够自助服务，减少了团队内部的依赖，同时提高了设置的可维护性。
- 使用这些做法的团队会更频繁，更快地发布，表现出总体上更高的绩效和满意度。
5：无法维持的测试自动化
没有自动化，就不可能进行有效的测试。持续交付带来了不破坏任何东西的持续责任。
您需要不断确保不要陷入倒置测试金字塔的 陷阱。为此，您需要能够在开发生命周期的正确点运行正确的测试。
足够的CI工具将帮助您将单元和集成测试放在正确的位置，而带有配置管理和环境管理的CD工具将帮助您以可靠的方式运行自动化的端到端测试。
做得好的设置允许开发人员或测试人员动态启动预配置的环境。严格外部化您的配置，并确保具有在部署时注入这些变量的配置管理。这带来了许多积极的改进：
- 在正确的时间运行正确的测试，同时向开发团队提供有效的反馈
- 开发人员可以获得自主权，您可以减少关键人物的依赖性，
- 质量检查人员现在可以通过功能环境测试子集，
- 质量检查人员可以并行化测试，这样可以节省时间，同时可以对数据的子集进行测试。
6：自己管理数据库
刚刚离开的队友负责为客户项目设置MongoDB，并且当然使用开源项目自己运行它。当然，切换是“完美无缺”的，当然，数据库也没有得到适当的保护，有一天晚上，它显示了数据应该位于的位置：
而且当然：您检查备份。发生语法错误。现在，您必须对所有数据进行反向工程。这是一个经常发生的真实示例。
自我管理的数据库有操作和安全风险。它们使人分心，无聊且不必要。使用Cloud SQL或其他产品并睡个好觉。我们通常会看到Aiven.io等公司提供的托管产品 。这些公司提供大多数数据库，它们可以为您在所有大型云提供商上运行它们，并且它们具有更多功能，更成熟和更复杂。而且，它们通常更便宜，并确保零锁定，同时为开发人员提供了更高的便利性，如果并驾齐驱，我将始终希望这样做。
7：无缘无故地走向多云
仅使用多云和尝试将系统设计为不可知论和可移植的之间是有区别的。后者具有许多不同的优势，例如动态环境，并且比使用多云更有意义。当然，这是有历史遗留的：有些团队一直在使用GCP，而其他部门则从AWS开始，现在就在这里。其他包括专业化。有人可能会说，GPU在GCP上比在AWS或成本原因上更有效地运行。但是要真正浮出水面，您需要足够的大小。简单的多云设置需要高度的自动化，并且需要开发人员屏蔽配置和设置任务。否则，最终会陷入脚本地狱。
作为一般规则：如果不是绝对必要，请不要进行多云。
结论
我希望这些观点能帮助您避免该领域中最大的错误。记住妮可·福斯格伦（Nicole Forsgren），杰兹·汉布尔（Jez Humble）和吉恩·金（Gene Kim）在他们的书“加速”中写道：“排名前1％的团队的发货频率是原来的 10倍”。
这是因为他们正在充分利用当今的一切。我每个月花费1个小时来查看我的个人工作流程，待办事项列表以及组织应用程序的方式。为什么？因为如果您的流程效率低下，它实际上会在数周内加起来。这些微小的事情（例如搜索您的照片应用程序）会分散您的大脑。停下来一个月度过一个下午，以确保您的生产率得到精简。这将帮助您专注于创新而不是配置，从而使团队更快乐。